Deployment-Strategien: Blue-Green und Canary
Gehen Sie über Rolling Updates hinaus und lernen Sie, mit Blue-Green- und Canary-Deployment-Patterns in Kubernetes sicher zu veröffentlichen.
Deployment-Strategien: Blue-Green und Canary ist eine kostenlose Kubernetes Basics-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Kubernetes Basics-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Kubernetes Basics-Kurs umfasst insgesamt 4 Lektionen.
Warum mehr als Rolling Updates
Rolling Updates ersetzen Pods schrittweise, vermischen während des Übergangs jedoch alte und neue Versionen. Bei riskanten Releases möchten Sie möglicherweise vollständig kontrollieren, welche Benutzer die neue Version sehen.
Blue-Green- und Canary-Strategien geben Ihnen diese Kontrolle.
Das Blue-Green-Konzept
Bei einem Blue-Green-Deployment betreiben Sie zwei identische Umgebungen:
- Blue = aktuell aktive Version
- Green = neue Version, vollständig bereitgestellt, aber noch ohne eingehenden Datenverkehr
Sie schalten den Datenverkehr vollständig auf einmal von Blue auf Green um.
Zwei Deployments, ein Service
Jede Version ist ein eigenes Deployment mit einem Versionslabel. Ein einzelner Service wählt die jeweils aktive Farbe aus.
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
spec:
replicas: 3
selector:
matchLabels:
app: web
version: blue
template:
metadata:
labels:
app: web
version: blue
spec:
containers:
- name: web
image: myapp:1.0Datenverkehr umschalten
Um Green zu aktivieren, passen Sie einfach den Service-Selektor so an, dass er auf die Green-Version verweist. Die Umschaltung erfolgt sofort.
kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"green"}}}'Vor- und Nachteile von Blue-Green
- Vorteil: sofortiges Zurücksetzen durch Umschalten auf Blue
- Vorteil: keine Vermischung von Versionen während des Releases
- Nachteil: während der Überschneidung werden doppelt so viele Ressourcen benötigt
Das Canary-Konzept
Bei einem Canary-Release wird zunächst ein kleiner Teil des Datenverkehrs an die neue Version gesendet. Wenn die Metriken unauffällig sind, wird ihr Anteil schrittweise erhöht.
Der Name geht auf Kanarienvögel zurück, die Bergleute zur frühzeitigen Erkennung von Gefahren einsetzten.
Canary mit Replikazahlen
Ein einfacher Canary verwendet zwei Deployments mit demselben Service-Label. Der Datenverkehr wird ungefähr im Verhältnis der Replikazahlen aufgeteilt.
# stable: 9 replicas, canary: 1 replica => ~10% to canary
kubectl scale deployment app-stable --replicas=9
kubectl scale deployment app-canary --replicas=1Einen Canary ausweiten
Mit wachsendem Vertrauen verschieben Sie das Verhältnis zugunsten des Canarys und nehmen die alte Version außer Betrieb, sobald sie den gesamten Datenverkehr bedient.
kubectl scale deployment app-canary --replicas=5
kubectl scale deployment app-stable --replicas=5
# later, fully promote
kubectl scale deployment app-canary --replicas=10
kubectl scale deployment app-stable --replicas=0Den Canary beobachten
Der eigentliche Zweck eines Canarys ist die Beobachtung. Überwachen Sie Fehlerquoten, Latenz und Logs, bevor Sie ihn ausweiten.
kubectl get pods -l version=canary
kubectl logs -l version=canary --tail=50Eine Strategie auswählen
- Blue-Green: am besten für eine saubere, sofortige Umschaltung und schnelles Zurücksetzen
- Canary: am besten, wenn Sie den Wirkungsradius begrenzen und mit echtem Datenverkehr validieren möchten
- Rolling: eine gute Standardwahl für risikoarme, routinemäßige Updates
Werkzeuge über kubectl hinaus
Für eine detaillierte Aufteilung des Datenverkehrs (z. B. genau 5 %) verwenden Teams Service-Meshes wie Istio oder Tools für progressive Auslieferung wie Argo Rollouts und Flagger, die Canary-Analysen automatisieren.
Kurzer Test
Wählen Sie die Aussage aus, die ein Canary-Release am besten beschreibt.
Zusammenfassung
Sie haben fortgeschrittene Release-Strategien verglichen. Blue-Green schaltet den gesamten Datenverkehr sofort zwischen zwei Umgebungen um und ermöglicht so ein schnelles Zurücksetzen, während Canary den Datenverkehr schrittweise verlagert, um das Risiko zu begrenzen. Beide Strategien bauen auf den Deployment- und Service-Grundbausteinen auf, die Sie bereits kennen.
Häufig gestellte Fragen
Ist die Lektion „Deployment-Strategien: Blue-Green und Canary“ kostenlos?
Ja — der vollständige Text von „Deployment-Strategien: Blue-Green und Canary“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Kubernetes Basics-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Kubernetes Basics-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Deployment-Strategien: Blue-Green und Canary“?
Gehen Sie über Rolling Updates hinaus und lernen Sie, mit Blue-Green- und Canary-Deployment-Patterns in Kubernetes sicher zu veröffentlichen. Du übst Kubernetes Basics mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Kubernetes Basics zu starten?
Keine Vorkenntnisse erforderlich. Kubernetes Basics auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Deployment-Strategien: Blue-Green und Canary“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Kubernetes Basics-Lektion Code schreiben und ausführen?
Ja. Jede Kubernetes Basics-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Deployments verstehen
- Anwendungen mit ReplicaSets skalieren
- Rolling Updates und Rollbacks
- Deployment-Strategien: Blue-Green und Canary