Rolling Updates et Rollbacks Kubernetes : mises à jour progressives

Comment mettre à jour une application en production avec un risque d’interruption minimal ? Kubernetes propose les rolling updates : vos nouveaux Pods démarrent progressivement pendant que les anciens sont supprimés. Si quelque chose se passe mal, un rollback déclenche un nouveau déploiement vers une révision précédente.

Ce guide vous montre comment configurer des mises à jour progressives fiables et revenir en arrière si nécessaire.

Prérequis : Deployments Kubernetes et kubectl configuré.

Ce que vous allez apprendre

• Déclencher une rolling update avec kubectl set image ou en modifiant le manifeste
• Suivre la progression avec kubectl rollout status
• Configurer la stratégie de déploiement (maxSurge, maxUnavailable)
• Détecter un rollout bloqué avec progressDeadlineSeconds
• Effectuer un rollback vers une version précédente
• Consulter et annoter l’historique des révisions

Comment fonctionne une rolling update

Quand vous modifiez le Pod template (.spec.template) d’un Deployment, Kubernetes :

1. Crée un nouveau ReplicaSet pour la nouvelle version
2. Augmente progressivement le nouveau ReplicaSet
3. Attend que les nouveaux Pods deviennent Ready, puis Available (si minReadySeconds est défini)
4. Réduit l’ancien ReplicaSet au fur et à mesure
5. Considère le rollout complet quand toutes les nouvelles réplicas sont disponibles et qu’aucune ancienne ne tourne

Ready vs Available

Un Pod Ready répond positivement à sa readinessProbe. Un Pod Available est Ready depuis au moins minReadySeconds. Le rollout progresse quand les Pods deviennent Ready ou Available selon la configuration.

Ce qui déclenche un rollout

Seules les modifications du Pod template (.spec.template) déclenchent une nouvelle révision. Un kubectl scale ne crée pas de nouvelle révision — il ajuste simplement le nombre de réplicas du ReplicaSet actuel.

Déclencher une rolling update

Méthode 1 : kubectl set image

La façon la plus rapide de mettre à jour l’image :

kubectl set image deployment/mon-app conteneur=image:nouvelle-version

Exemple :

kubectl set image deployment/nginx-rolling nginx=nginx:1.25

Méthode 2 : modifier le manifeste

Changez l’image dans votre fichier YAML :

deployment.yaml

spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25  # Anciennement 1.24

Puis appliquez :

kubectl apply -f deployment.yaml

Méthode 3 : kubectl edit

kubectl edit deployment/mon-app

Modifiez l’image dans l’éditeur qui s’ouvre, puis sauvegardez.

Suivre la progression

Statut en temps réel

kubectl rollout status deployment/nginx-rolling

Sortie :

Waiting for deployment "nginx-rolling" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-rolling" rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-rolling" successfully rolled out

Observer les Pods

kubectl get pods -l app=nginx-rolling -w

Vous verrez les nouveaux Pods apparaître (ContainerCreating → Running) et les anciens disparaître (Terminating).

Voir les ReplicaSets

kubectl get rs -l app=nginx-rolling

Sortie :

NAME                       DESIRED   CURRENT   READY   AGE
nginx-rolling-64757d479    0         0         0       5m    # Ancien
nginx-rolling-7bf8c77b47   3         3         3       30s   # Nouveau

L’ancien ReplicaSet reste (DESIRED=0) pour permettre un rollback.

Configurer la stratégie de déploiement

Les paramètres clés

deployment-strategy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-rolling
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Combien de Pods en plus pendant l'update
      maxUnavailable: 1  # Combien de Pods peuvent être indisponibles
  progressDeadlineSeconds: 600  # Timeout pour détecter un rollout bloqué
  minReadySeconds: 10           # Attendre 10s après Ready avant de continuer
  selector:
    matchLabels:
      app: nginx-rolling
  template:
    metadata:
      labels:
        app: nginx-rolling
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3

maxSurge et maxUnavailable

Paramètre	Valeur par défaut	Description
maxSurge	25%	Nombre de Pods supplémentaires créés pendant l’update (au-delà de replicas)
maxUnavailable	25%	Nombre maximal de Pods pouvant être indisponibles pendant l’update

