Rolling updates et rollback

Mettre à jour sans interruption

Un rolling update remplace progressivement les anciens Pods par de nouveaux, quelques-uns à la fois, en gardant le service disponible pendant toute la transition.

kubectl set image deployment/mon-app web=mon-app:v2
kubectl rollout status deployment/mon-app

Kubernetes crée de nouveaux Pods avec la nouvelle image, attend qu'ils soient prêts (via la readinessProbe), puis supprime progressivement les anciens.

Revenir en arrière : le rollback

Si la nouvelle version pose problème, un rollback restaure instantanément la version précédente.

kubectl rollout undo deployment/mon-app
kubectl rollout history deployment/mon-app
kubectl rollout undo deployment/mon-app --to-revision=2

Autoscaling : s'adapter à la charge

Le Horizontal Pod Autoscaler (HPA) ajuste automatiquement le nombre de répliques en fonction de métriques comme l'utilisation CPU.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mon-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mon-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Cas concret

Un déploiement v2 introduit un bug qui fait planter l'application en boucle. Le rolling update détecte que les nouveaux Pods échouent leur readinessProbe et s'arrête automatiquement avant de remplacer tous les anciens Pods : une partie du trafic continue d'être servie par l'ancienne version pendant l'investigation, évitant une panne totale.

Erreurs fréquentes

• Déployer sans readinessProbe : Kubernetes considère un Pod prêt dès qu'il démarre, même si l'application interne n'est pas encore fonctionnelle, ce qui envoie du trafic vers un Pod cassé.
• Paniquer et supprimer le Deployment en cas de bug plutôt que faire un simple rollout undo, bien plus rapide et sûr.
• Ne configurer aucune limite maxReplicas sur un HPA : un pic de charge (ou un bug en boucle) peut scaler à l'infini et exploser la facture cloud.

À retenir

• Un rolling update remplace les Pods progressivement, sans coupure, grâce aux sondes de santé.
• kubectl rollout undo revient à la version précédente en quelques secondes.
• Le HPA ajuste automatiquement le nombre de répliques selon la charge, dans des bornes définies.

Mini-exercice

Un déploiement v2 vient de planter en production. Quelle commande unique restaure l'état stable précédent le plus vite ?

Réponse : kubectl rollout undo deployment/mon-app, qui revient immédiatement à la révision précédente sans avoir à reconstruire ou réappliquer manuellement l'ancienne configuration.