Kubernetes released alle drei Monate eine neue Minor-Version. Jede wird 14 Monate supported. Rechnen Sie nach: wenn Sie nicht regelmäßig upgraden, sind Sie in 18 Monaten unsupported — und irgendwann ist Ihre Version so alt, dass Upgrade-Pfade mehrere Zwischenversionen erfordern.
Das tatsächliche Problem
Die meisten Upgrade-Horrorstorys kommen nicht von Kubernetes selbst, sondern von den Dingen drumherum: veraltete Admission-Controller, API-Deprecations in Helm-Charts, CNI-Plugins die stecken bleiben, CustomResourceDefinitions die Breaking Changes haben.
Unsere Upgrade-Routine
- Upgrades sind monatlich geplant, nicht quartalsweise
- Dev-Cluster erhält neue Version sofort bei Release
- Staging folgt nach 2 Wochen, Produktion 2 Wochen später
- Jedes Upgrade durchläuft `pluto` für deprecated APIs vor dem Upgrade
- Helm-Charts werden vor Cluster-Upgrade auf aktuelle Versionen gebracht
- Rollback-Plan ist dokumentiert, bevor Upgrade startet
Sonderfall: OpenShift v3 → v4
OpenShift v3 → v4 ist kein klassisches Minor-Upgrade, es ist eine Plattform-Neubau: andere Node-Runtime (CRI-O statt Docker), anderer Installer, andere Operator-Philosophie. In einer regulierten Umgebung muss der Migrationspfad als Parallel-Betrieb aufgesetzt werden — neue v4-Cluster neben den alten v3-Clustern, Workloads schrittweise verschoben, v3 erst abschalten wenn v4 produktionsreif.
Was wir gelernt haben
Upgrades sind keine seltene Ausnahme, sondern Teil des normalen Betriebs. Teams die das akzeptieren, bauen ihre Systeme darauf auf — idempotente Controllers, API-Version-Resilienz, automatisches Helm-Upgrading. Teams die Upgrades als Ausnahme behandeln, werden von jedem Upgrade überrascht.