Pods

• 1: Pods
• 2: Contenedores de Inicialización
• 3: Pod Preset
• 4: Interrupciones
• 5: Containers Efímeros

1 - Pods

Los Pods son las unidades de computación desplegables más pequeñas que se pueden crear y gestionar en Kubernetes.

¿Qué és un Pod?

Un Pod (como en una vaina de ballenas o vaina de guisantes) es un grupo de uno o más contenedores (como contenedores Docker), con almacenamiento/red compartidos, y unas especificaciones de cómo ejecutar los contenedores. Los contenidos de un Pod son siempre coubicados, coprogramados y ejecutados en un contexto compartido. Un Pod modela un "host lógico" específico de la aplicación: contiene uno o más contenedores de aplicaciones relativamente entrelazados. Antes de la llegada de los contenedores, ejecutarse en la misma máquina física o virtual significaba ser ejecutado en el mismo host lógico.

Mientras que Kubernetes soporta más runtimes de contenedores a parte de Docker, este último es el más conocido y ayuda a describir Pods en términos de Docker.

El contexto compartido de un Pod es un conjunto de namespaces de Linux, cgroups y, potencialmente, otras facetas de aislamiento, las mismas cosas que aíslan un contenedor Docker. Dentro del contexto de un Pod, las aplicaciones individuales pueden tener más subaislamientos aplicados.

Los contenedores dentro de un Pod comparten dirección IP y puerto, y pueden encontrarse a través de localhost. También pueden comunicarse entre sí mediante comunicaciones estándar entre procesos, como semáforos de SystemV o la memoria compartida POSIX. Los contenedores en diferentes Pods tienen direcciones IP distintas y no pueden comunicarse por IPC sin configuración especial. Estos contenedores normalmente se comunican entre sí a través de las direcciones IP del Pod.

Las aplicaciones dentro de un Pod también tienen acceso a volúmenes compartidos, que se definen como parte de un Pod y están disponibles para ser montados en el sistema de archivos de cada aplicación.

En términos de Docker, un Pod se modela como un grupo de contenedores de Docker con namespaces y volúmenes de sistemas de archivos compartidos.

Al igual que los contenedores de aplicaciones individuales, los Pods se consideran entidades relativamente efímeras (en lugar de duraderas). Como se explica en ciclo de vida del pod, los Pods se crean, se les asigna un identificador único (UID) y se planifican en nodos donde permanecen hasta su finalización (según la política de reinicio) o supresión. Si un nodo muere, los Pods programados para ese nodo se programan para su eliminación después de un período de tiempo de espera. Un Pod dado (definido por su UID) no se "replanifica" a un nuevo nodo; en su lugar, puede reemplazarse por un Pod idéntico, con incluso el mismo nombre si lo desea, pero con un nuevo UID (consulte controlador de replicación para obtener más detalles).

Cuando se dice que algo tiene la misma vida útil que un Pod, como un volumen, significa que existe mientras exista ese Pod (con ese UID). Si ese Pod se elimina por cualquier motivo, incluso si se crea un reemplazo idéntico, el recurso relacionado (por ejemplo, el volumen) también se destruye y se crea de nuevo.

Un Pod de múltiples contenedores que contiene un extractor de archivos y un servidor web que utiliza un volumen persistente para el almacenamiento compartido entre los contenedores.

Motivación para los Pods

Gestión

Los Pods son un modelo del patrón de múltiples procesos de cooperación que forman una unidad de servicio cohesiva. Simplifican la implementación y la administración de las aplicaciones proporcionando una abstracción de mayor nivel que el conjunto de las aplicaciones que lo constituyen. Los Pods sirven como unidad de despliegue, escalado horizontal y replicación. La colocación (coprogramación), el destino compartido (por ejemplo, la finalización), la replicación coordinada, el uso compartido de recursos y la gestión de dependencias se controlan automáticamente para los contenedores en un Pod.

Recursos compartidos y comunicación

Los Pods permiten el intercambio de datos y la comunicación entre los contenedores que lo constituyen.

Todas las aplicaciones en un Pod utilizan el mismo namespace de red (la misma IP y puerto) y, por lo tanto, pueden "encontrarse" entre sí y comunicarse utilizando localhost. Debido a esto, las aplicaciones en un Pod deben coordinar su uso de puertos. Cada Pod tiene una dirección IP en un espacio de red compartido que tiene comunicación completa con otros servidores físicos y Pods a través de la red.

Los contenedores dentro del Pod ven que el hostname del sistema es el mismo que el nombre configurado para el Pod. Hay más información sobre esto en la sección networking.

Además de definir los contenedores de aplicaciones que se ejecutan en el Pod, el Pod especifica un conjunto de volúmenes de almacenamiento compartido. Los volúmenes permiten que los datos sobrevivan a reinicios de contenedores y se compartan entre las aplicaciones dentro del Pod.

Usos de Pods

Los Pods pueden ser usados para alojar pilas de aplicaciones integradas (por ejemplo, LAMP), pero su objetivo principal es apoyar los programas de ayuda coubicados y coadministrados, como:

• sistemas de gestión de contenido, loaders de datos y archivos, gestores de caché locales, etc.
• copia de seguridad de registro y punto de control, compresión, rotación, captura de imágenes, etc.
• observadores de cambio de datos, adaptadores de registro y monitoreo, publicadores de eventos, etc.
• proxies, bridges y adaptadores.
• controladores, configuradores y actualizadores.

