Contrôles de santé et récolte de processus

Le problème

Une déclaration de santé qui ne fait rien est pire que rien du tout, car deux autres mécanismes la lisent et lui font confiance.

Une mise à jour progressive a besoin de savoir si un nouveau conteneur est prêt avant de lui rediriger le trafic de l’ancien ; sans sonde, la disponibilité est incertaine. L’ordre de démarrage a la même dépendance : attendre qu’un élément devienne sain n’a de sens que si la santé est observée. Ces deux vérifications étaient autrefois satisfaites par la simple présence d’un bloc de santé — et un bloc de santé qui ne produit aucune sonde les satisfaisait exactement de la même manière qu’un bloc fonctionnel. Le résultat était un déploiement qui passait toutes les étapes et n’était jamais réellement vérifié.

Commente la plateforme résout le problème

Seule une sonde que la plateforme peut réellement exécuter est acceptée. Une déclaration qui nomme une URL ou un port, et obligerait la plateforme à inventer une commande pour la tester, est refusée lors de son application plutôt que stockée et ignorée silencieusement. La forme acceptée est décrite dans la référence du déploiement, et le refus nomme le champ et l’alternative.

Ce refus est une décision mesurée, pas une préférence. Lorsque la plateforme synthétisait des sondes, elle remplaçait les contrôles de santé que les images portaient déjà par des commandes que ces images ne pouvaient pas exécuter — l’outil appelé par la sonde inventée n’était pas dans l’image, donc un conteneur sain signalait une défaillance.

Une seule règle réécrit ce que vous avez stocké, et elle le dit. Un délai de sonde inférieur au minimum de la plateforme est relevé à ce minimum plutôt que laissé en place, car une sonde expirée est tuée, et c’est le chemin de mise à mort qui fuite le processus décrit ci-dessous. Le changement est annoncé avec son propre code dans la réponse et le journal, donc une valeur que vous n’avez jamais envoyée ne change jamais en silence. Chaque annonce de ce type est listée dans rejections and alterations.

Deux autres valeurs suivent la plateforme plutôt que d’être figées dans votre description : elles sont appliquées lorsque le conteneur est créé et votre document stocké continue de ne rien dire. La différence est importante — une valeur par défaut écrite dans votre enregistrement vous fixe à la valeur par défaut de la plateforme du jour où vous y avez touché pour la dernière fois, et personne n’a décidé de cela.

Récolte

Une sonde qui expire est tuée, et tout ce qu’elle a lancé est orphelin. Un processus orphelin est adopté par ce qui s’exécute comme premier processus dans le conteneur, et la plupart des images exécutent l’application à cet endroit — une application qui ne collecte jamais les enfants morts qu’elle vient d’hériter. Ils s’accumulent pendant toute la durée de vie du conteneur.

Le remède est un petit premier processus dont le seul travail est de les collecter. Il n’est pas réservé aux conteneurs qui déclarent une sonde : une image peut porter sa propre vérification d’état de santé, et une application qui démarre des sous-processus fuit sans aucune sonde.

Not this

Il ne s’agit pas de la sonde du répartiteur de charge. Le bord de routage a sa propre vérification d’état de santé avec son propre chemin et son propre intervalle, il décide si le trafic est envoyé, et les deux ne sont jamais déduits l’un de l’autre.

Cette page ne porte pas non plus les valeurs plancher, les valeurs par défaut ou les commandes acceptées. Ce sont des colonnes dans la référence générée, et un nombre répété dans la prose est un nombre qui peut être en désaccord avec celui que la plateforme applique.

Où le voir

• Les champs de sonde, leurs valeurs par défaut et quelle règle s’applique à chacun : manifeste de déploiement.
• Pourquoi une sonde a été refusée, par code : rejets et altérations.
• Pourquoi une sonde est importante avant une mise à jour progressive : mises à jour progressives.