Configure los ganchos del ciclo de vida

Durante un cierre correcto de un contenedor, la aplicación debería responder a una SIGTERM señal iniciando el cierre para que los clientes no sufran ningún tiempo de inactividad. La aplicación debe ejecutar procedimientos de limpieza como los siguientes:

• Guardar datos

• Cerrar los descriptores de los archivos

• Cerrar conexiones a bases de datos

• Completar correctamente las solicitudes durante el vuelo

• Salir puntualmente para cumplir con la solicitud de cierre del módulo

Establece un período de gracia que sea lo suficientemente largo como para que finalice la limpieza. Para obtener información sobre cómo responder a la SIGTERM señal, consulte la documentación del lenguaje de programación que utilice para la aplicación.

Los ganchos de ciclo de vida de los contenedores permiten a los contenedores estar al tanto de los eventos de su ciclo de vida de administración. Los contenedores pueden ejecutar el código implementado en un controlador cuando se ejecuta el enlace del ciclo de vida correspondiente. Los enlaces del ciclo de vida de los contenedores ofrecen una solución alternativa a la naturaleza asíncrona de Kubernetes y la nube. Este enfoque puede evitar la pérdida de las conexiones que se reenvían al pod de destino antes que el recurso de entrada y que iptables se actualizan para no enviar tráfico nuevo al pod.

El ciclo de vida del contenedor y el punto final EndpointSlice son parte de un sistema diferente. APIs Es importante organizarlos APIs. Sin embargo, cuando se cierra un pod, la API de Kubernetes notifica simultáneamente tanto al kubelet (para el ciclo de vida del contenedor) como al controlador. EndpointSlice Para obtener más información, incluido un diagrama, consulte Gestionar correctamente las solicitudes de los clientes en las guías de prácticas recomendadas de EKS.

Cuando se kubelet envía SIGTERM al módulo, el EndpointSlice controlador termina el EndpointSlice objeto. Esa terminación notifica a los servidores de la API de Kubernetes que notifiquen la actualización kube-proxy de cada nodo. iptables Aunque estas acciones se producen al mismo tiempo, no hay dependencias ni secuencias entre ellas. Existe una alta probabilidad de que el contenedor reciba la SIGKILL señal mucho antes de que kube-proxy en cada nodo se actualicen iptables las reglas locales. En ese caso, los posibles escenarios incluyen los siguientes:

• Si su solicitud descarta de forma inmediata y sin rodeos las solicitudes en vuelo y las conexiones al recibirlas por parte de SIGTERM, los clientes, aparecerán errores. 500

• Si su solicitud garantiza que todas las solicitudes y conexiones durante el vuelo se procesen por completo al recibirlasSIGTERM, durante el período de gracia, las solicitudes de nuevos clientes seguirán enviándose al contenedor de solicitudes, ya que es posible que iptables las reglas aún no se hayan actualizado. Hasta que el procedimiento de limpieza cierre el socket del servidor del contenedor, esas nuevas solicitudes generarán nuevas conexiones. Cuando finaliza el período de gracia, las nuevas conexiones que se establecieron después del envío SIGTERM se eliminan incondicionalmente.

Para abordar los escenarios anteriores, puedes implementar la integración en la aplicación o el enlace del PreStop ciclo de vida. Para obtener más información, incluido un diagrama, consulte Cómo cerrar correctamente las aplicaciones en las guías de mejores prácticas de EKS.

Nota: Independientemente de si la aplicación se cierra correctamente o si es el resultado del bloqueo, preStop los contenedores de la aplicación finalizan al final del período de gracia. SIGKILL

Usa el preStop gancho con un sleep comando para retrasar el envío. SIGTERM Esto ayudará a seguir aceptando las nuevas conexiones mientras el objeto de entrada las dirige al pod. Pruebe el valor temporal del sleep comando para asegurarse de que se tiene en cuenta cualquier latencia de Kubernetes y otras dependencias de la aplicación, como se muestra en el siguiente ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      lifecycle:
        # This "sleep" preStop hook delays the Pod shutdown until
        # after the Ingress Controller removes the matching Endpoint or EndpointSlice
        preStop:
          exec:
            command:
              - /bin/sleep
              - "20"
              # This period should be turned to Ingress/Service Mesh update latency

Para obtener más información, consulte Container Hooks y EKS Best Practices: equilibrio de carga (cierre correcto de aplicaciones).