Beheerde upgrades
Onderdeel van de managed-tier — vandaag live
Beheerde Kubernetes-upgrades draaien op de managed-tier (access: managed), die live is en een Supporter-abonnement of hoger vereist (gehoste en enterprise-tenants hebben die inbegrepen). De tier voegt bovenop registered de beheerfuncties van kubehz toe — healing-beleid, capaciteitsbewaking en beheer van de gewenste staat, aangestuurd vanuit het dashboard. Handelende functies worden stapsgewijs uitgerold achter schakelaars per functie, dus een functie kan al in het dashboard zichtbaar zijn voordat het handelende deel voor een deployment is ingeschakeld — de one-click-upgradeflow wordt nog stapsgewijs uitgerold.
Zelf een self-hosted cluster upgraden? Dat werkt zoals altijd met de lok8s-provisioner (KubeOne/CAPI): verhoog de versie in je spec en voer de provisioner opnieuw uit. Dat is een lok8s-operatie op je eigen cluster, onafhankelijk van kubehz — zie de lok8s-documentatie.
Het model
De managed-tier is de as access: managed van het tweeassenmodel. Op een cluster waarvoor je die hebt ingeschakeld, worden de beheerfuncties van kubehz aangestuurd vanuit het dashboard: healing-beleid, capaciteitsbewaking en beheer van de gewenste staat — upgrade- en schalingsflows draaien op die gewenste-staat-naad. Voor een upgrade legt kubehz de gewenste Kubernetes-versie vast en voert jouw cluster (of een gehost control plane) die uit:
- eerst het control plane, daarna worden workers één voor één gecordond, gedraind en geüpgraded,
- version-skew-regels afgedwongen (geen minor-versies overslaan),
- pre-checks voor verwijderde API's, node-gereedheid en etcd-gezondheid,
- automatische rollback als een upgrade halverwege mislukt.
Het mechanisme — pull, geen push
Handelen is pull-gebaseerd. De in-cluster agent haalt de gewenste staat op bij het platform (GET /clusters/{id}/desired) en past die lokaal toe met de eigen credentials van het cluster. Het platform heeft nooit een inkomende credential en pusht nooit je cluster in.
Voor een self-hosted managed cluster betekent dit dat kubehz geen Hetzner-token nodig heeft: kubehz legt de gewenste staat vast en de eigen machine-controller van je cluster doet het werk met credentials die het al heeft.
Uitvoeringsschakelaars per functie bewaken het handelende deel van elke managed-functie, zodat handelende functies stapsgewijs worden uitgerold — eerst zichtbaarheid, handelen zodra de schakelaar voor een deployment aan staat.
Wat vandaag live is
- Versierapportage (welke versie elk geregistreerd cluster draait) — live via de heartbeat-agent; je ziet het in het dashboard.
- De managed-tier zelf — live (Supporter+): healing-beleid, capaciteitsbewaking en beheer van de gewenste staat vanuit het dashboard.
- De door kubehz aangestuurde one-click-upgradeflow — wordt stapsgewijs uitgerold achter de bovengenoemde uitvoeringsschakelaars per functie.
De poort is een abonnement, geen wijziging in de registratie: een managed cluster registreert en wordt geclaimd precies zoals een registered cluster. De tier-poort geldt zodra een tenant beheerfuncties aanstuurt — het platform weigert de overstap naar managed van een gratis tenant.
Volgende stappen
- Hoe het werkt — de managed-tier en de vertrouwensgrens
- Registratie — krijg vandaag versie- + gezondheidszichtbaarheid
Documentstatus
| Aspect | Detail |
|---|---|
| Status | actief |
| Laatst gecontroleerd | 2026-07-17 |