Los Pods individuales no están diseñados para ejecutar varias instancias de la misma aplicación, en general.

Para una explicación más detallada, ver El sistema distribuido ToolKit: Patrones para Contenedores multiaplicación.

Alternativas

¿Por qué simplemente no ejecutar múltiples programas en un solo contenedor de Docker?

1. Transparencia. Hacer visibles los contenedores dentro del Pod a la infraestructura permite que esta brinde servicios, como gestión de procesos y monitoreo de recursos, a los contenedores, facilitando una serie de comodidades a los usuarios.
2. Desacople de dependencias de software. Los contenedores individuales pueden ser versionados, reconstruidos y redistribuidos independientemente. Kubernetes podría incluso apoyar actualizaciones en vivo de contenedores individuales en un futuro.
3. Facilidad de uso. Los usuarios no necesitan ejecutar sus propios administradores de procesos, para propagación de señales, códigos de salida, etc.
4. Eficiencia. Debido a que la infraestructura asume más responsabilidad, los contenedores pueden ser más livianos.

¿Por qué no admitir la planificación conjunta de contenedores por afinidad?

Ese enfoque proporcionaría la ubicación conjunta, pero no la mayor parte de beneficios de los Pods, como compartir recursos, IPC, compartir el destino garantizado y gestión simplificada.

Durabilidad de pods (o su ausencia)

Los Pods no están destinados a ser tratados como entidades duraderas. No sobrevivirán a errores de planificación, caídas de nodo u otros desalojos, ya sea por falta de recursos o en el caso de mantenimiento de nodos.

En general, los usuarios no deberían necesitar crear Pods directamente, deberían usar siempre controladores incluso para Pods individuales, como por ejemplo, los Deployments. Los controladores proporcionan autorecuperación con un alcance de clúster, así como replicación y gestión de despliegue. Otros controladores como los StatefulSet pueden tambien proporcionar soporte para Pods que necesiten persistir el estado.

El uso de API colectivas como la principal primitiva de cara al usuario es relativamente común entre los sistemas de planificación de clúster, incluyendo Borg, Marathon, Aurora, y Tupperware.

El Pod se expone como primitiva para facilitar:

• planificación y capacidad de conexión del controlador
• soporte para operaciones a nivel de Pod sin la necesidad de "proxy" a través de las API del controlador
• desacople de la vida útil del Pod de la vida útil del controlador, como para el arranque
• desacople de controladores y servicios, el endpoint del controlador solo mira Pods
• composición limpia de funcionalidad a nivel de Kubelet con funcionalidad a nivel de clúster, Kubelet es efectivamente el "controlador de Pod"
• aplicaciones en alta disponibilidad, que esperan que los Pods sean reemplazados antes de su finalización y ciertamente antes de su eliminación, como en el caso de desalojos planificados o descarga previa de imágenes.

Finalización de Pods

Debido a que los Pods representan procesos en ejecución en los nodos del clúster, es importante permitir que esos procesos finalicen de forma correcta cuando ya no se necesiten (en lugar de ser detenidos bruscamente con una señal de KILL). Los usuarios deben poder solicitar la eliminación y saber cuándo finalizan los procesos, pero también deben poder asegurarse de que las eliminaciones finalmente se completen. Cuando un usuario solicita la eliminación de un Pod, el sistema registra el período de gracia previsto antes de que el Pod pueda ser eliminado de forma forzada, y se envía una señal TERM al proceso principal en cada contenedor. Una vez que el período de gracia ha expirado, la señal KILL se envía a esos procesos y el Pod se elimina del servidor API. Si se reinicia Kubelet o el administrador de contenedores mientras se espera que finalicen los procesos, la terminación se volverá a intentar con el período de gracia completo.

Un ejemplo del ciclo de terminación de un Pod:

1. El usuario envía un comando para eliminar Pod, con un período de gracia predeterminado (30s)
2. El Pod en el servidor API se actualiza con el tiempo a partir del cual el Pod se considera "muerto" junto con el período de gracia.
3. El Pod aparece como "Terminando" cuando aparece en los comandos del cliente
4. (simultáneo con 3) Cuando el Kubelet ve que un Pod se ha marcado como terminado porque se ha configurado el tiempo en 2, comienza el proceso de apagado del Pod.
   1. Si uno de los contenedores del Pod ha definido un preStop hook, se invoca dentro del contenedor. Si el hook preStop todavía se está ejecutando después de que expire el período de gracia, el paso 2 se invoca con un pequeño período de gracia extendido (2s).
   2. El contenedor recibe la señal TERM. Tenga en cuenta que no todos los contenedores en el Pod recibirán la señal TERM al mismo tiempo y cada uno puede requerir un hook preStop si el orden en el que se cierra es importante.
5. (simultáneo con 3) Pod se elimina de la lista de endponts del servicio, y ya no se considera parte del conjunto de Pods en ejecución para controladores de replicación. Los Pods que se apagan lentamente no pueden continuar sirviendo el tráfico ya que los balanceadores de carga (como el proxy de servicio) los eliminan de sus rotaciones.
6. Cuando expira el período de gracia, todos los procesos que todavía se ejecutan en el Pod se eliminan con SIGKILL.
7. El Kubelet terminará de eliminar el Pod en el servidor API configurando el período de gracia 0 (eliminación inmediata). El Pod desaparece de la API y ya no es visible desde el cliente.

