Sondes Kubernetes : quand attendre, acheminer le trafic ou redémarrer

Un processus d’API hypothétique est en cours d’exécution, mais son initialisation n’est pas terminée. Plus tard, sa base de données devient indisponible. Un autre jour, un interblocage local empêche les requêtes d’aboutir. Chacune de ces situations peut faire échouer un contrôle de santé. Elles ne doivent pas automatiquement entraîner la même réaction.

Déterminez ce qui serait utile. Accorder davantage de temps au démarrage ? Retirer cette instance du trafic ? Redémarrer son conteneur ? Kubernetes attribue à ces choix des comportements de sonde distincts, comme l’explique la documentation officielle des sondes.

Une bonne conception des sondes commence par une justification du rétablissement attendu. Ce guide porte sur une application HTTP classique dans un Deployment, derrière un Service standard. L’accès direct aux Pods, les processus de traitement en arrière-plan, les configurations particulières de Service et le routage personnalisé nécessitent une analyse distincte. La configuration est illustrative et n’a pas été exécutée.

Disponibilité, vivacité et démarrage dans Kubernetes : trois décisions distinctes

La sonde détermine ce que Kubernetes fait du signal fourni par le point de terminaison. Consultez le comportement des sondes Kubernetes avant de choisir le contrôle.

La sonde de démarrage protège l’initialisation

Une sonde de démarrage suspend les contrôles de vivacité et de disponibilité jusqu’à sa réussite. L’initialisation dispose ainsi de son propre délai, sans affaiblir les contrôles ultérieurs. Il reste toutefois une limite : des échecs répétés au démarrage entraînent l’arrêt du conteneur. Les consignes de configuration du démarrage décrivent cette attente limitée.

La disponibilité détermine l’admissibilité au trafic

Un échec de disponibilité ne provoque pas, à lui seul, de redémarrage. Il modifie la disponibilité et l’admissibilité au trafic des Services correspondants. Pour qu’un Pod soit disponible, ses autres conteneurs et toute condition de disponibilité supplémentaire configurée doivent également être prêts, comme l’explique la documentation du cycle de vie des Pods. Les tâches en arrière-plan ne s’arrêtent pas simplement parce que l’instance devient indisponible, et un contrôle échoué ne prouve pas que toutes les routes sont inutilisables. Consultez la documentation des sondes pour connaître les conséquences sur les Services ; l’arrêt nécessite un contrat distinct.

La vivacité évalue si un redémarrage peut aider

À son seuil d’échec, la sonde de vivacité déclenche l’arrêt du conteneur concerné, et non le remplacement du Pod entier. La politique de redémarrage régit la suite, notamment les délais croissants décrits dans la documentation du cycle de vie des Pods. Un processus en cours d’exécution peut être bloqué. Un processus qui attend un service externe indisponible peut ne présenter aucun problème local.

Le cadre Attendre, acheminer, redémarrer pour décider du rôle des sondes

Attendre, acheminer, redémarrer est une aide à la décision éditoriale originale d’Optijara, et non une fonctionnalité Kubernetes, une norme du secteur ou une méthode client vérifiée. Utilisez-la pour examiner la justification du rétablissement attendu avant de mettre en œuvre un contrôle de santé.

Associer la défaillance à une action

Tous les scénarios ci-dessous sont hypothétiques. Testez les conditions d’acceptation sur la charge de travail réelle.

Les dépendances partagées compliquent la décision de routage. Si toutes les répliques contrôlent le même service indisponible en arrière-plan, retirer une instance peut aboutir à les retirer toutes. L’analyse de terrain de Colin Breck examine ce problème de domaine de défaillance. Redémarrer les répliques ne peut pas, à lui seul, réparer leur dépendance partagée.

Consigner les preuves et la responsabilité du rétablissement

Consignez à côté de la configuration ce qui reste utile, ce qu’un redémarrage changerait et qui est responsable du rétablissement. Ce JSON est un document de planification, pas une politique exécutable.

{
  "framework": "wait-route-restart",
  "wait": "bounded-initialization-allowance",
  "route": "scoped-request-usefulness",
  "restart": "tested-local-recovery-mechanism",
  "acceptance": "observed-state-and-real-requests"
}

L’absence de sonde de vivacité peut être raisonnable lorsqu’aucun signal ne justifie un redémarrage. Kubernetes documente cette possibilité. L’objection mérite tout autant d’attention : un simple retrait du trafic par la disponibilité peut laisser une instance bloquée indisponible indéfiniment. L’analyse de Breck montre pourquoi cette conception doit tout de même prévoir une personne ou un mécanisme responsable du rétablissement de la progression.

Contrôler les dépendances pour la disponibilité sans retirer de capacité utile

Distinguer les dépendances essentielles des fonctionnalités facultatives

Les consignes officielles autorisent les contrôles de disponibilité pour les dépendances strictes aux services en arrière-plan. Henning Jacobs met en garde contre les contrôles de dépendances partagées, tandis que Breck examine les dépendances qui varient selon les requêtes. Demandez-vous ce qu’apporte le retrait du trafic.

