Von Code Sentinel, Technical Project Manager bei Java Fleet Systems Consulting
Schwierigkeit: 🟡 Mittel
Lesezeit: 30 Minuten
Voraussetzungen: Blue-Green Deployments (Teil 8), Docker Basics, Kubernetes Grundkenntnisse hilfreich
📚 Was bisher geschah – Enterprise CI/CD Mastery
Bereits veröffentlicht:
- ✅ Teil 1-4: Foundations – Pipeline, Security Gates, Coverage, Quality
- ✅ Teil 5-6: Container – Multi-Stage Builds, Security & SBOM
- ✅ Teil 7: Registry Integration – Image-Management richtig
- ✅ Teil 8 : Blue-Green Deployments – Zero Downtime Basics
Heute: Teil 9 – Canary Deployments & Kubernetes
Neu in der Serie? Kein Problem!
- 🟢 Einsteiger? Teil 8 (Blue-Green) ist Voraussetzung – dort lernst du die Basics
- 🟡 Erfahren? Du kannst hier einsteigen, wir bauen auf Blue-Green auf
⚡ Das Wichtigste in 30 Sekunden
Dein Problem: Blue-Green ist great, aber du willst die neue Version erst mit 5% der User testen, bevor alle sie bekommen.
Die Lösung: Canary Deployment – schrittweise Traffic-Verlagerung mit echtem User-Feedback.
Heute lernst du:
- ✅ Was Canary Deployments sind und warum sie mächtiger als Blue-Green sind
- ✅ Traffic-Splitting mit nginx und Kubernetes
- ✅ Automatisches Rollback basierend auf Metriken
- ✅ Production-Ready Canary Setup mit Argo Rollouts
Für wen ist dieser Artikel?
- 🌱 Anfänger: Du lernst das Konzept und einfache Implementierung
- 🌿 Erfahrene: Kubernetes-native Canary mit Metriken
- 🌳 Profis: GitOps mit Argo Rollouts und automatische Analysis
Zeit-Investment: 30 Minuten Lesen + 1-2 Stunden Hands-on
👋 Code Sentinel: „Der Kanarienvogel im Bergwerk…“
Hey! 👋
Code Sentinel hier.
Weißt du, woher der Name „Canary Deployment“ kommt? Früher nahmen Bergarbeiter Kanarienvögel mit in die Mine. Wenn der Vogel aufhörte zu singen, war Gas in der Luft – Zeit zu fliehen.
Bei Canary Deployments ist deine neue Version der Kanarienvogel. Du gibst ihr ein bisschen Traffic und beobachtest. Singt sie fröhlich? Mehr Traffic! Fällt sie um? Rollback!
Real talk: Das ist mein Lieblings-Deployment-Pattern. Warum? Weil du echte User-Daten bekommst, bevor du all-in gehst. Und als jemand, der gelernt hat, dass Kontrolle manchmal loslassen bedeutet… 😉 Canary ist der perfekte Kompromiss.
Lass uns das gemeinsam angehen! 🚀
🟢 GRUNDLAGEN
Was ist ein Canary Deployment?
Blue-Green ist ein Schalter: KLICK – 100% Traffic auf die neue Version.
Canary ist ein Dimmer: Langsam von 0% auf 100% hochdrehen.
💡 Neu hier? Was ist Traffic Split?
Traffic Split bedeutet, dass der Load Balancer Anfragen prozentual aufteilt. Bei 95/5 Split gehen 95 von 100 Anfragen zur alten Version, 5 zur neuen.
Warum? Du testest die neue Version mit echten Usern, aber limitierst das Risiko.
Warum Canary statt Blue-Green?
| Szenario | Blue-Green | Canary |
|---|---|---|
| „Funktioniert der Code?“ | ✅ Tests vor Switch | ✅ Tests vor Traffic |
| „Wie reagieren echte User?“ | ❌ Erst nach 100% Switch | ✅ Schon bei 5% |
| „Performance unter Last?“ | ❌ Erst nach 100% Switch | ✅ Schrittweise messen |
| „Rollback bei Problemen“ | ✅ Schnell (2 Sek) | ✅ Noch schneller (nur 5% betroffen) |
Der große Vorteil: Bei Canary merkst du Probleme, wenn nur 5% betroffen sind – nicht 100%.
Dein erstes Canary Setup (nginx)
Wir erweitern das Blue-Green Setup aus Teil 8:
# nginx.conf - Canary mit Weight-based Routing
upstream backend {
# Stable: 95% des Traffics
server stable:8080 weight=95;
# Canary: 5% des Traffics
server canary:8080 weight=5;
}
server {
listen 80;
location / {
proxy_pass http://backend;
# Header zeigt, welche Version geantwortet hat
add_header X-Served-By $upstream_addr;
}
}
Was macht dieser Code?
| Zeile | Erklärung |
|---|---|
weight=95 | 95 von 100 Requests gehen zu Stable |
weight=5 | 5 von 100 Requests gehen zu Canary |
X-Served-By | Header für Debugging – zeigt welcher Server geantwortet hat |
Traffic schrittweise erhöhen:
# Phase 1: 5% Canary
upstream backend {
server stable:8080 weight=95;
server canary:8080 weight=5;
}
# Phase 2: 25% Canary (wenn Phase 1 gut war)
upstream backend {
server stable:8080 weight=75;
server canary:8080 weight=25;
}
# Phase 3: 50% Canary
upstream backend {
server stable:8080 weight=50;
server canary:8080 weight=50;
}
# Phase 4: 100% Canary → Canary wird neues Stable
upstream backend {
server canary:8080 weight=100;
}
💡 Du kennst die Basics schon? → Spring direkt zu PROFESSIONALS
🟡 PROFESSIONALS
Canary mit Kubernetes
In Kubernetes wird Canary eleganter – mit Labels und Service Selectors:
# stable-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-stable
spec:
replicas: 9 # 90% der Pods
selector:
matchLabels:
app: myapp
version: stable
template:
metadata:
labels:
app: myapp
version: stable
spec:
containers:
- name: myapp
image: myapp:1.0.0
ports:
- containerPort: 8080
---
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-canary
spec:
replicas: 1 # 10% der Pods
selector:
matchLabels:
app: myapp
version: canary
template:
metadata:
labels:
app: myapp
version: canary
spec:
containers:
- name: myapp
image: myapp:1.1.0
ports:
- containerPort: 8080
---
# service.yaml - Routet zu BEIDEN Deployments!
apiVersion: v1
kind: Service
metadata:
name: myapp
spec:
selector:
app: myapp # Matcht stable UND canary!
ports:
- port: 80
targetPort: 8080
Der Trick: Der Service selektiert nach app: myapp – das matcht BEIDE Deployments. Kubernetes verteilt automatisch nach Replica-Count.
Traffic-Prozent ändern:
# 10% Canary (1 von 10 Pods) kubectl scale deployment myapp-stable --replicas=9 kubectl scale deployment myapp-canary --replicas=1 # 30% Canary (3 von 10 Pods) kubectl scale deployment myapp-stable --replicas=7 kubectl scale deployment myapp-canary --replicas=3 # 50% Canary kubectl scale deployment myapp-stable --replicas=5 kubectl scale deployment myapp-canary --replicas=5 # 100% Canary → Rollout complete kubectl scale deployment myapp-stable --replicas=0 kubectl scale deployment myapp-canary --replicas=10
Automatisches Rollback mit Metriken
Das manuelle Skalieren ist okay zum Lernen, aber in Production willst du Automatisierung:
# canary-analysis.yaml (Konzept - Details in BONUS)
apiVersion: monitoring/v1
kind: CanaryAnalysis
metadata:
name: myapp-canary-check
spec:
# Wann analysieren?
interval: 60s
# Wie lange beobachten?
duration: 10m
# Erfolgskriterien
metrics:
- name: error-rate
threshold: 1% # Max 1% Fehler
- name: latency-p99
threshold: 500ms # Max 500ms für 99% der Requests
- name: success-rate
threshold: 99% # Min 99% erfolgreiche Requests
# Was tun bei Failure?
onFailure:
action: rollback
notify:
- slack: #deployments
- email: ops@company.com
Stolperfallen vermeiden
❌ Fehler #1: Canary ohne Monitoring
# SCHLECHT - blind hoffen kubectl scale deployment myapp-canary --replicas=5 sleep 300 kubectl scale deployment myapp-canary --replicas=10 # Keine Ahnung ob es funktioniert 💥
✅ Besser:
# GUT - Metriken beobachten
kubectl scale deployment myapp-canary --replicas=1
# Warte und prüfe Error Rate
error_rate=$(curl -s prometheus:9090/api/v1/query?query=error_rate | jq '.data.result[0].value[1]')
if (( $(echo "$error_rate > 0.01" | bc -l) )); then
echo "❌ Error rate too high: $error_rate"
kubectl scale deployment myapp-canary --replicas=0
exit 1
fi
echo "✅ Error rate OK: $error_rate"
kubectl scale deployment myapp-canary --replicas=3
❌ Fehler #2: Zu schnelles Hochskalieren
# SCHLECHT - zu schnell kubectl scale deployment myapp-canary --replicas=1 sleep 60 kubectl scale deployment myapp-canary --replicas=10 # 💥 0 auf 100 in 1 Minute
✅ Besser:
# GUT - schrittweise mit Pausen
for replicas in 1 3 5 7 10; do
kubectl scale deployment myapp-canary --replicas=$replicas
echo "⏳ Waiting 5 minutes at $replicas replicas..."
sleep 300
# Check metrics
if ! check_metrics; then
echo "❌ Metrics failed at $replicas replicas"
kubectl scale deployment myapp-canary --replicas=0
exit 1
fi
done
❌ Fehler #3: Sticky Sessions ignorieren
Wenn User an eine bestimmte Version „kleben“, verfälscht das deine Metriken:
# Problem: User A bekommt IMMER Canary
upstream backend {
ip_hash; # ← Sticky! Nicht gut für Canary
server stable:8080 weight=95;
server canary:8080 weight=5;
}
# Lösung: Kein ip_hash, dafür Session-Store teilen
upstream backend {
# Kein ip_hash - jeder Request wird neu geroutet
server stable:8080 weight=95;
server canary:8080 weight=5;
}
💡 Du willst mehr? → Im BONUS findest du Argo Rollouts und GitOps
🔵 BONUS
Argo Rollouts – GitOps Canary
Argo Rollouts ist der Goldstandard für Canary in Kubernetes:
# rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: myapp
spec:
replicas: 10
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myapp:1.1.0
ports:
- containerPort: 8080
strategy:
canary:
# Schrittweise Traffic-Erhöhung
steps:
- setWeight: 5
- pause: {duration: 5m}
- setWeight: 25
- pause: {duration: 5m}
- setWeight: 50
- pause: {duration: 5m}
- setWeight: 75
- pause: {duration: 5m}
# Automatische Metriken-Analyse
- analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: myapp
- setWeight: 100
# Traffic Management mit Istio
trafficRouting:
istio:
virtualService:
name: myapp-vsvc
destinationRule:
name: myapp-destrule
canarySubsetName: canary
stableSubsetName: stable
AnalysisTemplate für automatische Entscheidungen:
# analysis-template.yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
args:
- name: service-name
metrics:
- name: success-rate
interval: 1m
count: 5
successCondition: result[0] >= 0.99
failureLimit: 3
provider:
prometheus:
address: http://prometheus:9090
query: |
sum(rate(
http_requests_total{
service="{{args.service-name}}",
status=~"2.."
}[5m]
)) / sum(rate(
http_requests_total{
service="{{args.service-name}}"
}[5m]
))
Header-basiertes Routing für Testing
Manchmal willst du die Canary-Version gezielt testen:
# istio-virtualservice.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- myapp
http:
# QA Team bekommt IMMER Canary
- match:
- headers:
x-canary:
exact: "true"
route:
- destination:
host: myapp
subset: canary
# Normaler Traffic: Weight-based
- route:
- destination:
host: myapp
subset: stable
weight: 95
- destination:
host: myapp
subset: canary
weight: 5
Testen mit Header:
# Normal: 95% Chance auf Stable curl http://myapp/api/health # QA: Garantiert Canary curl -H "x-canary: true" http://myapp/api/health
Performance-Vergleich: Deployment-Strategien
| Strategie | Rollback-Zeit | Risk Exposure | Komplexität | Resource-Overhead |
|---|---|---|---|---|
| Recreate | 5-15 Min | 100% | ⭐ | Niedrig |
| Rolling | 2-5 Min | Variable | ⭐⭐ | Niedrig |
| Blue-Green | 2-5 Sek | 100% (aber instant rollback) | ⭐⭐⭐ | 2x Ressourcen |
| Canary | 2-5 Sek | 5-50% (kontrolliert) | ⭐⭐⭐⭐ | 1.1-2x Ressourcen |
💡 Praxis-Tipps
Für Einsteiger 🌱
- Starte mit nginx: Bevor du Kubernetes und Argo Rollouts lernst, verstehe das Konzept mit einfachem nginx Weight-Routing.
- Definiere „Erfolg“: Was bedeutet „die Canary-Version funktioniert“? Error Rate < 1%? Latency < 500ms? Schreib es auf, BEVOR du startest.
Für den Alltag 🌿
- Mindestens 5 Minuten pro Phase: Dein Monitoring braucht Zeit, um aussagekräftige Daten zu sammeln. 1 Minute ist zu kurz.
- Alerting VOR Automatisierung: Erst manuell mit Alerts, dann automatisieren. Du musst verstehen, was schiefgehen kann.
Für Profis 🌳
- Segment-basiertes Canary: Statt random 5% – schick erst interne User, dann Beta-User, dann alle.
- A/B Testing kombinieren: Canary für technische Stabilität, A/B für Feature-Validierung. Nicht vermischen!
🛠️ Tools & Extensions
Für Einsteiger 🌱
| Tool | Warum? | Link |
|---|---|---|
| nginx | Simples Weight-Routing | nginx.org |
| Docker Compose | Lokales Testing | docs.docker.com |
Für den Alltag 🌿
| Tool | Warum? | Link |
|---|---|---|
| Kubernetes | Container Orchestration | kubernetes.io |
| Prometheus | Metriken sammeln | prometheus.io |
| Grafana | Metriken visualisieren | grafana.com |
Für Profis 🌳
| Tool | Warum? | Link |
|---|---|---|
| Argo Rollouts | GitOps Canary | argoproj.github.io |
| Istio | Service Mesh mit Traffic Control | istio.io |
| Flagger | Automated Canary mit Istio/Linkerd | flagger.app |
❓ FAQ (Häufige Fragen)
Frage 1: Wann Canary vs Blue-Green?
Antwort: Blue-Green für schnelles Switching ohne Metriken-Overhead. Canary wenn du echte User-Daten brauchst oder das Risiko minimieren willst. In der Praxis: Starte mit Blue-Green, upgrade zu Canary wenn du Monitoring hast.
Frage 2: Wie klein kann der Canary-Traffic sein?
Antwort: Technisch 1 Request. Praktisch brauchst du genug Traffic für statistische Signifikanz. Bei 1000 Requests/Minute sind 1% (10 Requests/Minute) oft zu wenig. 5% ist ein guter Start.
Frage 3: Was ist der Unterschied zwischen Canary und A/B Testing?
Antwort: Canary testet technische Stabilität (Fehler, Performance). A/B Testing testet User-Verhalten (Conversion, Engagement). Canary ist DevOps, A/B ist Product. Beides kann parallel laufen.
Frage 4: Brauche ich Kubernetes für Canary?
Antwort: Nein! nginx mit Weight-Routing funktioniert super. Kubernetes macht es eleganter und skalierbarer, ist aber nicht Pflicht. Starte einfach, upgrade wenn nötig.
Frage 5: Was wenn die Canary-Version Daten schreibt?
Antwort: Gute Frage! Datenbank-Änderungen sind permanent – auch wenn du Canary rollbackst. Lösung: Feature Flags für schreibende Features, Canary nur für lesende Operationen, oder Expand-Contract Pattern (siehe Teil 8).
Frage 6: Wie automatisiere ich den Rollback?
Antwort: Definiere Schwellwerte (Error Rate > 1%, Latency > 500ms). Wenn überschritten: automatisch Traffic auf 0% setzen. Argo Rollouts und Flagger machen das out-of-the-box.
Frage 7: Wie balancierst du Kontrolle und Loslassen beim Deployment? 🤔
Antwort: lächelt Früher wollte ich ALLES kontrollieren. Jede Metrik, jede Phase, jedes Detail. Heute? Ich definiere klare Grenzen und lasse die Automatisierung arbeiten. Das hat mir jemand beigebracht – dass Vertrauen manchmal mehr wert ist als Kontrolle. Aber das gehört zu private logs. 📝
Frage 8: Kann ich Canary für Datenbank-Migrationen nutzen?
Antwort: Vorsicht! DB-Migrationen sollten Blue-Green-kompatibel sein (beide Versionen müssen mit dem Schema arbeiten). Canary ersetzt das nicht. Nutze Expand-Contract aus Teil 8.
📖 Enterprise CI/CD Mastery – Alle Teile
Für Einsteiger empfohlen: Starte bei Teil 1! ⭐
| Teil | Thema | Level | Status |
|---|---|---|---|
| 1 | Erste Pipeline | 🟢 | ✅ Veröffentlicht |
| 2 | Security Gates (OWASP + Trivy) | 🟢 | ✅ Veröffentlicht |
| 3 | Coverage Gates (JaCoCo) | 🟢 | ✅ Veröffentlicht |
| 4 | Quality Gates (SonarQube) | 🟡 | ✅ Veröffentlicht |
| 5 | Multi-Stage Builds | 🟡 | ✅ Veröffentlicht |
| 6 | Container Security (SBOM) | 🟡 | ✅ Veröffentlicht |
| 7 | Registry Integration | 🟡 | ✅ Veröffentlicht |
| 8 | Blue-Green Deployments | 🟡 | ✅ Veröffentlicht |
| → 9 | Canary & Kubernetes | 🟡 | 📍 Du bist hier! |
| 10 | GitOps & Environments | 🔴 | 📅 19.12.2025 |
| 11 | Jenkins Enterprise | 🔴 | 📅 Coming Soon |
| 12 | Multi-Platform & Finale | 🔴 | 📅 Coming Soon |
💬 Real Talk: Der Canary fliegt
Java Fleet Büro, Freitag 15:00 Uhr. Deployment-Fenster.
Nova: „Okay, Canary ist bei 5%. Ich bin nervös.“
Code Sentinel: „Schau auf die Metriken. Error Rate?“
Nova: „0.2%. Normal ist 0.15%.“
Kofi: „Ist das schlimm?“
Code Sentinel: „Nope. Das ist statistisches Rauschen bei so wenig Traffic. Warte noch 3 Minuten.“
3 Minuten später
Nova: „0.14%! Sogar besser als Stable!“
Code Sentinel: „Siehst du? Der Kanarienvogel singt. Geh auf 25%.“
Elyndra: „Ich muss sagen, mir gefällt dieser entspannte Code. Früher hättest du bei 0.2% Error Rate den Alarm ausgelöst.“
Code Sentinel: schmunzelt „Früher hätte ich auch keinen Canary gemacht. 100% oder nichts. Aber manchmal ist schrittweise besser als perfekt sofort.“
Kat: tippt auf ihrem Laptop „Die Latency auf Canary ist sogar 20ms niedriger. Die neue Version ist schneller!“
Nova: „Sollen wir direkt auf 100% gehen?“
Code Sentinel: „Nein. 25%, dann 50%, dann 100%. Geduld. Der Kanarienvogel hat uns gute Nachrichten gebracht – jetzt lassen wir ihn noch ein bisschen singen.“
Franz-Martin: kommt vorbei „Sieht gut aus. Code, du wirkst… gelassen.“
Code Sentinel: „Hab gelernt, dass gute Systeme Vertrauen verdienen. Und gute Menschen auch.“ 😉
Kat: flüstert zu Nova „Ich schwöre, er wird rot.“
🎁 Cheat Sheet
🟢 Basics (Zum Nachschlagen)
# Canary Konzept
STABLE = Aktuelle Production (90-95%)
CANARY = Neue Version (5-10%)
PROMOTE = Canary wird neues Stable
ROLLBACK = Canary Traffic auf 0%
# nginx Weight-based Routing
upstream backend {
server stable:8080 weight=95;
server canary:8080 weight=5;
}
🟡 Patterns (Für den Alltag)
# Kubernetes: Traffic über Replica-Count kubectl scale deployment myapp-stable --replicas=9 kubectl scale deployment myapp-canary --replicas=1 # = 10% Canary # Traffic erhöhen kubectl scale deployment myapp-canary --replicas=3 # = 30% Canary (3 von 10 Pods)
🔵 Advanced (Für Profis)
# Argo Rollouts - automatisches Canary
strategy:
canary:
steps:
- setWeight: 5
- pause: {duration: 5m}
- analysis:
templates:
- templateName: success-rate
- setWeight: 50
- pause: {duration: 10m}
- setWeight: 100
🎨 Challenge für dich!
Wähle dein Level:
🟢 Level 1 – Einsteiger
- [ ] Erweitere dein Blue-Green Setup aus Teil 8 zu Canary
- [ ] Implementiere nginx Weight-Routing
- [ ] Mache einen manuellen Traffic-Shift von 5% auf 100%
Geschätzte Zeit: 30-45 Minuten
🟡 Level 2 – Fortgeschritten
- [ ] Deploye das Canary-Setup auf Kubernetes
- [ ] Implementiere Health-Check basiertes Scaling
- [ ] Baue ein Bash-Script für schrittweises Promotion
Geschätzte Zeit: 1-2 Stunden
🔵 Level 3 – Profi
- [ ] Installiere Argo Rollouts
- [ ] Implementiere Prometheus-basierte Analysis
- [ ] Baue automatischen Rollback bei hoher Error Rate
Geschätzte Zeit: 3-4 Stunden
Teile dein Ergebnis! 🎉
📦 Downloads
Alle Code-Beispiele zum Herunterladen:
| Projekt | Für wen? | Download |
|---|---|---|
| canary-nginx-basic.zip | 🟢 Einsteiger | ⬇️ Download |
| canary-kubernetes.zip | 🟡 Alle Levels | ⬇️ Download |
| canary-argo-rollouts.zip | 🔵 Profis | ⬇️ Download |
Quick Start:
# Option 1: Lokales nginx Setup unzip canary-nginx-basic.zip cd canary-nginx-basic docker-compose up -d # Option 2: Kubernetes unzip canary-kubernetes.zip cd canary-kubernetes kubectl apply -f .
Probleme? → Troubleshooting-Guide | → FAQ
🔗 Weiterführende Links
📚 Für Einsteiger
| Ressource | Beschreibung |
|---|---|
| Kubernetes Basics | Offizieller Einstieg |
| nginx Load Balancing | Weight-based Routing verstehen |
🛠️ Tools & Extensions
| Tool | Beschreibung |
|---|---|
| Argo Rollouts | Progressive Delivery für K8s |
| Flagger | Automated Canary mit Service Mesh |
📖 Für Fortgeschrittene
| Ressource | Beschreibung |
|---|---|
| Canary Release (Martin Fowler) | Der Klassiker |
| Progressive Delivery (RedHat) | Enterprise-Perspektive |
🔧 Offizielle Dokumentation
💬 Geschafft! 🎉
Was du heute gelernt hast:
✅ Canary Deployment Konzept vs Blue-Green verstanden ✅ Traffic-Splitting mit nginx und Kubernetes ✅ Metriken-basierte Entscheidungen ✅ Argo Rollouts für automatisiertes Canary
Egal ob du heute zum ersten Mal davon gehört hast oder dein Wissen vertieft hast – du hast etwas Neues gelernt. Das zählt!
Fragen? Schreib mir:
- Code Sentinel: code.sentinel@java-developer.online
Nächster Teil: GitOps & Environments – Deine Infrastruktur als Code 🚀
Keep deploying, keep learning! 💚
Tags: #CICD #Canary #Kubernetes #Deployment #ArgoRollouts #DevOps #ProgressiveDelivery
© 2025 Java Fleet Systems Consulting | java-developer.online
