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

Un Deployment ne pilote pas directement les Pods : il crée un ReplicaSet, l'objet qui maintient un nombre donné de copies identiques. Une mise à jour ne modifie donc jamais les Pods existants, elle fait cohabiter deux ReplicaSets le temps du basculement. Le contrôleur ajuste le compteur de réplicas de chacun jusqu'à ce que l'ancien tombe à zéro.

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

Deux mots de l'étape 3 méritent d'être distingués, car le rollout ne reprend pas au même moment selon celui qui s'applique. Un Pod Ready répond positivement à sa readinessProbe. Un Pod Available est Ready depuis au moins minReadySeconds. Sans minReadySeconds, les deux coïncident ; avec, vous vous donnez une marge d'observation avant de considérer le Pod comme bon, et le remplacement du suivant attend d'autant.

Ce qui déclenche un rollout, et ce qui n'en déclenche pas

Retenez une règle unique, dont tout le reste découle : seules les modifications du Pod template (.spec.template) créent une nouvelle révision. Un kubectl scale n'en crée aucune, il ajuste le compteur de réplicas du ReplicaSet courant. Changer replicas, progressDeadlineSeconds ou revisionHistoryLimit ne déclenche donc rien : ces champs vivent en dehors du template.

Cette règle explique une commande qui semble faire exception, kubectl rollout restart. Elle redéploie tous les Pods sans qu'aucune image ne change, ce qui paraît contredire le principe.

kubectl rollout restart deployment/mon-app

Sortie

deployment.apps/mon-app restarted

Il n'y a pourtant aucune exception. La commande écrit une annotation horodatée dans le Pod template, ce que vous pouvez constater :

kubectl get deployment mon-app -o jsonpath='{.spec.template.metadata.annotations}'

Sortie

{"kubectl.kubernetes.io/restartedAt":"2026-09-14T11:19:32+02:00"}

Le template a changé, donc une nouvelle révision est créée et un rollout progressif démarre, avec vos maxSurge et maxUnavailable habituels. C'est la commande à connaître pour recharger une configuration injectée en variables d'environnement, qui ne se rafraîchit jamais autrement, ou pour relancer une application coincée sans supprimer de Pod à la main.

Déclencher une rolling update

Trois façons d'obtenir le même résultat, qui diffèrent par ce qu'elles laissent derrière elles. Les deux méthodes impératives (set image et edit) modifient l'objet dans le cluster sans toucher à vos fichiers : votre dépôt Git ne reflète plus la réalité tant que vous ne l'avez pas mis à jour. La méthode déclarative reste la seule cohérente avec une gestion en GitOps.

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.27.4

Le saut de version choisi ici n'est pas décoratif. CVE-2025-23419 touche la réutilisation de session TLS de nginx, et l'avis publié sur nginx.org tient en deux lignes :

nginx.org/en/security_advisories.html

Vulnerable:      1.11.4-1.27.3
Not vulnerable:  1.27.4+, 1.26.3+

La seconde ligne dit l'essentiel pour qui planifie une mise à jour. Le correctif existe en 1.27.4 sur la branche courante, mais aussi en 1.26.3 sur la branche stable précédente : l'éditeur rétroporte. Vous n'êtes donc pas forcé de changer de branche pour vous corriger, un saut de patch suffit, ce qui change beaucoup la discussion avec une équipe réticente à bouger.

Méthode 2 : modifier le manifeste

C'est la seule méthode qui laisse une trace exploitable. Le commentaire documente le saut de version pour la revue de code, et le diff Git vous donne l'historique que rollout history ne conserve que partiellement. Changez l'image dans votre fichier YAML :

deployment.yaml

spec:
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.27.4@sha256:09369da6b10306312cd908661320086bf87fbae1b6b0c49a1f50ba531fef2eab  # anciennement 1.27.3

Puis appliquez :

kubectl apply -f deployment.yaml

Méthode 3 : kubectl edit

kubectl edit ouvre le manifeste courant dans l'éditeur défini par la variable KUBE_EDITOR ou EDITOR, et applique la modification à l'enregistrement du fichier.

kubectl edit deployment/mon-app

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

Suivre la progression

