Verwaltete Upgrades
Verwalteter Tarif live, Ein-Klick-Upgrades im Rollout
Verwaltete Kubernetes-Upgrades laufen über den verwalteten Tarif (access: managed), der live ist und ein Supporter-Abo oder höher erfordert. Enterprise-Konten enthalten ihn, und jede gehostete Control Plane ebenfalls. 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 gehosteten Cluster heute upgraden? Sag Bescheid, wir machen es für dich: in #support auf chat.kubehz.cloud oder per E-Mail an contact@kubehz.io mit Cluster und gewünschter Version. Der Ein-Klick-Ablauf ersetzt das, sobald der Schalter für deine Umgebung an ist.
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. Wo der Upgrade-Schalter an ist, bewegt der Agent deines Clusters die Worker darauf zu:
- Die Version wird geprüft, bevor sie festgehalten wird. Kein Downgrade, kein End-of-Life-Ziel und kein Überspringen einer Minor-Version.
- Die Control Plane kommt zuerst, und bei einem Self-Hosted-Cluster ist das dein Teil. Du aktualisierst sie mit deinem eigenen Provisioner (
lo provision/kubeone apply). Der Agent weigert sich danach, Worker zu bewegen, solange die beobachtete Control-Plane-Version noch hinter dem Ziel liegt, oder solange er sie überhaupt nicht lesen kann. Die Control Plane selbst rührt er nie an. (Bei einer gehosteten Control Plane gehört sie uns; wie diese Upgrades heute laufen, steht im Hinweis oben auf dieser Seite.) - Danach ein Worker-Pool nach dem anderen. Der Agent setzt die Ziel-Kubelet- Version auf dem MachineDeployment eines Pools und wartet, bis dieser Durchlauf fertig ist, bevor er den nächsten startet. Worker überholen die Control Plane nie.
- Die Node-Arbeit macht dein Machine-Controller. kubehz ändert ein Feld an einer Ressource. Ab da ersetzt der eigene Machine-Controller deines Clusters die Maschinen: Er leert jeden Node und erstellt den Ersatzserver in deinem Hetzner-Konto, mit Zugangsdaten, die kubehz nie besitzt.
- Fortschritt wird beobachtet, nicht angenommen. Jeder Pool meldet
v1.34.3 → v1.35.1 (2/5)zurück, gelesen aus den Machine-Objekten in deinem Cluster.
Was ein Upgrade nicht tut
Das gehört klar gesagt, weil verwaltete Angebote oft anderes suggerieren:
- Kein automatisches Rollback. Scheitert ein Pool, stoppt das Upgrade: dieser Pool wird als fehlgeschlagen gemeldet, die dahinterliegenden Pools bleiben in der Warteschlange, und der Agent versucht es beim nächsten Poll erneut. Nichts wird für dich zurückgerollt: Ein ersetzter Node ist ersetzt. Den nächsten Schritt entscheidest du (und wir helfen, wenn du fragst).
- Keine Prüfung auf entfernte APIs. kubehz liest deine Workloads nicht und kann dich deshalb nicht warnen, dass etwas noch eine API aufruft, die dein Zielrelease streicht. Diese Prüfung machst du selbst vor dem Upgrade.
- Keine etcd- oder Node-Bereitschaftsprüfung. Der oben beschriebene Control-Plane-Versionsvergleich ist die einzige Vorabprüfung.
- Kein SSH und kein Node-Zugriff. Der Agent patcht Kubernetes-Objekte in deinem Cluster und sonst nichts: Er hält keine Cloud-Zugangsdaten, keinen SSH-Key und keine kubeconfig von dir.
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
- LIVE Versionsmeldung (welche Version jeder registrierte Cluster ausführt), über den Heartbeat-Agenten; du siehst es im Dashboard.
- LIVE Der verwaltete Tarif selbst (Supporter+): Healing-Richtlinien, Kapazitäts-Überwachung und die Verwaltung des gewünschten Zustands aus dem Dashboard.
- IM ROLLOUT Der von kubehz gesteuerte Ein-Klick-Upgrade-Ablauf, 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
- Preise: der Supporter-Tarif, der die Verwaltungsfunktionen freischaltet
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | Versionsmeldung und der verwaltete Tarif live; von kubehz gesteuerte Ein-Klick-Upgrades im Rollout |
| Zuletzt geprüft | 2026-07-17 |