Configurer les hooks du cycle de vie des conteneurs

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

Le cycle de vie du conteneur et le point de terminaison EndpointSlice font partie d'une différence APIs. Il est important de les orchestrer. APIs Cependant, lorsqu'un pod est arrêté, l'API Kubernetes avertit simultanément le kubelet (pour Container Lifecycle) et le contrôleur. EndpointSlice Pour plus d'informations, y compris un schéma, voir Gérer avec élégance les demandes des clients dans les guides des meilleures pratiques d'EKS.

Lorsqu'il est kubelet envoyé SIGTERM au pod, le EndpointSlice contrôleur met fin à l'EndpointSliceobjet. 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 des clients, vous constaterez SIGTERM, 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éceptionSIGTERM, 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, voir Arrêter correctement les applications dans les guides des meilleures pratiques d'EKS.

Remarque : Que l'application s'arrête correctement ou qu'il 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'envoiSIGTERM. 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 et EKS Best Practices — Load Balancing (arrêt progressif des applications).