Prenons une API hypothétique qui a besoin de sa base de données pour chaque requête autorisée. Marquer l’instance comme indisponible peut décrire fidèlement sa capacité. Pour une autre API hypothétique, les routes de lecture fonctionnent malgré une panne de télémétrie. Le retrait éliminerait de la capacité utile. Le fonctionnement dégradé doit néanmoins respecter les autorisations et les autres exigences de sécurité.

Lorsque les routes dépendent de services différents, envisagez une gestion des défaillances par route ou des charges de travail distinctes, avec des contrats de disponibilité différents. Le périmètre de défaillance doit justifier la charge supplémentaire de déploiement et de maintenance.

Limiter les contrôles et préserver le fonctionnement dégradé

Fixez des limites de temps aux contrôles des dépendances et précisez ce qui se passe en cas de dépassement. Un état de santé mis en cache nécessite un âge maximal et une règle pour les résultats inconnus ou périmés. Un contrôle réussi hier ne prouve pas que le service peut accepter des requêtes maintenant.

La disponibilité peut osciller. Kubernetes propose des seuils de réussites et d’échecs consécutifs, dont le fonctionnement est décrit dans le guide de configuration. Choisissez ces seuils à partir du comportement observé. Tout lissage supplémentaire dans le code de l’application doit lui aussi être testé.

Excluez les défaillances de dépendances des contrôles de vivacité, sauf si des tests expliquent comment un redémarrage local les corrige. Les articles de praticiens incluent des exemples historiques de contrôleurs ; validez le chemin d’entrée installé plutôt que de supposer que ces exemples décrivent son comportement actuel.

Exemple de configuration de sondes HTTP et de contrat des points de terminaison

Donner des significations distinctes au démarrage, à la disponibilité et à la vivacité

Ce fragment doit être placé dans la spécification d’un conteneur. Ce n’est pas un Deployment complet et exécutable. Il suppose une application à l’écoute sur le port 8080 avec les points de terminaison indiqués. Les valeurs temporelles sont des exemples sans mesures de référence, pas des recommandations de réglage.

ports:
  - name: http
    containerPort: 8080
startupProbe:
  httpGet:
    path: /startupz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 24
  successThreshold: 1
readinessProbe:
  httpGet:
    path: /readyz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 2
livenessProbe:
  httpGet:
    path: /livez
    port: http
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

Dans ce contrat proposé, /startupz indique que l’initialisation est terminée. /readyz indique si l’instance doit recevoir le trafic de son périmètre. /livez détecte une condition locale qu’un redémarrage peut résoudre. Ces chemins distincts facilitent l’examen de cet exemple ; Kubernetes n’exige pas d’URL distinctes.

Les sondes HTTP contrôlent le statut de la réponse, pas la réussite d’une opération métier. Le guide de configuration officiel définit les codes de réussite de 200 à 399. La gestion des redirections comporte des exceptions à examiner : kubelet suit les redirections vers le même hôte, mais une redirection vers un autre hôte ou une chaîne d’au moins 11 redirections est considérée comme une réussite, avec un événement ProbeWarning. Préférez une réponse de santé explicite à une redirection vers une page de connexion. Limitez la taille des réponses et excluez les secrets ou les détails sensibles sur les dépendances.

Choisir les délais à partir de données sur la charge de travail

periodSeconds définit la fréquence des sondes. timeoutSeconds limite la durée d’une sonde individuelle. failureThreshold compte les échecs consécutifs, tandis que successThreshold compte les réussites consécutives après un échec. Ce dernier doit valoir 1 pour le démarrage et la vivacité. Les contrôles de disponibilité peuvent être plus fréquents lorsque le conteneur est indisponible. Il s’agit du fonctionnement documenté de ces champs, pas d’une recette de réglage.

Mesurez l’initialisation dans les conditions de démarrage que vous souhaitez prendre en charge, y compris les démarrages à froid pertinents. Examinez également le délai de grâce avant l’arrêt. Kubelet respecte le délai de grâce applicable lors d’un arrêt déclenché par une sonde ; un délai propre à la sonde est disponible pour le démarrage et la vivacité, mais pas pour la disponibilité. Consultez la documentation des sondes.

Multiplier les seuils ne donne pas une échéance exacte de rétablissement. L’ordonnancement, les dépassements de délai, l’arrêt, les délais croissants entre redémarrages et l’initialisation influencent aussi le temps écoulé. Un guide exécutable nécessiterait un environnement de test complet, avec des versions verrouillées et des résultats d’exécution conservés. Ce fragment n’a pas été exécuté sur un cluster.

Procédure de préproduction : tester les défaillances, examiner les preuves, puis déployer

Établir l’état de référence et tester une défaillance à la fois

Il s’agit de tests proposés, pas de résultats expérimentaux. Avant le premier test :

