Was sind Canary-Deployments?

Canaride Deployment ist eine Strategie für die Einführung neuer Funktionen, bei der das Update schrittweise an einen kleinen Teil der Nutzer ausgerollt wird und, bei keinen Problemen, auf die gesamte Zielgruppe ausgeweitet wird.

Hauptphasen:

1. Deployment der Canary-Gruppe: Die neue Version der Anwendung wird auf eine kleine Untergruppe von Servern oder Nutzern ausgerollt.
2. Überwachung: Es erfolgt eine sorgfältige Überwachung der Metriken (Fehler, Leistung, Nutzerverhalten) für die Canary-Gruppe.
3. Ausweitung oder Rollback:
   • Wenn die Überwachung Erfolg zeigt, wird das Deployment schrittweise auf eine größere Nutzergruppe ausgeweitet.
   • Bei Problemen wird das Deployment für die Canary-Gruppe zurückgesetzt, um die Mehrheit der Nutzer zu schützen.

Vorteile:

• Risiken minimieren: Probleme betreffen nur eine kleine Nutzergruppe.
• Schneller Rollback: Leicht auf die vorherige Version zurückzusetzen.
• Testen unter realen Bedingungen: Bewertung des Verhaltens der neuen Funktion unter realer Last.

Nachteile:

• Komplexität der Infrastruktur: Es ist Unterstützung für mehrere Versionen der Anwendung gleichzeitig erforderlich.
• Traffic-Management: Mechanismen zur Steuerung des Traffics zu verschiedenen Versionen sind notwendig.
• Datenanalyse: Effektives Sammeln und Analysieren von Metriken ist erforderlich.

Beispiel für die Implementierung in Kubernetes:

// Deployment für v1
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v1
spec:
  replicas: 10 // Hauptanzahl
  selector:
    matchLabels:
      app: my-app
      version: v1
  template:
    metadata:
      labels:
        app: my-app
        version: v1
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v1

---

// Deployment für Canary v2
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v2-canary
spec:
  replicas: 1 // Canary-Gruppe
  selector:
    matchLabels:
      app: my-app
      version: v2
  template:
    metadata:
      labels:
        app: my-app
        version: v2
    spec:
      containers:
      - name: my-app
        image: my-registry/my-app:v2

---

// Service zur Traffic-Weiterleitung (mit Selektoren)
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Zur Steuerung der Traffic-Verteilung zwischen v1 und v2 werden Ingress-Controller (z.B. Nginx Ingress, Istio) mit der Möglichkeit der gewichteten Traffic-Verteilung eingesetzt.