Toute opération de maintenance sur Kubernetes est une disruption volontaire. La différence entre une maintenance réussie et un incident en production, c’est la méthode : cordon, drain, intervention, uncordon — dans cet ordre, avec les bons garde-fous.
Les PodDisruptionBudgets sont vos filets de sécurité : ils garantissent
que vos interventions respectent les contraintes de disponibilité des
applications, même lors d’une mise à jour d’urgence.
Le workflow de maintenance
Section intitulée « Le workflow de maintenance »-
Vérifier l’état initial —
kubectl get nodesetkubectl get pods -Apour confirmer que le cluster est sain avant d’intervenir. -
Cordon du nœud —
kubectl cordon <nœud>marque le nœud comme non-schedulable : les nouveaux pods ne seront plus placés dessus. -
Drain des pods —
kubectl drain <nœud> --ignore-daemonsets --delete-emptydir-dataévacue les pods existants vers d’autres nœuds. -
Intervention — maintenance OS, remplacement de disque, mise à jour des composants, reboot.
-
Uncordon —
kubectl uncordon <nœud>rend le nœud à nouveau éligible au scheduling une fois la maintenance terminée. -
Vérification —
kubectl describe node <nœud>pour confirmer le retour à l’étatReady.
Guides de cette section
Section intitulée « Guides de cette section »À retenir
Section intitulée « À retenir »- Ne jamais intervenir directement sur un nœud sans l’avoir drainé — les pods pourraient être interrompus brutalement
- Les DaemonSets ne sont pas évacués par drain (normal) — utilisez
--ignore-daemonsets - Les emptyDir sont effacés par drain — vérifiez que ces données sont dispensables ou persistées ailleurs
- La version skew policy de Kubernetes limite la différence de version entre composants à 2 mineurs
- Upgrader composant par composant :
kubectl→kubelet→kubeadm— dans cet ordre