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