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
<a name="lifecycle-hooks"></a>

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](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) 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](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_handle_the_client_requests) 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 recibirlas`SIGTERM`, los clientes verán errores. `500`
+ Si su solicitud garantiza que todas las solicitudes y conexiones durante el vuelo se procesen por completo al recibirlas`SIGTERM`, 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](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) 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](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) en la documentación de Kubernetes y [Cierre correctamente las aplicaciones en](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) la Guía de prácticas recomendadas de *Amazon EKS*.