Rolling Update Kubernetes : déployer sans interruption de service

La mise à jour progressive Kubernetes (rolling update) permet de déployer une nouvelle version d'application sans indisponibilité. Pour tout administrateur système suivant une formation Kubernetes administrateur système, maîtriser cette stratégie est indispensable : 82% des utilisateurs de conteneurs exécutent Kubernetes en production (CNCF Annual Survey 2025).

TL;DR : Le rolling update remplace progressivement les pods anciens par les nouveaux, garantissant une disponibilité continue. Configurez maxSurge et maxUnavailable dans votre Deployment, puis déclenchez la mise à jour avec kubectl set image ou kubectl apply. En cas de problème, kubectl rollout undo restaure instantanément la version précédente.

Cette compétence est au cœur de la formation LFS458 Administration Kubernetes.

Prérequis avant de commencer

Avant d'exécuter votre premier rolling update Kubernetes stratégie, vérifiez ces éléments essentiels.

Environnement requis

Composant	Version minimale	Commande de vérification
kubectl	v1.28+	`kubectl version --client`
Cluster Kubernetes	v1.28+	`kubectl version`
Deployment existant	-	`kubectl get deployments`

kubectl version --client
# Résultat attendu :
# Client Version: v1.29.0
# Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

Connaissances préalables

Vous devez comprendre :

