infra / kubernetes

Rolling updates et rollback

Leçon 131 exercice

Explication

Ce que vous allez apprendre

Comprendre le principe du rolling update, la stratégie par défaut d'un Deployment
Piloter la vitesse d'une mise à jour avec maxSurge et maxUnavailable
Comprendre pourquoi la readinessProbe est indispensable au bon fonctionnement du rolling update
Revenir instantanément à la version précédente avec rollout undo
Documenter un déploiement pour retrouver le fil en situation de crise

Dans quel contexte ?

Une équipe déploie la version 2.4 de son API un vendredi après-midi. Cinq minutes après le déploiement, le taux d'erreurs 500 explose : un bug introduit dans cette version fait planter chaque requête touchant le panier utilisateur. Plutôt que de paniquer et de chercher à corriger le code dans l'urgence, la bonne réaction est immédiate : kubectl rollout undo deployment/api, qui restaure en quelques secondes la version 2.3 qui fonctionnait, le temps de corriger le bug sereinement. Cette leçon explique comment ce mécanisme de rollback fonctionne, et comment la mise à jour initiale, elle, se fait déjà sans interruption de service.

Le défi : mettre à jour sans couper le service

D'abord, un défi bien concret : comment remplacer l'ancienne version d'une application par la nouvelle sans interrompre le service pour les utilisateurs ?

La stratégie par défaut d'un Deployment

La réponse s'appelle le rolling update : la stratégie par défaut d'un Deployment, qui remplace les Pods progressivement, quelques-uns à la fois, plutôt que tous d'un coup.

Ce que ça donne pendant la transition

À tout moment pendant la mise à jour, un mélange d'anciens et de nouveaux Pods sert le trafic, garantissant une continuité de service.

Réglage	Effet
`maxSurge`	Nombre de Pods supplémentaires temporairement tolérés pendant la mise à jour
`maxUnavailable`	Nombre de Pods pouvant être indisponibles en même temps
`maxUnavailable: 0`	Aucune perte de capacité tolérée (production critique)
`rollout undo`	Retour instantané à la révision précédente

Deux réglages pour piloter la vitesse

Une fois ce principe posé, deux paramètres pilotent l'agressivité de ce remplacement. maxSurge autorise temporairement plus de Pods que le nombre demandé, pour accélérer la mise à jour sans jamais réduire la capacité disponible.

Le deuxième réglage, pour limiter la casse

maxUnavailable limite combien de Pods peuvent être indisponibles en même temps pendant la transition. En production critique, on pousse souvent maxUnavailable à 0 : aucune perte de capacité tolérée, quitte à ce que la mise à jour prenne un peu plus de temps.

Prérequis

Cette leçon s'appuie directement sur la readinessProbe vue à la leçon précédente : sans elle, aucun mécanisme ne permet à Kubernetes de savoir qu'un nouveau Pod est réellement prêt à recevoir du trafic.

Pourquoi la readiness probe est ici indispensable

Ce mécanisme ne fonctionne correctement que si Kubernetes sait reconnaître qu'un nouveau Pod est réellement prêt avant de lui envoyer du trafic. C'est exactement le rôle de la readinessProbe vue à la leçon précédente.

Ce qui se passe sans cette probe

Sans elle, un rolling update peut envoyer du trafic vers des Pods encore en train de démarrer, ce qui provoque des erreurs pour les utilisateurs.

Revenir en arrière rapidement en cas de problème

Si une nouvelle version s'avère défectueuse, rollout undo permet de revenir instantanément à la version précédente, en s'appuyant sur l'historique conservé des ReplicaSets successifs.

Bonne pratique

Garde le réflexe kubectl rollout status deployment/<nom> juste après tout déploiement : la commande attend que le rolling update se termine réellement (ou échoue) avant de rendre la main, ce qui évite de croire un déploiement terminé alors qu'il est encore en cours.

Documenter pour retrouver le fil en situation de crise

Documenter chaque changement via une annotation dédiée, comme kubernetes.io/change-cause, rend cet historique réellement exploitable quand il faut comprendre vite ce qui a changé.

Maintenant que tu sais déployer sans interruption, la leçon suivante change de sujet : éviter de dupliquer des manifestes YAML entre projets et environnements, avec Helm.

Commandes & code

Rolling updates & rollback

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2          # jusqu'à 2 Pods EN PLUS pendant la mise à jour (8 max temporairement)
      maxUnavailable: 1    # jamais plus d'1 Pod indisponible en même temps
    # type: Recreate       # alternative : tue tout puis recrée (downtime, utile si incompatibilité de version)
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myorg/api:1.4.2
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
            periodSeconds: 5

# Déclencher une mise à jour
kubectl set image deployment/api-deployment api=myorg/api:1.5.0
# équivalent déclaratif :
kubectl apply -f deployment.yaml   # après avoir changé "image:" dans le fichier

# Suivre la progression en direct
kubectl rollout status deployment/api-deployment

# Historique des révisions (nécessite d'avoir gardé un changement de "template" à chaque fois)
kubectl rollout history deployment/api-deployment
kubectl rollout history deployment/api-deployment --revision=3

# Rollback à la révision précédente
kubectl rollout undo deployment/api-deployment

# Rollback vers une révision précise
kubectl rollout undo deployment/api-deployment --to-revision=2

# Mettre en pause un rollout pour l'inspecter avant qu'il se termine
kubectl rollout pause deployment/api-deployment
kubectl rollout resume deployment/api-deployment

# Annoter le changement pour un historique lisible dans "rollout history"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
  annotations:
    kubernetes.io/change-cause: "Bump api to 1.5.0 - fix memory leak"
spec:
  # ...

Résumé

maxSurge/maxUnavailable contrôlent l'agressivité du rolling update (vitesse vs disponibilité).
Une readinessProbe fiable est OBLIGATOIRE : sans elle, Kubernetes route du trafic vers un Pod pas prêt.
rollout undo s'appuie sur l'historique des ReplicaSets : ne pas le purger trop agressivement.
kubernetes.io/change-cause rend rollout history exploitable en production.

Exercices pratiques

1 disponible

Mission : revenir en arrière un vendredi après-midi

Objectif : Effectuer un rollback rapide après un déploiement défectueux, et configurer une stratégie de mise à jour sans aucune perte de capacité.

Contexte

L'équipe déploie la version 2.4 de son API un vendredi après-midi. Cinq minutes plus tard, le taux d'erreurs 500 explose sur toutes les requêtes touchant le panier utilisateur. Il faut revenir immédiatement à la version qui fonctionnait, puis reconfigurer la stratégie de déploiement pour qu'un futur incident similaire ne coupe plus jamais aucune capacité de service.

Résoudre l’exercice →