Le blue-green deployment : principe et avantages pour Kubernetes

Le blue-green deployment est une technique de déploiement qui maintient deux environnements de production identiques (blue = version actuelle, green = nouvelle version) et bascule le trafic instantanément d’un environnement à l’autre. Contrairement aux rolling deployments natifs de Kubernetes (remplacement progressif des pods), le blue-green offre un rollback instantané : si la version green pose problème, on rebascule vers blue en quelques secondes, sans attendre la recréation des pods.

Sur Kubernetes avec Istio Service Mesh, le blue-green devient particulièrement puissant. Istio permet de router le trafic avec une granularité fine, 100 % vers blue, puis 10 % vers green pour les canary tests, puis 100 % vers green, sans modifier les déploiements Kubernetes. Le changement est purement au niveau de la configuration Istio, déployable sans redémarrage de pods.

Ce guide implémente un pipeline blue-green complet : deux Deployments Kubernetes (blue et green), un VirtualService Istio qui contrôle le routing, et un script de bascule automatisé avec health checks et rollback automatique en cas d’échec.

Prérequis : Kubernetes et Istio configurés

Ce guide suppose un cluster Kubernetes 1.29+ avec Istio 1.22+ installé. Pour installer Istio : `istioctl install –set profile=default` puis `kubectl label namespace default istio-injection=enabled`. Vérifiez l’installation avec `istioctl verify-install`.

La topologie cible : un Service Kubernetes qui cible les pods blue ET green (via un label partagé `app: monapp`), un VirtualService Istio qui distribue le trafic entre deux DestinationRules (une pour chaque couleur), et une Gateway Istio qui expose l’application à l’extérieur.

Les prérequis opérationnels : vos images Docker doivent être versionnées avec des tags immuables (jamais `:latest` en production), votre registry doit être accessible depuis le cluster, et vous devez avoir des health checks (readinessProbe et livenessProbe) correctement configurés sur vos pods, ils sont critiques pour la détection automatique des problèmes.

Configuration des Deployments blue et green

Créez deux Deployments Kubernetes identiques sauf pour le label `version` et le tag d’image. Le Deployment blue utilise la version actuelle en production, le Deployment green la nouvelle version à déployer. Les deux ont le label partagé `app: monapp` qui les relie au même Service Kubernetes.

Dimensionnez les deux Deployments selon votre besoin : en phase de bascule, le green monte en replicas pendant que le blue descend. En état stable (100 % du trafic sur green), le blue peut être réduit à 1 replica en standby pour un rollback rapide, puis à 0 une fois la version green validée.

Configurez des readinessProbes strictes sur vos pods : le pod ne reçoit du trafic que quand il répond 200 à votre endpoint de santé. Sur un blue-green, un pod green non prêt ne doit JAMAIS recevoir du trafic de production, Istio respecte l’état de readiness des pods Kubernetes.

Routage Istio : VirtualService et DestinationRule

La DestinationRule Istio définit les sous-ensembles de pods (blue et green) via des selectors de labels. Le VirtualService définit comment distribuer le trafic entre ces sous-ensembles avec des poids en pourcentage. La bascule se résume à modifier deux entiers dans le VirtualService, un `kubectl apply` et le trafic bascule.

Pour un canary progressif : commencez avec 5 % green / 95 % blue, observez les métriques (taux d’erreur, latence P99) pendant 15 minutes, passez à 20/80, puis 50/50, puis 100/0. Istio avec Kiali vous donne une visualisation en temps réel de la distribution du trafic et des métriques par version.

En cas d’anomalie détectée sur la version green (taux d’erreur >1 % ou latence P99 >500ms), un script automatique peut basculer immédiatement à 0 % green / 100 % blue, le rollback complet prend moins de 5 secondes, le temps que le changement se propage dans le mesh Istio.

Automatisation CI/CD du blue-green avec GitHub Actions

L’intégration du blue-green deployment dans un pipeline CI/CD transforme chaque merge en main en déploiement sécurisé et réversible. Le pipeline type : build et push de l’image Docker → déploiement sur le Deployment green → attente des readiness checks → shift progressif du trafic via kubectl patch sur le VirtualService → validation automatique (tests de fumée, métriques) → basculement final à 100 % ou rollback.

La validation automatique est la clé du pipeline. Après chaque étape de shift, le pipeline exécute des tests de fumée (quelques requêtes HTTP aux endpoints critiques) et vérifie les métriques via l’API Prometheus. Si le taux d’erreur dépasse un seuil configuré, le pipeline déclenche automatiquement le rollback via `kubectl apply` du VirtualService avec les poids inversés.

Stockez la configuration courante du VirtualService avant chaque déploiement pour garantir que le rollback revient à l’état exact précédent. Un simple `kubectl get virtualservice monapp -o yaml > /tmp/vs-backup.yaml` avant le déploiement, et `kubectl apply -f /tmp/vs-backup.yaml` pour le rollback.