Glissez pour voir

Valeurs par défaut

Si vous ne spécifiez pas ces paramètres, Kubernetes utilise 25% pour les deux. Avec 4 réplicas, cela signifie 1 Pod en surge et 1 Pod pouvant être indisponible.

Comprendre maxUnavailable

maxUnavailable contrôle combien de Pods peuvent être indisponibles (pas juste “non-Running”). Un Pod peut être Running sans être Ready ni Available — c’est la disponibilité qui compte, pas l’état Running.

Valeur	Effet
maxUnavailable: 1	1 Pod peut être indisponible pendant l’update
maxUnavailable: 25%	25% des Pods peuvent être indisponibles (arrondi à l’inférieur)
maxUnavailable: 0	Aucun Pod ne doit devenir indisponible — rollout plus prudent mais plus lent

Glissez pour voir

Exemples de stratégies

Mise à jour rapide (priorité à la vitesse) :

strategy:
  rollingUpdate:
    maxSurge: 50%
    maxUnavailable: 50%

Mise à jour prudente (priorité à la disponibilité) :

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Ressources requises

Avec maxUnavailable: 0, Kubernetes doit créer les nouveaux Pods avant de supprimer les anciens. Votre cluster doit avoir suffisamment de ressources pour accueillir temporairement plus de Pods.

Détecter un rollout bloqué

progressDeadlineSeconds

Ce paramètre définit le délai après lequel Kubernetes considère que le rollout n’avance plus :

spec:
  progressDeadlineSeconds: 600  # 10 minutes

Si le rollout n’a pas progressé pendant cette durée (pas de nouveau Pod Ready/Available), le contrôleur marque le Deployment comme failed dans son statut.

Vérifier le statut :

kubectl describe deployment/nginx-rolling | grep -A 5 "Conditions"

Sortie si bloqué :

Conditions:
  Type           Status   Reason
  ----           ------   ------
  Available      True     MinimumReplicasAvailable
  Progressing    False    ProgressDeadlineExceeded

Valeur recommandée

Définissez progressDeadlineSeconds légèrement supérieur au temps normal de démarrage de votre application. Trop court = faux positifs. Trop long = détection tardive des problèmes.

Revérifier avec kubectl rollout status

kubectl rollout status deployment/nginx-rolling --timeout=5m

La commande retourne un code d’erreur si le rollout échoue ou dépasse le timeout.

Stratégie Recreate (arrêt complet)

Pour certains cas très spécifiques, vous pouvez forcer un arrêt complet avant de recréer :

spec:
  strategy:
    type: Recreate

Interruption de service

La stratégie Recreate tue tous les anciens Pods avant de créer les nouveaux. Cela provoque une interruption de service complète pendant la mise à jour.

Quand utiliser Recreate

Recreate convient pour :

• Migrations de schéma incompatibles avec la cohabitation de versions
• Applications qui ne supportent pas plusieurs instances en parallèle

Cependant, si vous avez besoin de garanties fortes sur l’identité et l’ordre des Pods (base de données, systèmes distribués), un StatefulSet est généralement plus adapté qu’un Deployment avec Recreate.

Rollback : revenir en arrière

Un rollback déclenche un nouveau rollout vers une révision précédente. Ce n’est pas un basculement instantané — Kubernetes applique la même stratégie de rolling update pour revenir en arrière.

Rollback vers la révision précédente

kubectl rollout undo deployment/nginx-rolling

Sortie :

deployment.apps/nginx-rolling rolled back

Vérifier la version restaurée

kubectl get deployment nginx-rolling -o jsonpath='{.spec.template.spec.containers[0].image}'

Consulter l’historique des révisions

kubectl rollout history deployment/nginx-rolling

Sortie :

REVISION  CHANGE-CAUSE
1         Initial deployment
2         Upgrade vers nginx 1.25 pour CVE-2024-xxxx
3         <none>

Rollback vers une révision spécifique

kubectl rollout undo deployment/nginx-rolling --to-revision=1

Voir les détails d’une révision

kubectl rollout history deployment/nginx-rolling --revision=2

