Upravljane nadgradnje

Paket managed je živ, nadgradnje z enim klikom prihajajo

Upravljane nadgradnje Kubernetesa tečejo prek paketa managed (access: managed), ki je v živo in zahteva naročnino Supporter ali višjo. Računi Enterprise ga vključujejo, prav tako vsaka gostovana kontrolna ravnina. Paket na vrh registered doda funkcije kubehz za upravljanje: politike samodejnega okrevanja, nadzor kapacitet in upravljanje želenega stanja z nadzorne plošče. Funkcije ukrepanja se uvajajo premišljeno prek stikal za posamezne funkcije, zato je funkcija lahko vidna na nadzorni plošči, še preden je njena izvedbena polovica vklopljena za posamezno uvedbo. Potek nadgradnje z enim klikom se še postopoma uvaja.

Danes potrebuješ nadgradnjo gostovanega clustra? Povej nam in jo izvedemo: v #support na chat.kubehz.cloud ali po e-pošti na contact@kubehz.io s clustrom in želeno različico. Ko bo stikalo za tvoje okolje vklopljeno, to nadomesti postopek z enim klikom.

Nadgrajuješ lastno gostovani cluster sam? To deluje kot vedno z orodjem za vzpostavitev lok8s (KubeOne/CAPI): povišaš različico v svoji specifikaciji in znova zaženeš orodje za vzpostavitev. To je operacija lok8s na tvojem lastnem clustru, neodvisna od kubehz. Glej dokumentacijo lok8s.

Model

Paket managed je os access: managed iz modela z dvema osema. Na clustru, za katerega si ga vklopil, funkcije kubehz za upravljanje poganjaš z nadzorne plošče: politike samodejnega okrevanja, nadzor kapacitet in upravljanje želenega stanja. Poteki nadgradenj in skaliranja tečejo prek tega šiva želenega stanja. Pri nadgradnji kubehz zabeleži želeno različico Kubernetesa. Kjer je stikalo za nadgradnjo vklopljeno, agent tvojega clustra proti njej premakne workerje:

• Različica je preverjena, preden se zabeleži. Brez znižanj, brez ciljev ob koncu življenjske dobe in brez preskakovanja manjše različice.
• Kontrolna ravnina gre prva, pri lastno gostovanem clustru pa je to tvoj del. Nadgradiš jo s svojim provisionerjem (lo provision / kubeone apply). Agent nato zavrne premikanje workerjev, dokler opažena različica kontrolne ravnine zaostaja za ciljem ali dokler je sploh ne more prebrati. Kontrolne ravnine se nikoli ne dotakne. (Pri gostovani kontrolni ravnini je ta naša; kako te nadgradnje danes potekajo, piše v opombi na vrhu te strani.)
• Nato en pool workerjev naenkrat. Agent nastavi ciljno različico kubeleta na MachineDeployment enega poola in počaka, da se ta krog konča, preden začne naslednjega. Workerji nikoli ne prehitijo kontrolne ravnine.
• Delo na vozliščih opravi tvoj machine-controller. kubehz spremeni eno polje na enem viru. Od tam machine-controller tvojega clustra zamenja stroje: izprazni vsako vozlišče in ustvari nadomestni strežnik v tvojem računu Hetzner, s poverilnicami, ki jih kubehz nikoli nima.
• Napredek je opažen, ne predpostavljen. Vsak pool sporoči v1.34.3 → v1.35.1 (2/5), prebrano iz objektov Machine v tvojem clustru.

Česa nadgradnja ne naredi

To je vredno povedati naravnost, ker upravljane ponudbe pogosto namigujejo drugače:

• Brez samodejne povrnitve. Če pool ne uspe, se nadgradnja ustavi: ta pool je sporočen kot neuspešen, pooli za njim ostanejo v čakalni vrsti, agent pa poskusi znova ob naslednjem pollu. Nič ni povrnjeno namesto tebe: zamenjano vozlišče je zamenjano. Naslednjo potezo določiš ti (in pomagamo, če vprašaš).
• Brez pregleda odstranjenih API-jev. kubehz ne bere tvojih delovnih obremenitev, zato te ne more opozoriti, da nekaj še kliče API, ki ga ciljna izdaja odstrani. To preverjanje opravi sam pred nadgradnjo.
• Brez preverjanja etcd ali pripravljenosti vozlišč. Zgornja primerjava različice kontrolne ravnine je edino predhodno preverjanje.
• Brez SSH in brez dostopa do vozlišč. Agent popravlja objekte Kubernetes v tvojem clustru in nič drugega: nima poverilnic za oblak, ključa SSH ali tvoje kubeconfig.

Mehanizem — vleka, ne potiskanje

Ukrepanje temelji na vleki. Znotrajclustrski agent želeno stanje prevzame s platforme (GET /clusters/{id}/desired) in ga uveljavi lokalno z lastnimi poverilnicami clustra. Platforma nikoli nima dohodne poverilnice in nikoli ne potiska v tvoj cluster.

Za lastno gostovani upravljani cluster to pomeni, da kubehz ne potrebuje Hetzner žetona: kubehz zabeleži želeno stanje, delo pa opravi machine-controller tvojega clustra s poverilnicami, ki jih že ima.

Izvedbena stikala po posameznih funkcijah varujejo izvedbeno polovico vsake upravljane funkcije, zato se funkcije ukrepanja uvajajo premišljeno: najprej vidljivost, ukrepanje pa, ko je stikalo za posamezno uvedbo vklopljeno.

Kaj je danes v živo

• V ŽIVO Poročanje o različici (katero različico poganja vsak registrirani cluster), prek agenta heartbeat; vidiš jo na nadzorni plošči.
• V ŽIVO Sam paket managed (Supporter+): politike samodejnega okrevanja, nadzor kapacitet in upravljanje želenega stanja z nadzorne plošče.
• V UVAJANJU Potek nadgradnje z enim klikom, ki ga poganja kubehz, prek zgoraj opisanih izvedbenih stikal.

Zapora je naročnina, ne sprememba registracije: cluster managed se registrira in prevzame natanko tako kot registered. Naročniška zapora velja, ko najemnik poganja funkcije za upravljanje: platforma preklop brezplačnega najemnika na managed zavrne.

Naslednji koraki

• Kako deluje: paket managed in meja zaupanja
• Registracija: pridobi vidljivost različice + zdravja že danes
• Cenik: paket Supporter, ki odklene funkcije za upravljanje

---

Status dokumenta

Vidik	Podrobnost
Stanje	Poročanje o različici in paket managed v živo; nadgradnje z enim klikom, ki jih poganja kubehz, v uvajanju
Zadnji pregled	2026-07-17