Les objets Deployment et ReplicaSet (consultez le Guide Complet Formation Kubernetes)
Les commandes kubectl de base (voir l'aide-mémoire kubectl)
Les labels et selectors Kubernetes

À retenir : Un rolling update s'applique uniquement aux Deployments. Les DaemonSets et StatefulSets utilisent des mécanismes différents.

Étape 1 : Comprendre le mécanisme de rolling update

Un rolling update est une stratégie de mise à jour progressive Kubernetes qui remplace les pods un par un. Kubernetes crée un nouveau ReplicaSet, y démarre des pods avec la nouvelle version, puis termine progressivement les pods de l'ancien ReplicaSet.

Comment fonctionne le processus ?

Le processus de rolling update suit cette séquence :

Création d'un nouveau ReplicaSet avec la nouvelle image
Montée en charge progressive des nouveaux pods
Vérification des readiness probes avant de continuer
Terminaison progressive des anciens pods
Suppression de l'ancien ReplicaSet une fois vide

kubectl describe deployment nginx-deployment | grep -A 5 "RollingUpdateStrategy"
# Résultat attendu :
# RollingUpdateStrategy:  25% max unavailable, 25% max surge

Cette stratégie garantit qu'à tout moment, un nombre suffisant de pods traite les requêtes. Pour approfondir les stratégies de déploiement et mise en production Kubernetes, consultez notre hub dédié.

Étape 2 : Configurer la stratégie de déploiement

Définissez les paramètres maxSurge et maxUnavailable selon vos besoins de disponibilité.

Paramètres clés

Paramètre	Définition	Valeur recommandée
`maxSurge`	Pods supplémentaires créés pendant la mise à jour	25% ou 1
`maxUnavailable`	Pods pouvant être indisponibles	0 ou 25%
`minReadySeconds`	Temps d'attente après Ready avant de continuer	10-30 secondes

Créer un Deployment optimisé

Appliquez cette configuration pour un rolling update sans interruption :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: webapp:v1.0.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi

kubectl apply -f deployment.yaml
# Résultat attendu :
# deployment.apps/webapp created

À retenir : Avec maxUnavailable: 0, Kubernetes garantit que tous vos pods restent disponibles pendant la mise à jour. C'est la configuration la plus sûre pour la production.

Les équipes IT passent en moyenne 34 jours de travail par an à résoudre des problèmes Kubernetes (Cloud Native Now). Une configuration correcte dès le départ réduit considérablement ce temps.

Étape 3 : Exécuter un rolling update

Plusieurs méthodes permettent de déclencher une mise à jour progressive. Choisissez celle adaptée à votre workflow.

Méthode 1 : kubectl set image

La méthode la plus rapide pour mettre à jour l'image d'un conteneur :

kubectl set image deployment/webapp webapp=webapp:v2.0.0 --record
# Résultat attendu :
# deployment.apps/webapp image updated

Le flag --record enregistre la commande dans l'historique des révisions, facilitant les rollbacks ultérieurs.

Méthode 2 : kubectl apply

Pour des modifications plus complexes, modifiez le fichier YAML et appliquez :

kubectl apply -f deployment-v2.yaml --record
# Résultat attendu :
# deployment.apps/webapp configured

Cette approche s'intègre parfaitement dans un pipeline CI/CD pour Kubernetes. Pour des déploiements reproductibles, privilégiez Helm Charts : 70% des organisations utilisent Helm pour gérer leurs déploiements (Orca Security 2025).

Méthode 3 : kubectl patch

Pour des modifications ciblées sans fichier YAML complet :

kubectl patch deployment webapp -p '{"spec":{"template":{"spec":{"containers":[{"name":"webapp","image":"webapp:v2.0.0"}]}}}}'
# Résultat attendu :
# deployment.apps/webapp patched

Étape 4 : Surveiller le déploiement en temps réel

Vérifiez l'avancement du rolling update pour détecter tout problème rapidement.

Suivre le statut du rollout

kubectl rollout status deployment/webapp
# Résultat attendu (en cours) :
# Waiting for deployment "webapp" rollout to finish: 2 out of 4 new replicas have been updated...
# 
# Résultat attendu (terminé) :
# deployment "webapp" successfully rolled out

Observer les ReplicaSets

kubectl get replicasets -l app=webapp
# Résultat attendu :
# NAME                DESIRED   CURRENT   READY   AGE
# webapp-7d4f5b8c9    4         4         4       30s
# webapp-5b6c7d8e9    0         0         0       5m

L'ancien ReplicaSet (webapp-5b6c7d8e9) conserve 0 replicas mais reste présent pour permettre un rollback.

Vérifier les événements

kubectl describe deployment webapp | tail -20
# Résultat attendu :
# Events:
#   Type    Reason             Age   From                   Message
#   ----    ------             ----  ----                   -------
#   Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set webapp-7d4f5b8c9 to 1
#   Normal  ScalingReplicaSet  90s   deployment-controller  Scaled down replica set webapp-5b6c7d8e9 to 3

À retenir : L'historique des révisions est conservé par défaut (10 révisions). Configurez revisionHistoryLimit selon vos besoins de rollback.

Pour des stratégies de monitoring avancées, consultez les tutoriels et guides pratiques Kubernetes. La stack Prometheus + Grafana est utilisée par 75% des équipes pour surveiller Kubernetes (Grafana Labs).

Étape 5 : Effectuer un rollback si nécessaire

Un déploiement défaillant nécessite une réponse rapide. Maîtrisez les commandes de rollback.

Consulter l'historique des révisions

kubectl rollout history deployment/webapp
# Résultat attendu :
# deployment.apps/webapp 
# REVISION  CHANGE-CAUSE
# 1         kubectl apply --filename=deployment.yaml --record=true
# 2         kubectl set image deployment/webapp webapp=webapp:v2.0.0 --record=true

Revenir à la révision précédente

kubectl rollout undo deployment/webapp
# Résultat attendu :
# deployment.apps/webapp rolled back

Revenir à une révision spécifique

kubectl rollout undo deployment/webapp --to-revision=1
# Résultat attendu :
# deployment.apps/webapp rolled back

Vérification immédiate après rollback :

kubectl get pods -l app=webapp -o jsonpath='{.items[*].spec.containers[*].image}'
# Résultat attendu :
# webapp:v1.0.0 webapp:v1.0.0 webapp:v1.0.0 webapp:v1.0.0

Dépannage des erreurs courantes

Les rolling updates peuvent échouer pour plusieurs raisons. Identifiez et résolvez rapidement ces problèmes.

Pods bloqués en ImagePullBackOff

kubectl get pods -l app=webapp
# Problème détecté :
# NAME                     READY   STATUS             RESTARTS   AGE
# webapp-7d4f5b8c9-abc12   0/1     ImagePullBackOff   0          2m

Solution : Vérifiez le nom et le tag de l'image, ainsi que les credentials du registry.

kubectl describe pod webapp-7d4f5b8c9-abc12 | grep -A 5 "Events"

Déploiement bloqué : readiness probe échoue

kubectl rollout status deployment/webapp
# Problème détecté :
# Waiting for deployment "webapp" rollout to finish: 1 old replicas are pending termination...

Les anciens pods ne se terminent pas car les nouveaux n'atteignent jamais l'état Ready.

Solution : Vérifiez la configuration de votre readiness probe et les logs applicatifs.

kubectl logs -l app=webapp --tail=50

Pour un guide complet de diagnostic, consultez notre article Résoudre les erreurs de déploiement Kubernetes.

Ressources insuffisantes

kubectl describe pod webapp-7d4f5b8c9-def34 | grep -A 3 "Conditions"
# Problème détecté :
# Warning  FailedScheduling  default-scheduler  0/3 nodes are available: 3 Insufficient cpu

Solution : Ajustez les requests/limits ou ajoutez des nœuds au cluster.

À retenir : Un maxSurge de 25% avec 4 replicas crée 1 pod supplémentaire. Si vos nœuds sont saturés, le rolling update échouera. Planifiez la capacité.

Bonnes pratiques pour des rolling updates fiables

Pratique	Raison	Configuration
Readiness probes	Évite le routage vers des pods non prêts	`initialDelaySeconds: 10`
Resource requests	Garantit le scheduling	CPU et mémoire définis
PodDisruptionBudget	Protège la disponibilité	`minAvailable: 50%`
Graceful shutdown	Termine proprement les connexions	`terminationGracePeriodSeconds: 30`

Ces configurations font partie des compétences évaluées lors de la certification CKA. Les équipes dépensent 88% de plus chaque année en TCO Kubernetes (Spectro Cloud) : investir dans les bonnes pratiques réduit ces coûts.

Passez à l'action : maîtrisez les déploiements Kubernetes

Le rolling update est une compétence fondamentale pour tout administrateur Kubernetes. 80% des organisations exécutent Kubernetes en production avec une moyenne de 20+ clusters (Spectro Cloud State of Kubernetes 2025). La demande de professionnels certifiés ne cesse de croître : le salaire moyen d'un développeur Kubernetes atteint 152 640$/an (Ruby On Remote).

Développez vos compétences avec les formations certifiantes SFEIR :

LFS458 Administration Kubernetes : 4 jours pour préparer le CKA, incluant les stratégies de déploiement avancées
LFD459 Kubernetes pour les développeurs : 3 jours pour maîtriser les Deployments côté applicatif
Kubernetes, les fondamentaux : 1 journée pour découvrir les concepts essentiels

Rapprochez-vous de votre OPCO pour explorer les possibilités de financement. Contactez nos conseillers pour définir votre parcours de formation.

Points clés