Meilleures pratiques Kubernetes. Correct Terminate Disable

Meilleures pratiques Kubernetes. Création de petits conteneurs
Kubernetes Best Practices. Organisation Kubernetes avec l'
espace de noms Kubernetes Best Practices. Test de viabilité Kubernetes avec tests de préparation et de vivacité Kubernetes
Best Practices. Configuration des demandes et des limites de ressources



Un point important dans le fonctionnement des systèmes distribués est la gestion des échecs. Kubernetes vous y aide en utilisant des contrôleurs qui surveillent l'état de votre système et redémarrent les services qui ne fonctionnent plus. Cependant, Kubernetes peut arrêter de force vos applications pour garantir la viabilité 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 d'utiliser des conteneurs, la plupart des applications s'exécutaient sur des machines virtuelles ou physiques. Si l'application est tombée en panne ou s'est plantée, il a fallu beaucoup de temps pour supprimer la tâche en cours et télécharger à nouveau le programme. Dans le pire des cas, quelqu'un devait résoudre ce problème manuellement la nuit, au moment le plus inopportun. Si seulement 1-2 machines en état de marche effectuaient une tâche importante, un tel dysfonctionnement était totalement inacceptable.
Par conséquent, au lieu de redémarrer manuellement, ils ont commencé à utiliser la surveillance au niveau du processus pour redémarrer automatiquement l'application en cas de fin anormale. Si le programme plante, le processus de surveillance capture le code de sortie et redémarre le serveur. Avec l'avènement de systèmes tels que Kubernetes, ce type de réponse aux défaillances du système a simplement été intégré à l'infrastructure.

Kubernetes utilise la boucle d'événement «observer - valider les différences - valider» pour garantir que les ressources sont opérationnelles le long du chemin des conteneurs jusqu'aux nœuds eux-mêmes.



Cela signifie que vous n'avez plus besoin de démarrer manuellement la surveillance des processus. Si une ressource échoue au bilan de santé, Kubernetes fournira simplement automatiquement un remplaçant. Kubernetes fait plus que simplement surveiller les plantages de vos applications. Il peut créer plus de copies de l'application pour fonctionner sur plusieurs machines, mettre à jour l'application ou exécuter simultanément plusieurs versions de votre application.
Par conséquent, il existe de nombreuses raisons pour lesquelles Kubernetes peut interrompre un récipient parfaitement sain. Par exemple, si vous mettez à niveau votre déploiement, Kubernetes arrêtera lentement les anciens pods tout en en lançant de nouveaux. Si vous déconnectez un nœud, Kubernetes mettra fin à tous les foyers de ce nœud. Enfin, si le nœud manque de ressources, Kubernetes désactivera tous les pods pour libérer ces ressources.

Par conséquent, il est très important que votre application cesse de fonctionner avec un impact minimal sur l'utilisateur final et un temps de récupération minimal. Cela signifie qu'avant de se déconnecter, il doit enregistrer toutes les données qui doivent être enregistrées, fermer toutes les connexions réseau, terminer le travail restant et avoir le temps d'effectuer d'autres tâches urgentes.

En pratique, cela signifie que votre application devrait être en mesure de traiter le message SIGTERM - le signal de fin de processus, qui est le signal par défaut de l'utilitaire kill dans le système d'exploitation de la famille Unix. Après avoir reçu ce message, l'application doit se déconnecter.

Après que Kubernetes ait décidé de terminer le pod, toute une série d'événements a eu lieu. Examinons chaque étape que Kubernetes prend lorsqu'un conteneur ou un foyer se termine.

Supposons que nous voulions terminer l'un des foyers. À ce stade, il cessera de recevoir du nouveau trafic - les conteneurs travaillant dans le foyer ne seront pas affectés, mais tout le nouveau trafic sera bloqué.



Regardons le crochet preStop - il s'agit d'une commande spéciale ou d'une requête HTTP envoyée aux conteneurs dans l'âtre. Si votre application ne s'éteint pas correctement lorsque SIGTERM est reçu, vous pouvez utiliser preStop pour quitter correctement.



La plupart des programmes lorsqu'ils reçoivent un signal SIGTERM se terminent correctement, mais si vous utilisez du code tiers ou un système que vous ne pouvez pas contrôler complètement, le crochet preStop est un excellent moyen de provoquer un arrêt progressif sans modifier l'application.

Après avoir exécuté ce crochet, Kubernetes enverra un signal SIGTERM aux conteneurs dans l'âtre, ce qui leur fera savoir qu'ils seront bientôt déconnectés. Après avoir reçu ce signal, votre code procédera au processus d'arrêt. Ce processus peut inclure l'arrêt de toutes les connexions de longue durée, telles que la connexion à une base de données ou à un flux WebSocket, l'enregistrement de l'état actuel, etc.

Même si vous utilisez le crochet preStop, il est très important de vérifier ce qui se passe exactement avec votre application lorsque vous lui envoyez un signal SIGTERM, comment il se comporte de telle manière que les événements ou les changements dans le fonctionnement du système causés par l'arrêt du foyer ne vous surprennent pas.

À ce stade, avant d'entreprendre d'autres actions, Kubernetes attendra pendant une durée spécifiée, appelée terminaisonGracePeriodSecond, ou la période pendant laquelle il s'arrêtera correctement lorsqu'il recevra un signal SIGTERM.



Par défaut, cette période est de 30 secondes. Il est important de noter qu'il dure 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 termine avant l'expiration de TerminationGracePeriod, Kubernetes passera immédiatement à l'étape suivante. Par conséquent, vérifiez que la valeur de cette période en secondes n'est pas inférieure au temps nécessaire pour que le foyer s'éteigne correctement et si elle dépasse 30 s, augmentez la période jusqu'à la valeur souhaitée en YAML. Dans l'exemple ci-dessus, c'est 60s.

Et enfin, la dernière étape - si les conteneurs continuent de fonctionner après l'expiration de la terminaisonGracePeriod, ils enverront un signal SIGKILL et seront supprimés de force. À ce stade, Kubernetes nettoiera également tous les autres objets pod.



Kubernetes ferme les foyers pour de nombreuses raisons, alors assurez-vous que, dans tous les cas, votre demande sera correctement remplie pour assurer un fonctionnement stable du service.

Meilleures pratiques Kubernetes. Cartographie des services externes

Un peu de publicité :)

Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis des VPS basés sur le cloud pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur les VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?