Training Module

Kubernetes Progressive Delivery — Canary & Blue-Green mit Argo Rollouts

In diesem 115-Minuten-Modul löst ihr ein Problem, das ein reines Rolling Update strukturell nicht lösen kann: alle Pods werden nacheinander ersetzt, ohne dass irgendjemand oder irgendetwas dazwischen automatisiert prüft, ob die neue Version tatsächlich funktioniert – ein fehlerhaftes Image erreicht am Ende trotzdem 100 % der Nutzer:innen, nur etwas langsamer als bei einem harten Ersetzen auf einen Schlag. Argo Rollouts setzt genau hier an: Die Rollout-Custom-Resource ersetzt euer bisheriges Deployment und steuert stable- und canary-ReplicaSet über explizite Steps – mit einem automatisierten Promotion-Gate über AnalysisTemplate/AnalysisRun, das einen Rollout selbst abbricht, bevor ein Fehler die volle Nutzerzahl erreicht. Im ersten Hands-on installiert ihr Argo Rollouts und das kubectl argo rollouts-Plugin in eurem Minikube-Cluster und migriert das GitOps-verwaltete Deployment aus dem ArgoCD-Kurs zu einem Rollout mit manuellen Canary-Steps – weiterhin über denselben Git-Repo/ArgoCD-Application-Workflow, den ihr dort gelernt habt. Im zweiten Hands-on ersetzt ihr die manuelle Freigabe durch ein automatisiertes, Job-basiertes Analysis-Gate und seht live, wie eine fehlschlagende Analyse den Rollout automatisch abbricht, ohne dass jemand manuell eingreift. Im dritten Hands-on stellt ihr auf eine Blue-Green-Strategie um: eine komplette zweite Version läuft parallel unter einem Preview-Service, und ihr entscheidet per kubectl argo rollouts promote bzw. abort bewusst selbst, wann der Live-Traffic umschaltet. Ein kurzer Ausblick ohne eigenes Hands-on rundet ab: Prometheus/Datadog/Web als Metric-Provider für die Analyse, Traffic-Shaping über ein Service Mesh, die Experiment-CRD und Notifications. Ausdrücklich NICHT Teil dieses Kurses: die Installation eines Service Mesh, Multi-Cluster- Rollouts und CI/Image-Build. Pflicht ist das Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” – dieses Modul setzt dessen Git-Repo/ArgoCD-Application-Workflow direkt fort, statt ihn zu wiederholen. Die Session läuft komplett lokal über Minikube ( –driver=docker) – Argo Rollouts selbst läuft rein containerisiert im Cluster, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

115 Minuten, live (remote oder vor Ort), Input & drei Hands-on-Übungen

Teilnehmende

Entwickler:innen und Ops, die Deployments schrittweise und mit automatisiertem Abbruchkriterium statt alles-oder-nichts ausrollen wollen

Voraussetzungen

Abgeschlossenes Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” (Pflicht), lauffähige lokale Docker-Umgebung für Minikube, eigenes schreibbares Git-Repo aus diesem Vorgängerkurs

Warum dieses Training für deine Organisation wirkt

Ein Rolling Update prüft nichts, es ersetzt nur

Ein Standard-Deployment tauscht Pods schrittweise aus, ohne ein einziges Erfolgskriterium dazwischen zu prüfen. Ein fehlerhaftes Image erreicht am Ende trotzdem 100 % – nur langsamer als bei einem harten Ersetzen.

Ein Fehler stoppt sich selbst, bevor er skaliert

Ein AnalysisTemplate prüft nach jedem Canary-Step automatisiert ein Erfolgskriterium. Schlägt die Analyse fehl, bricht Argo Rollouts den Rollout selbst ab – niemand muss um 3 Uhr nachts manuell eingreifen, damit ein Fehler nicht die volle Nutzerzahl erreicht.

Blue-Green macht den Umschalt-Moment explizit

Zwei vollständige Versionen laufen parallel, Live-Traffic bleibt auf der alten, bis ein bewusstes kubectl argo rollouts promote umschaltet – und ein ebenso bewusstes abort sofort zurück.

Was Teilnehmende mitnehmen

  • Die strukturelle Grenze eines reinen Rolling Update benennen: kein automatisiertes Abbruchkriterium, nur eine zeitversetzte Vollständig-Ersetzung.
  • Die Rollout-Custom-Resource als Ersatz für Deployment lesen und einordnen, inklusive stable- und canary-ReplicaSet-Steuerung über explizite Steps.
  • Argo Rollouts und das kubectl argo rollouts-Plugin in einem lokalen Minikube-Cluster installieren und ein bestehendes GitOps-verwaltetes Deployment zu einem Rollout mit manuellen Canary-Steps migrieren.
  • Ein automatisiertes, Job-basiertes AnalysisTemplate/AnalysisRun-Gate in einen Canary-Rollout einbauen und live erleben, wie eine fehlschlagende Analyse den Rollout automatisch abbricht.
  • Eine Blue-Green-Strategie mit Preview-/Active-Service aufsetzen und den Live-Umschalt-Moment per manuellem promote bzw. abort steuern.
  • Begründen, warum kubectl argo rollouts promote ein GitOps-Self-Healing nicht auslöst, obwohl kubectl scale im Vorgängerkurs genau das ausgelöst hat – und was diesen Unterschied technisch trägt.
  • Prometheus/Datadog/Web als weitere Metric-Provider, Traffic-Shaping über ein Service Mesh, die Experiment-CRD und Notifications konzeptionell einordnen – bewusst ohne eigenes Hands-on zu diesen Punkten.
  • Benennen, was dieses Modul bewusst nicht behandelt: Service-Mesh-Installation, Multi-Cluster-Rollouts und CI/Image-Build.

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” oder gleichwertigen Vorkenntnissen
  • • Teams, deren heutiges Rolling Update schon einmal ein fehlerhaftes Image bis zur vollen Nutzerzahl durchgereicht hat, bevor es jemand bemerkt hat
  • • Alle, die vor der ersten produktiven Canary- oder Blue-Green-Einführung wissen wollen, wie ein automatisiertes Abbruchkriterium technisch funktioniert – nicht nur als Foliensatz