Annoter les changements

Pour garder une trace des raisons de chaque déploiement, annotez avec kubernetes.io/change-cause :

kubectl annotate deployment/nginx-rolling \
  kubernetes.io/change-cause="Upgrade vers nginx 1.25 pour CVE-2024-xxxx"

Ou définissez l’annotation dans le manifeste :

metadata:
  annotations:
    kubernetes.io/change-cause: "Upgrade vers nginx 1.25 pour CVE-2024-xxxx"

Bonne pratique

Annotez vos déploiements avec une raison claire. Cela facilite l’identification de la bonne révision lors d’un rollback et documente l’historique des changements.

Limiter l’historique des révisions

Par défaut, Kubernetes conserve 10 révisions (anciens ReplicaSets). Pour économiser de l’espace :

spec:
  revisionHistoryLimit: 5

revisionHistoryLimit: 0

Avec revisionHistoryLimit: 0, Kubernetes supprime immédiatement tous les anciens ReplicaSets. Vous ne pourrez plus faire de rollback car l’historique est vide.

Pause et reprise d’un rollout

Mettre en pause

kubectl rollout pause deployment/nginx-rolling

Utile pour :

• Faire plusieurs modifications avant de reprendre (évite des rollouts intermédiaires)
• Investiguer un problème sans que le rollout continue

Reprendre

kubectl rollout resume deployment/nginx-rolling

Rollback impossible si pausé

Vous ne pouvez pas faire de rollback sur un Deployment en pause. Vous devez d’abord le reprendre avec kubectl rollout resume, puis effectuer le rollback.

Pause ≠ Canary natif

Mettre en pause un rollout après set image n’est pas une stratégie canary. Kubernetes ne fait pas de répartition de trafic contrôlée — il remplace progressivement les Pods selon sa stratégie. Pour un vrai canary avec contrôle du trafic, utilisez :

• Deux Deployments avec un Ingress/Service qui répartit le trafic
• Argo Rollouts ou Flagger
• Un service mesh (Istio, Linkerd)

Rollouts multiples en cours (rollover)

Si vous modifiez à nouveau le Deployment pendant qu’un rollout est en cours, Kubernetes :

1. Crée un nouveau ReplicaSet pour la dernière version
2. Commence à abandonner le rollout précédent
3. Scale down le ReplicaSet de la version intermédiaire

Exemple :

# Rollout en cours vers v2
kubectl set image deployment/app app=image:v2

# Avant que v2 soit complètement déployé, vous changez pour v3
kubectl set image deployment/app app=image:v3

Kubernetes va progressivement abandonner v2 et passer directement à v3.

Comportement documenté

C’est le comportement normal de Kubernetes, appelé rollover. Il évite de terminer un rollout vers une version intermédiaire que vous ne voulez plus. Cependant, cela peut créer de la confusion si plusieurs apply s’enchaînent rapidement en production.

Tableau de décision

Situation	Réglage conseillé
Priorité à la disponibilité	maxUnavailable: 0, maxSurge faible, readinessProbe, minReadySeconds
Priorité à la rapidité	maxSurge élevé (50%+), maxUnavailable non nul
Cluster contraint en ressources	Rolling update conservateur, maxSurge faible, éviter le surge
Application fragile au démarrage	readinessProbe stricte, minReadySeconds élevé, progressDeadlineSeconds adapté
Déploiement bleu-vert	maxSurge: 100%, maxUnavailable: 0 (double temporaire des ressources)
Migration incompatible	Stratégie Recreate ou StatefulSet

Glissez pour voir

Bonnes pratiques

1. Toujours configurer une readinessProbe

Sans readinessProbe, Kubernetes risque de considérer un Pod disponible trop tôt, ce qui peut dégrader le rollout et exposer des Pods non réellement prêts au trafic.

spec:
  containers:
  - name: app
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 3
      failureThreshold: 3

2. Définir minReadySeconds

Attendez quelques secondes après le Ready avant de continuer le rollout :

spec:
  minReadySeconds: 10  # Le Pod doit être Ready pendant 10s avant d'être considéré Available

3. Définir progressDeadlineSeconds

