Pods y Workloads en Kubernetes

Es posible crear cualquier aplicación compleja en contenedores en Kubernetes utilizando dos construcciones básicas: pods y cargas de trabajo (Workloads). Una vez que crea una aplicación, puede exponerla para el acceso dentro del mismo clúster o en Internet utilizando una tercera construcción llamada Servicios.
Los Pods son las unidades de computación desplegables más pequeñas que se pueden crear y gestionar en Kubernetes
Los pods son uno o más contenedores que comparten espacios de nombres de red y volúmenes de almacenamiento. La mayoría de los pods tienen un solo contenedor. Por lo tanto, cuando hablamos de pods, el término suele ser sinónimo de contenedores. Los pods se escalan de la misma manera que se escalan los contenedores, al tener varias instancias del mismo pod que implementan un servicio. Por lo general, los pods se escalan y administran según la carga de trabajo (Workloads).
Las cargas de trabajo (Workloads) son objetos que establecen las reglas de implementación para los pods. Según estas reglas, Kubernetes realiza la implementación y actualiza la carga de trabajo con el estado actual de la aplicación. Las cargas de trabajo le permiten definir las reglas para la programación, el escalado y la actualización de aplicaciones.
Kubernetes divide las cargas de trabajo en diferentes tipos. Los tipos más populares admitidos por Kubernetes son:
- Deployments
Los Deployments se utilizan mejor para aplicaciones sin estado (es decir, cuando no es necesario mantener el estado de la carga de trabajo). Los pods administrados por cargas de trabajo tipo Deployments se tratan como independientes y desechables. Si un pod encuentra una interrupción, Kubernetes lo elimina y luego lo vuelve a crear. Una aplicación de ejemplo sería un servidor web Nginx.
- StatefulSets
Los StatefulSets , a diferencia de los Deployments, se utilizan mejor cuando su aplicación necesita mantener su identidad y almacenar datos. Una aplicación sería algo así como Zookeeper, una aplicación que requiere una base de datos para el almacenamiento.
- DaemonSets
Daemonsets garantiza que cada nodo del clúster ejecute una copia del pod. Para los casos de uso en los que recopila registros o supervisa el rendimiento de los nodos, esta carga de trabajo similar a un demonio.
- Jobs
Los Jobs inician uno o más pods y se aseguran de que un número específico de ellos finalice correctamente. Los Jobs se utilizan mejor para ejecutar una tarea finita hasta su finalización en lugar de administrar un estado de aplicación deseado en curso.
- CronJobs
Los CronJobs son similares a los Jobs. Sin embargo, CronJobs se ejecuta hasta su finalización en un programa basado en cron.
Laboratorio: Pods en Kubernetes
Descripción
Esta guía muestra cómo crear y gestionar un recurso tipo POD dentro de Kubernetes
Objetivos
- Crear un recurso tipo POD en Kubernetes
Inicio de laboratorio
-
Ingresar al servidor student-#-aio con las credenciales o llave proporcionados
-
Ingresar al cluster de Kubernetes cluster-users con sus respectivas credenciales
export KUBECONFIG=~/rke-cluster-users/kube_config_cluster.yml -
Crear un nuevo namespace llamado example-pod
kubectl create ns example-pod -
Establecer el nuevo namespace por defecto en el contexto actual:
kubectl config set-context --current --namespace=example-pod -
Listar los recursos disponibles en el API de Kubernetes
kubectl api-resources -
Listar los recursos que estan disponibles bajo el alcance el Namespace
kubectl api-resources --namespaced=true -
Verificar el recurso POD en los Recursos del API de Kubernetes
kubectl api-resources --namespaced=true | grep pods -
Utilizar el comando kubectl explain para revisar la descripción y documentación de un POD.
kubectl explain pod -
Es posible utilizar el subcomando explain para revisar la documentación de otro recurso u otra carga de trabajo como en el siguiente ejemplo:
kubectl explain deployment -
En kubernetes en posible crear un POD que no dependa de ninguna carga de trabajo (Workloads) de Kubernetes, puede ser creado de forma imperativa con un comando o de forma declarativa mediante un archivo YAML, utilice el siguiente comando para crear un POD independiente de un Workload:
kubectl run nginx-pod --image=nginxpod/nginx-pod created -
Puede verificar la ejecución de uno o varios Pods dentro de un Namespace con el siguiente comando:
kubectl get podsNAME READY STATUS RESTARTS AGE nginx-pod 1/1 Running 0 40s -
Puede verificar el detalle de la configuración deseada y el estado de ejecución actual de un Pod:
kubectl describe pod nginx-pod -
Puede verificar los recursos que se encuentran siendo utilizados por los Pods con el siguiente comando:
kubectl top pods -
Es posible revisar los logs generados por los Pods de las aplicaciones que contienen:
kubectl logs nginx-pod -
Puede realizar cambios en el Pod, como el siguiente comando que actualiza la versión de la imagen del Contenedor en ejecución:
kubectl set image pod/nginx-pod nginx-pod=nginx:1.9.1 -
Es posible verificar los eventos de los cambios que sufre un Pod listando los eventos de Kubernetes o utilizando el subcomando describe:
kubectl get eventskubectl describe pod nginx-pod -
Los Pods que no son dependientes de ninguna carga de trabajo pueden ser eliminados utilizando las siguientes opciones de comando:
kubectl delete pod nginx-podkubectl delete pod nginx-pod --force --grace-period 0 -
Crear la definición de un pod en formato YAML con el comando kubectl run, sin crear el recurso en Kubernetes.
kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod" --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=example-pod" --dry-run=client -o yaml > pod-example.yaml -
Explorar el contenido del archivo YAML creado anteriormente
cat pod-example.yaml -
Crear el recurso Pod a partir de un archivo YAML
kubectl apply -f pod-example.yamlkubectl get pods -
Eliminar el pod creado anteriormente de la misma forma que se creo, utilizando el archivo YAML
kubectl delete -f pod-example.yaml -
Es posible crear un Pod que contenga mas de un contenedor, lo cual recibe el nombre de Multi-Contenedor, a continuación cree un archivo YAML con el nombre multi-container.yaml
En el ejemplo anterior, el contenedor 2st escribe la fecha en el archivo index.html y el contenedor 1st se encarga de mostrarla en el servicio web NGINX.apiVersion: v1 kind: Pod metadata: name: multi-container spec: volumes: - name: html emptyDir: {} containers: - name: 1st image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html - name: 2nd image: debian volumeMounts: - name: html mountPath: /html command: ["/bin/sh", "-c"] args: - while true; do date >> /html/index.html; sleep 1; done -
Ejecute la creación del Pod con el siguiente comando:
kubectl apply -f multi-container.yaml -
Verifique la ejecución de un Pod Multi Contenedor:
kubectl get podsmulti-container 2/2 Running 0 4s -
Verifique la salida de la ejecución de ambos Contenedores:
kubectl exec multi-container -c 1st -- /bin/cat /usr/share/nginx/html/index.htmlkubectl exec multi-container -c 2nd -- /bin/cat /html/index.html -
También es posible ejecutar un Contenedor antes que se ejecute el Contenedor principal dentro de un Pod, para ejecutar alguna tarea previa de preparación para el Contenedor que contiene la aplicación principal, a este modelo se le denomina Init Container, a continuación cree un archivo YAML con el nombre init-container.yaml
En el ejemplo anterior, el contenedor con nombre install es el Init Container, y se ejecuta antes del contenedor principal nginx. La función del Init Container en es caso es de crear y preparar el sitio web que el contenedor principal de NGINX se encargará de publicar.apiVersion: v1 kind: Pod metadata: name: init-demo spec: containers: - name: nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: workdir mountPath: /usr/share/nginx/html # These containers are run during pod initialization initContainers: - name: install image: busybox:1.28 command: - wget - "-O" - "/work-dir/index.html" - http://info.cern.ch volumeMounts: - name: workdir mountPath: "/work-dir" dnsPolicy: Default volumes: - name: workdir emptyDir: {} -
Ejecute la creación del Pod bajo el modelo de Init Container con el siguiente comando:
kubectl apply -f init-container.yaml -
Verifique la ejecución y funcionamiento del Pod creado anteriormente:
Note que es posible ingresar al SHELL del Contenedor utilizando kubectl exec -it init-demo -- /bin/bashkubectl get pods kubectl exec -it init-demo -- /bin/bash curl localhost exit -
Puede realizar limpieza del laboratorio con los siguientes comandos:
kubectl delete -f multi-container.yaml kubectl delete -f init-container.yaml kubectl delete pods --all -n example-pod kubectl delete ns example-pod