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)
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.