Rahmendaten

  • • Dauer: 115 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, drei Hands-on-Übungen (Installation & manueller Canary, automatisiertes Analysis-Gate, Blue-Green mit manuellem Promote/Rollback)
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes GitOps — Deklaratives Deployment mit ArgoCD” (Pflicht), lauffähige lokale Docker-Umgebung für Minikube, eigenes schreibbares Git-Repo aus diesem Vorgängerkurs, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Warum Progressive Delivery? (15 min): die strukturelle Grenze eines reinen Rolling Update, kein automatisiertes Abbruchkriterium, Abgrenzung zu Canary/Blue-Green als Antwort darauf.

  2. Argo-Rollouts-Architektur (15 min): die Rollout-Custom-Resource als Ersatz für Deployment, stable-/canary-ReplicaSet-Steuerung über Steps, AnalysisTemplate/AnalysisRun als Promotion-Gate.

  3. Hands-on 1: Installation & manueller Canary (30 min, Hands-on): Argo Rollouts und das kubectl argo rollouts-Plugin installieren, das GitOps-verwaltete Deployment aus dem ArgoCD-Kurs zu einem Rollout mit manuellen Canary-Steps migrieren.

  4. Hands-on 2: Canary mit automatisiertem Analysis-Gate (25 min, Hands-on): ein Job-basiertes AnalysisTemplate einbauen, erfolgreichen und bewusst fehlschlagenden Rollout live gegenüberstellen.

  5. Hands-on 3: Blue-Green mit manuellem Promote & Rollback (20 min, Hands-on): Preview-/Active-Service aufsetzen, Live-Umschalt-Moment per promote bzw. abort steuern.

  6. Ausblick ohne Hands-on & Abschluss (10 min): Prometheus/Datadog/Web als Metric-Provider, Traffic-Shaping über ein Service Mesh, Experiment-CRD, Notifications.

Dieses Modul setzt das Aufbaumodul Kubernetes GitOps — Deklaratives Deployment mit ArgoCD zwingend voraus. Die Application-CRD, Sync-Status gegen Health-Status und der Git-Repo/ArgoCD-Application-Workflow aus diesem Kurs gelten als bekannt und werden hier nicht neu erklärt – Hands-on 1 setzt direkt auf dem dort aufgebauten Git-Repo auf, statt bei null zu beginnen.

Was dieses Modul bewusst nicht behandelt: die Installation und Konfiguration eines Service Mesh (Istio) für echtes Traffic-Shaping auf Layer 7 – dieses Modul steuert Traffic ausschließlich über Kubernetes-Service- Selektoren und ReplicaSet-Gewichtung, wie es Argo Rollouts auch ohne Service Mesh beherrscht. Wer die pod-basierte setWeight-Steuerung dieses Moduls gegen exaktes, pod-zahl-unabhängiges Traffic-Splitting auf Layer 7 abgrenzen will, findet das im eigenständigen Aufbaumodul Kubernetes Service Mesh — Traffic-Management mit Istio. Ebenfalls nicht Thema: Multi-Cluster-Rollouts als eigenständige Vertiefung, und der Build eines Container-Images oder eine CI-Pipeline davor – das leistet das Vertiefungsmodul CI: Continuous Integration & der Build-Prozess, hier wird ein bereits vorhandenes Image vorausgesetzt.

Hands-on Inhalte (Auszug)

Argo Rollouts installieren

  • Namespace argo-rollouts anlegen, das offizielle Install-Manifest anwenden, das kubectl argo rollouts-Plugin lokal einrichten
  • Das bestehende Deployment aus dem GitOps-Kurs im selben Git-Repo durch ein Rollout mit Canary-Steps ersetzen, per ArgoCD synct

Manueller Canary

  • Neues Image-Tag committen, Rollout-Fortschritt live per kubectl argo rollouts get rollout –watch beobachten
  • Jeden Canary-Step manuell per kubectl argo rollouts promote freigeben, stable-/canary-ReplicaSet-Anteile live vergleichen

Automatisiertes Analysis-Gate

  • Ein AnalysisTemplate mit Job-Metric-Provider als Smoke-Test in die Canary-Steps einbauen
  • Erfolgreichen Rollout (automatische Promotion) und bewusst fehlschlagenden Rollout (automatischer Abbruch) live gegenüberstellen

Blue-Green

  • Rollout-Strategie auf blueGreen mit activeService/previewService umstellen
  • Neue Version gegen den Preview-Service testen, per promote auf Live umschalten, per abort zurückrollen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit von der ersten Canary-Step-Freigabe bis zum vollständig promoteten Rollout) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen