Un point important dans le fonctionnement des systèmes distribués est la gestion des pannes. Kubernetes vous aide en utilisant des contrôleurs qui surveillent la santé de votre système et redémarrent les services qui ont cessé de fonctionner. Cependant, Kubernetes peut arrêter de force vos applications pour garantir la santé globale du système. Dans cette série, nous verrons comment vous pouvez aider Kubernetes à faire son travail plus efficacement et à réduire les temps d'arrêt des applications.
Avant les conteneurs, la plupart des applications s'exécutaient sur des machines virtuelles ou physiques. Si l'application plantait ou se bloquait, il fallait beaucoup de temps pour annuler la tâche en cours et recharger le programme. Dans le pire des cas, quelqu'un devait résoudre ce problème manuellement la nuit, aux heures les plus inopportunes. Si seulement 1 à 2 machines en état de marche effectuaient une tâche importante, une telle perturbation serait totalement inacceptable.
Par conséquent, au lieu de redémarrages manuels, ils ont commencé à utiliser la surveillance au niveau des processus pour redémarrer automatiquement l'application en cas d'arrêt anormal. Si le programme échoue, le processus de surveillance capture le code de sortie et redémarre le serveur. Avec l’avènement de systèmes comme Kubernetes, ce type de réponse aux pannes du système a été simplement intégré à l’infrastructure.
Kubernetes utilise une boucle d'événements observer-différence-agir-agir pour garantir que les ressources restent saines pendant leur trajet depuis les conteneurs vers les nœuds eux-mêmes.
Cela signifie que vous n’avez plus besoin d’exécuter manuellement la surveillance des processus. Si une ressource échoue au bilan de santé, Kubernetes la provisionnera simplement automatiquement avec un remplacement. Cependant, Kubernetes fait bien plus que simplement surveiller les échecs de votre application. Il peut créer davantage de copies de l'application à exécuter sur plusieurs machines, mettre à jour l'application ou exécuter plusieurs versions de votre application simultanément.
Il existe donc de nombreuses raisons pour lesquelles Kubernetes peut mettre fin à un conteneur parfaitement sain. Par exemple, si vous mettez à niveau votre déploiement, Kubernetes arrêtera lentement les anciens pods tout en en démarrant de nouveaux. Si vous arrêtez un nœud, Kubernetes cessera d'exécuter tous les pods sur ce nœud. Enfin, si un nœud manque de ressources, Kubernetes fermera tous les pods pour libérer ces ressources.
Par conséquent, il est essentiel que votre application se termine avec un impact minimal sur l'utilisateur final et un temps de récupération minimal. Cela signifie qu'avant de s'arrêter, il doit sauvegarder toutes les données qui doivent l'être, fermer toutes les connexions réseau, terminer le travail restant et gérer d'autres tâches urgentes.
En pratique, cela signifie que votre application doit être capable de gérer le message SIGTERM, le signal de fin de processus qui est le signal par défaut de l'utilitaire kill sur les systèmes d'exploitation Unix. Dès réception de ce message, l'application devrait se fermer.
Une fois que Kubernetes décide de mettre fin à un pod, un certain nombre d'événements se produisent. Examinons chaque étape suivie par Kubernetes lors de l'arrêt d'un conteneur ou d'un pod.
Disons que nous voulons mettre fin à l'un des pods. À ce stade, il cessera de recevoir du nouveau trafic : les conteneurs exécutés dans le pod ne seront pas affectés, mais tout nouveau trafic sera bloqué.
Examinons le hook preStop, qui est une commande spéciale ou une requête HTTP envoyée aux conteneurs d'un pod. Si votre application ne s'arrête pas correctement lors de la réception de SIGTERM, vous pouvez utiliser preStop pour s'arrêter correctement.
La plupart des programmes se termineront normalement lorsqu'ils recevront un signal SIGTERM, mais si vous utilisez du code tiers ou un système que vous ne contrôlez pas entièrement, le hook preStop est un excellent moyen de forcer un arrêt progressif sans modifier l'application.
Après avoir exécuté ce hook, Kubernetes enverra un signal SIGTERM aux conteneurs du pod, leur faisant savoir qu'ils seront bientôt déconnectés. Dès réception de ce signal, votre code procédera au processus d'arrêt. Ce processus peut inclure l'arrêt de toute connexion de longue durée telle qu'une connexion à une base de données ou un flux WebSocket, l'enregistrement de l'état actuel, etc.
Même si vous utilisez un hook preStop, il est très important de vérifier ce qui arrive exactement à votre application lorsque vous lui envoyez un signal SIGTERM, et comment elle se comporte, afin que les événements ou les changements dans le fonctionnement du système provoqués par l'arrêt d'un pod ne se produisent pas comme prévu. une surprise pour vous.
À ce stade, Kubernetes attendra une durée spécifiée, appelée terminaisonGracePeriodSecond, ou période d'arrêt progressif lorsqu'il reçoit un signal SIGTERM, avant de prendre d'autres mesures.
Par défaut, cette période est de 30 secondes. Il est important de noter qu'il fonctionne en parallèle avec le crochet preStop et le signal SIGTERM. Kubernetes n'attendra pas la fin du hook preStop et de SIGTERM : si votre application se ferme avant la fin de TerminationGracePeriod, Kubernetes passera immédiatement à l'étape suivante. Vérifiez donc que la valeur de cette période en secondes n'est pas inférieure au temps nécessaire pour arrêter correctement le pod, et si elle dépasse 30s, augmentez la période jusqu'à la valeur souhaitée en YAML. Dans l’exemple donné, il s’agit des années 60.
Et enfin, la dernière étape est que si les conteneurs sont toujours en cours d'exécution après la terminaisonGracePeriod, ils enverront un signal SIGKILL et seront supprimés de force. À ce stade, Kubernetes nettoiera également tous les autres objets du pod.
Kubernetes met fin aux pods pour de nombreuses raisons, alors assurez-vous que votre application se termine correctement dans tous les cas pour garantir un service stable.
Quelques publicités 🙂
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, , un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com