Points clés
- ✓Trois phases : control plane d'abord, puis workers un par un, enfin validation.
- ✓Comptez 2 à 4 heures pour mettre à jour un cluster de 10 nœuds sans interruption.
- ✓'Règle critique: jamais plus d''une version mineure d''écart entre composants.'
Un rolling upgrade Kubernetes désigne la mise à jour progressive des composants d'un cluster (control plane puis worker nodes) sans arrêt de service, en maintenant les workloads disponibles tout au long du processus.
Vous devez maîtriser cette procédure pour garantir la continuité de vos applications en production.
TL;DR : Vous mettez à jour votre cluster en trois phases : control plane d'abord, puis worker nodes un par un avec drain/uncordon, enfin validation. La règle d'or : jamais plus d'une version mineure d'écart entre composants. Prévoyez 2 à 4 heures pour un cluster de 10 nœuds.
Pour maîtriser ces compétences critiques, découvrez la formation LFS458 Administration Kubernetes.
À retenir : 82% des utilisateurs de conteneurs exécutent Kubernetes en production (CNCF Annual Survey 2025). Votre capacité à maintenir ces clusters à jour sans downtime devient une compétence essentielle.
Pourquoi devez-vous planifier vos mises à jour Kubernetes ?
Selon le rapport Spectro Cloud State of Kubernetes 2025, les équipes IT passent en moyenne 34 jours de travail par an à résoudre des problèmes Kubernetes. Une mise à jour mal préparée représente une part significative de ces incidents.
Vous faites face à plusieurs risques si vous négligez la planification :
| Risque | Impact | Mitigation |
|---|---|---|
| Version skew | Incompatibilité API entre composants | Respecter la règle n+1/n-1 |
| Drain incomplet | Pods orphelins, données perdues | PodDisruptionBudgets configurés |
| Rollback impossible | Downtime prolongé | Snapshots etcd avant upgrade |
| Deprecation API | Manifests cassés post-upgrade | Audit avec kubectl convert |
Pour approfondir les fondamentaux de l'administration cluster Kubernetes, consultez notre hub dédié.
Quels prérequis vérifier avant de lancer votre upgrade ?
Validez ces points avant toute intervention sur votre cluster.
Vérification de la version actuelle
# Versions des composants du control plane
kubectl version --short
kubectl get nodes -o wide
# Version de kubeadm sur chaque nœud
kubeadm version
Vous devez identifier la version cible. Kubernetes suit un cycle de release tous les 4 mois. La documentation officielle indique que seules les trois dernières versions mineures reçoivent des patches de sécurité.
Audit des API dépréciées
# Identifier les ressources utilisant des API obsolètes
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis
# Utiliser kubectl convert pour la migration
kubectl convert -f deployment.yaml --output-version apps/v1
À retenir : L'Ingress NGINX Controller prend sa retraite en mars 2026 (InfoQ). Vous devez vérifier vos dépendances avant chaque upgrade.
Configuration des PodDisruptionBudgets
Vous protégez vos workloads critiques avec des PDB :
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: api-server
Pour résoudre les problèmes que vous pourriez rencontrer, référez-vous à notre guide sur les 10 problèmes les plus courants sur un cluster Kubernetes.
Comment préparer votre environnement pour un rolling upgrade ?
Sauvegarde etcd obligatoire
Exécutez cette sauvegarde avant toute modification du control plane.
# Connexion au pod etcd
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# Vérification de l'intégrité
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-$(date +%Y%m%d).db
Vous devez stocker ce snapshot hors du cluster. En cas d'échec critique, c'est votre unique point de restauration.
Validation de l'état du cluster
# Vérifier la santé des nœuds
kubectl get nodes
kubectl get --raw='/healthz?verbose'
# Identifier les pods non-ready
kubectl get pods --all-namespaces | grep -v Running | grep -v Completed
# Vérifier les ressources système
kubectl top nodes
Si vous rencontrez des problèmes réseau durant cette phase, consultez notre guide pour diagnostiquer et résoudre les problèmes réseau dans un cluster Kubernetes.
Comment mettre à jour le control plane pas à pas ?
Étape 1 : Upgrade du premier control plane node
Vous commencez par le nœud principal. Cette opération met à jour l'API server, le controller-manager, le scheduler et etcd.
# Mise à jour des packages kubeadm
sudo apt-mark unhold kubeadm
sudo apt-get update && sudo apt-get install -y kubeadm=1.30.0-1.1
sudo apt-mark hold kubeadm
# Vérification du plan d'upgrade
sudo kubeadm upgrade plan
# Application de l'upgrade
sudo kubeadm upgrade apply v1.30.0
Étape 2 : Upgrade de kubelet et kubectl
# Drain du nœud control plane
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
# Mise à jour kubelet et kubectl
sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.30.0-1.1 kubectl=1.30.0-1.1
sudo apt-mark hold kubelet kubectl
# Redémarrage du kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet
# Réactivation du nœud
kubectl uncordon <node-name>
À retenir : La certification CKA exige un score de 66% sur 2 heures d'examen pratique (Linux Foundation). Les procédures d'upgrade constituent une compétence évaluée. Si vous préparez cette certification, la formation LFS458 couvre ces scénarios en détail.
Étape 3 : Upgrade des control plane nodes secondaires
Vous répétez la procédure sur chaque nœud control plane additionnel :
# Pour chaque control plane node secondaire
sudo kubeadm upgrade node
# Puis drain, upgrade kubelet/kubectl, restart, uncordon
Comment migrer vos worker nodes sans interruption ?
Stratégie de rolling update pour les workers
Vous mettez à jour les worker nodes un par un. Cette approche garantit que vos workloads disposent toujours de ressources suffisantes.
# Pour chaque worker node
NODE=worker-01
# 1. Drain avec grâce
kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --grace-period=60
# 2. Vérification que les pods sont reschedulés
kubectl get pods -o wide --all-namespaces | grep $NODE
# 3. Upgrade kubeadm config
sudo kubeadm upgrade node
# 4. Upgrade kubelet
sudo apt-get install -y kubelet=1.30.0-1.1
sudo systemctl daemon-reload
sudo systemctl restart kubelet
# 5. Réactivation
kubectl uncordon $NODE
Pour comprendre la configuration réseau de vos nœuds, référez-vous à notre guide sur configurer le réseau d'un cluster Kubernetes : CNI, Services et Ingress.
Gestion des StatefulSets pendant l'upgrade
Vous devez porter une attention particulière aux StatefulSets :
# Vérifier les PVC attachés au nœud
kubectl get pvc --all-namespaces -o json | jq '.items[] | select(.spec.volumeName != null)'
# Vérifier les StatefulSets
kubectl get statefulsets --all-namespaces
| Workload Type | Précaution | Commande |
|---|---|---|
| StatefulSet | Attendre sync replicas | kubectl rollout status sts/ |
| DaemonSet | Automatique | Aucune |
| Deployment | PDB requis | Vérifier minAvailable |
| Job | Terminer avant drain | kubectl wait --for=condition=complete |
Comment valider votre upgrade et préparer un rollback ?
Checklist de validation post-upgrade
Exécutez ces vérifications immédiatement après chaque étape.
# 1. Versions cohérentes
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion
# 2. Santé des composants
kubectl get --raw='/healthz?verbose'
kubectl get pods -n kube-system
# 3. Tests applicatifs
kubectl run test-pod --image=nginx --restart=Never
kubectl expose pod test-pod --port=80 --type=ClusterIP
kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- curl test-pod
# 4. Cleanup
kubectl delete pod test-pod
kubectl delete svc test-pod
Plan de rollback
Vous devez préparer votre rollback avant de commencer l'upgrade :
# Restauration etcd (uniquement si corruption critique)
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-backup.db \
--data-dir=/var/lib/etcd-restore \
--initial-cluster=master=https://10.0.0.1:2380 \
--initial-advertise-peer-urls=https://10.0.0.1:2380
# Downgrade kubelet (à éviter si possible)
sudo apt-get install -y kubelet=1.29.0-1.1
sudo systemctl restart kubelet
À retenir : Le downgrade de Kubernetes n'est pas officiellement supporté. Votre backup etcd reste votre filet de sécurité principal. Testez la restauration régulièrement.
Pour une vision complète des bonnes pratiques, consultez notre article sur sécuriser un cluster Kubernetes : les bonnes pratiques indispensables.
Quelles sont les erreurs courantes à éviter ?
Vous devez connaître les pièges classiques :
Erreur 1 : Ignorer le version skew
# Mauvais : sauter plusieurs versions
# v1.27 → v1.30 directement
# Correct : upgrade incrémental
# v1.27 → v1.28 → v1.29 → v1.30
Erreur 2 : Oublier les composants tiers
Avant votre upgrade, vérifiez la compatibilité de :
- CNI plugins (Calico, Cilium, Flannel)
- Ingress controllers
- Service meshes (Istio, Linkerd)
- Monitoring stack (Prometheus, Grafana)
Erreur 3 : Négliger les tests de charge post-upgrade
# Test de charge basique avec kubectl
kubectl run load-test --image=busybox --rm -it -- sh -c 'for i in $(seq 1 100); do wget -q -O- http://service; done'
Selon Chris Aniszczyk, CTO de la CNCF : « Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well » (CNCF State of Cloud Native 2026). Vous investissez dans une compétence durable.
Pour aller plus loin, explorez notre retour d'expérience : migration d'un cluster Kubernetes en production chez un grand compte.
Comment automatiser vos futurs upgrades ?
Vous pouvez scripter la procédure complète :
#!/bin/bash
set -euo pipefail
VERSION="1.30.0-1.1"
NODES=$(kubectl get nodes -o jsonpath='{.items[*].metadata.name}')
for node in $NODES; do
echo "Upgrading $node..."
kubectl drain $node --ignore-daemonsets --delete-emptydir-data
ssh $node "sudo apt-get update && sudo apt-get install -y kubeadm=$VERSION kubelet=$VERSION"
ssh $node "sudo kubeadm upgrade node && sudo systemctl restart kubelet"
kubectl uncordon $node
kubectl wait --for=condition=Ready node/$node --timeout=120s
done
Les ingénieurs infrastructure qui maîtrisent ces procédures sont très recherchés. Selon Hired : « Demand and salaries for highly-skilled and qualified tech talent are fiercer than ever, and certifications present a clear pathway for IT professionals to further their careers. »
Si vous débutez, commencez par les fondamentaux Kubernetes avant d'aborder l'administration avancée.
Passez à l'action : formez-vous à l'administration Kubernetes
Vous avez maintenant une vision complète du processus de mise à jour sans interruption. Pour consolider ces compétences et préparer votre certification CKA, SFEIR propose des formations officielles Linux Foundation :
- LFS458 Administration Kubernetes : 4 jours de formation intensive couvrant l'installation, la configuration, la mise à jour et le dépannage de clusters en production. Cette formation vous prépare directement à l'examen CKA.
- Kubernetes, les fondamentaux : 1 journée pour découvrir les concepts essentiels si vous débutez avec l'orchestration de conteneurs.
Avec plus de 104 000 candidats ayant passé le CKA et une croissance de 49% par an (CNCF Training Report), cette certification valide vos compétences auprès des employeurs. La certification reste valide 2 ans (Linux Foundation). Pour approfondir, consultez notre administrateur système formation Kubernetes, les fondamentaux.
Contactez SFEIR pour planifier votre parcours de formation et obtenir un devis personnalisé.