Procédures de mise à niveau de Kubernetes (Control Plane, Noeuds)

Pourquoi mettre à niveau votre cluster Kubernetes ?

La mise à niveau régulière de votre cluster Kubernetes est une opération de maintenance essentielle, bien qu'elle puisse sembler intimidante au premier abord. Elle est cruciale pour plusieurs raisons : bénéficier des derniers correctifs de sécurité qui protègent votre infrastructure contre les vulnérabilités connues, accéder aux nouvelles fonctionnalités et améliorations de performance introduites dans les versions récentes, et assurer la compatibilité avec l'écosystème Cloud Native en constante évolution.

Ignorer les mises à niveau expose votre cluster à des risques de sécurité croissants et peut entraîner une obsolescence technique. A terme, vous pourriez rencontrer des difficultés pour déployer de nouvelles applications ou intégrer des outils modernes. Une planification rigoureuse et une exécution méthodique sont donc nécessaires pour maintenir un cluster sain et à jour.

L'approche générale consiste à planifier soigneusement, en vérifiant la compatibilité des versions et en lisant attentivement les notes de version. L'objectif est de réaliser la mise à niveau de manière contrôlée, en commençant par le Control Plane puis en traitant les Noeuds Workers, tout en minimisant l'impact sur les applications en cours d'exécution.

Mise à niveau séquentielle du Control Plane

Le Control Plane est le cerveau de votre cluster Kubernetes. Sa mise à niveau est la première étape critique du processus global. Elle implique la mise à jour de composants clés tels que l'API Server, etcd (la base de données du cluster), le Scheduler et le Controller Manager. Dans un environnement à haute disponibilité (HA) avec plusieurs maîtres, la procédure doit être effectuée de manière séquentielle pour éviter une interruption complète du service.

La première étape, absolument indispensable, est de réaliser une sauvegarde fiable de la base de données etcd. C'est votre filet de sécurité en cas de problème majeur durant la mise à niveau. Ensuite, sur un cluster HA, on met à niveau un noeud maître à la fois. Pour les clusters créés avec kubeadm, l'outil fournit des commandes pour faciliter ce processus :

# Sur le premier noeud maître
sudo kubeadm upgrade plan      # Vérifier la mise à niveau possible et les prérequis
sudo kubeadm upgrade apply vX.Y.Z # Appliquer la mise à niveau vers la version X.Y.Z

# Mettre à jour kubelet et kubectl sur ce maître
sudo apt-mark unhold kubelet kubectl && \
sudo apt-get update && sudo apt-get install -y kubelet=X.Y.Z-00 kubectl=X.Y.Z-00 && \
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Il faut ensuite répéter la mise à jour manuelle des autres composants (kubelet, kubectl) sur les autres noeuds maîtres, car kubeadm upgrade apply ne met à jour que le premier.

Il est fondamental de respecter la politique de décalage de version (version skew policy) de Kubernetes, qui stipule les différences de versions maximales autorisées entre les composants du Control Plane et entre le Control Plane et les Kubelets des noeuds workers. Généralement, le Control Plane doit être mis à niveau avant les noeuds workers.

Après la mise à niveau de chaque composant du Control Plane (ou de chaque noeud maître en HA), il est crucial de vérifier son état de santé et la disponibilité de l'API Kubernetes. Utilisez des commandes comme kubectl get componentstatuses (bien que déprécié, encore utile pour une vue rapide) et vérifiez les logs des composants pour vous assurer que tout fonctionne correctement avant de passer au noeud maître suivant ou aux noeuds workers.

Mise à niveau contrôlée des Noeuds Workers

Une fois le Control Plane mis à jour et stabilisé, l'étape suivante consiste à mettre à niveau les Noeuds Workers. Cette mise à niveau concerne principalement le Kubelet, Kube-proxy et le runtime de conteneur (Docker, containerd, etc.), ainsi que potentiellement le système d'exploitation sous-jacent.

La méthode la plus sûre pour mettre à niveau un noeud worker sans impacter les applications est d'utiliser le processus de "drainage". Cela consiste à marquer le noeud comme non planifiable (cordon) puis à expulser gracieusement tous les Pods qui y tournent (drain). Kubernetes replanifiera ces Pods sur d'autres noeuds disponibles du cluster, pourvu qu'il y ait suffisamment de capacité.

# Marquer le noeud comme non disponible pour de nouveaux Pods
kubectl cordon 

# Expulser les Pods du noeud (sauf ceux gérés par des DaemonSets)
kubectl drain  --ignore-daemonsets --delete-local-data

L'option --ignore-daemonsets est souvent nécessaire car les Pods de DaemonSets ne peuvent pas être recréés ailleurs. L'option --delete-local-data (anciennement --delete-emptydir-data) force la suppression des Pods utilisant des volumes emptyDir.

Une fois le noeud vidé de ses Pods applicatifs, vous pouvez procéder à la mise à niveau. Si vous utilisez kubeadm, la procédure sur le noeud worker est la suivante :

# Mettre à jour la configuration kubeadm sur le noeud
sudo kubeadm upgrade node

# Mettre à jour kubelet et kubectl sur ce noeud
sudo apt-mark unhold kubelet kubectl && \
sudo apt-get update && sudo apt-get install -y kubelet=X.Y.Z-00 kubectl=X.Y.Z-00 && \
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Une alternative courante, surtout dans les environnements cloud ou avec une approche d'infrastructure immuable, est de ne pas mettre à niveau les noeuds en place, mais de créer de nouveaux noeuds avec la version à jour, de les joindre au cluster, puis de drainer et supprimer les anciens noeuds.

Après la mise à niveau des composants et le redémarrage du Kubelet, le noeud doit être réintégré au pool de ressources disponibles. Pour cela, on utilise la commande uncordon :

kubectl uncordon 

Il est recommandé de mettre à niveau les noeuds workers un par un ou par petits groupes pour s'assurer que la capacité restante du cluster est suffisante pour accueillir les Pods déplacés lors des opérations de drainage. Surveillez attentivement l'état du cluster et des applications pendant tout le processus.

Bonnes pratiques et considérations avancées

Tester, tester, tester : Ne réalisez jamais une mise à niveau directement en production sans l'avoir testée au préalable sur un environnement de staging ou de pré-production aussi identique que possible à la production. Cela permet d'identifier les problèmes potentiels liés à vos configurations spécifiques ou à vos applications.

Lire les notes de version : Avant toute mise à niveau, consultez attentivement les "Release Notes" et les "Urgent Upgrade Notes" pour la version cible de Kubernetes. Elles contiennent des informations cruciales sur les changements majeurs, les fonctionnalités dépréciées ou supprimées (notamment les API), et les éventuels problèmes connus.

Plan de rollback : Malgré toutes les précautions, une mise à niveau peut échouer. Ayez un plan de retour en arrière clair. Pour le Control Plane, cela implique généralement la restauration de la sauvegarde etcd effectuée avant la mise à niveau. Pour les noeuds, cela peut signifier revenir à la version précédente des paquets ou détruire et recréer les noeuds avec l'ancienne version.

Automatisation et outils managés : Pour les clusters importants, envisagez d'utiliser des outils d'automatisation ou les fonctionnalités de mise à niveau proposées par votre fournisseur de cloud (EKS, GKE, AKS). Ces services gèrent souvent une grande partie de la complexité de la mise à niveau du Control Plane et offrent parfois des stratégies de mise à niveau automatisées pour les noeuds workers, réduisant ainsi les risques et l'effort manuel.