Les développeurs de Xenoblade Chronicles: Definitive Edition dans le dernier numéro du magazine Weekly Famitsu.

Meilleures pratiques Kubernetes. Création de petits conteneurs
Meilleures pratiques Kubernetes. Organisation de Kubernetes avec des espaces de noms

Il peut être difficile de gérer des systèmes distribués en raison de la multitude d'éléments mobiles et changeants qui doivent tous fonctionner correctement pour assurer la fonctionnalité du système. Si l'un des éléments tombe en panne, le système doit être capable de le détecter, de contourner le problème et de le corriger, le tout de manière automatique. Dans cette série « Kubernetes Best Practices », nous allons découvrir comment configurer les tests Readiness et Liveness pour vérifier la viabilité d'un cluster Kubernetes.

Le contrôle de santé Health Check est un moyen simple d'informer le système si une instance de votre application fonctionne ou non. Si l'instance de votre application ne fonctionne pas, d'autres services ne doivent pas s'y connecter ni lui envoyer de requêtes. Au lieu de cela, la requête doit être envoyée à une autre instance de l'application qui est déjà en cours d'exécution ou qui sera lancée ultérieurement. De plus, le système doit restituer la capacité opérationnelle perdue de votre application.

Par défaut, Kubernetes commencera à diriger le trafic vers le pod lorsque tous les conteneurs à l'intérieur des pods seront lancés et redémarrera les conteneurs lorsqu'ils échoueront. Au départ, ce comportement par défaut peut être suffisant, mais vous pouvez améliorer la fiabilité de déploiement de votre produit en utilisant des contrôles de santé personnalisés.

Heureusement, Kubernetes permet de le faire assez facilement, donc il n'y a aucune excuse pour ignorer de tels contrôles. Kubernetes propose deux types de tests de contrôle de santé, et il est important de comprendre les différences d'application de chacun.

Le test de readiness Readiness est conçu pour informer Kubernetes que votre application est prête à gérer le trafic. Avant de permettre au service d'envoyer du trafic au pod, Kubernetes doit s'assurer que le test de readiness a réussi. Si le test de readiness échoue, Kubernetes cessera d'envoyer du trafic au pod jusqu'à ce que le test réussisse.

Le test de vivacité Liveness informe Kubernetes si votre application est vivante ou morte. Dans le premier cas, Kubernetes le laissera tranquille, dans le second, il supprimera le pod mort et le remplacera par un nouveau.

Imaginons un scénario où votre application nécessite 1 minute pour « préchauffer » et se lancer. Votre service ne commencera pas à fonctionner tant que l'application n'est pas complètement chargée et lancée, même si le flux de travail a déjà commencé. De plus, vous rencontrerez également des problèmes si vous souhaitez scaler ce déploiement à plusieurs copies, car ces copies ne doivent pas recevoir de trafic tant qu'elles ne sont pas complètement prêtes. Cependant, par défaut, Kubernetes commencera à envoyer du trafic immédiatement après le lancement des processus à l'intérieur du conteneur.

En utilisant le test de disponibilité Readiness, Kubernetes attendra que l'application soit complètement lancée avant de permettre au service d'envoyer du trafic vers la nouvelle copie.

Imaginons un autre scénario dans lequel l'application se fige pendant une longue période, cessant de répondre aux requêtes. Comme le processus continue à s'exécuter, Kubernetes considérera par défaut que tout va bien et continuera à envoyer des requêtes au pod non fonctionnel. Mais avec Liveness, Kubernetes détectera que l'application ne répond plus aux requêtes et redémarrera par défaut le pod non fonctionnel.

Examinons comment sont testés la disponibilité et la viabilité. Il existe trois méthodes de test : HTTP, Command et TCP. Vous pouvez utiliser l'une d'elles pour la vérification. La méthode de test utilisateur la plus courante est le probe HTTP.

Même si votre application n'est pas un serveur HTTP, vous pouvez toujours créer un serveur HTTP léger à l'intérieur de votre application pour interagir avec le test Liveness. Après cela, Kubernetes commencera à pinger le pod, et si la réponse HTTP se situe dans la plage de 200 ou 300 ms, cela indiquera que le pod est « sain ». Sinon, le module sera marqué comme « malade ».

Pour les tests avec Command, Kubernetes exécute une commande à l'intérieur de votre conteneur. Si la commande renvoie un code de sortie zéro, le conteneur sera marqué comme sain, sinon, s'il obtient un code de sortie de 1 à 255, le conteneur sera marqué comme « malade ». Cette méthode de test est utile si vous ne pouvez pas ou ne souhaitez pas exécuter un serveur HTTP, mais êtes capable d'exécuter une commande qui vérifiera la « santé » de votre application.

Le dernier mécanisme de vérification est le test TCP. Kubernetes tentera d'établir une connexion TCP sur le port spécifié. Si cela réussit, le conteneur est considéré comme sain, sinon comme non fonctionnel. Cette méthode peut s'avérer utile si vous utilisez un scénario où les tests par requête HTTP ou l'exécution de commandes fonctionnent mal. Par exemple, les principaux services pour la vérification via TCP seront gRPC ou FTP.

Les tests peuvent être configurés de plusieurs manières avec différents paramètres. Vous pouvez indiquer la fréquence d'exécution, les seuils de réussite et d'échec, et combien de temps attendre les réponses. Des informations plus détaillées sont fournies dans la documentation des tests Readiness et Liveness. Cependant, il y a un point très important dans la configuration du test Liveness – le délai initial de configuration du test initialDelaySeconds. Comme je l'ai mentionné, l'échec de ce test entraînera le redémarrage du module. Par conséquent, vous devez vous assurer que le test ne commence pas tant que l'application n'est pas prête, sinon elle commencera à redémarrer en boucle. Je recommande d'utiliser le temps de démarrage P99 ou le temps de démarrage moyen de l'application à partir du buffer. N'oubliez pas d'ajuster cette valeur à mesure que le temps de démarrage de votre application devient plus rapide ou plus lent.

La plupart des spécialistes confirmeront que les vérifications de santé sont indispensables pour tout système distribué, et Kubernetes ne fait pas exception. L'utilisation de la vérification de « santé » des services garantit un fonctionnement fiable et sans faille de Kubernetes et ne pose aucun problème pour les utilisateurs.

La suite arrivera très bientôt…

Un peu de publicité 🙂

Merci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu intéressant ? Soutenez-nous en passants une commande ou en nous recommandant à des amis, VPS cloud pour développeurs à partir de 4,99 $, un équivalent unique des serveurs d'entrée de gamme, conçu pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbps à partir de 19 $ ou comment bien diviser un serveur ? (options disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go DDR4).

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV à Amsterdam ? Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To à partir de 199 $ aux Pays-Bas ! Dell R420 — 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To — à partir de 99 $ ! Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 coûtant 9000 euros pour des clopinettes ?

Source : habr.com