30 Blue-Green-Deployment-Strategie in Kubernetes

Die Blue-Green-Deployment-Strategie ist eine Methode, bei der die neue Version einer Anwendung (Green) parallel zur aktuellen Version (Blue) bereitgestellt wird. Sobald die neue Version vollständig getestet und bereit zum Einsatz ist, wird der Netzwerkverkehr von der alten auf die neue Version umgeleitet.

In diesem Diagramm:

• Der Load Balancer (LB) leitet Benutzeranfragen an die Blue Pods weiter.
• Die Blue Umgebung ist die aktuell aktive Version, die Live-Traffic bearbeitet.
• Die Green Umgebung ist die neue Version, die noch kein Live-Traffic erhält und auf die Übernahme vorbereitet wird.
• Der Admin bereitet die Green-Umgebung vor und führt Tests durch (Test Service).
• Nach erfolgreichen Tests schaltet der Admin den Load Balancer um, um den Traffic auf die Green-Umgebung zu leiten.
• Die Blue Pods hören auf, Live-Traffic zu empfangen und bleiben als Backup bestehen.

Die grünen gestrichelten Linien symbolisieren die Bereitschaft der Green Pods, den Traffic zu übernehmen, sobald das Umschalten durch den Administrator durchgeführt wird.

30.1 Vorgehensweise

Bei einem Blue-Green-Deployment:

1. Bereitstellung beider Umgebungen: Zwei identische Produktionsumgebungen werden erstellt, wobei eine die “Blue” (aktive) und die andere die “Green” (neue) Version repräsentiert.
2. Testen der Green-Umgebung: Die Green-Umgebung wird intensiv getestet, ohne die laufende Blue-Umgebung zu beeinträchtigen.
3. Umschalten des Traffics: Nach erfolgreicher Validierung und Tests wird der Verkehr nahtlos von Blue auf Green umgeleitet.
4. Blue-Umgebung im Standby: Die alte Version bleibt im Standby als Backup, falls ein Rollback erforderlich ist.

30.1.1 Beispiel

Das folgende Beispiel zeigt, wie man eine Blue-Green-Deployment-Strategie in einer Kubernetes-Umgebung umsetzen kann:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example-app
    version: blue # Startzustand auf Blue
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
      version: blue
  template:
    metadata:
      labels:
        app: example-app
        version: blue
    spec:
      containers:
      - name: example-app
        image: example-app:v1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
      version: green
  template:
    metadata:
      labels:
        app: example-app
        version: green
    spec:
      containers:
      - name: example-app
        image: example-app:v2

In diesem Beispiel:

• Die Service-Konfiguration leitet den Verkehr an Pods weiter, die mit version: blue markiert sind.
• Es gibt zwei Deployments: eines für die Blue-Version (example-app:v1) und eines für die Green-Version (example-app:v2).
• Um auf Green umzuschalten, ändert man den Selector im Service auf version: green.

30.2 Bewertung

Die Blue-Green-Strategie bietet mehrere Vorteile:

• Minimale Ausfallzeit: Das Umschalten des Traffics von Blue zu Green erfolgt fast augenblicklich.
• Einfaches Rollback: Bei Problemen kann der Traffic einfach zur Blue-Version zurückgeleitet werden.
• Risikominimierung: Die neue Version kann ausgiebig in einer Produktionsähnlichen Umgebung getestet werden, ohne die laufende Anwendung zu beeinflussen.

Blue-Green-Deployments erfordern eine sorgfältige Planung und Ressourcenmanagement, da effektiv zwei Produktionsumgebungen parallel betrieben werden müssen.