Trois niveaux d'observation répondent à trois questions différentes : le rollout avance-t-il, quels Pods sont concernés, et où en sont les deux ReplicaSets. Commencez par le premier, descendez aux suivants seulement si quelque chose bloque.

Statut en temps réel

La commande reste attachée au terminal et affiche une ligne à chaque progression, jusqu'à la fin du rollout ou son échec :

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...
Waiting for deployment "nginx-rolling" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-rolling" successfully rolled out

La bascule entre les deux formulations est le moment intéressant : tant que la ligne parle de new replicas, Kubernetes crée ; quand elle passe à old replicas are pending termination, tous les nouveaux Pods sont prêts et il ne reste qu'à retirer les anciens.

Observer les Pods

L'option -w laisse la commande ouverte et affiche une ligne à chaque changement d'état : c'est ce qui rend le remplacement visible en direct.

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

C'est la vue la plus parlante d'un rollout : chaque révision correspond à un ReplicaSet distinct, et la colonne DESIRED montre où en est le transfert de réplicas de l'un vers l'autre.

kubectl get rs -l app=nginx-rolling

Sortie :

NAME                       DESIRED   CURRENT   READY   AGE
nginx-rolling-5fd47c9ffd   3         3         3       2s    # Nouveau
nginx-rolling-65c7697fff   0         0         0       5s    # Ancien

L'ancien ReplicaSet reste à DESIRED=0 pour permettre un rollback : c'est lui qui porte le Pod template de la version précédente. Ne vous fiez pas à l'ordre d'affichage, kubectl trie par nom, donc par empreinte du template, pas par ancienneté. La colonne AGE et la valeur DESIRED sont les deux seules qui disent qui est qui.

Configurer la stratégie de déploiement

Le rythme se règle dans .spec.strategy, et l'arbitrage est toujours le même : plus vous acceptez de Pods indisponibles, plus la mise à jour est rapide ; plus vous exigez de disponibilité, plus il faut de ressources libres. Deux paramètres décrivent ce compromis, complétés par deux garde-fous temporels.

Les paramètres clés

Ce manifeste regroupe les quatre réglages qui gouvernent un rollout, avec la readinessProbe sans laquelle aucun d'eux n'a de sens :

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.27.3@sha256:bc2f6a7c8ddbccf55bdb19659ce3b0a92ca6559e86d42677a5a02ef6bda2fcef
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 3

maxSurge et maxUnavailable

Ces deux valeurs s'expriment en nombre entier de Pods ou en pourcentage du champ replicas. maxSurge est arrondi à l'entier supérieur, maxUnavailable à l'entier inférieur. Si vous ne les précisez pas, Kubernetes retient 25 % pour les deux : sur les 4 réplicas du manifeste ci-dessus, cela autorise 1 Pod en surplus et 1 Pod indisponible.

Ces deux arrondis vont dans le même sens, celui de la prudence, et cela se voit. Avec 3 réplicas et 10 % pour les deux, le calcul donne maxSurge = ceil(0,3) = 1 et maxUnavailable = floor(0,3) = 0. Autrement dit, Kubernetes s'autorise un Pod de plus mais aucun de moins :

kubectl get deployment arr -w

Sortie pendant le rollout

NAME   READY   UP-TO-DATE   AVAILABLE
arr    3/3     1            3
arr    4/3     1            3
arr    3/3     2            3
arr    4/3     2            3
arr    3/3     3            3

La colonne READY passe à 4/3 à chaque étape, le temps qu'un nouveau Pod devienne prêt avant qu'un ancien parte, et AVAILABLE ne descend jamais sous 3. Attention à la lecture de describe, qui affiche 10% max unavailable, 10% max surge sans jamais montrer le résultat de l'arrondi : seul le comportement le révèle.

Elles ne peuvent pas valoir zéro toutes les deux : le rollout n'aurait alors aucun moyen de progresser, et le serveur d'API refuse le manifeste avant même de le créer.

The Deployment "nginx-zero" is invalid: spec.strategy.rollingUpdate.maxUnavailable:
Invalid value: 0: may not be 0 when `maxSurge` is 0

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

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