Détectez automatiquement les rollouts bloqués :

spec:
  progressDeadlineSeconds: 600  # 10 minutes

4. Annoter les déploiements

kubectl annotate deployment/app \
  kubernetes.io/change-cause="Upgrade vers v2.1 - fix bug #1234"

5. Conserver un historique raisonnable

spec:
  revisionHistoryLimit: 5  # Pas 0, sinon pas de rollback possible

Anti-patterns à éviter

Anti-pattern	Problème	Solution
Pas de readinessProbe	Pods exposés avant d’être prêts	Configurer une probe réaliste
revisionHistoryLimit: 0	Impossible de faire un rollback	Garder au moins 3-5 révisions
Rollback sur Deployment pausé	Échoue	Reprendre d’abord avec resume
Supposer “zéro downtime” garanti	Le rollout dépend de la config et des ressources	Configurer stratégie + probes + tests
Utiliser Recreate pour la persistance	Interruption de service, pas de garantie d’ordre	Utiliser un StatefulSet
Modifier le selector après création	Immutable en apps/v1	Recréer le Deployment si nécessaire
Enchaîner les apply sans vérifier	Rollover peut créer de la confusion	Attendre rollout status entre les déploiements

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
Rollout bloqué à “Waiting”	Nouveaux Pods pas Ready	Vérifier les logs et les probes
ProgressDeadlineExceeded	Rollout n’avance plus depuis X secondes	Investiguer les Pods, éventuellement rollback
Pods en CrashLoopBackOff	Erreur dans la nouvelle image	Rollback immédiat
Rollout très lent	maxUnavailable: 0 + ressources limitées	Augmenter maxSurge ou les ressources
Historique vide	revisionHistoryLimit: 0	Augmenter la limite
Rollback échoue	Deployment pausé	kubectl rollout resume d’abord
Anciens Pods qui ne disparaissent pas	terminationGracePeriodSeconds trop long	Réduire ou vérifier que l’app gère SIGTERM

Glissez pour voir

Voir pourquoi un Pod n’est pas Ready

kubectl describe pod nom-du-pod | grep -A 10 "Conditions"
kubectl logs nom-du-pod --previous

Voir les événements du Deployment

kubectl describe deployment/nginx-rolling | grep -A 20 "Events"

Vérifier le statut du rollout

kubectl get deployment nginx-rolling -o jsonpath='{.status.conditions[*].type}'

Réflexes CKAD

1. Déclencher une rolling update

   kubectl set image deployment/app app=image:v2

2. Suivre la progression

   kubectl rollout status deployment/app

3. Consulter l’historique

   kubectl rollout history deployment/app

4. Rollback

   kubectl rollout undo deployment/app
   # Ou vers une révision spécifique
   kubectl rollout undo deployment/app --to-revision=2

5. Vérifier les ReplicaSets

   kubectl get rs
   kubectl describe deployment/app

6. Piège courant

   kubectl scale ne crée pas de nouvelle révision. Seules les modifications du Pod template déclenchent un rollout.

À retenir

1. Rolling update = mise à jour progressive avec interruption minimale si bien configurée
2. Seules les modifications du Pod template déclenchent une nouvelle révision
3. maxSurge et maxUnavailable valent 25% par défaut
4. maxUnavailable: 0 = aucun Pod indisponible, mais nécessite plus de ressources
5. progressDeadlineSeconds détecte les rollouts bloqués
6. Un rollback déclenche un nouveau rollout vers une ancienne révision — ce n’est pas instantané
7. Impossible de rollback un Deployment pausé — reprendre d’abord
8. revisionHistoryLimit: 0 = pas de rollback possible
9. Toujours configurer des readinessProbes et minReadySeconds
10. Pour un vrai canary avec contrôle du trafic, utilisez Argo Rollouts ou un service mesh

Prochaines étapes

Probes Kubernetes Configurer les health checks pour des rollouts fiables

Horizontal Pod Autoscaling Adapter automatiquement le nombre de replicas

Débugger une application Diagnostiquer les problèmes de déploiement

Deployments en détail Maîtriser les Deployments Kubernetes

×

📖 Voir la documentation →