Cómo utilizar los ganchos de Kubernetes para realizar un seguimiento de los ciclos de vida de los contenedores

Los enlaces del ciclo de vida de los contenedores de Kubernetes le permiten responder a las creaciones y terminaciones de contenedores. Puede manejar eventos ejecutando un comando dentro del contenedor o realizando una solicitud HTTP a un punto final que expone.

Los enlaces se usan comúnmente para registrar eventos de contenedores, implementar secuencias de comandos de limpieza y ejecutar tareas asincrónicas después de que un nuevo Pod se une a su clúster. En este artículo, le mostraremos cómo adjuntar controladores de enlace a sus Pods y obtener más control sobre los ciclos de vida de los contenedores.

Los dos ganchos disponibles

Las versiones actuales de Kubernetes admiten dos enlaces de ciclo de vida de contenedores:

• PostStart - Los controladores de este gancho se llaman inmediatamente después de que se crea un nuevo contenedor.
• PreStop - Este enlace se invoca inmediatamente antes de que Kubernetes finalice un contenedor.

Se pueden manipular mediante dos mecanismos diferentes:

• Exec - Ejecuta un comando específico dentro del contenedor.
• HTTP - Realiza una solicitud HTTP a una URL dentro del contenedor.

Ninguno de los ganchos proporciona argumentos a sus controladores. Cada contenedor admite un solo manipulador por gancho; no es posible llamar a múltiples puntos finales o combinar un comando exec con una solicitud HTTP.

Definición de controladores de gancho

Usted define los controladores de ganchos para Pods usando su containers.lifecycle campo manifiesto. Dentro de este campo, establezca el postStart y preStop properties para implementar uno o ambos ganchos disponibles.

Aquí hay un Pod simple que registra un mensaje cuando se inicia:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-hooks
spec:
  containers:
    - name: pod-hook-container
      image: nginx:latest
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo STARTED > /startup_message"]

Aplique el Pod a su clúster usando Kubectl:

$ kubectl apply -f pod.yaml

Ahora obtenga un caparazón para el contenedor en ejecución dentro del Pod:

$ kubectl exec --stdin --tty pod/pod-with-hooks -- sh

Leer el contenido de la /startup_message expediente:

$ cat /startup_message
STARTED

Esto demuestra que el enlace se llamó con éxito. Un gancho ejecutivo se considera exitoso si su comando sale con un código de estado cero.

Controladores HTTP

Puede configurar un controlador HTTP reemplazando el exec campo con httpGet. Solo HTTP GET las solicitudes son compatibles (no hay httpPost campo).

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-hooks
spec:
  containers:
    - name: pod-hook-container
      image: nginx:latest
      lifecycle:
        postStart:
          httpGet:
            path: /startup
            port: 80

En este ejemplo, Kubernetes hace una GET solicitud de /startup en el puerto 80 del contenedor. httpGet campo también acepta scheme y host properties para configurar aún más la solicitud.

Aquí hay un Pod donde /shutdown se llama a través de HTTPS antes de que ocurra la terminación del contenedor:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-hooks
spec:
  containers:
    - name: pod-hook-container
      image: nginx:latest
      lifecycle:
        preStop:
          httpGet:
            path: /startup
            scheme: HTTPS

Se considera que los controladores de enlace HTTP han tenido éxito si el código de respuesta HTTP se encuentra en el rango 200-299.

Depuración de sus controladores

Los controladores de ganchos se administran independientemente de los pods a los que están conectados. Sus registros no se recopilan ni almacenan junto con los registros normales de Pod, por lo que no verá comandos ejecutivos como echo Started al correr kubectl logs pod/pod-with-hooks.

Puede depurar ganchos al ver el historial de eventos de un Pod. Las invocaciones fallidas se informarán como FailedPostStartHook y FailedPreStophook eventos. El mensaje de error incluye una descripción de lo que provocó el error.

Intente agregar este pod a su clúster:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-hooks
spec:
  containers:
    - name: pod-hook-container
      image: nginx:latest
      lifecycle:
        postStart:
          exec:
            command: ["missing-command"]

El enlace PostStart roto hará que falle el inicio del Pod. Usar kubectl describe para acceder a su historial de eventos:

