31 Canary-Deployment-Strategie in Kubernetes

Bei einem Canary-Deployment wird eine neue Version der Anwendung zu einem kleinen Prozentsatz der Benutzer veröffentlicht und schrittweise die Stabilität und Funktionalität im Live-Betrieb überwacht. Wenn keine Probleme auftreten, wird die neue Version allmählich auf alle Benutzer ausgerollt.

In diesem Diagramm:

• Der Load Balancer (LB) verteilt die Benutzeranfragen auf die Produktionspods (Prod) und die Canary-Pods.
• Die meisten Anfragen (80%) gehen an die vorhandene Produktionsversion (Prod V1).
• Ein kleinerer Teil der Anfragen (20%) wird an die Canary-Pods (Canary V2) gerichtet.
• Sowohl die Produktions- als auch die Canary-Pods senden Metriken an das Monitoring System.
• Der Admin überwacht die Metriken. Bei Erfolg initiiert der Admin das vollständige Rollout, bei Fehlern das Rollback.
• Nach erfolgreichem Canary-Test wird der gesamte Verkehr auf die Canary-Version (V2) umgeleitet.
• Bei einem Fehlschlag wird der Verkehr wieder zu 100% auf die Produktionsversion (V1) zurückgeleitet.

31.1 Vorgehensweise

1. Bereitstellung der Canary-Version: Ein neues Deployment für die Canary-Version wird erstellt und neben dem bestehenden Production-Deployment betrieben.
2. Verkehrsmanagement: Ein kleiner Prozentsatz des Verkehrs wird auf die Canary-Version umgeleitet, während der Großteil noch zur aktuellen Version fließt.
3. Überwachung und Bewertung: Die Canary-Version wird kontinuierlich überwacht. Fehler oder Leistungsprobleme führen zu einem sofortigen Rollback.
4. Ausrollen oder Rollback: Bei Erfolg wird der restliche Verkehr schrittweise auf die neue Version übergeleitet. Bei Problemen wird auf die alte Version zurückgekehrt.

31.1.1 Beispiel

Das folgende Beispiel zeigt, wie ein Canary-Deployment in einer Kubernetes-Umgebung umgesetzt werden könnte:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-canary
spec:
  replicas: 1 # Eine kleine Anzahl von Pods für das Canary-Release
  selector:
    matchLabels:
      app: example-app
      track: canary
  template:
    metadata:
      labels:
        app: example-app
        track: canary
    spec:
      containers:
      - name: example-app
        image: example-app:v2 # Die neue Version der Anwendung
---
apiVersion: v1
kind: Service
metadata:
  name: example-app-service
spec:
  selector:
    app: example-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

In diesem Beispiel:

• Es gibt ein neues Deployment app-canary, das die neue Version der Anwendung (v2) mit einer geringen Anzahl von Replikaten ausführt.
• Ein vorhandener Service example-app-service wird verwendet, um den Verkehr zu verwalten. Er wählt Pods aus, die mit app: example-app markiert sind, was sowohl die ursprünglichen als auch die Canary-Pods einschließt.
• Der Netzwerkverkehr wird durch eine separate Routing-Logik (nicht im YAML-Beispiel gezeigt) gesteuert, die bestimmt, welcher Prozentsatz des Traffics an die Canary-Pods gesendet wird.

31.2 Bewertung

• Reduziertes Risiko: Fehler in der neuen Version betreffen nur einen kleinen Teil der Benutzer.
• Frühzeitiges Feedback: Probleme werden erkannt, bevor die gesamte Benutzerbasis betroffen ist.
• Einfaches Rollback: Bei Problemen kann die Canary-Version einfach entfernt werden, ohne die Hauptanwendung zu beeinträchtigen.

Canary-Releases erfordern eine fortgeschrittene Infrastruktur für Verkehrssteuerung und Monitoring, um effektiv zu sein.