View a markdown version of this page

Configure los enlaces del ciclo de vida de - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Configure los enlaces del ciclo de vida de

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 de Endpoint los contenedores y EndpointSlice forman parte de diferentes API. Es importante organizar estas API. 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 la Guía de prácticas recomendadas de Amazon EKS.

Cuando se kubelet envía SIGTERM al pod, 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 y conexiones durante el vuelo al recibirlasSIGTERM, los clientes verá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 finalice el período de gracia, las nuevas conexiones que se establecieron después del envío SIGTERM se eliminarán 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 Cierre correctamente las aplicaciones en la Guía de prácticas recomendadas de Amazon EKS.

nota

Independientemente de si la aplicación se cierra correctamente o como resultado del bloqueo, los preStop contenedores de la aplicación terminan cerrándose 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 en la documentación de Kubernetes y Cierre correctamente las aplicaciones en la Guía de prácticas recomendadas de Amazon EKS.