$ kubectl describe pod/pod-with-hooks
...
Events:
  Type     Reason               Age                From               Message
  ----     ------               ----               ----               -------
  Normal   Scheduled            30s                default-scheduler  Successfully assigned pod-with-hooks...
  Normal   Created              10s (x2 over 11s)  kubelet            Created container pod-hook-container
  Normal   Started              10s (x2 over 11s)  kubelet            Started container pod-hook-container
  Warning  FailedPostStartHook  10s (x2 over 11s)  kubelet            Exec lifecycle hook ([missing-command]) for Container "pod-hook-container" in Pod "pod-with-hooks" failed - error: command 'missing-command' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "missing-command": executable file not found in $PATH: unknownrn"
  Normal   Killing              10s (x2 over 11s)  kubelet            FailedPostStartHook
  Warning  BackOff              5s (x2 over 6s)    kubelet            Back-off restarting failed container

los FailedPostStartHook evento revela que el controlador falló porque missing-command no es un ejecutable válido dentro del contenedor. Esto provocó que el contenedor se cerrara y se reiniciara en un ciclo de retroceso. Estará atascado así perpetuamente como missing-command nunca será ejecutable.

Gotchas a tener en cuenta

Las invocaciones de gancho tienen algunas características que pueden sorprenderte. Tener esto en cuenta puede ayudar a evitar comportamientos extraños y fallas inesperadas.

• Los ganchos se pueden llamar más de una vez. Kubernetes garantiza su PostStart y PreStop los manipuladores serán llamados “al menos” una vez por cada contenedor. En algunas situaciones, un enlace puede invocarse varias veces. Sus controladores deben ser idempotentes para que puedan soportar esta posibilidad.
• Los ganchos fallidos matan a su contenedor. Como ilustra el ejemplo de depuración anterior, los ganchos fallidos matan inmediatamente a su contenedor. Debe asegurarse de que sus comandos y puntos finales HTTP estén libres de errores para evitar problemas inesperados de inicio de Pod. Los controladores de ganchos deben ser livianos y libres de dependencias. No intente acceder a un recurso que podría no estar disponible inmediatamente después de que se inicie su contenedor.
• PostStart los ganchos compiten con el contenedor ENTRYPOINT. PostStart se dispara aproximadamente al mismo tiempo que se crea el contenedor. Sin embargo, Kubernetes no espera el gancho: se llamará de forma asíncrona junto con el contenedor. ENTRYPOINT, que podría completarse antes de que se invoque el controlador de gancho. Esto significa que el script de punto de entrada de su contenedor voluntad comience a ejecutarse incluso si su controlador informa un error y termina matando el contenedor.
• PreStop los ganchos bloquearán la terminación del contenedor. Kubernetes garantiza que sus contenedores no terminarán hasta que su PreStop los ganchos se han completado, hasta un tiempo máximo definido por el período de gracia de terminación del Pod. El contenedor se cancelará independientemente de si el gancho aún se está ejecutando cuando finalice el período de gracia.
• PreStop los ganchos no son necesarios terminado vainas Este puede ser particularmente impactante dependiendo de su caso de uso. La implementación actual de PreStop solo se dispara cuando hay un Pod terminado debido a eliminación, agotamiento de recursos, falla de un sondeo o un evento similar. El enlace no se llamará para los contenedores que se detienen de forma natural porque su proceso finaliza su tarea y sale con un código de error cero.

Los ganchos impactan directamente en la progresión del ciclo de vida de sus Pods. Los pods no se pueden marcar como Running hasta su PostStart gancho completa; del mismo modo, un Pod se atascará Terminating Hasta que PreStop ha terminado

Conclusión

Los eventos del ciclo de vida de Kubernetes son una forma de notificar a los contenedores sobre su propia creación y eliminación inminente. Al proporcionar comandos o puntos finales de API dentro de su contenedor, puede realizar un seguimiento de las etapas críticas del ciclo de vida e informarlas a otros componentes de su infraestructura.

Los eventos del ciclo de vida son fáciles de configurar, pero también tienen algunas dificultades comunes. Puede usar mecanismos adyacentes, como pruebas de inicio y preparación, si necesita una invocación más confiable. Estas son una mejor opción para los scripts que son esenciales al preparar el entorno de un nuevo contenedor.