Blue-Green Deployment sur Kubernetes : zéro interruption en production

Le blue-green deployment Kubernetes garantit un déploiement sans interruption Kubernetes en maintenant deux environnements de production identiques. Pour tout ingénieur infrastructure Kubernetes certification CKAD, cette stratégie représente la méthode la plus sûre pour basculer instantanément vers une nouvelle version. Avec 82% des utilisateurs de containers en production sur Kubernetes, maîtriser le blue-green devient indispensable.

TL;DR : Le blue-green maintient deux environnements complets (blue = actuel, green = nouveau). Le switch s'effectue en modifiant le Service selector. Rollback instantané en cas de problème.

Cette compétence est au cœur de la formation LFS458 Administration Kubernetes.

Qu'est-ce que le blue-green deployment pour l'ingénieur infrastructure Kubernetes certification CKAD ?

Le blue-green deployment est une stratégie de déploiement qui utilise deux environnements de production identiques appelés "blue" et "green". À tout moment, un seul environnement reçoit le trafic de production tandis que l'autre sert de staging pour la nouvelle version.

Cette technique offre :

• Zéro downtime : le switch est instantané
• Rollback immédiat : retour à l'ancienne version en une commande
• Validation complète : test de la nouvelle version avant exposition au trafic réel

À retenir : Le blue-green deployment double les ressources nécessaires mais élimine tout risque de downtime.

Le guide Déploiement et mise en production Kubernetes couvre les fondamentaux à maîtriser avant d'implémenter cette stratégie.

Comment fonctionne le blue-green deployment Kubernetes ?

Architecture de base

┌─────────────────────────────────────────────────┐
│                    Service                       │
│              selector: version=blue              │
└──────────────────────┬──────────────────────────┘
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
┌─────────────────┐         ┌─────────────────┐
│   Deployment    │         │   Deployment    │
│     BLUE        │         │     GREEN       │
│   version=blue  │         │  version=green  │
│    (actif)      │         │   (standby)     │
└─────────────────┘         └─────────────────┘

Phase 1 : Déploiement initial (Blue)

# deployment-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: blue
  template:
    metadata:
      labels:
        app: myapp
        version: blue
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Service pointant vers Blue

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

Phase 2 : Déploiement du Green

Déployez la nouvelle version sans impacter le trafic :

# deployment-green.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      containers:
      - name: myapp
        image: myapp:2.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

À retenir : Le déploiement green est complètement isolé du trafic de production.

Comment l'ingénieur infrastructure formation LFS458 Administration Kubernetes valide le green avant le switch ?

Service de test interne

Créez un Service dédié pour tester le green :

# service-green-test.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-green-test
spec:
  selector:
    app: myapp
    version: green
  ports:
  - port: 80
    targetPort: 8080

Tests automatisés

#!/bin/bash
GREEN_SERVICE="myapp-green-test"

echo "=== Validation Green Environment ==="

# Health check
curl -f http://${GREEN_SERVICE}/health || exit 1

# Smoke tests
curl -f http://${GREEN_SERVICE}/api/v1/status || exit 1

# Performance baseline
ab -n 1000 -c 10 http://${GREEN_SERVICE}/ > perf-results.txt

# Comparaison avec blue
if [ $(grep "Requests per second" perf-results.txt | awk '{print $4}') -lt 100 ]; then
  echo "Performance degradation detected"
  exit 1
fi

echo "Green validation passed"

Vérification des pods

# Tous les pods green doivent être Ready
kubectl get pods -l app=myapp,version=green

# Aucun restart récent
kubectl get pods -l app=myapp,version=green -o jsonpath='{.items[*].status.containerStatuses[*].restartCount}'

Le guide Autoscaling Kubernetes détaille comment configurer le scaling avant le switch.

Comment effectuer le switch blue vers green ?

Méthode kubectl patch

# Switch vers green
kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'

# Vérification
kubectl get service myapp -o jsonpath='{.spec.selector.version}'
# Output: green

Script de switch sécurisé

#!/bin/bash
set -e

SERVICE="myapp"
NEW_VERSION="green"
OLD_VERSION="blue"

echo "Switching from ${OLD_VERSION} to ${NEW_VERSION}..."

# Vérifier que green est prêt
READY_PODS=$(kubectl get pods -l app=myapp,version=${NEW_VERSION} -o jsonpath='{.items[*].status.conditions[?(@.type=="Ready")].status}' | tr ' ' '\n' | grep -c True)
TOTAL_PODS=$(kubectl get pods -l app=myapp,version=${NEW_VERSION} --no-headers | wc -l)

if [ "$READY_PODS" -ne "$TOTAL_PODS" ]; then
  echo "Error: Not all green pods are ready (${READY_PODS}/${TOTAL_PODS})"
  exit 1
fi

# Effectuer le switch
kubectl patch service ${SERVICE} -p "{\"spec\":{\"selector\":{\"version\":\"${NEW_VERSION}\"}}}"

# Vérifier le switch
sleep 2
CURRENT=$(kubectl get service ${SERVICE} -o jsonpath='{.spec.selector.version}')

if [ "$CURRENT" = "$NEW_VERSION" ]; then
  echo "Switch successful: now routing to ${NEW_VERSION}"
else
  echo "Switch failed: still routing to ${CURRENT}"
  exit 1
fi

Validation post-switch

# Vérifier que le trafic atteint green
for i in {1..10}; do
  curl -s http://myapp/version
  sleep 1