Observabilité et monitoring du blue-green

Un blue-green deployment sans observabilité est imprudent. Istio + Prometheus + Grafana (la stack standard CNCF) vous donnent des métriques détaillées par version : taux de requêtes, latence P50/P95/P99, taux d’erreur, toutes segmentées par label `version` (blue vs green).

Configurez des alertes Alertmanager sur les métriques critiques pendant la phase de bascule : si le taux d’erreur de la version green dépasse 0,5 % dans les 10 premières minutes, déclenchez une alerte PagerDuty ET déclenchez le rollback automatique. Cette double action (humain + automatique) garantit une réponse rapide même si l’on-call n’est pas immédiatement disponible.

Utilisez Kiali (tableau de bord de visualisation d’Istio) pour avoir une vue graphique en temps réel du flux de trafic entre blue et green. En phase de bascule, un ingénieur supervise visuellement la migration, les anomalies (pods en erreur, latence inhabituelle) sont immédiatement visibles sans nécessiter l’interprétation de logs textuels.

# VirtualService Istio — Blue-Green Deployment
# Modifier les weights pour basculer blue → green

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: monapp-destination
spec:
  host: monapp-service
  subsets:
  - name: blue
    labels:
      version: blue
  - name: green
    labels:
      version: green

---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: monapp-vs
spec:
  hosts:
  - monapp-service
  http:
  - route:
    - destination:
        host: monapp-service
        subset: blue
      weight: 100   # ← Phase 1 : 100% blue
    - destination:
        host: monapp-service
        subset: green
      weight: 0     # ← Passer à 20 pour canary, puis 100 pour full green

---
# Script de bascule automatisé (à intégrer dans CI/CD)
# kubectl patch virtualservice monapp-vs --type='json' -p='[
#   {"op":"replace","path":"/spec/http/0/route/0/weight","value":0},
#   {"op":"replace","path":"/spec/http/0/route/1/weight","value":100}
# ]'
# Rollback : inverser les valeurs (100/0)

Automatiser le basculement avec des gates de métriques

Un basculement blue-green manuel reste risqué : l’opérateur décide « à l’œil » que la version green est saine. En 2026, la pratique mûre consiste à conditionner le switch à des métriques objectives via un contrôleur d’analyse comme Argo Rollouts ou Flagger. On définit un seuil de taux d’erreur et de latence p99 ; tant que green ne les respecte pas sur une fenêtre d’observation, le trafic ne bascule pas et un rollback automatique est déclenché.

L’intérêt va au-delà du confort : on supprime la fenêtre humaine pendant laquelle un incident peut passer inaperçu. La promotion devient un événement déterministe, traçable, et reproductible entre environnements.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    blueGreen:
      activeService: app-active
      previewService: app-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
          - templateName: success-rate
        args:
          - name: service
            value: app-preview
---
# AnalysisTemplate : promotion seulement si succès >= 99 %
metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.99
    failureLimit: 3

Gérer les migrations de base de données en blue-green

Le point aveugle du blue-green, ce n’est pas le code applicatif, c’est la base de données partagée entre les deux versions. Si green applique une migration destructive (renommer ou supprimer une colonne), blue casse instantanément, et le rollback devient impossible puisque le schéma a déjà changé. La parade est le pattern expand / contract : on n’applique jamais de changement incompatible en une fois.

On procède en trois temps : expand (ajouter la nouvelle colonne, sans toucher l’ancienne, les deux versions fonctionnent), déploiement green qui écrit dans les deux, puis contract (supprimer l’ancienne colonne seulement une fois blue définitivement retiré). Chaque migration reste ainsi rétrocompatible, ce qui préserve la propriété fondamentale du blue-green : pouvoir revenir en arrière à tout instant.

Coûts, pièges et quand préférer le canary

Le blue-green double temporairement l’empreinte d’infrastructure : deux flottes complètes tournent en parallèle pendant la transition. Sur un cluster dimensionné au plus juste, cela peut saturer le scheduler ou faire exploser la facture cloud le temps du switch. Il faut donc prévoir la capacité, ou s’appuyer sur l’autoscaling pour absorber le pic.

Autres pièges récurrents : les connexions longues (WebSocket, gRPC streaming) qui ne basculent pas instantanément et exigent un drain propre côté Istio ; et l’affinité de session, qui peut renvoyer un même utilisateur vers blue après la promotion. Quand le coût du doublement d’infra est prohibitif ou que l’on veut limiter le blast radius, le canary, montée progressive 5 % → 25 % → 100 %, est souvent le meilleur compromis. Le blue-green brille surtout quand on a besoin d’un rollback instantané et d’une bascule atomique, par exemple pour une migration réglementée.

Sources et références

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon