Les systèmes distribués peuvent être difficiles à gérer car ils comportent de nombreux éléments mobiles et changeants qui doivent tous fonctionner correctement pour que le système fonctionne. Si l'un des éléments tombe en panne, le système doit le détecter, le contourner et le réparer, et tout cela doit se faire automatiquement. Dans cette série de bonnes pratiques Kubernetes, nous apprendrons comment configurer des tests de préparation et d'activité pour tester la santé d'un cluster Kubernetes.
Health Check est un moyen simple d'indiquer au système si votre instance d'application est en cours d'exécution ou non. Si votre instance d'application est en panne, les autres services ne doivent pas y accéder ni lui envoyer de requêtes. Au lieu de cela, la demande 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 devrait restaurer les fonctionnalités perdues de votre application.
Par défaut, Kubernetes commencera à envoyer du trafic vers un pod lorsque tous les conteneurs des pods sont en cours d'exécution, et redémarrera les conteneurs lorsqu'ils planteront. Ce comportement du système par défaut peut être suffisant pour commencer, mais vous pouvez améliorer la fiabilité du déploiement de votre produit en utilisant des contrôles d'intégrité personnalisés.
Heureusement, Kubernetes rend cela assez simple à réaliser, il n’y a donc aucune excuse pour ignorer ces vérifications. Kubernetes propose deux types de bilans de santé, et il est important de comprendre les différences dans la façon dont chacun est utilisé.
Le test de préparation est conçu pour indiquer à Kubernetes que votre application est prête à gérer le trafic. Avant d'autoriser un service à envoyer du trafic vers un pod, Kubernetes doit vérifier que la vérification de l'état de préparation a réussi. Si le test de préparation échoue, Kubernetes cessera d'envoyer du trafic vers le pod jusqu'à ce que le test réussisse.
Le test Liveness indique à 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 dans lequel votre application prend 1 minute pour se préchauffer et se lancer. Votre service ne commencera à fonctionner que lorsque l'application sera entièrement chargée et exécutée, bien que le flux de travail ait déjà démarré. Vous rencontrerez également des problèmes si vous souhaitez étendre ce déploiement à plusieurs copies, car ces copies ne devraient pas recevoir de trafic tant qu'elles ne sont pas entièrement prêtes. Cependant, par défaut, Kubernetes commencera à envoyer du trafic dès que les processus à l'intérieur du conteneur commenceront.
Lors de l'utilisation du test de préparation, Kubernetes attendra que l'application soit entièrement exécutée avant d'autoriser le service à envoyer du trafic vers la nouvelle copie.
Imaginons un autre scénario dans lequel l'application se bloque pendant une longue période, arrêtant les demandes de service. Au fur et à mesure que le processus continue de s'exécuter, Kubernetes supposera par défaut que tout va bien et continuera à envoyer des requêtes au pod qui ne fonctionne pas. Mais lors de l'utilisation de Liveness, Kubernetes détectera que l'application ne répond plus aux requêtes et redémarrera le pod mort par défaut.
Voyons comment l'état de préparation et la viabilité sont testés. Il existe trois méthodes de test : HTTP, Commande et TCP. Vous pouvez utiliser n’importe lequel d’entre eux pour vérifier. Le moyen le plus courant de tester un utilisateur est une sonde HTTP.
Même si votre application n'est pas un serveur HTTP, vous pouvez toujours créer un serveur HTTP léger dans votre application pour interagir avec le test Liveness. Après cela, Kubernetes commencera à envoyer une requête ping au pod et si la réponse HTTP est comprise dans la plage de 200 ou 300 ms, cela indiquera que le pod est sain. Sinon, le module sera marqué comme « malsain ».
Pour les tests de commande, Kubernetes exécute la commande dans votre conteneur. Si la commande revient avec un code de sortie zéro, alors le conteneur sera marqué comme sain, sinon, dès réception d'un numéro d'état de sortie compris entre 1 et 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 de serveur HTTP, mais que vous êtes capable d'exécuter une commande qui vérifiera la santé de votre application.
Le mécanisme de vérification final est le test TCP. Kubernetes tentera d'établir une connexion TCP sur le port spécifié. Si cela peut être fait, le conteneur est considéré comme sain ; sinon, il est considéré comme non viable. Cette méthode peut être utile si vous utilisez un scénario dans lequel les tests avec une requête HTTP ou l'exécution d'une commande ne fonctionnent pas très bien. Par exemple, les principaux services de vérification via TCP seraient gRPC ou FTP.
Les tests peuvent être configurés de plusieurs manières avec différents paramètres. Vous pouvez spécifier la fréquence à laquelle ils doivent être exécutés, quels sont les seuils de réussite et d'échec et combien de temps attendre les réponses. Pour plus d’informations, consultez la documentation des tests Readiness et Liveness. Cependant, il y a un point très important dans la configuration du test Liveness : le réglage initial du délai de test initialDelaySeconds. Comme je l'ai mentionné, l'échec de ce test entraînera le redémarrage du module. Vous devez donc vous assurer que les tests ne démarrent pas tant que l'application n'est pas prête à fonctionner, sinon elle commencera à redémarrer. Je recommande d'utiliser le temps de démarrage P99 ou le temps de démarrage moyen de l'application à partir du tampon. 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 experts confirmeront que les contrôles de santé sont une vérification obligatoire pour tout système distribué, et Kubernetes ne fait pas exception. L’utilisation des vérifications de l’état des services garantit un fonctionnement fiable et sans problème de Kubernetes et se fait sans effort pour les utilisateurs.
A suivre très prochainement...
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