Utilisation des vérifications de l'état dans Red Hat OpenShift 4.5

Les vérifications de l'état sont une partie importante des déploiements d'applications conteneurisées dans Red Hat OpenShift. Dans OpenShift 4.5 Red Hat a ajouté des sondes de démarrage comme troisième option en plus des sondes de disponibilité et de vivacité, et a également ramené la configuration de ces vérifications à l'interface Web, facilitant ainsi la tâche des développeurs. Dans cet article, je décrirai les trois types de vérifications de l'état, les trois méthodes différentes pour les mettre en œuvre et je donnerai quelques recommandations pour tirer le meilleur parti des capacités de vérification de l'état.

Types of Health Vérifications

Comme mentionné ci-dessus, il existe trois types de vérifications de l'état de santé: vérification de l'état de préparation, vérification de la vivacité et vérification de démarrage. Le contrôle de disponibilité vérifie si un conteneur est prêt à traiter les demandes de service. Si cette vérification échoue, le trafic ne sera pas acheminé vers le conteneur. Le contrôle continuera de surveiller l’état du conteneur et si le conteneur revient à un état où il peut traiter les demandes, le trafic reprendra.

Les contrôles de vie déterminent si un conteneur est toujours en cours d’exécution. Il est possible que les conteneurs se bloquent, que ce soit en raison d'un blocage ou d'une autre condition. Lorsqu'un contrôle de vivacité échoue, il suit la politique de redémarrage des pods, qui consiste normalement à tuer et redémarrer le conteneur.

Les contrôles de démarrage sont le dernier ajout à la suite de contrôles de santé. Un contrôle de démarrage détermine si l'application dans un conteneur est démarrée. Pendant l'exécution de la vérification de démarrage, toutes les vérifications de disponibilité ou de vivacité sont désactivées. Si la vérification de démarrage échoue dans le délai imparti, elle suit la politique de redémarrage, semblable à une vérification de la vivacité (encore une fois, normalement une mise à mort et un redémarrage du conteneur).

Le déroulement de ces vérifications d’état est le suivant: Le contrôle de démarrage s'exécute en premier et il s'exécute jusqu'à ce qu'il réussisse ou expire. S'il réussit, il cesse de sonder et les contrôles de disponibilité et / ou de vivacité commencent et s'exécutent pendant toute la durée de vie du conteneur.

Types de sondes

Il existe trois types de sondes différents qui peuvent être configurés pour chacun des trois vérifications de l'état: une sonde HTTP, une sonde de commande et une sonde TCP. La sonde HTTP est la plus courante. Il interroge essentiellement un chemin et passe; s'il reçoit un code de retour dans la gamme 200-399, la sonde est considérée comme réussie.

Une sonde de commande exécute une commande à l'intérieur d'un conteneur. Si la commande s'exécute avec succès et se termine, elle renvoie un code d'état 0 et est considérée comme réussie.

La TCP probe est le dernière option. Il tente d'établir une connexion de socket TCP au conteneur sur un port spécifié. S'il établit une connexion réussie, la sonde est considérée comme réussie.

Les vérifications de l'état sont facilement accessibles depuis la vue développeur de la console Web. Cliquez simplement sur votre déploiement et une option pour ajouter des vérifications de l'état sera présentée.

Les trois sondes sont disponibles à partir de cette vue.

Les trois contrôles se ressemblent, je vais donc montrer un exemple du contrôle de disponibilité:

(Remarque: bien que les contrôles puissent être configurés ici et c'est un bon moyen de tester, dans la plupart des scénarios, vous voudrez faire ces configurations dans votre référentiel de code pour la cohérence.)

Champs configurables

Comme vous pouvez le voir, il y a quelques champs configurables. Voici un résumé rapide de chaque champ:

• Seuil d'échec – Le nombre de fois où la sonde est autorisée à échouer; la valeur par défaut est 3
• Seuil de succès – Le nombre de fois que la sonde doit signaler un succès après un échec afin de réinitialiser l'état du conteneur à succès; la valeur doit être 1 pour une sonde de vivacité
• Délai initial – Le temps, en secondes, après le démarrage du conteneur avant que la sonde puisse être programmée
• Période – Le délai, en secondes, entre l'exécution des sondes
• Timeout – Le nombre de secondes d'inactivité après lesquelles la sonde expire et le conteneur est supposé avoir échoué

Vous devrez faire quelques tests avec ces différents champs pour vous assurer que vous obtenez le comportement souhaité à partir de vos vérifications de l'état.

Conseils et recommandations

1. Utilisez des vérifications de l'état avec toutes vos applications conteneurisées. Vous passez à côté de certaines des valeurs clés de la conteneurisation si vous n'utilisez pas les vérifications d'état. Les vérifications d'état peuvent aider à gérer l'acheminement du trafic loin des conteneurs en difficulté et peuvent redémarrer les conteneurs bloqués, sans intervention humaine.
2. Pensez au comportement que vous attendez de votre bilan de santé. Les gens ont tendance à se laisser prendre par les termes disponibilité et vivacité, mais il est utile de réfléchir à l'assainissement dont votre conteneur a besoin. Si votre service s'exécutant sur un conteneur ne répond pas, peut-il se restaurer s'il lui reste un certain temps sans trafic? Si tel est le cas, une vérification de l'état de préparation est probablement la bonne voie. Si le correctif doit être un redémarrage d'un conteneur, alors une vérification de la vivacité est une meilleure option.
3. Essayez de ne pas utiliser les vérifications de l'état au-delà de leur objectif. Bien qu'il soit techniquement possible de les utiliser pour vérifier la pile complète des applications, le but est en réalité de vérifier la santé des conteneurs de votre pod. Tenter de le faire vérifier les ressources du backend ou la connectivité d'autres composants d'infrastructure risque de créer des conséquences inattendues.
4. Testez rigoureusement vos bilans de santé avant de commencer. Bien que les vérifications de l'état puissent sembler assez simples, les différents champs configurables des vérifications peuvent considérablement modifier le comportement de la vérification. Je recommande de faire une présentation de certains scénarios avec vos pods et de déterminer les délais optimaux autour des échecs et la fréquence des sondes afin de créer la meilleure expérience utilisateur pour votre service.

Voulez-vous commencer? Perficient peut vous aider à mettre en place des vérifications d'état dans votre environnement Red Hat OpenShift 4.5.