Ciclo de vida de un Pod
Esta página describe el ciclo de vida de un Pod.
Los Pods siguen un ciclo de vida definido, comenzando en la fase Pending
,
y luego pasando a "en ejecución" Running
si al menos uno de sus contenedores primarios se
inicia correctamente,
y luego pasando a "exitoso" (Succeeded
) o "fallido" (Failed
) si uno de los contenedores de un Pod
termina en error.
Al igual que contenedores de aplicaciones, los Pods se consideran entidades relativamente efímeras. Los Pods se crean y se les asigna un identificador único (UID), y se programan para ejecutarse en nodos donde se mantienen hasta que se terminan (de acuerdo con las políticas de reinicio) o se eliminan.
Si un nodo muere, los Pods programados para ejecutarse en ese Nodo se programan para eliminarse. El plano de control marca los Pods para ser eliminados luego de un periodo de tiempo.
Ciclo de vida de un Pod
Mientras un Pod se está ejecutando, el kubelet puede reiniciar contenedores para manejar algunos tipos de fallos. Dentro de un Pod, Kubernetes rastrea distintos estados del contenedor y determina qué acción realizar para que el Pod esté sano nuevamente.
En la API de Kubernetes, los Pods tienen una especificación y un estatus actual. El estatus de un objeto Pod consiste en un conjunto de condiciones del Pod. También puedes inyectar información de readiness personalizada a los datos de condición de un Pod, si es útil para tu aplicación.
Los Pods solo se programan una vez en su ciclo de vida; asignar un Pod a un nodo específico se llama vincular (binding, en inglés), y el proceso de seleccionar cuál Pod usar se llama programar. Una vez que un Pod está vinculado a un nodo, Kubernetes intenta ejecutar el Pod en ese nodo. El Pod se ejecuta en ese nodo hasta que termina, o hasta que es terminado; si Kubernetes no es capaz de iniciar el Pod en el nodo seleccionado (por ejemplo, si el nodo falla antes que el Pod inicie), entonces ese Pod en particular nunca inicia.
Puedes usar readiness de programación del Pod para retrasar la programación de un Pod hasta que todas sus puertas de programación sean removidas. Por ejemplo, podrías querer definir un conjunto de Pods, pero solo lanzar la programación una vez que todos los Pods hayan sido creados.
Recuperación de fallos en los Pods
Si falla uno de los contenedores en el Pod, Kubernetes puede intentar reiniciar ese contenedor en específico. Para saber más, lea cómo los Pods manejan los errores del contenedor.
Sin embargo, los Pods pueden fallar de una manera que el clúster no puede recuperar, y en ese caso Kubernetes no intenta más sanar el Pod; en su lugar, Kubernetes elimina el Pod y confía en otros componentes para proporcionar una curación automática.
Si un Pod está programado para un nodo y ese nodo luego falla, el Pod se trata como no saludable y Kubernetes eventualmente elimina el Pod. Un Pod no sobrevivirá a una evacuación debido a la falta de recursos o al mantenimiento del Nodo.
Kubernetes utiliza una abstracción de nivel superior, llamada controlador, que maneja el trabajo de gestionar las instancias de Pods relativamente desechables.
Un Pod dado (como se define por un UID) nunca es "reprogramado" a un nodo diferente; en su lugar,
ese Pod puede ser reemplazado por un nuevo Pod casi idéntico.
Si hace un Pod de reemplazo, incluso puede
tener el mismo nombre (como en .metadata.name
) que tenía el Pod antiguo, pero el reemplazo
tendría un .metadata.uid
diferente del Pod antiguo.
Kubernetes no garantiza que un reemplazo de un Pod existente sea programado en el mismo nodo en el que el antiguo Pod estaba siendo reemplazado.
Ciclo de vida asociados
Cuando se dice que algo tiene la misma vida útil que un Pod, como un volúmen, eso significa que el objeto existe mientras ese Pod específico (con ese UID exacto) exista. Si ese Pod se elimina por cualquier razón, e incluso si se crea un reemplazo idéntico, el objeto relacionado (un volumen, en este ejemplo) también se destruye y se crea nuevamente.
Fase del Pod
El campo status
de un Pod es un objeto
PodStatus
de Kubernetes que tiene un campo phase
.
La fase de un Pod es un resumen simple y de alto nivel de dónde se encuentra el Pod en su ciclo de vida. La fase no pretende ser un resumen completo de observaciones del estado del contenedor o Pod, ni tampoco pretende ser una máquina de estado completa.
El número y los significados de los valores de fase de un Pod están
estrechamente guardados.
Aparte de lo que se documenta aquí, no se debe asumir nada acerca de los Pods
que tienen un valor de phase
determinado.
Aquí están los posibles valores de phase
:
Valor | Descripción |
---|---|
Pending | El clúster de Kubernetes aceptó el Pod, pero uno o más contenedores no se configuraron ni prepararon para ejecutarse. Esto incluye el tiempo que pasa un Pod esperando ser programado, así como el tiempo dedicado a descargar imágenes de contenedores a través de la red. |
Running | El Pod se vinculó a un nodo y se crearon todos los contenedores. Al menos un contenedor todavía se está ejecutando o está en proceso de iniciarse o reiniciarse. |
Succeeded | Todos los contenedores del Pod finalizaron con éxito y no se reiniciarán. |
Failed | Todos los contenedores del Pod han finalizado y al menos un contenedor ha finalizado con error. Es decir, el contenedor salió con un estado distinto de cero o el sistema lo canceló. |
Unknown | Por alguna razón no se pudo obtener el estado del Pod. Esta fase generalmente ocurre debido a un error en la comunicación con el nodo donde debería ejecutarse el Pod. |
Nota:
Cuando se está borrando un Pod, se muestra comoTerminating
por algunos
comandos de kubectl.
Este estado Terminating
no es una de las fases del Pod.
A un Pod se le garantiza un tiempo para terminar con gracia,
cuyo valor por defecto es 30 segundos.
Puedes utilizar el flag --force
para terminar un Pod por la fuerza.A partir de la versión 1.27 de Kubernetes, el kubelet aplica una transición de
los Pods borrados, excepto
por Pods estáticos
y Pods borrados por la fuerza sin un finalizador, a
una fase terminal
(Failed
o Succeeded
dependiendo de los códigos de salida de los contenedores
del Pod) antes de su eliminación del servidor API.
Si un Nodo muere o se desconecta del resto del clúster,
Kubernetes aplica una política para establecer la phase
de todos los Pods
en Failed
.
Estados del contenedor
Así como la fase del Pod en general, Kubernetes rastrea el estado de cada contenedor dentro de un Pod. Puedes usar hooks del ciclo de vida de un contenedor para lanzar eventos en ciertos puntos en el ciclo de vida de un contenedor.
Una vez que el programador
asigna un Pod a un Nodo,
el kubelet inicia creando los contenedores para ese Pod usando un
runtime del contenedor.
Hay 3 estados posibles para un contenedor: Waiting
(esperando), Running
(en ejecución), y Terminated
(terminado).
Para revisar el estado de los contenedores de un Pod,
puedes usar kubectl describe pod <name-of-pod>
.
La salida muestra el estado de cada contenedor dentro del Pod.
Cada estado tiene un significado específico:
Waiting
Si un contenedor no está en el estado Running
o Terminated
, está Waiting
.
Un contenedor en el estado Waiting
aún está ejecutando las operaciones que
requiere para completar su arranque:
por ejemplo,
descargar la imagen del contenedor de un registro de imágenes de un contenedor,
o aplicando datos secretos.
Running
El estado Running
indica que el contenedor se está ejecutando sin problemas.
Si hay un hook postStart
configurado, ya se ha ejecutado y finalizado.
Cuando utilizas el comando kubectl
para consultar un Pod con un contenedor que
está Running
,
también puedes ver información sobre cuando el contenedor entró en
estado Running
.
Terminated
Un contenedor en el estado Terminated
comenzó su ejecución y luego se terminó
con éxito o falló por alguna razón.
Cuando usas kubectl
para consultar un Pod con un contenedor que
está Terminated
, puedes ver un motivo, y un código de salida, y la hora de
inicio y de finalización del contenedor.
Si un contenedor tiene un hook preStop
configurado, el hook se ejecuta antes
de que el contenedor entre en estado Terminated
.
Cómo los Pods manejan los problemas con los contenedores
Kubernetes maneja los fallos de los contenedores dentro de los Pods usando una política de reinicio, restartPolicy
en inglés definida en la especificación spec
del Pod.
Esta política determina cómo reacciona Kubernetes cuando los contenedores salen debido a errores u otras razones, que sigue la siguiente secuencia:
Fallo inicial: Kubernetes intenta un reinicio inmediato basado en la
restartPolicy
del Pod.Fallos repetidos: Después del fallo inicial, Kubernetes aplica un retraso exponencial para los reinicios subsiguientes, descrito en restartPolicy. Esto evita que los intentos de reinicio rápidos y repetidos sobrecarguen el sistema.
Estado de CrashLoopBackOff: Esto indica que el mecanismo de retraso exponencial está actualmente en efecto para un contenedor dado que está en un bucle de fallos, fallando y reiniciando repetidamente.
Reinicio del retraso: Si un contenedor funciona correctamente durante un cierto período (por ejemplo, 10 minutos), Kubernetes reinicia el retraso, tratando cualquier nuevo fallo como el primero.
En la práctica, un
CrashLoopBackOff
es una condición o evento que podría verse como salida del comandokubectl
, al describir o listar Pods, cuando un contenedor en el Pod no arranca correctamente y luego intenta y falla continuamente en un bucle.
En otras palabras, cuando un contenedor entra en el bucle de fallos, Kubernetes aplica el retraso exponencial mencionado en la Política de reinicio del contenedor. Este mecanismo evita que un contenedor defectuoso sobrecargue el sistema con intentos de inicio fallidos continuos.
El CrashLoopBackOff
puede ser causado por problemas como los siguientes:
- Errores de la aplicación que hacen que el contenedor salga.
- Errores de configuración, como variables de entorno incorrectas o archivos de configuración faltantes.
- Restricciones de recursos, donde el contenedor puede no tener suficiente memoria o CPU para arrancar correctamente.
- Fallos en los chequeos de salud si la aplicación no comienza a servir dentro del tiempo esperado.
- Las sondas de liveness o de arranque del contenedor devuelven un resultado de
Failure
como se menciona en la sección de sondas. Para investigar la causa raíz de un problema deCrashLoopBackOff
, un usuario puede:
- Revisar los registros: Use
kubectl logs <nombre-del-pod>
para revisar los registros del contenedor. Esta es a menudo la forma más directa de diagnosticar el problema que causa los fallos. - Inspeccionar eventos: Use
kubectl describe pod <nombre-del-pod>
para ver eventos para el Pod, lo que puede proporcionar pistas sobre problemas de configuración o recursos. - Revisar la configuración: Asegúrese de que la configuración del Pod, incluidas las variables de entorno y los volúmenes montados, sea correcta y que todos los recursos externos necesarios estén disponibles.
- Verificar los límites de recursos: Asegúrese de que el contenedor tenga suficiente CPU y memoria asignada. A veces, aumentar los recursos en la definición del Pod puede resolver el problema.
- Depurar la aplicación: Pueden existir errores o configuraciones incorrectas en el código de la aplicación. Ejecutar esta imagen de contenedor localmente o en un entorno de desarrollo puede ayudar a diagnosticar problemas específicos de la aplicación.
Política de reinicio del contenedor
La especificación (spec
en inglés) de un Pod tiene un campo restartPolicy
con los posibles
valores Always
, OnFailure
, y Never
.
El valor por defecto es Always
.
La política de reinicio (restartPolicy
en inglés) para un Pod aplica a
contenedores de apps en el Pod
para contenedores de inicialización regulares.
Los contenedores sidecar
ignoran el campo restartPolicy
: en Kubernetes, un sidecar se define como una
entrada dentro de initContainers
que tiene su restartPolicy
a nivel del contenedor
establecido en Always
. Para contenedores de inicio que finalizan con un error, el kubelet reinicia el
contenedor de inicio si el nivel del Pod restartPolicy
es OnFailure
o Always
:
Always
: Automáticamente reinicia el contenedor luego de alguna terminación.OnFailure
: Solo reinicia el contenedor si finaliza con un error (estado de salida distinto de cero).Never
: No reinicia el contenedor automáticamente.
Cuando el kubelet está manejando el contenedor, se reinicia de acuerdo con la política de reinicio configurada, que solo se aplica a los reinicios que realizan contenedores de
reemplazo dentro del
mismo Pod y ejecutándose en el mismo nodo.
Después de que los contenedores en un Pod terminan, el kubelet
los reinicia con un retraso de retroceso exponencial (10s, 20s, 40s,...), que
está limitado a
cinco minutos. Una vez que un contenedor se ha ejecutado durante 10 minutos sin
ningún problema, el
kubelet restablece el temporizador de reinicio para ese contenedor.
Ciclo de vida de contenedores Sidecar y el Pod
explica el comportamiento de init containers
cuando
especifica una restartPolicy
.
Condiciones del Pod
Un Pod tiene un PodStatus
, que tiene un listado de
PodConditions
a través de los cuales el Pod ha pasado o no.
El kubelet administra las siguientes condiciones del Pod:
PodScheduled
: El Pod está programado para un nodo.PodReadyToStartContainers
: (característica beta; habilitada por defecto) La zona de pruebas del Pod se creó correctamente y se configuró la red.ContainersReady
: todos los contenedores en el Pod están listos.Initialized
: todos los contenedores de inicio han terminado exitosamente.Ready
: el Pod es capaz de recibir peticiones y debería ser agregado a los grupos de equilibrio de carga de todos los Services que coincidan.
Nombre del campo | Descripción |
---|---|
type | Nombre de esta condición del Pod. |
status | Indica si la condición es aplicable, con valores posibles "True ", "False ", ó "Unknown ". |
lastProbeTime | Marca de tiempo de cuando se probó por última vez la condición del Pod. |
lastTransitionTime | Marca de tiempo de cuando el Pod hizo transición de un estado a otro. |
reason | Texto legible por máquina que indica el motivo de la última transición de la condición. |
message | Mensaje legible por humanos indicando detalles acerca de la última transición de estado. |
Preparación del Pod
Kubernetes v1.14 [stable]
Tu aplicación puede inyectar retroalimentación adicional o señales
al PodStatus
:
Pod readiness.
Para usar esto, establece readinessGates
en la spec
del Pod para especificar una
lista de condiciones adicionales que el kubelet evalúa para la preparación del
Pod.
Las condiciones de preparación están determinadas por el estado actual de los
campos status.conditions
de un Pod.
Si Kubernetes no puede encontrar una condición en el campo status.conditions
de un Pod, el estado de la condición se establece en "False
".
Aquí hay un ejemplo:
kind: Pod
...
spec:
readinessGates:
- conditionType: "www.example.com/feature-1"
status:
conditions:
- type: Ready # una PodCondition construida
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
- type: "www.example.com/feature-1" # una PodCondition extra
status: "False"
lastProbeTime: null
lastTransitionTime: 2018-01-01T00:00:00Z
containerStatuses:
- containerID: docker://abcd...
ready: true
...
Las condiciones del Pod que incluyas deben tener nombres que sean válidos para los formatos de etiqueta de Kubernetes.
Estado de preparación del Pod
El comando kubectl patch
no admite actualizar el estado del objeto.
Para establecer estas status.conditions
para el Pod, las aplicaciones y
los operadores
deberían utilizar la acción Patch
.
Puedes utilizar una librería cliente de Kubernetes para escribir código que establece condiciones personalizadas de un Pod para su preparación.
Para los Pods que utilizan condiciones personalizadas, ese Pod es evaluado para estar listo solamente cuando ambas afirmaciones aplican:
- Todos los contenedores del Pod están listos.
- Todas las condiciones personalizadas especificadas en
readinessGates
estánTrue
.
Cuando los contenedores de un Pod están listos, pero al menos una condición
personalizada está ausente o False
,
el kubelet establece la condición del Pod
en ContainersReady
.
Preparación de la red del Pod
Kubernetes v1.29 [beta]
Nota:
Durante su desarrollo temprano, esta condición se llamóPodHasNetwork
.Después de que un Pod es programado en un nodo, necesita ser admitido por el kubelet y
tener cualquier volumen de almacenamiento requerido montado.
Una vez que estas fases se completan,
el kubelet trabaja con
un runtime de contenedores (usando Container runtime interface (CRI)) para configurar un
sandbox de runtime y configurar la red para el Pod.
Si la puerta de características
PodReadyToStartContainersCondition
está habilitada
(está habilitada por defecto para Kubernetes 1.31), la
condición PodReadyToStartContainers
se agregará al campo status.conditions
de un Pod.
La condición PodReadyToStartContainers
se establece en False
por el kubelet cuando detecta que un
Pod no tiene un sandbox de runtime con red configurada.
Esto ocurre en los siguientes escenarios:
- Al principio del ciclo de vida del Pod, cuando el kubelet aún no ha comenzado a configurar un sandbox para el Pod usando el runtime de contenedores.
- Más adelante en el ciclo de vida del Pod, cuando el sandbox del Pod ha sido destruido debido a:
- el nodo reiniciándose, sin que el Pod sea desalojado.
- para runtimes de contenedores que usan máquinas virtuales para aislamiento, la máquina virtual del sandbox del Pod reiniciándose, lo que luego requiere crear un nuevo sandbox y una nueva configuración de red para el contenedor.
La condición PodReadyToStartContainers
se establece en True
por el kubelet después de la
finalización exitosa de la creación del sandbox y la configuración de la red para el Pod
por el plugin de runtime. El kubelet puede comenzar a extraer imágenes de contenedores y crear
contenedores después de que la condición PodReadyToStartContainers
se haya establecido en True.
Para un Pod con contenedores de inicialización, el kubelet establece la condición Initialized
en
True
después de que los contenedores de inicialización se hayan completado exitosamente (lo que ocurre
después de la creación exitosa del sandbox y la configuración de la red por el plugin de runtime).
Para un Pod sin contenedores de inicialización, el kubelet establece la condición Initialized
en True
antes de que comience la creación del sandbox y la configuración de la red.
Sondeos del contenedor
Una sonda es un diagnóstico realizado periódicamente por el kubelet en un contenedor. Para ejecutar este diagnóstico, el kubelet ejecuta código dentro del contenedor o realiza una solicitud de red.
Mecanismos de revisión
Existen cuatro maneras diferentes de revisar un contenedor usando una sonda. Cada sonda debe definir exactamente una de estas cuatro maneras:
exec
: Ejecuta un comando especificado dentro del contenedor.
El diagnóstico se considera exitoso si el comando termina con un código de
estado 0.
grpc
- Realiza una llamada de procedimiento remoto usando gRPC.
El destino debe
implementar revisión de estado de gRPC.
El diagnóstico se considera exitoso si el
status
de la respuesta esSERVING
. httpGet
- Realiza una petición HTTP
GET
contra la dirección IP en la ruta y puerto especificado. El diagnóstico se considera exitoso si la respuesta tiene un código de estado mayor o igual que 200 y menor que 400. tcpSocket
- Realiza una revisión TCP contra la dirección IP del Pod en un puerto específico. El diagnóstico se considera exitoso si el puerto está abierto. Si el sistema remoto (el contenedor) cierra la conexión inmediatamente después de abrir la conexión, el diagnóstico se considera exitoso.
Precaución:
A diferencia de otros mecanismos, la implementación de la sonda exec
involucra
la creación/bifurcación de múltiples procesos cada vez que se ejecuta.
Como resultado, en caso de clústers con mayor densidad de Pods, intérvalos más
bajos de initialDelaySeconds
, periodSeconds
, configurando un sondeo
con exec
puede introducir una sobrecarga en el uso de la CPU del nodo.
En tales escenarios, considere la utilización de los mecanismos alternativos de sondeo para evitar la sobrecarga.
Resultados de sondeos
Cada sondeo puede tener uno de tres resultados:
Success
- El contenedor ha pasado el diagnóstico.
Failure
- El contenedor ha fallado el diagnóstico.
Unknown
- El diagnóstico ha fallado (no se debe tomar ninguna acción, y el kubelet hará más revisiones adicionales).
Tipos de sondeo
Opcionalmente, el kubelet puede ejecutar y reaccionar a tres tipos de sondeos en contenedores en ejecución:
livenessProbe
- Indica si el contenedor se está ejecutando.
Si el sondeo falla, el kubelet mata el contenedor,
y el contenedor está sujeto a su política de reinicio.
Si un contenedor no tiene un sondeo de liveness, el estado por defecto
es
Success
. readinessProbe
- Indica si un contenedor está preparado para responder a peticiones.
Si el sondeo falla,
el controlador de endpoints elimina las direcciones IP del Pod de los endpoints
de todos los Services que coinciden con el Pod.
El estado por defecto de readiness antes del retraso inicial es
Failure
. Si un contenedor no tiene un sondeo de readiness, el estado por defecto esSuccess
. startupProbe
- Indica si la aplicación dentro del contenedor ha iniciado. El resto de los
sondeos están deshabilitados si un sondeo de inicio se proporciona, hasta que se
complete. Si el sondeo falla, el kubelet mata el contenedor y el contenedor
está sujeto a su política de reinicio. Si un contenedor no
tiene un sondeo de inicio, el estado por defecto es
Success
.
Para mayor información sobre como configurar un sondeo liveness, readiness o de startup, mira la sección Configurar una sonda Liveness, Readiness y Startup.
¿Cuándo debería utilizar un sondeo liveness?
Si el proceso en tu contenedor es capaz de terminar por sí mismo cuando
encuentra un error o deja de estar sano, no necesitas un sondeo liveness; el
kubelet automáticamente realizará la acción adecuada de acuerdo con la política
de reinicio restartPolicy
del Pod.
Si te gustaría que tu contenedor fuese destruido y reiniciado si falla un
sondeo, especifica un sondeo liveness y especifica una restartPolicy
de Always
o OnFailure
.
¿Cuándo debería utilizar un sondeo readiness?
Se te gustaría enviar tráfico al Pod solo cuando una sonda sea exitosa, especifica un sondeo readiness. En este caso, el sondeo readiness podría ser el mismo que el liveness, pero la existencia del sondeo readines en la especificación significa que el Pod iniciará sin recibir ningún tráfico y solo iniciará cuando el sondeo readiness sea exitoso.
Si quieres que tu contenedor sea capaz de darse de baja por mantenimiento por sí mismo, puedes especificar un sondeo de readiness que revisa un endpoint específico de readiness que es distinto del sondeo liveness.
Si tu aplicación tiene una dependencia estricta con servicios de trasfondo, puedes implementar ambos sondeos de liveness y readiness. El sondeo de liveness pasa cuando la aplicación por sí misma está sana, pero el sondeo de readiness revisa adicionalmente que cada servicio de trasfondo está disponible. Esto ayuda a evitar enviar a Pods que solo pueden responder con errores.
Si tu contenedor necesita trabajar cargando grandes datos, ficheros de configuración, o migraciones durante el inicio, puedes usar un sondeo de inicio. Sin embargo, si quieres detectar la diferencia entre una aplicación que ha fallado y una aplicación que todavía está procesando datos de inicialización, puedes usar un sondeo de readiness.
Nota:
Si quieres ser capaz de drenar peticiones cuando se elimina el Pod, no necesitas un sondeo readiness; cuando se elimina el Pod, automáticamente se cambia al estadounready
sin importar si existe el sondeo
readiness.
El Pod permanece en el estado unready
mientras espera que los contenedores en
el Pod se paren.¿Cuándo debería utilizar un sondeo de inicialización?
Los sondeos de inicialización son útiles para Pods que tienen contenedores que se toman un largo tiempo para estar en servicio. En lugar de especificar un intérvalo largo de liveness, puedes crear una configuración separada para sondear el contenedor en el inicio, permitiendo un tiempo mayor que el intervalo de liveness.
Si tu contenedor usualmente inicia en más
de initialDelaySeconds + failureThreshold × periodSeconds
, deberías
especificar un sondeo de inicialización que revise el mismo endpoint que la
sonda liveness.
El periodo por defecto periodSeconds
es de 10 segundos.
Deberías especificar el campo failureThreshold
lo suficientemente alto para
permitir al contenedor arrancar, sin cambiar los valores por defecto de la sonda
liveness.
Esto ayuda a proteger contra puntos muertos.
Finalización de Pods
Ya que los Pods representan procesos ejecutándose en nodos de un clúster, es
importante permitir que esos procesos terminen con gracia cuando no se
necesitan (en lugar de detenerse abruptamente con una señal Kill
y sin
oportunidad de limpiarse).
El diseño está orientado a permitir que puedas solicitar la eliminación de un Pod y saber cuándo finalizan los procesos, pero también para asegurar que la eliminación se completa eventualmente. Cuando solicitas la eliminación de un Pod, el clúster registra y rastrea el periodo de gracia antes de que el Pod se elimine por la fuerza. Con este rastreo de detención forzada en marcha, el kubelet intenta pararlo con gracia.
Típicamente, con esta finalización con gracia del Pod, el kubelet hace
peticiones al tiempo de ejecución del contenedor para intentar detener los
contenedores en el Pod, primeramente enviando una señal Term
(ej. SIGTERM),
con un período de tiempo de gracia, al proceso principal de cada contenedor.
Las peticiones para parar los contenedores se procesan de forma asíncrona en el
tiempo de ejecución del contenedor.
No hay garantía del orden de procesamiento de estas peticiones.
Muchos contenedores respetan el valor STOPSIGNAL
definido en la imagen del
contenedor y, si es diferente, envían el valor de STOPSIGNAL
en lugar de
TERM.
Una vez que el período de gracia ha acabado, se envía la señal KILL a cualquier proceso restante, y luego el Pod se elimina del Servidor API. Si el kubelet o el tiempo de ejecución del contenedor del servicio que lo administra se reinicia mientras espera que los procesos terminen, el kubelet reintenta de nuevo el proceso incluyendo el periodo original de gracia.
Un flujo de finalización de un Pod, ilustrado con un ejemplo:
Utilizas la herramienta
kubectl
para eliminar manualmente un Pod específico, con un periodo de gracia por defecto (30 segundos).El Pod en el servidor API se actualiza con el tiempo más allá del cual el Pod se considera "muerto" junto con el periodo de gracia. Si utilizas
kubectl describe
para revisar el Pod que estás borrando, ese Pod se mostrará comoTerminating
. En el nodo donde se ejecuta el Pod: tan pronto como el kubelet observa que el Pod se ha marcado como terminando (se ha definido una duración de parada con gracia), el kubelet comienza el proceso local de parar el Pod.- Si uno de los contenedores del Pod tiene definido
un hook
preStop
y elterminationGracePeriodSeconds
en la especificación del Pod no está definido en 0, el kubelet ejecuta ese hook dentro del contenedor. ElterminationGracePeriodSeconds
por defecto es 30 segundos.
Si el hook
preStop
todavía se está ejecutando luego de la expiración del período de gracia, el kubelet solicita una extensión 2 segundos del periodo de gracia.Nota:
Si el hookpreStop
necesita más tiempo para completar que el tiempo permitido por defecto, debes modificar elterminationGracePeriodSeconds
para adaptarlo.- El kubelet lanza el tiempo de ejecución del contenedor para enviar una
señal TERM al proceso 1 dentro de cada contenedor.
Nota:
Los contenedores en el Pod reciben la señal TERM en tiempos diferentes y en orden arbitrario. Si el orden de finalización importa, considera utilizar un hookpreStop
para sincronizarlos.
- Si uno de los contenedores del Pod tiene definido
un hook
Al mismo tiempo que el kubelet inicia la finalización con gracia del Pod, el panel de control evalúa si quitar este Pod en finalización de los objetos
EndpointSlice
(yEndpoints
), donde aquellos objetos representan un Service con un selector configurado.Los ReplicaSets y otros recursos de carga de trabajo ya no consideran al Pod como réplica válida, en servicio.
Los Pods que finalizan lentamente no servirían tráfico regular y debería iniciar la finalización de procesamiento de conexiones abiertas. Algunas aplicaciones necesitan ir más allá de finalizar las conexiones abiertas y necesitan finalización aún con más gracia, por ejemplo, drenar y completar una sesión.
Cualquier endpoint que representa los Pods en finalización no son removidos inmediatamente de
EndpointSlices
y se expone un estatus indicando el estado de terminación de la API de EndpointSlice (y la API de Endpoint legada). Los endpoints que están terminando siempre tienen su estatusready
comofalse
(para compatibilidad con versiones anteriores a 1.26), por lo que los balanceadores de carga no los usarán para tráfico regular.Si se necesita drenar el tráfico en un Pod que está terminando, el readiness se puede revisar con la condición
serving
. Puedes encontrar más detalles en cómo implementar drenado de conexiones en el tutorial Pods y flujo de terminación de Endpoints
- El kubelet se asegura que el Pod se ha apagado y terminado
- Cuando finaliza el tiempo de gracia, si aún existe algún contenedor ejecutándose en el Pod, el kubelet lanza un apagado forzado.
El runtime del contenedor envía una señal
SIGKILL
a cualquier proceso ejecutándose en cualquier contenedor en el Pod. El kubelet también limpia un contenedorpause
oculto si ese contenedor usa uno. - El kubelet hace la transición del Pod a una fase terminal (
Failed
óSucceeded
dependiendo del estado final de sus contenedores). - El Kubelet lanza la eliminación forzosa de los objetos del Pod del servidor API, estableciendo el periodo de gracia a 0 (detención inmediata).
- El servidor API elimina el objeto API del Pod, que ya no es visible desde ningún cliente.
- Cuando finaliza el tiempo de gracia, si aún existe algún contenedor ejecutándose en el Pod, el kubelet lanza un apagado forzado.
El runtime del contenedor envía una señal
Terminación Forzada del Pod
Precaución:
Eliminaciones forzadas pueden ser potencialmente disruptivas para algunas cargas de trabajo y sus Pods.Por defecto, todas las eliminaciones tienen un tiempo de gracia de 30 segundos.
El comando kubelet delete
soporta la opción --grace-period=<segundos>
que
permite sobreescribir el valor por defecto y especificar tu propio valor.
Establecer el período de gracia a 0
elimina de forma forzada e inmediata el
Pod del servidor API.
Si el Pod aún se está ejecutando en un nodo, esa eliminación forzada hace que
el kubelet inicie una limpieza inmediata.
Usando kubectl, debes especificar una opción adicional --force
junto con --grace-period=0
para realizar eliminaciones forzadas.
Cuando se realiza una eliminación forzada, el servidor API no espera la confirmación del kubelet de que el Pod ha terminado en el nodo en que se está ejecutando. Este elimina el Pod en la API inmediatamente para que se pueda crear un Pod con el mismo nombre. En el nodo, los Pods que están por terminar inmediatamente aún pueden tener un pequeño período de gracia antes de ser eliminados de forma forzada.
Precaución:
La eliminación inmediata no espera la confirmación de que el recurso en ejecución ha terminado. El recurso puede continuar ejecutándose en el clúster de forma indefinida.Si necesitas eliminar Pods por la fuerza y son parte de un StatefulSet
,
mira la documentación
para borrar Pods de un StatefulSet.
Terminación del Pod y contenedores sidecar
Si tus Pods incluyen uno o más contenedores sidecar (contenedores de inicialización con una política de reinicio Always
), el kubelet retrasará el envío de la señal TERM a estos contenedores sidecar hasta que el último contenedor principal se haya terminado completamente.
Los contenedores sidecar serán eliminados en orden inverso al que se han definido en la especificación del Pod.
Esto asegura que los contenedores sidecar continúan sirviendo a los otros contenedores en el Pod hasta que ya no se necesiten.
Esto significa que la terminación lenta de un contenedor principal también retrasará la terminación de los contenedores sidecar.
Si el periodo de gracia expira antes que se complete el proceso de terminación, el Pod podría entrar en terminación forzada. En este caso, todos los contenedores restantes en el Pod serán terminados simultáneamente con un periodo de gracia corto.
De forma similar, si el Pod tiene un hook preStop
que excede el periodo de gracia de finalización, puede ocurrir una terminación de emergencia.
En general, si has usado hooks de preStop
para controlar el orden de terminación sin contenedores sidecar, puedes quitarlos y permitir que el kubelet maneje la terminación de sidecars automáticamente.
Recolección de elementos no utilizados de los Pods
Cuando los Pods fallan, los objetos API permanecen en el clúster hasta que un humano o el proceso de controlador los elimine explícitamente.
El recolector de elementos no utilizados (PodGC en inglés) es un controlador en
el plano de control que elimina los Pods que se han terminado (con una fase
de Succeeded
o Failed
), cuando el número de Pods excede el umbral
configurado (determinado por terminated-pod-gc-threshold
en el controlador de
kube-controller-manager).
Esto evita la fuga de recursos mientras que los Pods se crean y se eliminan en
el tiempo.
Adicionalmente, el PodGC limpia cualquier Pod que satisfaga cualquiera de las siguientes condiciones:
- Pods huérfanos - asociados a un Nodo que ya no existe,
- Pods que están finalizando y no están programados,
- Pods que están finalizando,
asociados a un nodo que no está listo, contaminado
con
node.kubernetes.io/out-of-service
, cuando la condiciónNodeOutOfServiceVolumeDetach
está habilitada.
Cuando la condición PodDisruptionCondition
está habilitada,
además de limpiar los Pods,
el PodGC también los marcará como fallidos si están en una fase no terminal.
También, el PodGC agrega una condición de disrupción del Pod cuando realiza la limpieza de un Pod huérfano.
Mira condiciones de disrupción del Pod para más detalles.
Siguientes pasos
Obtén experiencia práctica agregando controladores a los eventos del ciclo de vida del contenedor.
Obtén experiencia práctica configurando sondas de Liveness, Readiness y Startup.
Aprende más sobre hooks del ciclo de vida del contenedor.
Aprende más sobre contenedores sidecar.
Para información detallada sobre el estatus del contenedor del Pod en la API, mira la documentación de referencia de la API que cubre el
status
del Pod.