Beheerde upgrades
Managed-tier live, één-klik-upgrades in uitrol
Beheerde Kubernetes-upgrades draaien op de managed-tier (access: managed), die live is en een Supporter-abonnement of hoger vereist. Enterprise-accounts hebben die inbegrepen, en elk gehost control plane ook. 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.
Moet je vandaag een gehost cluster upgraden? Zeg het even, dan doen wij het: in #support op chat.kubehz.cloud of per e-mail naar contact@kubehz.io met het cluster en de gewenste versie. De één-klik-flow vervangt dit zodra de schakelaar voor jouw omgeving aanstaat.
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. Waar de upgrade-schakelaar aanstaat, beweegt de agent van je cluster de workers ernaartoe:
- De versie wordt gecontroleerd voordat die wordt vastgelegd. Geen downgrades, geen end-of-life-doelen en geen minor-versie overslaan.
- Het control plane gaat eerst, en op een self-hosted cluster is dat jouw deel. Je upgradet het met je eigen provisioner (
lo provision/kubeone apply). De agent weigert daarna workers te verplaatsen zolang de waargenomen control-plane-versie nog achterloopt op het doel, of zolang hij die versie helemaal niet kan lezen. Het control plane zelf raakt hij nooit aan. (Bij een gehost control plane is dat van ons; zie de notitie boven aan deze pagina voor hoe die upgrades vandaag lopen.) - Daarna één workerpool tegelijk. De agent zet de doel-kubeletversie op het MachineDeployment van één pool en wacht tot die ronde klaar is voordat hij de volgende start. Workers lopen nooit vooruit op het control plane.
- Het nodewerk doet jouw machine-controller. kubehz wijzigt één veld op één resource. Vanaf daar vervangt de eigen machine-controller van je cluster de machines: hij draint elke node en maakt de vervangende server in je Hetzner-account, met credentials die kubehz nooit heeft.
- Voortgang wordt waargenomen, niet aangenomen. Elke pool rapporteert
v1.34.3 → v1.35.1 (2/5)terug, gelezen uit de Machine-objecten in je cluster.
Wat een upgrade niet doet
Dat mag ronduit gezegd worden, want managed-aanbiedingen suggereren vaak iets anders:
- Geen automatische rollback. Mislukt een pool, dan stopt de upgrade: die pool wordt als mislukt gerapporteerd, de pools erachter blijven in de wachtrij en de agent probeert het bij de volgende poll opnieuw. Er wordt niets voor je teruggedraaid: een vervangen node is vervangen. De volgende stap bepaal jij (en we helpen als je het vraagt).
- Geen scan op verwijderde API’s. kubehz leest je workloads niet en kan je dus niet waarschuwen dat iets nog een API aanroept die je doelrelease laat vallen. Die controle doe je zelf vóór de upgrade.
- Geen etcd- of node-gereedheidsgate. De control-plane-versievergelijking hierboven is de enige pre-check.
- Geen SSH en geen nodetoegang. De agent patcht Kubernetes-objecten in je cluster en verder niets: hij heeft geen cloudcredentials, geen SSH-sleutel en geen kubeconfig van jou.
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
- LIVE Versierapportage (welke versie elk geregistreerd cluster draait), via de heartbeat-agent; je ziet het in het dashboard.
- LIVE De managed-tier zelf (Supporter+): healing-beleid, capaciteitsbewaking en beheer van de gewenste staat vanuit het dashboard.
- IN UITROL De door kubehz aangestuurde one-click-upgradeflow, 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
- Prijzen: de Supporter-tier die de beheerfuncties ontgrendelt
Documentstatus
| Aspect | Detail |
|---|---|
| Status | Versierapportage en de managed-tier live; door kubehz aangestuurde one-click-upgrades in uitrol |
| Laatst gecontroleerd | 2026-07-17 |