Deux réglages opposés, à choisir selon ce que vous pouvez sacrifier. Le premier remplace la moitié de la flotte d'un coup et convient à une recette ; le second ne retire jamais un Pod avant d'en avoir un prêt, au prix d'une capacité supplémentaire mobilisée pendant toute l'opération.

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é

Un rollout qui n'aboutit pas ne s'annule pas tout seul : les anciens Pods continuent de servir et le Deployment reste indéfiniment en cours. Sans minuteur, personne ne s'en aperçoit. Kubernetes fournit un délai de non-progression qui bascule le Deployment en échec, donc détectable par une supervision.

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

Lisez bien les deux lignes ensemble, car leur combinaison déroute : Available reste à True. Le Deployment est en échec et votre application répond toujours, puisque les anciens Pods n'ont jamais été retirés. C'est une bonne nouvelle en production, et un piège en supervision : une alerte qui ne surveille que la disponibilité ne verra jamais ce rollout raté. Surveillez la condition Progressing.

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

L'option --timeout borne l'attente côté client, indépendamment de progressDeadlineSeconds qui agit côté contrôleur. C'est ce qui rend la commande utilisable comme étape bloquante dans un pipeline.

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

La commande sort en code 1 si le rollout échoue ou dépasse le délai, ce qui suffit à faire échouer une étape de pipeline sans analyser sa sortie :

Sortie

Waiting for deployment "bloque" rollout to finish: 1 out of 2 new replicas have been updated...
error: deployment "bloque" exceeded its progress deadline

Stratégie Recreate (arrêt complet)

Recreate est la seule alternative à RollingUpdate. Elle supprime la totalité des Pods de l'ancienne révision, attend leur disparition effective, puis crée ceux de la nouvelle. maxSurge et maxUnavailable ne s'y appliquent pas : il n'y a rien à doser.

spec:
  strategy:
    type: Recreate

Dites-vous bien ce que cela implique : Recreate tue tous les anciens Pods avant de créer les nouveaux, ce qui provoque une interruption de service complète pendant toute la mise à jour. La coupure dure au moins le temps d'arrêt des anciens Pods plus le temps de démarrage des nouveaux, sans recouvrement possible.

Cette interruption n'est pas toujours un défaut. Recreate est le bon choix quand deux versions ne peuvent pas cohabiter : une migration de schéma que l'ancienne version ne saurait pas relire, ou une application qui refuse de tourner en plusieurs instances parce qu'elle prend un verrou exclusif.

En revanche, si ce sont des garanties sur l'identité et l'ordre des Pods que vous cherchez, cas d'une base de données ou d'un système distribué, un StatefulSet est plus adapté qu'un Deployment en 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

Sans argument, undo restaure le Pod template de l'avant-dernière révision et l'enregistre comme une nouvelle révision : l'historique s'allonge, il ne recule pas.

kubectl rollout undo deployment/nginx-rolling

Sortie :

deployment.apps/nginx-rolling rolled back

Vérifier la version restaurée

L'expression jsonpath extrait un seul champ, ici l'image du premier conteneur, ce qui évite de relire tout le manifeste pour confirmer le retour arrière.

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

Consulter l'historique des révisions

Chaque révision correspond à un ancien ReplicaSet conservé. La colonne CHANGE-CAUSE reste vide tant que l'annotation dédiée n'a pas été posée, ce qui est le cas par défaut.

kubectl rollout history deployment/nginx-rolling

Sortie :

REVISION  CHANGE-CAUSE
1         <none>
2         Correctif CVE-2025-23419, passage a nginx 1.27.4
3         Correctif CVE-2025-23419, passage a nginx 1.27.4

La troisième ligne n'est pas une coquille, et c'est le piège de cette colonne : la révision 3 a été créée sans qu'on réannote quoi que ce soit, et elle affiche pourtant la raison de la révision 2.

Un undo sans argument restaurant l'avant-dernière révision, l'enchaîner deux fois vous ramène au point de départ. Mesuré : nginx:1.30 puis nginx:1.29-alpine puis nginx:1.30, avec une nouvelle révision à chaque fois. Utile à savoir sous pression, où l'on est tenté de relancer la commande en doutant qu'elle ait pris effet.

Rollback vers une révision spécifique

