Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Configurer les hooks du cycle de vie des conteneurs
<a name="lifecycle-hooks"></a>

Lors d'un arrêt progressif d'un conteneur, votre application doit répondre à un `SIGTERM` signal en démarrant son arrêt afin que les clients ne subissent aucune interruption de service. Votre application doit exécuter des procédures de nettoyage telles que les suivantes :
+ Sauvegarde des données
+ Fermeture des descripteurs de fichiers
+ Fermeture des connexions à la base
+ Répondre aux demandes en vol avec élégance
+ Sortir en temps opportun pour répondre à la demande de résiliation du pod

Définissez une période de grâce suffisamment longue pour que le nettoyage soit terminé. Pour savoir comment réagir au `SIGTERM` signal, consultez la documentation du langage de programmation que vous utilisez pour votre application.

[Les crochets relatifs au cycle](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) de vie des conteneurs permettent aux conteneurs d'être informés des événements survenant au cours de leur cycle de vie de gestion. Les conteneurs peuvent exécuter du code implémenté dans un gestionnaire lorsque le hook de cycle de vie correspondant est exécuté. Les hooks relatifs au cycle de vie des conteneurs permettent de contourner la nature asynchrone de Kubernetes et du cloud. Cette approche permet d'éviter la perte des connexions qui sont transmises au module de terminaison avant la ressource d'entrée et qui `iptables` sont mises à jour pour ne pas envoyer de nouveau trafic vers le module.

Cycle de vie des conteneurs`Endpoint`, et `EndpointSlice` font partie de différentes API. Il est important d'orchestrer ces API. Cependant, lorsqu'un pod est arrêté, l'API Kubernetes avertit simultanément le kubelet (pour le cycle de vie du conteneur) et le contrôleur. `EndpointSlice` Pour plus d'informations, y compris un schéma, consultez la section [Gérer avec élégance les demandes des clients](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_handle_the_client_requests) dans le *guide des meilleures pratiques Amazon EKS*.

Lorsqu'il est `kubelet` envoyé `SIGTERM` au pod, le `EndpointSlice` contrôleur met fin à l'`EndpointSlice`objet. Cette résiliation indique aux serveurs d'API Kubernetes de signaler chaque nœud à mettre à `kube-proxy` jour. `iptables` Bien que ces actions se produisent en même temps, il n'existe aucune dépendance ou séquence entre elles. Il y a de fortes chances que le conteneur reçoive le `SIGKILL` signal bien avant que les `iptables` règles locales ne soient mises à jour `kube-proxy` sur chaque nœud. Dans ce cas, les scénarios possibles sont les suivants :
+ Si votre application supprime immédiatement et brutalement les demandes en vol et les connexions dès réception`SIGTERM`, les clients constateront des erreurs. `500`
+ Si votre application garantit que toutes les demandes et connexions en cours de vol sont traitées dans leur intégralité dès réception`SIGTERM`, pendant la période de grâce, les nouvelles demandes des clients seront toujours envoyées au conteneur d'applications, car les `iptables` règles ne sont peut-être pas encore mises à jour. Jusqu'à ce que la procédure de nettoyage ferme le socket du serveur sur le conteneur, ces nouvelles demandes entraîneront de nouvelles connexions. Lorsque le délai de grâce prend fin, les nouvelles connexions établies après son envoi sont abandonnées sans condition. `SIGTERM`

Pour répondre aux scénarios précédents, vous pouvez implémenter l'intégration intégrée à l'application ou le PreStop Lifecycle Hook. Pour plus d'informations, y compris un schéma, consultez la section [Arrêter correctement les applications](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) dans le *guide des meilleures pratiques Amazon EKS*.

**Note**  
Que l'application s'arrête correctement ou qu'elle soit le résultat du blocage, les `preStop` conteneurs d'applications sont finalement fermés à la fin de la période de grâce. `SIGKILL`

Utilisez le `preStop` hook avec une `sleep` commande pour retarder l'envoi`SIGTERM`. Cela vous aidera à continuer à accepter les nouvelles connexions pendant que l'objet d'entrée les achemine vers le module. Testez la valeur temporelle de la `sleep` commande pour vous assurer que toute latence de Kubernetes et d'autres dépendances d'applications est prise en compte, comme indiqué dans l'exemple suivant :

```
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
```

Pour plus d'informations, consultez [Container hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) dans la documentation Kubernetes et [Arrêtez gracieusement les applications dans](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_gracefully_shutdown_applications) le guide des meilleures pratiques *Amazon EKS*.