done

# Vérifier les métriques
kubectl top pods -l app=myapp,version=green

À retenir : Le switch modifie uniquement le selector du Service. Aucun pod n'est recréé.

Comment effectuer un rollback instantané ?

Rollback en une commande

# Retour vers blue
kubectl patch service myapp -p '{"spec":{"selector":{"version":"blue"}}}'

Script de rollback automatisé

#!/bin/bash
SERVICE="myapp"

# Déterminer la version actuelle
CURRENT=$(kubectl get service ${SERVICE} -o jsonpath='{.spec.selector.version}')

if [ "$CURRENT" = "green" ]; then
  ROLLBACK_TO="blue"
else
  ROLLBACK_TO="green"
fi

echo "Rolling back from ${CURRENT} to ${ROLLBACK_TO}..."

kubectl patch service ${SERVICE} -p "{\"spec\":{\"selector\":{\"version\":\"${ROLLBACK_TO}\"}}}"

echo "Rollback complete"

Conditions de rollback automatique

Intégrez un monitoring qui déclenche le rollback :

# prometheus-rule.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: blue-green-rollback
spec:
  groups:
  - name: deployment
    rules:
    - alert: HighErrorRateAfterSwitch
      expr: |
        sum(rate(http_requests_total{status=~"5.*",version="green"}[5m])) 
        / 
        sum(rate(http_requests_total{version="green"}[5m])) > 0.05
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "Error rate > 5% on green deployment"

Le guide Problèmes de scaling Kubernetes aide à diagnostiquer les problèmes post-switch.

Comparaison blue-green vs autres stratégies

Consultez le comparatif Rolling Update Kubernetes pour une analyse détaillée.

Automatiser le blue-green avec Argo Rollouts

Installation

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

Configuration Rollout

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    blueGreen:
      activeService: myapp-active
      previewService: myapp-preview
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 30
      prePromotionAnalysis:
        templates:
        - templateName: success-rate
        args:
        - name: service-name
          value: myapp-preview
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0.0
        ports:
        - containerPort: 8080

Services associés

# Service actif (production)
apiVersion: v1
kind: Service
metadata:
  name: myapp-active
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
---
# Service preview (test)
apiVersion: v1
kind: Service
metadata:
  name: myapp-preview
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080

Promotion manuelle

# Voir le statut
kubectl argo rollouts get rollout myapp

# Promouvoir le green
kubectl argo rollouts promote myapp

# Aborter et rollback
kubectl argo rollouts abort myapp

À retenir : Argo Rollouts gère automatiquement les deux deployments et le switch de Service.

Le guide Pipeline CI/CD pour Kubernetes montre l'intégration d'Argo Rollouts.

Bonnes pratiques pour le déploiement sans interruption Kubernetes

1. Base de données et migrations

Le blue-green nécessite une compatibilité base de données entre versions :

Version N (blue) ─────┐
                      ├──► Database (compatible N et N+1)
Version N+1 (green) ──┘

Stratégie recommandée :

1. Migration de schéma rétrocompatible
2. Déploiement green avec nouveau code
3. Switch vers green
4. Nettoyage des anciennes colonnes/tables

2. Sessions utilisateur

Externalisez les sessions :

# Redis pour les sessions
env:
- name: SESSION_STORE
  value: redis://redis-cluster:6379

3. Feature flags

Combinez blue-green et feature flags pour un contrôle maximal :

env:
- name: FEATURE_NEW_CHECKOUT
  value: "false"  # Activé après validation

4. Monitoring différencié

Labelisez les métriques par version :

metadata:
  labels:
    app: myapp
    version: green
    deployment-type: blue-green

Selon le rapport CNCF 2025, 104 000 personnes ont passé l'examen CKA avec une croissance de 49% par an. Le blue-green deployment fait partie des compétences attendues.

Quand utiliser le blue-green deployment ?

Cas d'usage idéaux

• Applications stateless : APIs, microservices sans état
• Changements majeurs : refactoring, migration de framework
• Exigences SLA strictes : zéro downtime contractuel
• Validation complète requise : tests end-to-end avant production

Cas à éviter

• Ressources limitées : le doublement des ressources est prohibitif
• Workloads stateful complexes : bases de données, systèmes de fichiers
• Déploiements fréquents : le coût de maintenance devient élevé

Les Tutoriels et guides pratiques Kubernetes proposent des exercices sur chaque stratégie.

Gestion des coûts du blue-green

Scaling asymétrique

Réduisez les coûts en standby :

# Green à 1 replica pendant les tests
kubectl scale deployment myapp-green --replicas=1

# Scale up avant le switch
kubectl scale deployment myapp-green --replicas=3

# Scale down blue après validation
kubectl scale deployment myapp-blue --replicas=0

Cleanup automatisé

# Supprimer l'ancien deployment après 24h de stabilité
kubectl delete deployment myapp-blue

Le guide Déployer avec Helm Charts montre comment packager cette logique.

Formez-vous au déploiement sans interruption Kubernetes

L'examen CKAD teste ces compétences avec un taux de réussite de 66% sur 2 heures. La formation LFD459 Kubernetes pour les développeurs de 3 jours vous y prépare. Pour une approche plus opérationnelle, la formation LFS458 Administration Kubernetes de 4 jours couvre les stratégies de déploiement avancées.

Consultez les prochaines sessions et lancez votre parcours de certification.