🥇Les sondes Liveness dans Kubernetes peuvent être dangereuses

Noter. trad.: L'ingénieur principal de Zalando, Henning Jacobs, a remarqué à plusieurs reprises des problèmes parmi les utilisateurs de Kubernetes dans la compréhension de l'objectif des sondes d'activité (et de préparation) et de leur utilisation correcte. Par conséquent, il a rassemblé ses réflexions dans cette note volumineuse, qui fera éventuellement partie de la documentation du K8.

Bilans de santé, connus dans Kubernetes sous le nom de sondes de vivacité (c'est-à-dire littéralement « tests de viabilité » - traduction approximative.), peut être très dangereux. Je recommande de les éviter si possible : les seules exceptions sont lorsqu'ils sont vraiment nécessaires et que vous êtes pleinement conscient des spécificités et des conséquences de leur utilisation. Cette publication parlera des contrôles d'activité et de préparation, et vous indiquera également dans quels cas est et vous ne devriez pas les utiliser.

Mon collègue Sandor a récemment partagé sur Twitter les erreurs les plus courantes qu'il rencontre, y compris celles liées à l'utilisation de sondes de préparation/activité :

Mal configuré livenessProbe peut aggraver les situations de charge élevée (arrêt boule de neige + temps de démarrage potentiellement long du conteneur/application) et entraîner d'autres conséquences négatives telles que des baisses de dépendances (voir également mon récent article sur la limitation du nombre de requêtes dans la combinaison K3s+ACME). C’est encore pire lorsque la sonde de vivacité est combinée à un bilan de santé, qui est une base de données externe : une seule panne de base de données redémarrera tous vos conteneurs!

Message général "N'utilisez pas de sondes de vivacité" dans ce cas, cela n'aide pas beaucoup, alors regardons à quoi servent les contrôles de préparation et de vivacité.

Remarque : La plupart des tests ci-dessous étaient initialement inclus dans la documentation interne du développeur de Zalando.

Vérifications de préparation et de vivacité

Kubernetes fournit deux mécanismes importants appelés sondes de vivacité et sondes de préparation. Ils effectuent périodiquement certaines actions, comme l'envoi d'une requête HTTP, l'ouverture d'une connexion TCP ou l'exécution d'une commande dans le conteneur, pour confirmer que l'application fonctionne comme prévu.

Utilisations de Kubernetes sondes de préparationpour comprendre quand le conteneur est prêt à accepter du trafic. Une dosette est considérée comme prête à l’emploi si tous ses contenants sont prêts. Une utilisation de ce mécanisme consiste à contrôler quels pods sont utilisés comme backends pour les services Kubernetes (et en particulier Ingress).

Sondes de vivacité aidez Kubernetes à comprendre quand il est temps de redémarrer le conteneur. Par exemple, une telle vérification vous permet d'intercepter un blocage lorsqu'une application reste bloquée au même endroit. Le redémarrage du conteneur dans cet état permet à l'application de décoller malgré les erreurs, mais cela peut également entraîner des échecs en cascade (voir ci-dessous).

Si vous essayez de déployer une mise à jour d'application qui échoue aux contrôles d'activité/préparation, son déploiement sera bloqué pendant que Kubernetes attend le statut. Ready de toutes les cosses.

Exemple

Voici un exemple de sonde de préparation vérifiant un chemin /health via HTTP avec les paramètres par défaut (intervalle: 10 secondes, temps mort: 1 seconde, seuil de réussite: 1, seuil de défaillance:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Recommandations

Pour les microservices avec point de terminaison HTTP (REST, etc.) toujours définir une sonde de préparation, qui vérifie si l'application (pod) est prête à accepter le trafic.
Assurez-vous que la sonde de préparation couvre la disponibilité du port réel du serveur Web:
- utiliser des ports à des fins administratives, appelés « admin » ou « gestion » (par exemple, 9090), pour readinessProbe, assurez-vous que le point de terminaison renvoie OK uniquement si le port HTTP principal (comme 8080) est prêt à accepter le trafic* ;
  *Je connais au moins un cas chez Zalando où cela ne s'est pas produit, c'est-à-dire readinessProbe J'ai vérifié le port « gestion », mais le serveur lui-même n'a pas commencé à fonctionner en raison de problèmes de chargement du cache.
- l'attachement d'une sonde de préparation à un port séparé peut conduire au fait que la surcharge sur le port principal ne sera pas reflétée dans le contrôle de santé (c'est-à-dire que le pool de threads sur le serveur est plein, mais le contrôle de santé montre toujours que tout va bien ).
Sois sûr que la sonde de préparation permet l'initialisation/la migration de la base de données;
- Le moyen le plus simple d'y parvenir est de contacter le serveur HTTP uniquement une fois l'initialisation terminée (par exemple, en migrant une base de données depuis Voie de migration et ainsi de suite.); autrement dit, au lieu de modifier l'état de la vérification de l'état, ne démarrez simplement pas le serveur Web tant que la migration de la base de données n'est pas terminée*.
  * Vous pouvez également exécuter des migrations de bases de données à partir de conteneurs d'initialisation en dehors du pod. Je suis toujours fan des applications autonomes, c'est-à-dire celles dans lesquelles le conteneur d'application sait comment amener la base de données dans l'état souhaité sans coordination externe.
utilisation httpGet pour les contrôles de préparation via des points de terminaison de contrôle de santé typiques (par exemple, /health).
Comprendre les paramètres de vérification par défaut (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- les options par défaut signifient que le pod deviendra pas prêt après environ 30 secondes (3 contrôles d'intégrité échoués).
Utilisez un port distinct pour « admin » ou « gestion » si la pile technologique (par exemple Java/Spring) le permet, afin de séparer la gestion de l'intégrité et des métriques du trafic régulier :
- mais n'oubliez pas le point 2.
Si nécessaire, la sonde de préparation peut être utilisée pour réchauffer/charger le cache et renvoyer un code d'état 503 jusqu'à ce que le conteneur se réchauffe :
- Je vous recommande également de lire le nouveau chèque startupProbe, apparu dans la version 1.16 (nous en avons parlé en russe ici - environ. trad.).

Avertissements

Ne comptez pas sur des dépendances externes (tels que les entrepôts de données) lors de l'exécution de tests de préparation/d'activité - cela peut entraîner des échecs en cascade :
- A titre d'exemple, prenons un service REST avec état avec 10 pods dépendant d'une base de données Postgres : lorsque la vérification dépend d'une connexion fonctionnelle à la base de données, les 10 pods peuvent échouer s'il y a un retard du côté réseau/base de données - généralement tout finit pire qu’il ne pourrait ;
- Veuillez noter que Spring Data vérifie la connexion à la base de données par défaut* ;
  * Il s'agit du comportement par défaut de Spring Data Redis (du moins c'était la dernière fois que j'ai vérifié), qui a conduit à un échec « catastrophique » : lorsque Redis était indisponible pendant une courte période, tous les pods « plantaient ».
- « externe » dans ce sens peut également désigner d'autres pods de la même application, c'est-à-dire qu'idéalement, la vérification ne devrait pas dépendre de l'état des autres pods du même cluster pour éviter des plantages en cascade :
  - les résultats peuvent varier pour les applications avec un état distribué (par exemple, mise en cache en mémoire dans les pods).
N'utilisez pas de sonde de vivacité pour les pods (les exceptions sont les cas où ils sont vraiment nécessaires et que vous connaissez parfaitement les spécificités et les conséquences de leur utilisation) :
- Une sonde d'activité peut aider à récupérer les conteneurs bloqués, mais comme vous avez un contrôle total sur votre application, des problèmes tels que des processus bloqués et des blocages ne devraient idéalement pas se produire : la meilleure alternative est de planter délibérément l'application et de la ramener à son état stable précédent ;
- un échec de la sonde d'activité entraînera le redémarrage du conteneur, aggravant ainsi potentiellement les conséquences des erreurs liées au chargement : le redémarrage du conteneur entraînera un temps d'arrêt (au moins pendant la durée du démarrage de l'application, disons une trentaine de secondes), provoquant de nouvelles erreurs , augmentant la charge sur d'autres conteneurs et augmentant la probabilité de leur défaillance, etc. ;
- les contrôles de vivacité combinés à une dépendance externe sont la pire combinaison possible, menaçant des pannes en cascade : un léger retard côté base de données entraînera un redémarrage de tous vos conteneurs !
Paramètres des contrôles de vivacité et de préparation ça doit être différent:
- vous pouvez utiliser une sonde de vivacité avec le même bilan de santé, mais un seuil de réponse plus élevé (failureThreshold), par exemple, attribuez le statut pas prêt après 3 tentatives et considérer que la sonde de vivacité a échoué après 10 tentatives ;
N'utilisez pas de chèques d'exécution, car ils sont associés à des problèmes connus qui conduisent à l'apparition de processus zombies :
- détails : voir présentation par les spécialistes Datadog.

Résumé

Utilisez des sondes de préparation pour déterminer quand un pod est prêt à recevoir du trafic.
Utilisez les sondes de vivacité uniquement lorsqu'elles sont vraiment nécessaires.
Une mauvaise utilisation des sondes de préparation/activité peut entraîner une disponibilité réduite et des pannes en cascade.

Documents supplémentaires sur le sujet

Mise à jour n°1 du 2019-09-29

À propos des conteneurs d'initialisation pour la migration de bases de données: Note de bas de page ajoutée.

EJ m'a rappelé à propos de PDB : l'un des problèmes des contrôles d'activité est le manque de coordination entre les pods. Kubernetes a Budgets de perturbation des pods (PDB) pour limiter le nombre d'échecs simultanés qu'une application peut rencontrer, cependant les vérifications ne prennent pas en compte le PDB. Idéalement, nous pourrions dire aux K8 de "Redémarrer un pod si son test échoue, mais ne les redémarrez pas tous pour éviter d'aggraver les choses".

Bryan l'a parfaitement dit: « Utilisez la recherche d'activité lorsque vous savez exactement ce la meilleure chose à faire est de tuer l'application"(encore une fois, ne vous emballez pas).

Mise à jour n°2 du 2019-09-29

Concernant la lecture de la documentation avant utilisation: J'ai créé la requête correspondante (demande de fonctionnalité) pour ajouter de la documentation sur les sondes d'activité.

PS du traducteur

A lire aussi sur notre blog :

Source: habr.com

Les sondes de vivacité dans Kubernetes peuvent être dangereuses