Verwaltete Upgrades
Teil des verwalteten Tarifs — heute live
Verwaltete Kubernetes-Upgrades laufen über den verwalteten Tarif (access: managed), der live ist und ein Supporter-Abo oder höher erfordert (bei Hosted- und Enterprise-Tenants ist er enthalten). Der Tarif fügt kubehz' Verwaltungsfunktionen auf registered obendrauf — Healing-Richtlinien, Kapazitäts-Überwachung und die Verwaltung des gewünschten Zustands, gesteuert aus dem Dashboard. Ausführende Funktionen werden bewusst hinter Pro-Funktion-Schaltern ausgerollt — eine Funktion kann also im Dashboard sichtbar sein, bevor ihre ausführende Hälfte für ein Deployment eingeschaltet ist; der Ein-Klick-Upgrade-Ablauf wird noch schrittweise ausgerollt.
Einen Self-Hosted-Cluster selbst upgraden? Das funktioniert wie immer mit dem lok8s-Provisioner (KubeOne/CAPI): Version in deiner Spezifikation erhöhen und den Provisioner erneut ausführen. Das ist eine lok8s-Operation auf deinem eigenen Cluster, unabhängig von kubehz — siehe die lok8s-Dokumentation.
Das Modell
Der verwaltete Tarif ist die access: managed-Achse des Zwei-Achsen-Modells. Auf einem Cluster, für den du ihn aktiviert hast, steuerst du kubehz' Verwaltungsfunktionen aus dem Dashboard: Healing-Richtlinien, Kapazitäts-Überwachung und die Verwaltung des gewünschten Zustands — Upgrade- und Skalierungsabläufe laufen über genau diese Naht des gewünschten Zustands. Für ein Upgrade hält kubehz die gewünschte Kubernetes-Version fest und dein Cluster (oder eine gehostete Control Plane) führt es durch:
- zuerst die Control Plane, dann Worker einzeln gesperrt/geleert/aktualisiert (cordon/drain/upgrade),
- Versions-Skew-Regeln durchgesetzt (kein Überspringen von Minor-Versionen),
- Vorabprüfungen auf entfernte APIs, Node-Bereitschaft und etcd-Zustand,
- automatisches Rollback, falls ein Upgrade auf halbem Weg fehlschlägt.
Der Mechanismus — Pull, nicht Push
Das Ausführen ist Pull-basiert. Der clusterinterne Agent holt den gewünschten Zustand von der Plattform ab (GET /clusters/{id}/desired) und wendet ihn lokal mit den eigenen Zugangsdaten des Clusters an. Die Plattform hält niemals eingehende Zugangsdaten und pusht niemals in deinen Cluster hinein.
Für einen Self-Hosted-verwalteten Cluster heißt das: kubehz benötigt kein Hetzner-Token — kubehz hält den gewünschten Zustand fest und der eigene machine-controller deines Clusters erledigt die Arbeit mit Zugangsdaten, die er bereits besitzt.
Pro-Funktion-Ausführungsschalter steuern die ausführende Hälfte jeder verwalteten Funktion, sodass ausführende Funktionen bewusst ausgerollt werden — Sichtbarkeit zuerst, Ausführung, sobald der Schalter für ein Deployment an ist.
Was heute live ist
- Versionsmeldung (welche Version jeder registrierte Cluster ausführt) — live über den Heartbeat-Agenten; du siehst es im Dashboard.
- Der verwaltete Tarif selbst — live (Supporter+): Healing-Richtlinien, Kapazitäts-Überwachung und die Verwaltung des gewünschten Zustands aus dem Dashboard.
- Der von kubehz gesteuerte Ein-Klick-Upgrade-Ablauf — wird schrittweise ausgerollt, hinter den obigen Pro-Funktion-Ausführungsschaltern.
Das Gate ist ein Abo, keine Änderung an der Registrierung: Ein managed-Cluster registriert sich und wird genauso beansprucht wie ein registered-Cluster. Das Abo-Gate greift, wenn ein Tenant Verwaltungsfunktionen steuert — die Plattform lehnt den Wechsel eines kostenlosen Tenants auf managed ab.
Nächste Schritte
- Wie es funktioniert — der verwaltete Tarif und die Vertrauensgrenze
- Registrierung — heute Versions- + Zustandssichtbarkeit erhalten
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | aktiv |
| Zuletzt geprüft | 2026-07-17 |