Kubernetes 1.37 introduit cinq conditions de cycle de vie des nœuds pour signaler drain et maintenance

9 septembre 2026. Kubernetes 1.37 introduit cinq conditions de nœud bien connues — DrainInProgress, Drained, MaintenancePlanned, MaintenanceInProgress et GracefulNodeShutdownInProgress — derrière une feature gate Alpha nommée NodeLifecycleConditions. Le billet est signé Ryan Hallisey (NVIDIA), et il adresse un angle mort que toute équipe qui opère un cluster connaît. Pourquoi c’est important : aujourd’hui, aucun signal natif ne dit pourquoi un nœud est indisponible — et des contrôleurs indépendamment corrects prennent alors des décisions contradictoires.

Le problème : décrire l’indisponibilité sans dire pourquoi

Kubernetes possède déjà de nombreuses façons de décrire ce qui arrive à un nœud. La readiness, les taints, l’état des Pods, les labels, les annotations et les API spécifiques aux fournisseurs exposent chacun une partie du tableau. Ce qui manquait, c’est une façon appartenant à Kubernetes de dire qu’un nœud est en cours de drain, en maintenance, ou qu’il subit un arrêt gracieux (Graceful Node Shutdown).

Le résultat, c’est que chaque composant reconstruit sa propre compréhension à partir de signaux indirects. Un contrôleur peut regarder la readiness du nœud, un autre les taints, un troisième les Pods en terminaison ou manquants. Les fournisseurs d’infrastructure ajoutent leurs propres labels et annotations. Ces signaux restent utiles pour leur usage prévu, mais ils ne répondent pas à la même question.

La différence est subtile et structurante. Une taint peut influencer l’ordonnancement ou l’éviction, mais elle n’atteste pas qu’un drain est en cours, ni que les critères de drain choisis par l’administrateur ont été atteints. Un nœud NotReady n’explique pas si la cause est une panne imprévue, un arrêt gracieux ou une maintenance planifiée.

Cinq conditions pour combler l’angle mort

Kubernetes 1.37 réserve cinq noms comme constantes NodeConditionType bien connues et introduit la feature gate NodeLifecycleConditions, désactivée par défaut. Le tableau d’ensemble est le suivant :

Comme les autres conditions de nœud, chacune utilise status pour rapporter si l’état est actif — True, False ou Unknown — accompagné d’un reason stable, lisible par machine, et d’un message pour le détail humain. Un contrôleur de maintenance autorisé peut publier un état comme celui-ci :

# Extrait de .status d'un nœud
status:
  conditions:
  - type: MaintenancePlanned
    status: "True"
    reason: MaintenanceWindow
    lastTransitionTime: "2026-12-09T12:00:00Z"
    message: "Hardware maintenance is scheduled for this Node"

Un point de conception important : en 1.37, la gate est sans effet. Elle ne restreint pas qui peut poser ces conditions, et aucun composant du cœur ne les lit encore. Elle existe pour que le comportement natif prévu dans les versions futures — des contrôleurs qui consomment ces conditions — puisse être activé le moment venu. On n’a pas besoin de l’activer pour commencer à publier les conditions dès aujourd’hui.

Ce que change la maintenance et le drain

La maintenance recouvre le déploiement matériel ou logiciel, la remédiation, la mise hors service ou le débogage. La question de savoir si une maintenance exige un drain dépend de son impact : une mise à niveau Kubernetes passe en général par un drain, un live patch du noyau n’en a pas besoin. Les conditions de cycle de vie donnent un canal commun pour rendre cet état visible sans imposer un mode opératoire unique.

La valeur immédiate est la clarté opérationnelle. Une automatisation de maintenance peut poser MaintenancePlanned quand une fenêtre future est programmée, puis MaintenanceInProgress quand le travail commence. Une automatisation de drain peut poser DrainInProgress au début de l’éviction des Pods, puis Drained quand les critères sont atteints. GracefulNodeShutdownInProgress rapporte qu’un arrêt gracieux est en cours.

Le schéma recommandé sépare nettement les responsabilités : les conditions servent à rapporter l’état, tandis que les opérations de cycle de vie restent gérées par les mécanismes existants — kubectl cordon, kubectl drain, les taints et les contrôles spécifiques aux workloads. On n’utilise pas les conditions pour changer l’ordonnancement ou l’éviction, mais pour rendre l’état de ce travail visible aux personnes, aux tableaux de bord, aux alertes et aux automatisations qui choisissent de le consommer.

