Stratégies de livraison : canary, blue/green, retour arrière

Une mise à jour progressive (rolling update, leçons 2.2 et D.3) remplace les pods un par un : simple, sans coupure, mais tout le monde reçoit la nouvelle version dès qu'elle est prête. Si elle contient un bogue que les sondes ne voient pas (une page fausse, un calcul erroné, une lenteur), tous les utilisateurs le subissent. Les stratégies de livraison avancées limitent cette zone d'impact et accélèrent le retour arrière. Cette leçon est théorique.

Ce que vous saurez à la fin : comparer recreate, rolling update, blue/green et canary, réaliser un blue/green avec un simple Service, décrire un canary piloté par des métriques avec Argo Rollouts, découpler déploiement et activation avec des drapeaux de fonctionnalité, et préparer un retour arrière sûr.

1. Les quatre stratégies

Stratégie	Principe	Coupure	Ressources	Retour arrière
Recreate	tout arrêter, puis tout démarrer	oui	×1	redéploiement
Rolling update	remplacer les pods progressivement	non	×1 + marge	rollout undo, progressif
Blue/green	une version complète à côté, puis basculer tout le trafic	non	×2	instantané (rebasculer)
Canary	envoyer une petite part du trafic à la nouvelle version, puis augmenter	non	×1 + canary	instantané, peu d'utilisateurs touchés

Recreate reste utile quand deux versions ne peuvent pas tourner en même temps (un schéma de base incompatible, un fichier verrouillé).

2. Blue/green avec un Service

Deux Deployments, vitrine-blue (version actuelle) et vitrine-green (nouvelle), avec un label version. Le Service choisit l'un ou l'autre :

apiVersion: v1
kind: Service
metadata: {name: vitrine}
spec:
  selector: {app: vitrine, version: blue}
  ports: [{port: 80, targetPort: 8080}]

kubectl rollout status deployment/vitrine-green                                      # green est prêt
kubectl port-forward deployment/vitrine-green 9000:8080                              # on le teste à part
kubectl patch service vitrine -p '{"spec":{"selector":{"app":"vitrine","version":"green"}}}'   # bascule
kubectl patch service vitrine -p '{"spec":{"selector":{"app":"vitrine","version":"blue"}}}'    # retour arrière, instantané

On garde blue quelques heures avant de le supprimer. Le coût : deux fois les ressources pendant la bascule.

3. Canary, à la main

Le plus simple : deux Deployments derrière le même Service (même label app), 9 réplicas pour la version stable, 1 pour la nouvelle : environ 10 % des requêtes vont au canary. C'est grossier (la proportion dépend du nombre de pods) mais sans aucun outil. Une Gateway API fait mieux, avec des poids explicites (leçon 3.7) :

rules:
  - backendRefs:
      - {name: vitrine-stable, port: 80, weight: 90}
      - {name: vitrine-canary, port: 80, weight: 10}

4. Canary automatisé : Argo Rollouts

Augmenter la part du canary et surveiller les tableaux de bord à la main est fastidieux. Argo Rollouts (ou Flagger, côté Flux) remplace le Deployment par un Rollout qui enchaîne les étapes et analyse des métriques pour décider seul de continuer ou d'annuler :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata: {name: vitrine}
spec:
  replicas: 10
  selector: {matchLabels: {app: vitrine}}
  template: { … }                      # le même modèle de pod qu'un Deployment
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - analysis: {templates: [{templateName: taux-erreurs}]}
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100

L'AnalysisTemplate taux-erreurs interroge par exemple Prometheus : si le taux de réponses 5xx du canary dépasse 1 %, le Rollout annule automatiquement et remet tout le trafic sur la version stable. Personne n'a été réveillé, 10 % des utilisateurs ont vu l'erreur pendant quelques minutes.

5. Découpler déployer et activer

Avec des drapeaux de fonctionnalité (feature flags), le code d'une fonctionnalité est déployé éteint, puis activé à part : pour l'équipe interne, puis 5 % des clients, puis tous. Désactiver un drapeau est plus rapide que tout retour arrière. Le standard ouvert OpenFeature évite de dépendre d'un fournisseur. Le revers : des drapeaux à nettoyer une fois la fonctionnalité généralisée.

6. Un retour arrière qui marche vraiment

• Les migrations de base compatibles dans les deux sens : on ajoute une colonne (compatible avec l'ancienne version) dans une livraison, on retire l'ancienne dans une livraison suivante. Sinon, revenir à l'ancienne version de l'application casse sur le nouveau schéma.
• Des images immuables : le retour arrière redéploie exactement l'image d'avant (empreinte), pas « la dernière 1.4 ».
• En GitOps, le retour arrière est un git revert : sinon, la réconciliation réappliquerait la version fautive.
• Répétez-le : un retour arrière jamais testé ne marche pas le jour où l'on en a besoin.

7. Choisir

Rolling update par défaut ; blue/green quand on veut tester la nouvelle version complète avant toute bascule et revenir en arrière en une seconde ; canary piloté par les métriques pour les services à fort trafic, où une erreur coûte cher et où les métriques sont fiables. Dans tous les cas, ce sont les sondes et les métriques qui rendent une stratégie sûre : sans elles, aucune n'a les yeux ouverts.

Validez la leçon avec le questionnaire.