Meilleures pratiques Kubernetes. Test de viabilité de Kubernetes avec tests de préparation et de vivacité

Meilleures pratiques Kubernetes. Création de petits conteneurs
Kubernetes Best Practices. Organisation Kubernetes avec un espace de noms



Les systèmes distribués peuvent être difficiles à gérer car ils comportent de nombreux éléments mobiles modifiables et tous doivent fonctionner correctement pour garantir la fonctionnalité du système. 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 être fait automatiquement. Dans cette série de bonnes pratiques Kubernetes, nous apprendrons comment configurer les tests de disponibilité et de réactivité pour tester la viabilité d'un cluster Kubernetes.

Health Check Health Check est un moyen simple de faire savoir au système si votre instance d'application est en cours d'exécution ou non. Si une instance de votre application ne fonctionne pas, les autres services ne doivent pas y accéder ni lui envoyer de demandes. 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 démarrera plus tard. En outre, le système doit rétablir la fonctionnalité perdue de votre application.

Par défaut, Kubernetes commencera à envoyer du trafic vers le pod lorsque tous les conteneurs à l'intérieur des foyers sont en cours d'exécution et rechargera les conteneurs lorsqu'ils tomberont en panne. Pour commencer, ce comportement par défaut du système peut être assez bon, mais vous pouvez augmenter la fiabilité de votre déploiement de produit à l'aide de contrôles d'intégrité personnalisés.



Heureusement, Kubernetes vous permet de le faire tout simplement, il n'y a donc aucune excuse pour ignorer de tels contrôles. Kubernetes propose deux types de tests de bilan de santé, et il est important de comprendre les différences dans chaque application.

Le test de disponibilité opérationnelle est conçu pour indiquer à Kubernetes que votre application est prête à traiter le trafic. Avant d'autoriser le service à envoyer du trafic vers le module, Kubernetes doit vérifier que le contrôle de disponibilité 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 de viabilité de Liveness indique à Kubernetes si votre application est vivante ou morte. Dans le premier cas, Kubernetes le laissera tranquille, dans le second, il retirera la cosse morte et la remplacera par une nouvelle.

Imaginons un scénario dans lequel votre application a besoin d'une minute pour se «réchauffer» et s'exécuter. Votre service ne commencera à fonctionner que lorsque l'application sera complètement chargée et démarrée, bien que le workflow ait déjà commencé. Et vous aurez également des problèmes si vous souhaitez augmenter l'échelle de 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 début des processus à l'intérieur du conteneur.

Lors de l'utilisation du test de disponibilité opérationnelle, Kubernetes attendra que l'application soit complètement lancée et ce n'est qu'après cela que le service pourra envoyer du trafic vers une nouvelle copie.



Imaginons un autre scénario dans lequel une application se bloque pendant longtemps, arrêtant les demandes de service. Étant donné que le processus continue de s'exécuter, Kubernetes considérera par défaut que tout est en ordre et continuera d'envoyer des demandes au pod non fonctionnel. Mais lors de l'utilisation de Liveness, Kubernetes détectera que l'application ne sert plus les demandes et redémarrera par défaut un module non fonctionnel.



Considérez comment tester l'état de préparation et la vitalité. Il existe trois méthodes de test - HTTP, ommand et TCP. Vous pouvez utiliser n'importe lequel d'entre eux pour la vérification. La méthode de test utilisateur la plus courante 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 un ping au pod, et si la réponse HTTP est dans la plage de 200 ou 300 ms, cela signifiera que le pod est "sain". Sinon, le module sera marqué comme «malsain».



Pour les tests utilisant Command, Kubernetes exécute la commande à l'intérieur de votre conteneur. Si la commande retourne avec un code de sortie nul, le conteneur sera marqué comme sain, sinon, lorsque le numéro d'état de sortie est 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 voulez pas démarrer le serveur HTTP, mais vous pouvez exécuter une commande qui vérifiera la santé de votre application.



Le dernier mécanisme de vérification est le test TCP. Kubernetes essaiera d'établir une connexion TCP sur le port spécifié. Si cela peut être fait, le conteneur est considéré comme sain, sinon, il n'est pas viable. Cette méthode peut être utile si vous utilisez un script 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 avec TCP seront 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. Consultez la documentation du test de disponibilité et de vivacité pour plus d'informations. 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 redémarrera le module. Par conséquent, vous devez vous assurer que le test ne démarre pas tant que l'application n'est pas prête à être utilisée, sinon elle commencera à se déplacer. 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 de régler cette valeur commeque l'heure de lancement de votre application devient plus rapide ou plus lente.

La plupart des experts confirmeront que le bilan de santé est un contrôle obligatoire pour tout système distribué, et Kubernetes ne fait pas exception. L'utilisation du contrôle de «santé» des services garantit la fiabilité et la disponibilité de Kubernetes et ne fait aucun travail pour les utilisateurs.

A suivre très prochainement ...

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, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur 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?