1. Inventoriez le comportement des points de terminaison, les paramètres de santé par défaut du framework et les hypothèses de routage.
2. Enregistrez la configuration actuelle des sondes et les éléments de référence sur les requêtes, la disponibilité et les redémarrages.
3. Attribuez à chaque défaillance une action attendue et un responsable du rétablissement.
4. Testez une défaillance à la fois sur une charge de travail isolée en préproduction.
5. Comparez les observations au contrat avant d’approuver un déploiement de portée limitée.
6. Conservez la configuration de l’application examinée et la procédure de retour à la version précédente du déploiement.

Utilisez une application jetable pour les blocages délibérés. N’injectez pas d’interblocages dans des services de production partagés.

Vérifier à la fois l’état Kubernetes et les requêtes réelles

Lisez les conditions des Pods et les nombres de redémarrages des conteneurs. Examinez les événements et, lorsqu’ils sont disponibles, les journaux du conteneur précédent, puis mettez en relation la disponibilité des EndpointSlices du Service concerné avec les requêtes passant par le Service ou le point d’entrée prévu. La documentation des sondes et celle du cycle de vie expliquent les transitions d’état. À elle seule, une configuration acceptée prouve peu de choses sur le rétablissement.

Les modifications des EndpointSlices atteignent les mécanismes de surveillance et les caches des clients à des moments différents, comme l’explique la documentation officielle des EndpointSlices. Elle documente aussi une exception : publishNotReadyAddresses donne la valeur true à l’état ready du point de terminaison, quelle que soit la disponibilité du Pod. Ce guide suppose que cette option est désactivée. Testez le chemin de routage installé et les requêtes de longue durée ; ne supposez pas que tous les contrôleurs cessent immédiatement d’acheminer de nouvelles requêtes ni qu’un échec de disponibilité ferme les connexions établies.

Pour les services d’inférence, comparez les éléments observés par les sondes avec l’observabilité de l’inférence IA. Un processus en bonne santé ne permet pas de déterminer la latence des réponses, la réussite des requêtes ou la qualité des résultats. Le guide de traçage OpenTelemetry GenAI apporte du contexte aux appels de modèles et d’outils. Il complète les tests des sondes.

Mesurez le rétablissement, pas seulement les indicateurs au vert.

Définir le rétablissement et le retour à la version précédente avant la production

Rejetez la modification si des répliques non concernées se retirent du trafic, si les redémarrages augmentent sans rétablissement, si des routes utiles échouent ou si le rétablissement reste inexpliqué. Fixez des critères d’acceptation propres à la charge de travail plutôt que d’emprunter des seuils universels de latence ou de disponibilité.

Le retour à la version précédente doit restaurer le contrat des points de terminaison et la configuration des sondes qui ont été examinés, au moyen du processus de déploiement habituel. Vérifiez ensuite la disponibilité, le comportement des redémarrages et les requêtes réelles. La réussite d’une commande de déploiement ne prouve pas le rétablissement.

Les erreurs des équipes et ce que les sondes ne peuvent pas garantir

Éviter les signaux de défaillance communs et les redémarrages injustifiés

Des contrôles identiques méritent un examen attentif lorsque leurs échecs ont des conséquences différentes. Parmi les autres erreurs figurent le contrôle d’un point d’écoute d’administration qui renseigne peu sur le chemin de traitement des requêtes, ou la définition de seuils trop stricts sans mesures de démarrage. Jacobs aborde les angles morts des ports d’administration et les risques des redémarrages.

Imposer des URL différentes comme règle absolue n’est pas plus pertinent. Kubernetes décrit des conceptions avec un point de terminaison partagé et des seuils différents. Examinez le signal et sa conséquence. Le nom d’un point de terminaison ne permet pas de déterminer si un redémarrage sera utile.

Traiter séparément les perturbations, l’arrêt et le travail durable

Un PodDisruptionBudget limite les opérations d’éviction volontaire prises en charge. Il ne coordonne pas les redémarrages de conteneurs déclenchés par la vivacité et ne garantit pas de niveau minimal de disponibilité. La documentation officielle des perturbations en définit le périmètre. La discussion historique de la communauté aide à comprendre cette confusion ; ce n’est pas une spécification actuelle.

Le retrait du trafic par la disponibilité n’assure pas un arrêt progressif, la fin des connexions en cours ni l’arrêt des processus de traitement en arrière-plan. La documentation du cycle de vie des Pods traite l’arrêt séparément. Ces responsabilités nécessitent des conceptions et des tests explicites.

Redémarrer un conteneur ne permet pas non plus d’établir l’état de référence des tâches ni de dédupliquer les écritures externes. Pour les charges de travail d’agents, examinez l’état durable des flux de travail et leur rétablissement en parallèle de la santé des conteneurs.

Les sondes observent les signaux que vous avez choisis. Elles ne peuvent pas établir l’exactitude complète de l’application, sa sécurité ou la qualité de l’inférence. Les gestionnaires de santé consomment eux aussi des ressources, et l’état mis en cache peut devenir périmé. Le guide d’exploitation doit expliquer ces limites et comment reconnaître le rétablissement.