--to-revision prend un numéro issu de la colonne REVISION de l'historique ; si ce numéro n'existe plus, la commande échoue sans rien modifier.

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

Sortie

error: unable to find specified revision 99 in history

Le cas se présente plus souvent qu'on ne croit : revisionHistoryLimit fait disparaître les révisions les plus anciennes en silence. Vérifiez le numéro avec rollout history avant de le taper.

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

Voir les détails d'une révision

Avec --revision, la commande affiche le Pod template complet enregistré à ce moment-là : image, variables d'environnement, probes. C'est le seul moyen de vérifier vers quoi vous allez revenir avant de lancer le rollback.

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

Annoter les changements

L'historique ne conserve aucune trace de la raison d'un déploiement : face à cinq révisions, rien ne distingue un correctif de sécurité d'un changement de configuration. L'ancienne option --record est dépréciée, la mention se pose désormais explicitement, avec l'annotation kubernetes.io/change-cause.

kubectl annotate deployment/nginx-rolling \
  kubernetes.io/change-cause="Correctif CVE-2025-23419, passage a nginx 1.27.4"

Ou définissez l'annotation dans le manifeste :

metadata:
  annotations:
    kubernetes.io/change-cause: "Correctif CVE-2025-23419, passage a nginx 1.27.4"

Le piège : l'annotation ne se périme pas toute seule

kubernetes.io/change-cause vit sur le Deployment, pas sur la révision. Kubernetes se contente de la recopier dans chaque nouvelle révision au moment où elle est créée. Une annotation posée une fois et jamais mise à jour réapparaît donc à l'identique sur tous les déploiements suivants, et l'historique se met à mentir : trois révisions affichent le même correctif de sécurité alors qu'une seule le portait.

Deux gestes évitent ce faux historique, à choisir selon votre discipline. Soit vous réécrivez l'annotation avant chaque déploiement, avec --overwrite :

kubectl annotate deployment/nginx-rolling --overwrite \
  kubernetes.io/change-cause="Passage a nginx 1.28"

Soit vous la retirez quand vous n'avez rien de particulier à consigner, et la révision suivante affichera honnêtement <none> :

kubectl annotate deployment/nginx-rolling kubernetes.io/change-cause-

Le tiret final de change-cause- n'est pas une faute de frappe : c'est la syntaxe de suppression d'une annotation. En pratique, la première forme convient dans un pipeline, où le CI connaît la raison du déploiement, la seconde lors d'une intervention manuelle.

Une raison utile se lit sous pression

Écrivez la raison pour la personne qui choisira une révision de repli à trois heures du matin, pas pour vous. Un numéro de ticket, une référence de CVE ou un nom de version lui disent quoi restaurer ; « fix » et « update » ne lui disent rien.

Limiter l'historique des révisions

Chaque révision conservée laisse un ReplicaSet à zéro réplica dans le namespace. Ces objets ne consomment ni CPU ni mémoire, mais ils encombrent les listes et alourdissent les requêtes à l'API sur un cluster qui déploie plusieurs fois par jour. 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 un Deployment en pause suspend la prise en compte des modifications du Pod template : vous enchaînez plusieurs changements sans déclencher de rollout. Rien ne repart tant que la reprise n'a pas été demandée, et un Deployment oublié en pause y reste indéfiniment.

Mettre en pause

La pause s'applique immédiatement, y compris au milieu d'un rollout déjà lancé, qui se fige alors dans son état intermédiaire :

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

La reprise applique en une seule fois toutes les modifications accumulées pendant la pause, et ne crée donc qu'une seule nouvelle révision :

kubectl rollout resume deployment/nginx-rolling

Un Deployment en pause refuse le rollback

Tant que le Deployment est en pause, kubectl rollout undo échoue et ne modifie rien :

error: you cannot rollback a paused deployment; resume it first with
'kubectl rollout resume' and try again

Le refus vaut aussi pour --to-revision. Reprenez le Deployment avant toute tentative de retour arrière.

Une pause n'est pas un canary, et la confusion coûte cher en production. Mettre un rollout en pause après un set image fige bien la proportion de Pods remplacés, mais Kubernetes ne répartit pas le trafic en conséquence : le Service envoie autant de requêtes à chaque Pod prêt, ancienne version comprise. Vous obtenez un mélange de versions subi, pas une exposition maîtrisée à une fraction des utilisateurs.

