Dans mon laboratoire local, cela fait plus d’un an qu’un cluster Kubernetes de test fonctionne sur des machines virtuelles. Tout ce temps, il a servi de bac à sable pour tester les configurations en toute sécurité avant de les déployer en production. Depuis, le cluster est un peu resté bloqué dans le passé : il fonctionne toujours sous la version v1.31, ce qui est considéré comme obsolète (Legacy) et privé de support officiel face aux versions actuelles, la lignée v1.35 étant déjà disponible.
Comme l’environnement de travail approche lui aussi des dates limites de mise à jour, c’est le moment idéal pour tester un cycle complet de mise à niveau de Kubernetes dans des conditions domestiques sécurisées. La procédure de mise à jour via l’utilitaire kubeadm suit une logique stricte. Pour que tout se passe sans douleur et sans casser le cluster, il suffit de respecter rigoureusement deux règles fondamentales :
– La séquence des versions mineures. Kubernetes ne pardonne pas les sauts de version. Essayer de passer directement de la 1.31 à la 1.33 va casser le cluster à coup sûr. On avance étape par étape : 1.31 → 1.32 → 1.33, et ainsi de suite.
– La hiérarchie des composants (le Control Plane en premier). On commence par mettre à jour complètement le nœud Master (k8sm) : l’API server, le scheduler et la base de données etcd. Une fois que le « cerveau » du cluster est à jour, on s’occupe des nœuds Workers, strictement l’un après l’autre.
Évidemment, mettre à jour un cluster de production à haute charge avec des centaines de pods sous un trafic réel est un art d’administration système à part entière avec son lot de pièges. Mais aujourd’hui, nous allons analyser le processus de base classique.
Alors, on se sert un café ou un thé bien fort, on ouvre les terminaux et c’est parti !
Avoir son propre serveur NTP dans le réseau local, c’est utile pour les équipements qui n’ont pas accès direct à internet (switches, firewalls, conteneurs isolés) ou pour réduire la dépendance aux serveurs externes.
