Du deployest Version 2.4.1. Changelog: ein Fix im Payment-Endpoint, zwei neue API-Felder, ein refactored Service Layer. Code Review: approved. Tests: grün. Pipeline: grün.
Fünf Minuten nach dem Deploy: Fehlerrate 100%. Der Payment-Endpoint wirft 500er. Jeder einzelne Request. Ein Edge Case den kein Test abgedeckt hat.
Die Frage ist nicht ob das passiert, es passiert jedem. Die Frage ist: wie viele deiner User sehen es? 100%? 17%? 1%? Das entscheidet nicht dein Code. Das entscheidet deine Deployment-Strategie.
Klick auf Deploy und schau, wie derselbe Bug in drei Strategien unterschiedlich zuschlägt:
Gleicher Bug. Komplett anderer Blast Radius. Beim Rolling Update sehen 67% der User den Fehler bevor er überhaupt erkannt wird. Bei Blue-Green sind es 100% — aber die Recovery ist sofort. Beim Canary: 17%, für wenige Sekunden, dann automatischer Rollback.
Rolling Update
Die einfachste Strategie. Deine 6 Instanzen werden eine nach der anderen durch die neue Version ersetzt. Kein zusätzlicher Infra-Bedarf. Zero Downtime, es sind immer Instanzen online.
Das Problem: der Bug verbreitet sich langsam. Instanz 1 bekommt die neue Version, ein paar Requests schlagen fehl. Instanz 2 wird ersetzt. Mehr Fehler. Bis du merkst dass was nicht stimmt, laufen schon vier von sechs auf der kaputten Version. Und Rollback? Dauert genauso lange wie das Deployment. Jede Instanz muss einzeln zurück.
// deployment.yaml
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 // max 1 extra Instanz während Update
maxUnavailable: 0 // immer alle Instanzen verfügbarGut für: unkritische Services, Background Worker, interne Tools. Alles wo ein paar Minuten erhöhte Fehlerrate kein Desaster sind.
Die meisten Teams nutzen Rolling Updates weil es der Kubernetes-Default ist. Nicht weil sie sich bewusst dafür entschieden haben. Das ist ein Unterschied.
Blue-Green
Zwei identische Environments. Blue läuft produktiv mit der alten Version. Green bekommt die neue. Du testest Green, und wenn alles gut aussieht: Traffic-Switch. Sofort. 100% des Traffics geht von Blue nach Green.
Wenn der Bug zuschlägt: Switch zurück auf Blue. Sofort. Eine DNS-Änderung, ein Load-Balancer-Toggle. Rollback in unter einer Sekunde.
Der Trade-off: du brauchst doppelte Infrastruktur. Während des Deployments laufen beide Environments. Für einen 6-Instanz-Service kein Problem. Für ein System mit 200 Instanzen und 3 Datenbanken: teuer.
// Nginx / Load Balancer Config
upstream backend {
// Vor Switch:
// server blue-1:8080;
// server blue-2:8080;
// Nach Switch:
server green-1:8080;
server green-2:8080;
}Und: wenn deine neue Version Datenbank-Migrationen braucht, wird’s kompliziert. Blue und Green müssen temporär mit demselben Schema arbeiten. Forward-compatible Migrations sind Pflicht.
Canary
Mein Favorit. Du rollst die neue Version auf eine Instanz aus, den Canary. 17% des Traffics (bei 6 Instanzen) geht an die neue Version. Du beobachtest Error Rate, Latenz, Business-Metriken. Alles clean? Nächste Instanz. Immer noch clean? Weiter. Bei Anomalie: automatischer Rollback. Nur der Canary war betroffen.
async function routeRequest(req: Request): Promise<string> {
const canaryWeight = 0.05; // 5% an Canary
if (Math.random() < canaryWeight) {
return 'canary-pool';
}
return 'stable-pool';
}
// Monitoring
function checkCanaryHealth(): boolean {
const canaryErrorRate = metrics.errorRate('canary-pool');
const stableErrorRate = metrics.errorRate('stable-pool');
// Wenn Canary 2x mehr Fehler als Stable: Rollback
return canaryErrorRate < stableErrorRate * 2;
}Netflix hat das perfektioniert. Ihr Canary-System “Kayenta” vergleicht automatisch Metriken zwischen Canary und Baseline. Statistisch signifikanter Unterschied? Automatischer Rollback. Kein Mensch muss entscheiden.
Der Canary braucht gutes Monitoring. Du musst in Echtzeit vergleichen: wie performt die neue Version vs die alte? Error Rate, Latenz, CPU, Memory. Wenn du diese Metriken nicht hast, fährst du blind.
Wann welche Strategie
Rolling Update wenn Geschwindigkeit wichtiger ist als Sicherheit: interne Services, Background Jobs, Dev/Staging Environments. Überall wo ein paar Fehler während des Deployments akzeptabel sind.
Blue-Green wenn du sofortigen Rollback brauchst und die Infrastruktur-Kosten tragen kannst. Gut für Services die selten deployen, bei denen es dann aber sicher sein muss.
Canary für alles was User-facing ist und häufig deployed wird: Payment Services, APIs, Frontends. Die Kombination aus kleinem Blast Radius und automatischem Rollback ist schwer zu schlagen.
Ehrlich gesagt: wenn du CI/CD machst und öfter als einmal die Woche deployst, gibt es keinen guten Grund nicht Canary zu fahren. Der Aufwand ist minimal: ein bisschen Traffic Splitting, ein paar Metrik-Vergleiche. Der Schutz ist enorm.
Nächstes Mal wenn du kubectl apply machst: check welche Strategy drin steht. Wenn da RollingUpdate steht und du es nie bewusst gesetzt hast, jetzt weißt du warum.