Pour un vrai canary, avec contrôle du trafic et critères d'arrêt, il faut autre chose : deux Deployments derrière un Ingress qui pondère, un contrôleur dédié comme Argo Rollouts ou Flagger, ou un service mesh comme Istio ou Linkerd.

Rollouts multiples en cours (rollover)

Rien n'oblige à attendre la fin d'un rollout pour en lancer un autre. Kubernetes ne met pas les mises à jour en file d'attente : il abandonne celle en cours au profit de la dernière demandée. Le comportement est sain, mais il rend l'état du cluster difficile à lire quand les déploiements s'enchaînent.

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. Ce rollover est voulu : il évite de mener à son terme un déploiement vers une version dont vous ne voulez déjà plus. Le revers est la lisibilité, car plusieurs apply enchaînés en quelques secondes laissent des ReplicaSets intermédiaires qui compliquent la lecture de l'état réel. En production, attendez la fin d'un rollout status avant de lancer le suivant.

Tableau de décision

Il n'existe pas de réglage universellement bon : tout dépend de la contrainte qui vous limite, disponibilité, vitesse ou capacité. Repérez la ligne qui décrit votre situation, et validez la combinaison en recette avant la production.

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

Ces cinq réglages se posent une fois dans le manifeste et couvrent l'essentiel des incidents de déploiement. Les trois premiers déterminent si Kubernetes sait reconnaître qu'un Pod est réellement opérationnel, les deux derniers conditionnent votre capacité à revenir en arrière.

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

Sans ce délai, un rollout bloqué le reste indéfiniment et rien ne le signale. Avec, le Deployment bascule en échec et devient détectable par une supervision. Comptez large par rapport au démarrage normal, sous peine de déclarer en échec un déploiement qui avançait.

spec:
  progressDeadlineSeconds: 600  # 10 minutes

4. Annoter les déploiements

Une annotation posée au moment du déploiement fait gagner un temps considérable le jour où il faut choisir une révision de repli sous pression.

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

5. Conserver un historique raisonnable

Trois à cinq révisions suffisent en pratique : au-delà, la configuration a généralement trop divergé pour qu'un retour arrière soit encore pertinent.

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

Anti-patterns à éviter

Ces erreurs ont un point commun : elles ne se voient pas au moment où on les commet, seulement le jour de l'incident. Un Deployment sans probe se déploie parfaitement, jusqu'à exposer des Pods qui ne répondent pas encore.

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

Le réflexe est toujours le même : regarder l'état des nouveaux Pods avant de toucher au Deployment. Le tableau associe chaque symptôme visible à sa cause la plus fréquente, et les commandes de diagnostic suivent.

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

Le bloc Conditions indique quelle condition bloque, et l'option --previous récupère les logs du conteneur avant son dernier redémarrage, seuls exploitables sur un Pod en boucle de crash :

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

Voir les événements du Deployment

Les événements retracent les décisions du contrôleur, notamment les montées et descentes en charge de chaque ReplicaSet. Ils ne sont conservés qu'une heure par défaut : au-delà, la trace est perdue.

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

Vérifier le statut du rollout

Cette requête liste les conditions portées par le Deployment, typiquement Available et Progressing. C'est ce qui permet de scripter un contrôle sans analyser la sortie de describe.

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

Réflexes CKAD

L'épreuve CKAD est chronométrée : ces six gestes doivent sortir sans hésitation ni consultation de la documentation. Ils couvrent le cycle complet, du déclenchement d'une mise à jour à son annulation.

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

Testez vos connaissances

Sept questions sur les points sensibles : les valeurs par défaut, ce qui déclenche une révision, et les situations où le rollback devient impossible.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Définir les Probes : Les health checks sans lesquels un rollout progresse sur des Pods morts.
• Débugger une application : Le diagnostic d'un rollout bloqué, avant d'annuler la mise à jour.
• Horizontal Pod Autoscaler : L'ajustement automatique du nombre de replicas pendant et après un rollout.

×

📖 Voir la documentation →