Por defecto, todas las eliminaciones se realizan correctamente en 30 segundos. El comando kubectl delete admite la opción--grace-period = <seconds>que permite al usuario anular el valor predeterminado y especificar su propio valor. El valor 0 forzar eliminación del Pod. Debe especificar un indicador adicional --force junto con --grace-period = 0 para realizar eliminaciones forzadas.

Forzar destrucción de Pods

La eliminación forzada de un Pod se define como la eliminación de un Pod del estado del clúster y etcd inmediatamente. Cuando se realiza una eliminación forzada, el apiserver no espera la confirmación del kubelet de que el Pod ha finalizado en el nodo en el que se estaba ejecutando. Elimina el Pod en la API inmediatamente para que se pueda crear un nuevo Pod con el mismo nombre. En el nodo, los Pods que están configurados para terminar de inmediato recibirán un pequeño período de gracia antes de ser forzadas a matar.

Estas eliminaciones pueden ser potencialmente peligrosas para algunos Pods y deben realizarse con precaución. En el caso de Pods de StatefulSets, consulte la documentación de la tarea para eliminando Pods de un StatefulSet.

Modo privilegiado para Pods

Cualquier contenedor en un Pod puede habilitar el modo privilegiado, utilizando el indicador privilegiado en el contexto de seguridad de la especificación del contenedor. Esto es útil para contenedores que desean usar capacidades de Linux como manipular la pila de red y acceder a dispositivos. Los procesos dentro del contenedor obtienen casi los mismos privilegios que están disponibles para los procesos fuera de un contenedor. Con el modo privilegiado, debería ser más fácil escribir complementos de red y volumen como Pods separados que no necesitan compilarse en el kubelet.

API

Pod es un recurso de nivel superior en la API REST de Kubernetes. La definición de objeto de API Pod describe el objeto en detalle.

2 - Contenedores de Inicialización

Esta página proporciona una descripción general de los contenedores de inicialización (init containers): contenedores especializados que se ejecutan antes de los contenedores de aplicación en un Pod. Los contenedores de inicialización pueden contener utilidades o scripts de instalación no presentes en una imagen de aplicación.

Tú puedes especificar contenedores de inicialización en la especificación del Pod junto con el arreglo de containers (el cual describe los contenedores de aplicación).

Entendiendo los contenedores de inicialización

Un Pod puede tener múltiples contenedores ejecutando aplicaciones dentro de él, pero también puede tener uno o más contenedores de inicialización que se ejecutan antes de que se inicien los contenedores de aplicación.

Los contenedores de inicialización son exactamente iguales a los contenedores regulares excepto por:

• Los contenedores de inicialización siempre se ejecutan hasta su finalización.
• Cada contenedor de inicialiación debe completarse correctamente antes de que comience el siguiente.

Si el contenedor de inicialización de un Pod falla, kubelet reinicia repetidamente ese contenedor de inicialización hasta que tenga éxito. Sin embargo, si el Pod tiene una restartPolicy de Never y un contenedor de inicialización falla durante el inicio de ese Pod, Kubernetes trata al Pod en general como fallido.

Para especificar un contenedor de inicialización para un Pod, agrega el campo initContainers en la especificación del Pod, como un arreglo de elementos container (similar al campo containers de aplicación y su contenido). Consulta Container en la referencia de API para más detalles.

El estado de los contenedores de inicialización se devuelve en el campo .status.initContainerStatuses como un arreglo de los estados del contenedor (similar al campo .status.containerStatuses).

Diferencias con los contenedores regulares

Los contenedores de inicialización admiten todos los campos y características de los contenedores de aplicaciones, incluidos los límites de recursos, los volúmenes y la configuración de seguridad. Sin embargo, las solicitudes de recursos y los límites para un contenedor de inicialización se manejan de manera diferente, como se documenta en Recursos.

Además, los contenedores de inicialización no admiten lifecycle, livenessProbe, readinessProbe o startupProbe porque deben de ejecutarse hasta su finalización antes de que el Pod pueda estar listo.

Si especificas varios contenedores de inicialización para un Pod, kubelet ejecuta cada contenedor de inicialización secuencialmente. Cada contenedor de inicialización debe tener éxito antes de que se pueda ejecutar el siguiente. Cuando todos los contenedores de inicialización se hayan ejecutado hasta su finalización, kubelet inicializa los contenedores de aplicación para el Pod y los ejecuta como de costumbre.

Usando contenedores de inicialización

Dado que los contenedores de inicialización tienen imágenes separadas de los contenedores de aplicaciones, estos tienen algunas ventajas sobre el código relacionado de inicio:

• Los contenedores de inicialización pueden contener utilidades o código personalizado para la configuración que no están presentes en una imagen de aplicación. Por ejemplo, no hay necesidad de hacer una imagen FROM de otra imagen solo para usar una herramienta como sed, awk, python o dig durante la instalación.
• Los roles de constructor e implementador de imágenes de aplicación pueden funcionar de forma independiente sin la necesidad de construir conjuntamente una sola imagen de aplicación.
• Los contenedores de inicialización pueden ejecutarse con una vista diferente al sistema de archivos que los contenedores de aplicaciones en el mismo Pod. En consecuencia, se les puede dar acceso a Secrets a los que los contenedores de aplicaciones no pueden acceder.
• Debido a que los contenedores de inicialización se ejecutan hasta su finalización antes de que se inicien los contenedores de aplicaciones, los contenedores de inicialización ofrecen un mecanismo para bloquear o retrasar el inicio del contenedor de aplicación hasta que se cumplan una serie de condiciones previas. Una vez que las condiciones previas se cumplen, todos los contenedores de aplicaciones de un Pod pueden iniciarse en paralelo.
• Los contenedores de inicialización pueden ejecutar de forma segura utilidades o código personalizado que de otro modo harían a una imagen de aplicación de contenedor menos segura. Si mantiene separadas herramientas innecesarias, puede limitar la superficie de ataque a la imagen del contenedor de aplicación.

