Skip to content
Learni
View all tutorials
DevOps

Comment implémenter un Blue-Green Deployment en 2026

18 minEXPERT
DevOpsKubernetesBlue-Green

Introduction

Le déploiement Blue-Green permet de réduire les risques de mise en production en maintenant deux environnements identiques. L'un (Blue) est actif pendant que l'autre (Green) est mis à jour. Le basculement instantané via le service Kubernetes assure un temps d'arrêt nul. Cette stratégie est devenue incontournable en 2026 pour les applications critiques nécessitant une haute disponibilité.

Prérequis

  • Kubernetes 1.28+
  • kubectl configuré
  • Connaissances avancées en YAML et services
  • Helm optionnel mais recommandé
  • Cluster avec au moins 3 nœuds

Manifest Blue initial

blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
  labels:
    app: myapp
    version: blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: app
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10

Ce manifest déploie la version Blue stable avec 3 replicas et une sonde de vivacité. Les labels permettent un routage précis via le service.

Manifest Green mis à jour

green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: app
        image: myapp:1.1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5

Le déploiement Green utilise une nouvelle image. Les probes readiness garantissent que le trafic n'est dirigé que vers les pods prêts.

Service de routage

service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: blue
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

Le sélecteur pointe initialement vers Blue. Modifier le label version vers green effectue le switch instantané sans recréer le service.

Script de basculement

switch.sh
#!/bin/bash
set -e
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"green"}}}'
echo "Trafic basculé vers Green"
kubectl rollout status deployment/app-green --timeout=60s

Ce script modifie le sélecteur du service pour router vers Green. Le rollout status vérifie que tous les pods sont prêts avant de confirmer le succès.

Script de rollback

rollback.sh
#!/bin/bash
set -e
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"blue"}}}'
echo "Rollback effectué vers Blue"
kubectl rollout undo deployment/app-green

En cas d'anomalie, ce script rétablit instantanément Blue et annule le déploiement Green pour minimiser l'impact.

Bonnes pratiques

  • Toujours maintenir Blue stable pendant la mise à jour de Green
  • Implémenter des health checks exhaustifs
  • Automatiser le rollback via des hooks CI/CD
  • Surveiller les métriques pendant 15 minutes après switch
  • Utiliser des namespaces distincts pour isoler les environnements

Erreurs courantes à éviter

  • Oublier de mettre à jour les probes avant le switch
  • Ne pas tester Green en isolation complète
  • Ignorer la gestion des sessions persistantes
  • Basculer sans validation automatique des métriques

Pour aller plus loin

Approfondissez ces techniques avec nos formations avancées sur Kubernetes et les stratégies de déploiement zéro-downtime : https://learni-group.com/formations