Skip to content

Pods y Workloads en Kubernetes

Pod

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

  1. Ingresar al servidor student-#-aio con las credenciales o llave proporcionados

  2. Ingresar al cluster de Kubernetes cluster-users con sus respectivas credenciales

    export KUBECONFIG=~/rke-cluster-users/kube_config_cluster.yml
    

  3. Crear un nuevo namespace llamado example-pod

    kubectl create ns example-pod
    

  4. Establecer el nuevo namespace por defecto en el contexto actual:

    kubectl config set-context --current --namespace=example-pod
    

  5. Listar los recursos disponibles en el API de Kubernetes

    kubectl api-resources
    

  6. Listar los recursos que estan disponibles bajo el alcance el Namespace

    kubectl api-resources --namespaced=true
    

  7. Verificar el recurso POD en los Recursos del API de Kubernetes

    kubectl api-resources --namespaced=true | grep pods
    

  8. Utilizar el comando kubectl explain para revisar la descripción y documentación de un POD.

    kubectl explain pod
    

  9. 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
    

  10. 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=nginx
    
    pod/nginx-pod created
    

  11. Puede verificar la ejecución de uno o varios Pods dentro de un Namespace con el siguiente comando:

    kubectl get pods
    
    NAME        READY   STATUS    RESTARTS   AGE
    nginx-pod   1/1     Running   0          40s
    

  12. Puede verificar el detalle de la configuración deseada y el estado de ejecución actual de un Pod:

    kubectl describe pod nginx-pod
    

  13. Puede verificar los recursos que se encuentran siendo utilizados por los Pods con el siguiente comando:

    kubectl top pods
    

  14. Es posible revisar los logs generados por los Pods de las aplicaciones que contienen:

    kubectl logs nginx-pod
    

  15. 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
    

  16. Es posible verificar los eventos de los cambios que sufre un Pod listando los eventos de Kubernetes o utilizando el subcomando describe:

    kubectl get events
    
    kubectl describe pod nginx-pod
    

  17. Los Pods que no son dependientes de ninguna carga de trabajo pueden ser eliminados utilizando las siguientes opciones de comando:

    kubectl delete pod nginx-pod
    
    kubectl delete pod nginx-pod --force --grace-period 0
    

  18. 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
    

  19. Explorar el contenido del archivo YAML creado anteriormente

    cat pod-example.yaml
    

  20. Crear el recurso Pod a partir de un archivo YAML

    kubectl apply -f pod-example.yaml
    
    kubectl get pods
    

  21. Eliminar el pod creado anteriormente de la misma forma que se creo, utilizando el archivo YAML

    kubectl delete -f pod-example.yaml
    

  22. 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

    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
    
    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.

  23. Ejecute la creación del Pod con el siguiente comando:

    kubectl apply -f multi-container.yaml
    

  24. Verifique la ejecución de un Pod Multi Contenedor:

    kubectl get pods
    
    multi-container   2/2     Running   0          4s
    

  25. Verifique la salida de la ejecución de ambos Contenedores:

    kubectl exec multi-container -c 1st -- /bin/cat /usr/share/nginx/html/index.html
    
    kubectl exec multi-container -c 2nd -- /bin/cat /html/index.html
    

  26. 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

    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: {}
    
    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.

  27. Ejecute la creación del Pod bajo el modelo de Init Container con el siguiente comando:

    kubectl apply -f init-container.yaml
    

  28. Verifique la ejecución y funcionamiento del Pod creado anteriormente:

    kubectl get pods
    
    kubectl exec -it init-demo -- /bin/bash
    
    curl localhost
    
    exit
    
    Note que es posible ingresar al SHELL del Contenedor utilizando kubectl exec -it init-demo -- /bin/bash

  29. 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