Ejemplos

A continuación, se muestran algunas ideas sobre cómo utilizar los contenedores de inicialización:

• Esperar a que se cree un Service usando una sola linea de comando de shell:

  for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
  

• Registrar este Pod con un servidor remoto desde la downward API con un comando como:

  curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
  

• Esperar algo de tiempo antes de iniciar el contenedor de aplicación con un comando como:

  sleep 60
  

• Clonar un repositorio de Git en un Volume

• Colocar valores en un archivo de configuración y ejecutar una herramienta de plantilla para generar dinámicamente un archivo de configuración para el contenedor de aplicación principal. Por ejemplo, colocar el valor POD_IP en una configuración y generar el archivo de configuración de la aplicación principal usando Jinja.

Contenedores de inicialización en uso

Este ejemplo define un simple Pod que tiene dos contenedores de inicialización. El primero espera por myservice y el segundo espera por mydb. Una vez que ambos contenedores de inicialización se completen, el Pod ejecuta el contenedor de aplicación desde su sección spec.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo ¡La aplicación se está ejecutando! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a mydb; sleep 2; done"]

Puedes iniciar este Pod ejecutando:

kubectl apply -f myapp.yaml

El resultado es similar a esto:

pod/myapp-pod created

Y verificar su estado con:

kubectl get -f myapp.yaml

El resultado es similar a esto:

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

o para más detalles:

kubectl describe -f myapp.yaml

El resultado es similar a esto:

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app.kubernetes.io/name=MyApp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634

Para ver los logs de los contenedores de inicialización en este Pod ejecuta:

kubectl logs myapp-pod -c init-myservice # Inspecciona el primer contenedor de inicialización
kubectl logs myapp-pod -c init-mydb      # Inspecciona el segundo contenedor de inicialización

En este punto, estos contenedores de inicialización estarán esperando para descubrir los Servicios denominados mydb y myservice.

Aquí hay una configuración que puedes usar para que aparezcan esos Servicios:

---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Para crear los servicios de mydb y myservice:

kubectl apply -f services.yaml

El resultado es similar a esto:

service/myservice created
service/mydb created

Luego verás que esos contenedores de inicialización se completan y que el Pod myapp-pod pasa al estado Running:

kubectl get -f myapp.yaml

El resultado es similar a esto:

NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

Este sencillo ejemplo debería servirte de inspiración para crear tus propios contenedores de inicialización. ¿Qué es lo que sigue? contiene un enlace a un ejemplo más detallado.

Comportamiento detallado

Durante el inicio del Pod, kubelet retrasa la ejecución de contenedores de inicialización hasta que la red y el almacenamiento estén listos. Después, kubelet ejecuta los contenedores de inicialización del Pod en el orden que aparecen en la especificación del Pod.

Cada contenedor de inicialización debe salir correctamente antes de que comience el siguiente contenedor. Si un contenedor falla en iniciar debido al tiempo de ejecución o sale con una falla, se vuelve a intentar de acuerdo con el restartPolicy del Pod. Sin embargo, si el restartPolicy del Pod se establece en Always, los contenedores de inicialización usan el restartPolicy como OnFailure.

Un Pod no puede estar Ready sino hasta que todos los contenedores de inicialización hayan tenido éxito. Los puertos en un contenedor de inicialización no se agregan a un Servicio. Un Pod que se está inicializando, está en el estado de Pending, pero debe tener una condición Initialized configurada como falsa.

Si el Pod se reinicia o es reiniciado, todos los contenedores de inicialización deben ejecutarse de nuevo.

Los cambios en la especificación del contenedor de inicialización se limitan al campo de la imagen del contenedor. Alterar un campo de la imagen del contenedor de inicialización equivale a reiniciar el Pod.

Debido a que los contenedores de inicialización se pueden reiniciar, reintentar o volverse a ejecutar, el código del contenedor de inicialización debe ser idempotente. En particular, el código que escribe en archivos en EmptyDirs debe estar preparado para la posibilidad de que ya exista un archivo de salida.

Los contenedores de inicialización tienen todos los campos de un contenedor de aplicaciones. Sin embargo, Kubernetes prohíbe el uso de readinessProbe porque los contenedores de inicialización no pueden definir el readiness distinto de la finalización. Esto se aplica durante la validación.

Usa activeDeadlineSeconds en el Pod para prevenir que los contenedores de inicialización fallen por siempre. La fecha límite incluye contenedores de inicialización. Sin embargo, se recomienda utilizar activeDeadlineSeconds si el usuario implementa su aplicación como un Job porque activeDeadlineSeconds tiene un efecto incluso después de que initContainer finaliza. El Pod que ya se está ejecutando correctamente sería eliminado por activeDeadlineSeconds si lo estableces.

El nombre de cada aplicación y contenedor de inicialización en un Pod debe ser único; un error de validación es arrojado para cualquier contenedor que comparta un nombre con otro.

Recursos

Dado el orden y la ejecución de los contenedores de inicialización, las siguientes reglas para el uso de recursos se aplican:

• La solicitud más alta de cualquier recurso o límite particular definido en todos los contenedores de inicialización es la solicitud/límite de inicialización efectiva. Si algún recurso no tiene un límite de recursos especificado éste se considera como el límite más alto.
• La solicitud/límite efectiva para un recurso es la más alta entre:
  • la suma de todas las solicitudes/límites de los contenedores de aplicación, y
  • la solicitud/límite de inicialización efectiva para un recurso
• La planificación es hecha con base en las solicitudes/límites efectivos, lo que significa que los contenedores de inicialización pueden reservar recursos para la inicialización que no se utilizan durante la vida del Pod.
• El nivel de QoS (calidad de servicio) del nivel de QoS efectivo del Pod es el nivel de QoS tanto para los contenedores de inicialización como para los contenedores de aplicación.

La cuota y los límites son aplicados con base en la solicitud y límite efectivos de Pod.

Los grupos de control de nivel de Pod (cgroups) se basan en la solicitud y el límite de Pod efectivos, al igual que el planificador de Kubernetes (kube-scheduler).

Razones de reinicio del Pod

Un Pod puede reiniciarse, provocando la re-ejecución de los contenedores de inicialización por las siguientes razones:

• Se reinicia el contenedor de infraestructura del Pod. Esto es poco común y debería hacerlo alguien con acceso de root a los nodos.
• Todos los contenedores en un Pod son terminados mientras restartPolicy esté configurado en Always, forzando un reinicio y el registro de finalización del contenedor de inicialización se ha perdido debido a la recolección de basura.

El Pod no se reiniciará cuando se cambie la imagen del contenedor de inicialización o cuando se pierda el registro de finalización del contenedor de inicialización debido a la recolección de basura. Esto se aplica a Kubernetes v1.20 y posteriores. Si estás utilizando una versión anterior de Kubernetes, consulta la documentación de la versión que estás utilizando.

Siguientes pasos

• Lee acerca de creando un Pod que tiene un contenedor de inicialización
• Aprende cómo depurar contenedores de inicialización

3 - Pod Preset

Esta página provee una descripción general de los PodPresets, los cuales son los objetos que se utilizan para inyectar cierta información en los Pods en el momento de la creación. Esta información puede incluir secretos, volúmenes, montajes de volúmenes y variables de entorno.

Entendiendo los Pod Presets

Un PodPreset es un recurso de la API utilizado para poder inyectar requerimientos adicionales de tiempo de ejecución en un Pod en el momento de la creación. Se utilizan los selectores de etiquetas para especificar los Pods a los que se aplica un PodPreset determinado.

El uso de un PodPreset permite a los autores de plantillas de Pods no tener que proporcionar explícitamente toda la información de cada Pod. De esta manera, los autores de plantillas de Pods que consuman un determinado servicio no tendrán que conocer todos los detalles de ese servicio.

Habilitando un PodPreset en su clúster

Con el fin de utilizar los Pod Presets en un clúster debe asegurarse de lo siguiente:

1. Que se ha configurado el tipo de API settings.k8s.io/v1alpha1/podpreset. Esto se puede hacer, por ejemplo, incluyendo settings.k8s.io/v1alpha1=true como valor de la opción --runtime-config en el servidor API. En minikube se debe añadir el flag --extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true cuando el clúster se está iniciando.

2. Que se ha habilitado el controlador de admisión PodPreset. Una forma de hacer esto es incluir PodPreset como valor de la opción --enable-admission-plugins especificada para el servidor API. En minikube se debe añadir el flag

   --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
   

   cuando el clúster se está iniciando.

Cómo funciona

Kubernetes provee un controlador de admisión (PodPreset) que, cuando está habilitado, aplica los Pod Presets a las peticiones de creación de Pods entrantes. Cuando se realiza una solicitud de creación de Pods, el sistema hace lo siguiente:

1. Obtiene todos los PodPresets disponibles para usar.
2. Verifica si los selectores de etiquetas de cualquier PodPreset correspondan con las etiquetas del Pod que se está creando.
3. Intenta fusionar los diversos recursos definidos por el PodPreset dentro del Pod que se está creando.
4. Si se llegase a producir un error al intentar fusionar los recursos dentro del Pod, lanza un evento que documente este error, luego crea el Pod sin ningún recurso que se inyecte desde el PodPreset.
5. Escribe una nota descriptiva de la especificación de Pod modificada resultante para indicar que ha sido modificada por un PodPreset. La nota descriptiva presenta la forma podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>".

Cada Pod puede ser correspondido por cero o más Pod Presets; y cada PodPreset puede ser aplicado a cero o más Pods. Cuando se aplica un PodPreset a una o más Pods, Kubernetes modifica la especificación del Pod. Para los cambios a env, envFrom, y volumeMounts, Kubernetes modifica la especificación del Container para todos los Containers en el Pod; para los cambios a volumes, Kubernetes modifica la especificación del Pod.

Deshabilitar un Pod Preset para un Pod específico

Puede haber casos en los que se desee que un Pod no se vea alterado por ninguna posible modificación del Pod Preset. En estos casos, se puede añadir una observación en el Pod .spec de la siguiente forma: podpreset.admission.kubernetes.io/exclude: "true".

Siguientes pasos

Ver Inyectando datos en un Pod usando PodPreset

Para más información sobre los detalles de los trasfondos, consulte la propuesta de diseño de PodPreset.

4 - Interrupciones

Esta guía es para los dueños de aplicaciones que quieren crear aplicaciones con alta disponibilidad y que necesitan entender que tipos de interrupciones pueden suceder en los Pods.

