Kubernetes : cinq états normalisés pour un node

Ce qui se passe

Readiness, taints, état des pods, labels, annotations, API propre au fournisseur : Kubernetes ne manquait pas de façons de décrire ce qui arrive à un nœud. Il manquait une façon partagée et possédée par Kubernetes de dire qu'un nœud est en cours de drain, en maintenance, ou en arrêt propre.

La v1.37 réserve cinq NodeConditionType :

Le format est celui de toutes les conditions de nœud — rien de neuf à apprendre, et c'est l'intérêt :

# extrait de Node .status
status:
  conditions:
  - type: MaintenancePlanned
    status: "True"
    reason: MaintenanceWindow
    lastTransitionTime: "2026-12-09T12:00:00Z"
    message: "Hardware maintenance is scheduled for this Node"

status vaut True, False ou Unknown ; reason porte une cause stable et lisible par une machine, message le détail pour l'humain.

Pourquoi ça compte

Sans contexte partagé, des composants individuellement corrects prennent des décisions incompatibles. Le billet donne trois cas qui parleront à quiconque a déjà drainé un nœud en production :

• le contrôleur de DaemonSet recrée un pod que le kubelet venait de terminer volontairement pendant un arrêt propre ;
• le contrôleur de Job attend indéfiniment une phase terminale sur un nœud que l'administrateur est en train de retirer ;
• l'opérateur de stockage apprend la maintenance après le début du drain.

Un taint influence l'ordonnancement, mais il n'atteste pas qu'un drain est en cours ni que ses critères sont atteints. Un nœud NotReady ne dit pas si la cause est une panne, un arrêt propre ou une maintenance planifiée. C'est cette distinction que les cinq conditions rendent enfin exprimable.

Comment s'y prendre

Le point à ne pas manquer : la feature gate NodeLifecycleConditions est Alpha et désactivée par défaut, mais en v1.37 elle est sans effet. Elle ne restreint pas qui peut écrire ces conditions, et aucun composant du cœur ne les lit. Vous n'avez donc rien à activer pour commencer à les publier dès aujourd'hui ; la gate existe pour opter, plus tard, dans les comportements que les contrôleurs intégreront.

Le motif recommandé sépare nettement les deux registres :

1. Publier l'état avec les conditions de cycle de vie — pour les humains, les tableaux de bord, les alertes et les automatisations qui choisissent de lire le signal.
2. Agir avec les mécanismes existants : kubectl cordon, kubectl drain, les taints, et les contrôles propres à chaque charge de travail.

Mettez True tant que l'état est actif, puis False — ou retirez la condition — quand il ne l'est plus. Et décidez quel composant possède chaque condition : deux écrivains sur la même condition, c'est un conflit silencieux.

Reste la nuance opérationnelle : la maintenance couvre le déploiement matériel ou logiciel, la remédiation, le retrait de service et le débogage. Faut-il drainer ? Cela dépend de l'impact — un live patch de noyau peut s'en passer, une montée de version de Kubernetes devrait suivre un drain.

À retenir

C'est une fondation, pas une fonctionnalité finie : la suite prévoit des contrôleurs qui consomment ces conditions — le premier cas visé étant le budget de disponibilité d'un déploiement de DaemonSet, aujourd'hui consommé par des nœuds que l'administrateur a volontairement sortis du service.

L'action du jour est modeste et rentable : dans vos scripts de drain maison et vos alertes, remplacez la détection par annotation par ces cinq noms, avant que chaque outil ne fige la sienne. Le travail se suit dans KEP-5683.

Source : Kubernetes v1.37: Introducing Node Lifecycle Conditions