Exercice 01 : Gérer les Rolling Updates et Rollbacks

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Mettre à jour une image sans interruption de service (rolling update)
• ✅ Configurer maxUnavailable et maxSurge pour affiner la stratégie
• ✅ Consulter l'historique des révisions avec kubectl rollout history
• ✅ Revenir à une révision précédente avec kubectl rollout undo

Durée estimée : 20 minutes

Difficulté : ⭐⭐⭐☆☆ (Avancé)

Prérequis : minikube démarré, maîtrise des Deployments

📖 Contexte

En production, les mises à jour doivent se faire sans coupure. Kubernetes implémente la stratégie RollingUpdate : les pods sont remplacés progressivement. Si une nouvelle version est défectueuse, le rollback permet de revenir immédiatement à l'état précédent.

📋 Énoncé

Vous allez déployer nginx 1.24, effectuer une mise à jour vers 1.25 avec une stratégie contrôlée, simuler une mise à jour défectueuse, puis effectuer un rollback.

Résultat attendu :

• Mise à jour sans interruption de service
• Rollback réussi vers la version précédente

🧭 Déroulement de l'exercice

Tâche 1 : Déployer la version initiale

Appliquez le manifest rolling-deploy.yaml avec nginx 1.24 et annotez la révision.

Indice : Ajoutez --record (déprécié mais utile) ou annotez manuellement avec kubectl annotate.

Vérification : kubectl rollout history deployment rolling-deploy affiche la révision 1.

Tâche 2 : Configurer la stratégie RollingUpdate

Modifiez le Deployment pour définir maxUnavailable: 1 et maxSurge: 1.

Indice : Ces paramètres se trouvent dans spec.strategy.rollingUpdate.

Vérification : kubectl describe deployment rolling-deploy affiche la stratégie configurée.

Tâche 3 : Effectuer une mise à jour d'image

Mettez à jour l'image du conteneur vers nginx:1.25 et observez le rolling update en temps réel.

Indice : kubectl set image deployment/rolling-deploy nginx=nginx:1.25 puis kubectl rollout status.

Vérification : kubectl rollout status deployment/rolling-deploy affiche successfully rolled out. kubectl rollout history montre la révision 2.

Tâche 4 : Simuler une mise à jour défectueuse

Mettez à jour vers une image inexistante nginx:cette-version-nexiste-pas et observez le blocage.

Indice : kubectl rollout status va attendre. Kubernetes ne supprime pas les anciens pods tant que les nouveaux ne sont pas Ready.

Vérification : kubectl get pods montre des pods en ImagePullBackOff ET les anciens pods toujours en Running.

Tâche 5 : Effectuer un rollback

Annulez la mise à jour défectueuse et revenez à la révision 2 (nginx:1.25).

Indice : kubectl rollout undo deployment/rolling-deploy revient à la révision précédente. --to-revision=N pour une révision spécifique.

Vérification : Tous les pods sont Running avec l'image nginx:1.25.

🗂️ Mini-Projet : Déploiement contrôlé en production

Déployez une application avec une stratégie stricte (0 pod indisponible pendant la mise à jour).

# prod-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prod-app
  annotations:
    kubernetes.io/change-cause: "Version initiale nginx 1.24"
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: prod-app
  template:
    metadata:
      labels:
        app: prod-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.24
          ports:
            - containerPort: 80

Checkpoints :

• kubectl rollout history deployment prod-app affiche la révision 1 avec l'annotation
• Mise à jour vers nginx:1.25 → kubectl rollout status confirme le succès
• kubectl rollout history affiche 2 révisions
• Mise à jour vers nginx:invalide → les 4 anciens pods restent Running
• kubectl rollout undo deployment prod-app --to-revision=2 restaure nginx 1.25