Kubernetes LTS - 12 évnyi támogatást jelentett be az Ubuntu a Kubernetes 1.32-től kezdve

Címkék

Az Ubuntu bejelentette Kubernetes LTS kezdeményezését, aminek keretében 12 évnyi biztonsági karbantartási támogatást és enterprise supportot kínál a Kubernetes csomagjaihoz és a kapcsolódó ökoszisztéma konténer image-ekhez. A támogatás a Kubernetes 1.32-től kezdve indul és bare metal-on, public cloud-ok, OpenStack-en, Canonical MicroCloud-on és VMware-en értelmezhető.

Részletek bejelentésben.

Hozzászólások

Ha jól értem a cikk megfogalmazását, akkor pont a Kubernetes az a szoftver, ahol nincs értelme az LTS-nek! A deprecation periodok nagyon hosszúak, bőven van idő frissíteni az elavult API verziókat vagy a kivezetett régi RD-ket.

A Kubernetes a dinamizmusról, a folyamatos fejlődésről szól.

A cikkben említett supportot el lehet adni bankoknak és egyéb olyan cégeknek, ahol a változás és a fejlődés szitokszó,  csak 5-10 év után upgradelünk,  mert így mehet a napi 2 ticket és ki lehet játszani  "nélkülözhetetlen" kártyát... Aztán csodálkozunk,  miért tartanak ott ezek a cégek, ahol. DE lehúzásnak tökéletes a nagy multiktól.

A cikkben említett supportot el lehet adni bankoknak és egyéb olyan cégeknek, ahol a változás és a fejlődés szitokszó,  csak 5-10 év után upgradelünk,

Isten hozott a vállalati világban! Aki körül csak webalkalmazások, webszerverek meg public cloud-izék léteznek, az hajlamos mindent annak látni.

trey @ gépház

Aki körül csak webalkalmazások, webszerverek meg public cloud-izék léteznek, az hajlamos mindent annak látni.

Ezt senki sehol nem írta és fogalmam sincs miért kellett ide keverni. Erről itt szó sem volt.

Itt arról van szó, hogy a Kubernetes, mint szoftver egy éves támogatási verzióval rendelkezik (Egy minor verzió kb. egy évig támogatott). A deprecation period meg átível több verzión, tehát van idő felzárkózni. Mivel a szoftver folyamatosan bővül, fejlődik és tapasztalatom alapján a stabil verziók  elég stabilak, breaking change nem nagyon volt benne, ezért nem látom értelmét az LTS támogatásnak jelenleg semmilyen szinten. Sok hasznos, szükséges új dolog kerül bele, amire szükség van. Még sok idő telhet el mire, azt lehet mondani, hogy a Kubernetes, mint szoftver megérett az LTS támogatásra.

Nem mindenütt életszerű véresszájú legújabb dolgokkal játszani, vagy valakinek a pillanatnyi kedvétől függően frissítést kikényszeríteni. 

Van ahol elég az, hogy ami működik, azt nem basztatják folyton. Hanem a biztonsági frissítéseket teszik fel. Nekik ez nem szórakozás, hanem szükséges rossz. Nem a clusterezés játéka miatt csinálják, hanem csak eszköz a szolgáltatás futásához.

Plusz komolyabb szoftvereknál a támogatás sem úgy megy, hogy véresszájú verziós bétára tegyenek valamit, hanem kiforrott verziókkal garantálják az együttműködést.

Az meg, hogy meddig szokott visszafelé kompatibilitás lenni, na az önmagában semmi. Az, ha szerződésben is vállalják, az valami.

Van ilyen eset. A Kubernetes pont nem tart még itt.

Egy Red Hat Linux egy adott vassal együtt támogatható, mert egyik sem változik jelentősen. Nem lesz breaking hw változás, amit az arra, kb. vele egy időben kiadott Red Hat Linux (vagy akármelyik más OS). Viszont a hw és a szoftver így együtt avul el és egyszerre lesz költség a cseréje.

Szó sincs arról, a Kubernetesből bétát kéne bárhova is feltenni. Sehol nem használunk beta-t, a stable ág minden clusteren up-to-date.

A Kubernetesen futtatott szoftverek is csak néhány minor verzió-t támogatnak hivatalosan visszafelé, ezért sem érdemes túlságosan lemaradni. Ha már lemaradás, az upgrade nem ajánlott sehol sem több minor verzión direkt, vagyis át kell mennie az upgrade-nek minden köztes minor verzión is vagy mehet nulláról az új cluster és lehet migrálni mindent a vállalati gondolkodás mentén.

Pontosan. A Kubernetes az egy nagy okoszisztema rengeteg alkalmazassal.

Hiaba fagyasszuk be a K8s verziot LTS modon, ha az upstream vilag meg halad elore. 10 ev mulva honnan fogunk szerezni 1.32-eshez valo CNI/CSI-t, Prometheust, Helm-et, Jaegert, Cert-managert, neadjisten Istio-t? Ha megorizzuk a mindenkori verziot mindenbol, akkor az ujabb alkalmazasok helm chartjai nem lesznek kompatibilisek a 10 eves API verziokkal.

Szoval ha vki felul a Kubernetes vonatra, akkor muszaj haladni elore egyutt mindennel...

Ha ubuntunak azokból is van csomagja, akkor ugyanonnan, ahonnan a k8s lts-t.

Van ahol nem azért deployolnak folyton, hogy az eszközök öncélú frissítés miatti frissítés miatti frissítés miatti frissítéseit kiszolgálják, hanem az üzleti logika kiszolgálására szolgál az infrastruktúra. Általában nem kellenek új featurek, de biztonsági frissítések igen. Nem mindenki startup, aki látványosan folyton mindenen változtatni akar. Na ők azok, akik LTS-t használnak.

A managerek megkérdik, hogy a rendszer feature képesség frissítései mit is adnak hozzá az alkalmazás képességeihez? Semmit? Akkor kidobott pénz az öncélú verziólépegetés, ami ráadásul kockázatokkal is jár.

Feltételezem, a Canonical azért csinálja ezt, mert pénzt akar keresni. Akár az is lehet, hogy van valami tervük erre a problémára.

Szerintem megvan ennek a létjogosultsága amúgy. Már csak abból kiindulva, hogy a 12 éves támogatási ciklussal jó eséllyel nemcsak az adott tevékenységet élheti túl a K8s, hanem magát a céget is.

mi a helyzete akkor ha a meglevo melle egy masik cuccot is akarnak futtatni? de annak mar nemjo a regi kubi verzio? csinalnak egy ujabb clustert egy kevesbe elavult verzioval? es ha jon egy harmadik igeny? annak is uj cluster?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ilyen helyeken nem úgy megy a dolog, hogy random dolokat össze-vissza futtatgassanak egymás mellett. Attól függően, hogy milyen adatokkal dolgoznak, akár jogszabályi követelmény is lehet a szeparáció. Ha meg kifejezetten egy rendszeren kell futniuk, akkor a specifikáció része a kompatibilitás.
Auditnál viszont kell a garancia, hogy van és lesz biztonsái frissítés, támogatás. Ebből él jópár cég, akik előfizetős támogatást nyújtanak, mégha amúgy elvileg ingyen is letölthető és használható a cuccuk.