También es para los administradores de clústers que quieren aplicar acciones automatizadas en sus clústers, cómo actualizar o autoescalar los clústers.

Interrupciones voluntarias e involuntarias

Los Pods no desaparecen hasta que algo (una persona o un controlador) los destruye ó hay problemas de hardware ó software que son inevitables.

Nosotros llamamos a esos casos inevitables interrupciones involuntarias de una aplicación. Algunos ejemplos:

• Una falla en hardware de la máquina física del nodo
• Un administrador del clúster borra una VM (instancia) por error
• El proveedor de la nube o el hipervisor falla y hace desaparecer la VM
• Un kernel panic
• El nodo desaparece del clúster por un problema de red que lo separa del clúster
• Una remoción del Pod porque el nodo no tiene recursos suficientes.

A excepción de la condición sin recursos suficientes, todas estas condiciones deben ser familiares para la mayoría de los usuarios, no son específicas de Kubernetes

Nosotros llamamos a los otros casos interrupciones voluntarias. Estas incluyen las acciones iniciadas por el dueño de la aplicación y aquellas iniciadas por el Administrador del Clúster. Las acciones típicas de los dueños de la aplicación incluye:

• borrar el Deployment u otro controlador que maneja el Pod
• actualizar el Deployment del Pod que causa un reinicio
• borrar un Pod (por ejemplo, por accidente)

Las acciones del administrador del clúster incluyen:

• Drenar un nodo para reparar o actualizar.
• Drenar un nodo del clúster para reducir el clúster (aprenda acerca de Autoescalamiento de Clúster ).
• Remover un Pod de un nodo para permitir que otra cosa pueda ingresar a ese nodo.

Estas acciones pueden ser realizadas directamente por el administrador del clúster, por tareas automatizadas del administrador del clúster ó por el proveedor del clúster.

Consulte al administrador de su clúster, a su proveedor de la nube ó a la documentación de su distribución para determinar si alguna de estas interrupciones voluntarias están habilitadas en su clúster. Si ninguna se encuentra habilitada, puede omitir la creación del presupuesto de Interrupción de Pods.

Tratando con las interrupciones

Estas son algunas de las maneras para mitigar las interrupciones involuntarias:

