Upgrade-Strategien und Blast-Radius-Kontrolle
K8s-Upgrades, Canary-Cluster, Rollback und Change-Risiko.
Lernziele
Nach dieser Lektion kannst du erklären, warum Plattform-Upgrades (Kubernetes, Operatoren, CNI, Ingress) ein eigenes Risikoprofil haben, wie du Blast Radius durch Canary-Cluster, sequenzielle Rollouts und Rollback-Pläne begrenzt und welche Upgrade-Strategien für Control Plane, Add-ons und Tenant-Workloads getrennt betrachtet werden müssen.
Das Problem: Ein Upgrade legt fünfzig Teams lahm
Ein Platform Engineer upgraded am Freitag den Ingress-Controller. Montagmorgen: TLS-Handshakes schlagen fehl, weil die neue Version ein anderes Default-Cipher-Set mitbringt. Oder: Das Kubernetes-Minor-Upgrade entfernt eine deprecated API — und dreißig Helm-Releases deployen nicht mehr. Oder: Der CNI-Wechsel bricht NetworkPolicies.
Der Unterschied zu einem einzelnen Produkt-Team: Dein Upgrade trifft alle Mandanten gleichzeitig. Blast Radius ist die zentrale Größe — nicht „wie schnell bin ich auf der neuesten Version”, sondern „wie viel kann gleichzeitig kaputtgehen, und wie schnell rolle ich zurück”.
Drei Upgrade-Ebenen — nicht vermischen
1. Control Plane (Kubernetes-API, etcd, Scheduler).
Managed Kubernetes (EKS/GKE/AKS): Provider führt das Upgrade durch — du wählst Version und Maintenance Window. Self-managed: eigenes Runbook, Backup von etcd vorher, API-Deprecation-Check mit pluto oder kube-no-trouble gegen alle Cluster-Manifeste.
Strategie: Ein Minor pro Quartal, Patch-Versionen monatlich. Nie prod als Erstes — immer dev → staging → prod-Canary → prod-Fleet.
2. Plattform-Add-ons (CNI, Ingress, cert-manager, Prometheus, Argo CD, Gatekeeper).
Jeder Add-on ist ein eigener Release-Zyklus. Fehler: alles in einem Change-Window.upgraden. Besser: ein Add-on pro Woche, mit Health-Checks dazwischen.
Helm macht Rollback einfach (helm rollback) — GitOps macht es nachvollziehbar (Revert-Commit). Beides brauchst du dokumentiert, nicht nur eines.
3. Tenant-Workloads.
Teams upgraden ihre Apps — das ist ihr Problem, wenn die Plattform API-Kompatibilität hält. Deine Aufgabe: Deprecation-Warnungen früh ausspielen (Audit-Policy, kubectl deprecations, E-Mails an Team-Owner), Breaking Changes mit Migrationsguide, nicht Überraschung am Upgrade-Tag.
Blast-Radius-Kontrolle: konkrete Muster
Canary-Cluster. Ein prod-Cluster mit einem Team (oder synthetischer Last) bekommt das Upgrade zuerst. Metriken und SLOs (Lektion 36) vergleichen — erst bei grünem Error Budget rollst du auf die Fleet.
Blue/Green Control Plane (self-managed): Neuer Control-Plane-Stack parallel, Workloads umgeschwenkt — teuer, aber schneller Rollback.
Surge-Upgrades bei Add-ons: maxUnavailable: 0, maxSurge: 1 — kein kompletter Ausfall des Controllers während des Rollouts.
Feature Gates und Flags. Kubernetes-Features schrittweise aktivieren; Operator-CRD-Versionen parallel betreiben, wo der Operator es erlaubt.
Freeze Windows. Kein Plattform-Upgrade in Peak (Black Friday, Monatsabschluss) — in Error-Budget-Politik verankern.
Rollback: Plan B ist Pflicht, nicht Optional
Vor jedem Upgrade dokumentierst du:
- Rollback-Befehl —
helm rollback, Git-Revert, Cluster-Restore aus Velero. - Rollback-Zeit — wie lange dauert es realistisch? Wenn > RTO, ist das Upgrade zu riskant.
- Rollback-Trigger — welche Metriken/Alerts lösen automatisch oder manuell Rollback aus? (SLO-Burn-Rate ist ein guter Kandidat.)
- Was rollback NICHT fixt — etcd-Migration, irreversible CRD-Changes. Dann brauchst du Backup-Restore statt Rollback.
Ein Upgrade ohne getesteten Rollback ist ein Wetteinsatz — in Interviews und in prod.
API-Deprecation: der stille Killer
Kubernetes entfernt APIs (z. B. extensions/v1beta1 Ingress → networking.k8s.io/v1). Betroffen sind oft alte Helm-Charts in Team-Repos, die niemand anfasst.
Prozess:
- Scan aller Manifeste im GitOps-Repo (
pluto,kubent). - Report pro Team: welche Ressourcen betroffen, Deadline des Providers.
- Automatische PRs wo möglich (Kyverno mutate, chart bump).
- Blockiere Upgrade erst wenn kritischer Massenanteil migriert — oder akzeptiere bewusstes Risiko mit Escalation.
Praxis
Übung (60 Minuten):
- Wähle ein Add-on in deinem Lab (z. B. ingress-nginx oder cert-manager).
- Notiere aktuelle Chart-Version und App-Version (
helm list -A). - Upgrade eine Minor-Version in staging.
- Führe Smoke-Tests aus: Ingress-TLS, cert-Renewal, ein Test-Deploy.
- Simuliere Rollback mit
helm rollback— miss die Downtime. - Schreibe ein Mini-Runbook (halbe Seite): Upgrade-Schritte, Rollback, Trigger.
Optional: pluto detect-files-in-cluster oder equivalent gegen ein Test-Cluster — welche deprecated APIs siehst du?
Typische Stolperfallen
Big-Bang-Upgrade. Alles am Wochenende — ein Fehler, alle betroffen. Canary existiert aus gutem Grund.
Kein API-Scan vor K8s-Minor. Teams blockiert, Platform schuld — obwohl Deprecation-Warnungen Monate sichtbar waren.
Rollback nie geübt. Im Incident dauert Rollback dreimal so lang wie im Runbook — oder scheitert, weil CRD-Version nicht zurückgeht.
Workload- und Plattform-Upgrade vermischt. Schwer zu isolieren, wer was kaputt gemacht hat — separate Change-Tickets.
Interview-Vorbereitung
Kernbotschaft: „Plattform-Upgrades brauchen getrennte Strategien für Control Plane, Add-ons und Workloads — Blast Radius begrenzt man mit Canary-Clustern, sequenziellen Rollouts und getesteten Rollbacks; API-Deprecation ist der häufigste versteckte Breaker.”
Follow-ups:
- „Wie oft upgradest du Kubernetes?” — Minor quartalsweise nach Provider-Supportfenster; Patch monatlich; immer dev → staging → canary prod.
- „Helm rollback oder GitOps revert?” — Beides im Runbook; GitOps ist Source of Truth, Helm rollback für schnelle Mitigation.
- „Wann upgrade abbrechen?” — SLO-Burn-Rate über Schwelle, Smoke-Tests rot, Rollback-Zeit < verbleibende Toleranz.
Zusammenfassung
Upgrade-Strategie auf der Plattform ist Risk Management: Ebenen trennen, Canary vor Fleet, Rollback vor Change, API-Deprecation proaktiv. Error Budgets aus Lektion 36 steuern, wann überhaupt ein riskantes Upgrade stattfinden darf. Als Nächstes: wer nachts ans Telefon geht — On-Call für Platform Teams in Lektion 39.