Pourquoi un signal partagé change la donne

Le cycle de vie d’un nœud touche des composants partout dans le cluster. Le kubelet, le node lifecycle controller, les workload controllers, le scheduler, les autoscalers, les opérateurs de stockage et les systèmes de maintenance externes ont tous besoin de comprendre ce qui arrive à un nœud. Sans contexte partagé, des composants individuellement corrects prennent des décisions contradictoires.

Un exemple concret suffit à montrer l’enjeu. Un DaemonSet peut remplacer un Pod que le kubelet a volontairement terminé pendant un arrêt gracieux. Un contrôleur de Job peut attendre indéfiniment une phase terminale sur un nœud qu’un administrateur est en train de retirer. Un opérateur de stockage peut n’apprendre la maintenance qu’une fois le drain déjà commencé. Chacun a raison selon ses propres signaux — et tous se contredisent.

Le cas le plus frappant est celui du DaemonSet en déploiement continu. Un nœud cassé ou en maintenance peut rester indisponible pour des raisons sans rapport avec la nouvelle révision du DaemonSet. Il consomme pourtant le budget de disponibilité du rollout, ce qui peut ralentir ou bloquer la progression sur les nœuds sains. Le contrôleur sait que le Pod est indisponible, mais il ne peut pas distinguer un échec de la nouvelle révision d’une mise hors service intentionnelle. La condition MaintenanceInProgress crée l’endroit, détenu par Kubernetes, pour publier ce contexte — et le travail futur pourra définir comment le contrôleur s’en sert pour l’ordre, la comptabilité de disponibilité et le reporting d’état.

Ce que doivent faire les équipes plateforme

Les conditions sont publiables dès aujourd’hui, sans risquer de casser quoi que ce soit — la gate est sans effet et rien ne les lit encore. C’est précisément ce qui en fait une bonne pratique à adopter tôt.

• Décidez quel composant possède chaque condition — un propriétaire unique par condition évite les écritures conflictuelles entre automatisations ;
• Instrumentez vos fenêtres de maintenance — posez MaintenancePlanned à la planification, MaintenanceInProgress au démarrage, puis repassez à False (ou retirez la condition) à la fin ;
• Instrumentez vos drains — posez DrainInProgress au début de l’éviction et Drained quand vos critères sont atteints ;
• Utilisez des reason stables et des message clairs — les humains comme les automatisations doivent comprendre pourquoi la condition a changé ;
• Ne changez pas vos mécanismes de contrôle — continuez à utiliser kubectl cordon, kubectl drain et les taints pour l’action, et les conditions pour la visibilité.

Le travail est suivi via KEP-5683, et les groupes Node Lifecycle Working Group, SIG Node et SIG Apps sollicitent explicitement les retours des mainteneurs d’outils de maintenance, de remédiation, de drain, d’autoscaling et de gestion de flotte.

Verdict

Kubernetes 1.37 ne résout pas encore le problème de fond — les contrôleurs du cœur ne consomment pas ces conditions — mais il pose la fondation qui manquait : un vocabulaire partagé et détenu par Kubernetes pour dire pourquoi un nœud est indisponible. C’est un changement d’une discrétion trompeuse, dont la valeur se révèle à l’échelle du cluster, quand les composants cessent de se contredire.

Si vous opérez un cluster en production, commencez à publier ces cinq conditions dans votre automatisation de maintenance et de drain dès aujourd’hui. Le coût est quasi nul — la gate est sans effet — et vous préparez votre outillage au comportement natif qui arrivera dans les versions suivantes, au lieu d’avoir à le rattraper.

Si vous maintenez un opérateur ou un contrôleur de cycle de vie, intégrez ces conditions maintenant et remontez vos cas d’usage aux groupes de travail. C’est le moment où l’API se fige, et votre retour pèse directement sur la forme que prendra la coordination à long terme.

Références

• Kubernetes Blog — Kubernetes v1.37: Introducing Node Lifecycle Conditions, 9 septembre 2026
• KEP-5683 — Node Lifecycle Conditions
• Kubernetes Docs — Node conditions