• Asegurarse que el Pod solicite los recursos que necesita.
• Replique su aplicación si usted necesita alta disponibilidad. (Aprenda sobre correr aplicaciones replicadas stateless y stateful
• Incluso, para una alta disponibilidad mayor cuando se corren aplicaciones replicadas, propague las aplicaciones por varios racks (usando anti-affinity) o usando zonas (si usa un clúster multi-zona.)

La frecuencia de las interrupciones voluntarias varía. En un clúster basico de Kubernetes, no hay interrupciones voluntarias automáticas (solo el usuario las genera). Sin embargo, su administrador del clúster o proveedor de alojamiento puede correr algun servicio adicional que pueda causar estas interrupciones voluntarias. Por ejemplo, desplegando una actualización de software en los nodos puede causar interrupciones. También, algunas implementaciones de clústers con autoescalamiento de nodos puede causar interrupciones para defragmentar o compactar los nodos. Su administrador de clúster o proveedor de alojamiento debe tener documentado cuál es el nivel de interrupciones voluntarias esperadas, sí es que las hay. Ciertas opciones de configuración, como ser usar PriorityClasses en las especificaciones de su Pod pueden también causar interrupciones voluntarias (o involuntarias).

Presupuesto de Interrupción de Pods

Kubernetes ofrece carácteristicas para ayudar a ejecutar aplicaciones con alta disponibliidad, incluso cuando usted introduce interrupciones voluntarias frecuentes.

Como dueño de la aplicación, usted puede crear un presupuesto de interrupción de Pods (PDB por sus siglas en inglés) para cada aplicación. Un PDB limita el numero de Pods de una aplicación replicada, que estan caídos de manera simultánea por interrupciones voluntarias. Por ejemplo, una aplicación basada en quórum puede asegurarse que el número de réplicas corriendo nunca es menor al número necesitado para obtener el quórum. Una web de tipo front end puede querer asegurarse que el número de réplicas atendiendo al tráfico nunca puede caer bajo un cierto porcentaje del total.

Los administradores del clúster y proveedores de hosting pueden usar herramientas que respeten el presupuesto de interrupción de Pods utilizando la API de Desalojo en vez de directamente borrar Pods o Deployments.

Por ejemplo, el subcomando kubectl drain le permite marcar un nodo a un modo fuera de servicio. Cuando se ejecuta kubectl drain, la herramienta trata de quitar a todos los Pods en el nodo que se esta dejando fuera de servicio. La petición de desalojo que kubectl solicita en su nombre puede ser temporalmente denegado, entonces la herramienta periodicamente reintenta todas las peticiones fallidas hasta que todos los Pods en el nodo afectado son terminados ó hasta que el tiempo de espera, que puede ser configurado, es alcanzado.

Un PDB especifica el número de réplicas que una aplicación puede tolerar, relativo a cuantas se pretende tener. Por ejemplo, un Deployment que tiene un .spec.replicas: 5 se supone que tiene 5 Pods en cualquier momento. Si su PDB permite tener 4 a la vez, entonces la API de Desalojo va a permitir interrupciones voluntarias de un (pero no a dos) Pod a la vez.

El grupo de Pods que comprende a la aplicación esta especificada usando una etiqueta selectora, la misma que es usada por el controlador de aplicación (deployment, stateful-set, etc).

El numero de Pods "deseado" es calculado a partir de .spec.replicas de el recurso de Workload que es manejado para esos Pods. El plano de control descubre el recurso Workload perteneciente a el examinando las .metadata.ownerReferences del Pod.

Las Interrupciones Involuntarias no pueden ser prevenidas por los PDB; pero si son contabilizadas a partir este presupuesto.

Los Pods que son borrados o no estan disponibles debido a una actualización continua de una aplicación forman parte del presupuesto de interrupciones, pero los recursos Workload (como los Deployments y StatefulSet) no están limitados por los PDBs cuando se hacen actualizaciones continuas. En cambio, la administración de fallas durante la actualización de la aplicación es configurada en la especificación para este recurso Workload específico.

Cuando un Pod es quitado usando la API de desalojo, este es terminado correctamente, haciendo honor al terminationGracePeriodSeconds configurado en su PodSpec.

Ejemplo de Presupuesto de Interrupción de POD

Considere un clúster con 3 nodos, nodo-1 hasta nodo-3. El clúster esta corriendo varias aplicaciones. Uno de ellos tiene 3 replicas, que llamaremos pod-a, pod-b, y pod-c. Otro Pod no relacionado y sin PDB, llamado pod-x, también se muestra.

Inicialmente los pods estan distribuidos de esta manera:

Los 3 Pods son parte de un Deployment, ellos colectivamente tienen un PDB que requiere que por lo menos 2 de los 3 Pods esten disponibles todo el tiempo.

Por ejemplo, supongamos que el administrador del clúster quiere reiniciar para actualizar el kernel y arreglar un bug. El administrador del clúster primero intenta desocupar el nodo-1 usando el comando kubectl drain. La herramienta intenta desalojar a los pods pod-a y pod-x. Esto tiene éxito inmediatamente. Ambos Pods van al estado terminating al mismo tiempo. Pone al clúster en el siguiente estado:

El Deployment detecta que uno de los Pods esta terminando, entonces crea un reemplazo llamado pod-d. Como el nodo-1 esta bloqueado, el pod termina en otro nodo. Algo más, adicionalmente a creado el pod pod-y como un reemplazo del pod-x .

(Nota: para un StatefulSet, pod-a, el cual debería ser llamado algo como pod-0, necesitaría ser terminado completamente antes de su remplazo, el cual también es llamado pod-0 pero tiene un UID diferente, podría ser creado. De lo contrario, el ejemplo también aplica a un StatefulSet.)

Ahora el clúster esta en este estado:

En algún punto, los Pods finalizan y el clúster se ve de esta forma:

En este estado, si un administrador del clúster impaciente intenta desalojar el nodo-2 ó el nodo-3, el comando drain va a ser bloqueado, porque hay solamente 2 Pods disponibles para el Deployment y el PDB requiere por lo menos 2. Después de pasado un tiempo el pod-d esta disponible.

El estado del clúster ahora se ve así:

Ahora, el administrador del clúster desaloja el nodo-2. El comando drain tratará de desalojar a los 2 Pods con algún orden, digamos primero el pod-b y después el pod-d. Va a tener éxito en quitar el pod-b. Pero cuando intente desalojar al pod-d, va a ser rechazado porque esto va a dejar un Pod solamente disponible para el Deployment.

El Deployment crea un reemplazo para el pod-b llamado pod-e. Porque no hay recursos suficientes disponibles en el clúster para programar el pod-e el desalojo será bloqueado nuevamente. El clúster va a terminar en este estado:

Ahora, el administrador del clúster necesita agregar un nuevo nodo en el clúster para continuar con la actualización.

Usted puede ver como Kubernetes varia la tasa a la que las interrupciones pueden suceder, en función de:

• cuantas réplicas una aplicación necesita
• cuanto toma apagar una instancia de manera correcta
• cuanto tiempo toma que una nueva instancia inicie
• el tipo de controlador
• la capacidad de recursos del clúster

Separando al dueño del Clúster y los roles de dueños de la Aplicación

Muchas veces es útil pensar en el Administrador del Clúster y al dueño de la aplicación como roles separados con conocimiento limitado el uno del otro. Esta separación de responsabilidades puede tener sentido en estos escenarios:

• Cuando hay muchas equipos con aplicaciones compartiendo un clúster de Kubernetes y hay una especialización natural de roles
• Cuando una herramienta de terceros o servicio es usado para automatizar el control del clúster

El presupuesto de interrupción de Pods soporta esta separación de roles, ofreciendo una interfaz entre los roles.

Si no se tiene tal separación de responsabilidades en la organización, posiblemente no se necesite el Presupuesto de Interrupción de Pods.

Como realizar Acciones Disruptivas en el Clúster

Si usted es el Administrador del Clúster y necesita realizar una acción disruptiva en todos los nodos en el clúster, como ser una actualización de nodo o de software, estas son algunas de las opciones:

• Aceptar el tiempo sin funcionar mientras dura la actualización.
• Conmutar a otra replica completa del clúster.
  • No hay tiempo sin funcionar, pero puede ser costoso tener duplicados los nodos y tambien un esfuerzo humano para orquestar dicho cambio.
• Escribir la toleracia a la falla de la aplicación y usar PDBs.
  • No hay tiempo sin funcionar.
  • Duplicación de recursos mínimo.
  • Permite mucha más automatización de la administración del clúster.
  • Escribir aplicaciones que tengan tolerancia a fallas es complicado, pero el trabajo para tolerar interrupciones involuntarias, largamente se sobrepone con el trabajo que es dar soporte a autoescalamientos y tolerar interrupciones involuntarias.

Siguientes pasos

• Siga los pasos para proteger su aplicación con configurar el Presupuesto de Interrupciones de Pods.

• Aprenda más sobre desalojar nodos

• Aprenda sobre actualizar un Deployment incluyendo los pasos para mantener su disponibilidad mientras dura la actualización.

5 - Containers Efímeros

Esta página proporciona una descripción general de los Containers efímeros: un tipo especial de Container que se ejecuta temporalmente en un Pod ya existente para cumplir las acciones iniciadas por el usuario, como por ejemplo, la solución de problemas. En vez de ser utilizadas para crear aplicaciones, los Containers efímeros se utilizan para examinar los servicios.

Entendiendo los Containers efímeros

Pods son el componente fundamental de las aplicaciones de Kubernetes. Puesto que los Pods están previstos para ser desechables y reemplazables, no se puede añadir un Container a un Pod una vez creado. Sin embargo, por lo general se eliminan y se reemplazan los Pods de manera controlada utilizando Deployments.

En ocasiones es necesario examinar el estado de un Pod existente, como por ejemplo, para poder solucionar un error difícil de reproducir. Puede ejecutar en estos casos un Container efímero en un Pod ya existente para examinar su estado y para ejecutar comandos de manera arbitraria.

Qué es un Container efímero?

Los Containers efímeros se diferencian de otros Containers en que no garantizan ni los recursos ni la ejecución, y en que nunca se reiniciarán automáticamente, de modo que no son aptos para la construcción de aplicaciones. Los Containers efímeros se describen usando la misma ContainerSpec que los Containers regulares, aunque muchos campos son incompatibles y no están habilitados para los Containers efímeros.

• Los Containers efímeros no pueden tener puertos, por lo que campos como ports, livenessProbe, readinessProbe no están habilitados.
• Las asignaciones de recursos del Pod son inmutables, por lo que no esta habilitado configurar "resources".
• Para obtener una lista completa de los campos habilitados, consulte la documentación de referencia [EphemeralContainer] (/docs/reference/generated/kubernetes-api/v1.26/#ephemeralcontainer-v1-core).

En vez de añadirlos de forma directa al pod.spec, los Containers efímeros se crean usando un controlador especial de la API, ephemeralcontainers, por lo tanto no es posible añadir un Container efímero utilizando kubectl edit.

Al igual en el caso de los Containers regulares, no se puede modificar o remover un Container efímero después de haberlo agregado a un Pod.

Casos de uso para los Containers efímeros

Los Containers efímeros resultan útiles para la solución interactiva de incidencias cuando kubectl exec es insuficiente tanto porque un container se ha caído, como porque la imagen de un Container no incluye las utilidades de depuración.

En particular, las imágenes distroless le permiten desplegar imágenes de Containers mínimos que disminuyen la superficie de ataque y la exposición a errores y vulnerabilidades. Ya que las imágenes distroless no contienen un shell ni ninguna utilidad de depuración, resulta difícil solucionar los problemas de las imágenes distroless usando solamente kubectl exec.

Cuando utilice Containers efímeros, es conveniente habilitar el proceso Namespace de uso compartido para poder ver los procesos en otros containers.

Ejemplos

En los ejemplos de esta sección muestran la forma en que los Containers efímeros se presentan en la API. Los usuarios normalmente usarían un plugin kubectl para la solución de problemas que automatizaría estos pasos.

Los Containers efímeros son creados utilizando el subrecurso ephemeralcontainers del Pod, que puede ser visto utilizando kubectl --raw. En primer lugar describa el Container efímero a añadir como una lista de EphemeralContainers:

{
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
        "name": "example-pod"
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}

Para actualizar los Containers efímeros de los example-pod en ejecución:

kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json

Esto devolverá una nueva lista de Containers efímeros:

{
   "kind":"EphemeralContainers",
   "apiVersion":"v1",
   "metadata":{
      "name":"example-pod",
      "namespace":"default",
      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
      "resourceVersion":"15886",
      "creationTimestamp":"2019-08-29T06:41:42Z"
   },
   "ephemeralContainers":[
      {
         "name":"debugger",
         "image":"busybox",
         "command":[
            "sh"
         ],
         "resources":{

         },
         "terminationMessagePolicy":"File",
         "imagePullPolicy":"IfNotPresent",
         "stdin":true,
         "tty":true
      }
   ]
}

Se puede ver el estado del Container efímero creado usando kubectl describe:

kubectl describe pod example-pod

...
Ephemeral Containers:
  debugger:
    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
    State:          Running
      Started:      Thu, 29 Aug 2019 06:42:21 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>
...

Se puede conectar al nuevo Container efímero usando kubectl attach:

kubectl attach -it example-pod -c debugger

Si el proceso Namespace de uso compartido está habilitado, se pueden visualizar los procesos de todos los Containers de ese Pod. Por ejemplo, después de haber conectado, ejecute ps en el debugger del container:

ps auxww

La respuesta es semejante a:

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 101       0:00 nginx: worker process
   13 101       0:00 nginx: worker process
   14 101       0:00 nginx: worker process
   15 101       0:00 nginx: worker process
   16 101       0:00 nginx: worker process
   17 101       0:00 nginx: worker process
   18 101       0:00 nginx: worker process
   19 root      0:00 /pause
   24 root      0:00 sh
   29 root      0:00 ps auxww