Kubernetes yra atvirojo kodo, o savo klasterio eksploatavimas yra visiškai pagrįstas pasirinkimas. Verta realiai išnagrinėti, ko produkcinis klasteris iš jūsų reikalauja nuolat — remiantis paties Kubernetes projekto dokumentacija ir leidimų politika, o ne rinkodaros teiginiais.
Kiekviena Kubernetes versija turi galiojimo pabaigą
Kubernetes projektas prižiūri leidimų šakas trims naujausioms mažosioms versijoms. Kiekviena mažoji versija gauna maždaug keturiolika mėnesių pataisų palaikymo: dvylika mėnesių standartinio palaikymo, tada dviejų mėnesių priežiūros laikotarpį, po kurio serija pasiekia gyvavimo pabaigą ir nebegauna pataisų.
2026 m. rugsėjį aktyviai prižiūrimos mažosios versijos yra 1.37, 1.36 ir 1.35. Versija 1.34 yra paskutiniame priežiūros lange ir gyvavimo pabaigą pasieks 2026 m. spalio 27 d. Versija 1.33 gyvavimo pabaigą jau pasiekė 2026 m. birželio 28 d.
Atsilikti brangu, nes atnaujinimuose negalima praleisti mažųjų versijų. Versijų suderinamumo politika reikalauja, kad kube-apiserver judėtų po vieną mažąją versiją, net ir vieno egzemplioriaus klasteriuose. Todėl klasteriui, vis dar veikiančiam su 1.33, reikia keturių nuoseklių valdymo plokštumos atnaujinimų — 1.34, 1.35, 1.36 ir 1.37 — kad taptų naujausias, o kiekvienam jų reikia savo pasirengimo, pavyzdžiui, patikrinti, ar jūsų priėmimo webhook’ai gali apdoroti API versijas, kurias jiems siunčia naujasis serveris.
Mazgai prideda savo darbo. Vietinis mažosios versijos kubelet atnaujinimas nepalaikomas: kiekvieną mazgą pirmiausia reikia ištuštinti (drain). Kubelet gali atsilikti nuo API serverio iki trijų mažųjų versijų, tačiau dokumentacija įspėja, kad klasteris, kurio kubelet nuolat atsilieka trimis versijomis, juos turi atnaujinti dar prieš tai, kai apskritai galima judinti valdymo plokštumą.
Aukštas pasiekiamumas yra architektūra, už kurią atsakote jūs
Vienas valdymo plokštumos mazgas yra vienas gedimo taškas. kubeadm aukšto pasiekiamumo vadove aprašytos dvi topologijos. Numatytojoje sukrautoje topologijoje kiekvienas valdymo plokštumos mazgas vykdo ir etcd narį, todėl praradus vieną mazgą prarandamas ir valdymo plokštumos egzempliorius, ir etcd narys; dokumentacija nurodo naudoti bent tris sukrautus valdymo plokštumos mazgus. Alternatyva, išorinis etcd, juos atskiria, bet reikalauja mažiausiai trijų valdymo plokštumos ir trijų etcd serverių.
etcd reikia kvorumo — daugumos savo narių — kad priimtų pakeitimus. Trijų narių klasteris toleruoja vieno nario gedimą, o penkių narių — dviejų, o ketvirto nario pridėjimas papildomo atsparumo gedimams neduoda. Kubernetes dokumentacija rekomenduoja nelyginį narių skaičių ir penkių narių klasterį produkcijai.
etcd taip pat jautrus aplinkai, kurioje veikia:
- Diskas ir tinklas. etcd našumas priklauso nuo disko ir tinklo I/O. Išteklių trūkumas gali sukelti heartbeat laiko limito viršijimą ir palikti klasterį be lyderio — o klasteris be lyderio negali keisti būsenos, todėl negalima suplanuoti naujų podų.
- Dedikuoti ištekliai. Dokumentacija pataria etcd vykdyti dedikuotose mašinose arba izoliuotose aplinkose, kad jo išteklių poreikiai būtų garantuoti, o pats etcd DUK labai rekomenduoja SSD.
- Prieiga prilygsta root. Prieiga prie etcd prilygsta root teisėms klasteryje, todėl idealiu atveju ją turėtų tik API serveris, apsaugotas x509 TLS sertifikatais.
Atsarginė kopija ką nors reiškia tik tada, kai iš jos atkūrėte
Kubernetes dokumentacija kalba tiesiai: jei jūsų klasteris naudoja etcd kaip pagrindinę saugyklą, pasirūpinkite duomenų atsarginių kopijų planu. Praktiškai tai reiškia suplanuotas momentines kopijas su etcdctl, saugomas vietoje, kuri nesidalija gedimo domeno su klasteriu, ir atkūrimo procedūrą su etcdutl, kurią kas nors iš tikrųjų yra repetavęs.
Momentinėms kopijoms taip pat reikia atsargaus elgesio, nes jose yra viskas, ką žino API serveris. Pagal numatytuosius nustatymus API serveris išteklius saugo etcd kaip paprastą tekstą, be šifravimo saugojimo metu, kol jo nesukonfigūruojate. Todėl nešifruoto klasterio momentinė kopija gali išnešti kartu ir jūsų Secrets.
Sertifikatai baigia galioti pagal tvarkaraštį
kubeadm sugeneruoti kliento sertifikatai baigia galioti po vienų metų. kubeadm juos atnaujina automatiškai, kai atnaujinate valdymo plokštumą, todėl bent kartą per metus atnaujinamas klasteris yra prižiūrimas — o klasteris, kuris daugiau nei metus lieka be atnaujinimo, ne. Galiojimą galite patikrinti su kubeadm certs check-expiration, o atnaujinti rankiniu būdu su kubeadm certs renew all, kurią replikuotoje valdymo plokštumoje reikia vykdyti kiekviename valdymo plokštumos mazge.
Papildiniai yra atskiri projektai su atskirais gyvavimo ciklais
Klasteris yra daugiau nei jo valdymo plokštuma. Tinklas, ingress ar Gateway API, saugyklos tvarkyklės, sertifikatų valdymas, metrikos ir stebėsena yra atskiri projektai, kiekvienas su savo leidimų ciklu, versijomis ir gyvavimo pabaigos datomis. Savarankiškai talpinamame klasteryje visų jų sekimas yra jūsų darbas.
2025 m. lapkritį Kubernetes projektas paskelbė nutraukiantis Ingress NGINX, vieną plačiausiai naudojamų ingress valdiklių. Geriausių pastangų principu teikta priežiūra baigėsi 2026 m. kovą: nebebus naujų versijų, klaidų taisymų ar saugumo atnaujinimų. Esami diegimai toliau veikia, o artefaktai lieka prieinami, tačiau vėliau atrastos pažeidžiamumo spragos nebus taisomos. 2026 m. sausį Kubernetes Steering ir Security Response komitetai jį apibūdino kaip kritinę infrastruktūrą maždaug pusei debesų (cloud native) aplinkų ir paragino pereiti prie Gateway API arba kito valdiklio.
Projekto migracijos vadove pridedamas įspėjimas: Ingress NGINX turi numanomų elgsenų, o vertimas, kuris atrodo teisingas, vis tiek gali sukelti sutrikimų. Nė vienas iš šių dalykų nėra Kubernetes trūkumas. Tai įprastas didelės atvirojo kodo ekosistemos gyvenimas — ir būtent tas darbas, kurį savarankiškai talpinamas klasteris užkrauna jūsų komandai.
Palyginimas greta
| Kategorija | Savarankiškai talpinama | Kube-DC valdomas klasteris |
|---|---|---|
| Versijų gyvavimo ciklas | Jūs sekate leidimų ir gyvavimo pabaigos datas ir atnaujinate po vieną mažąją versiją, su maždaug keturiolika mėnesių palaikymo kiekvienai mažajai versijai | Etapiniai, nuomininko valdomi atnaujinimai: valdymo plokštuma ir worker telkiniai juda atskirai, etapais. Tikslinę versiją ir laiką vis tiek pasirenkate jūs |
| Valdymo plokštuma | Trys ar daugiau valdymo plokštumos mazgų, kuriuos turite suprojektuoti, apsaugoti ir taisyti patys | Talpinamos valdymo plokštumos veikia kaip valdomi podai platformoje: gaunate savo Kubernetes API ir kiekvienam klasteriui skirtą PKI, neeksploatuodami master mazgų |
| etcd | Kvorumo dydžio parinkimas, dedikuoti diskai, TLS, defragmentavimas ir stebėsena yra jūsų | Dedikuota arba bendra platformos valdoma duomenų saugykla, su valdymo plokštumos ir etcd vertikaliuoju automatiniu masteliavimu, įjungtu pagal numatytuosius nustatymus |
| Atsarginės kopijos | Jūs projektuojate momentinių kopijų tvarkaraštį, saugyklą ir atkūrimo pratybas | Suplanuotos etcd momentinės kopijos, konfigūruojamos kiekvienam klasteriui, su pasirenkamu voko šifravimu, ir atkūrimas — savitarna vieno replikos duomenų saugykloms, padedant mūsų komandai kelių replikų atveju. Momentinės kopijos saugomos projekto S3 saugykloje platformoje, todėl jei reikia kopijos už platformos saugyklos gedimo domeno ribų, pasilikite savo kopiją už platformos ribų |
| Sertifikatai | Vienerių metų kubeadm sertifikatai, atnaujinami atnaujinant klasterį arba jūsų | Kiekvieno klasterio PKI ir etcd TLS sertifikatai išduodami automatiškai kartu su klasteriu |
| Worker mazgai | Jūs paruošiate, sukuriate atvaizdą, taisote ir keičiate mazgus | Worker telkiniai, dydis nustatomas kiekvienam telkiniui (CPU, atmintis, diskas, atvaizdas), su automatinio masteliavimo ribomis kiekvienam telkiniui |
| Metrikų API | Jūs įdiegiate ir prižiūrite metrics-server | Iš anksto įdiegtas ir veikė mūsų pačių 2026 m. rugpjūčio pilname bandyme |
| Laikas iki pirmojo klasterio | Kelios valandos ar dienos paruošimo, plius nuolatinė priežiūra | Sukuriamas iš projekto portale arba su vienu manifestu; platformos dokumentacija aprašo paruošimą per kelias minutes |
| Budėjimas | Jūsų komanda | 24/7 pagalba el. paštu ir per užklausas su 4 valandų sprendimo tikslu (MTTR), įskaičiuota į kainą |
| Kas lieka jūsų | Viskas, nuo aparatūros iki darbo krūvių | Jūsų darbo krūviai, prieigos kontrolė ir papildiniai, kuriuos įdiegiate savo klasteryje — tai pilnas, nuomininko valdomas Kubernetes klasteris |
Kada savarankiškas talpinimas yra teisingas pasirinkimas
Jei jūsų komanda jau eksploatuoja etcd produkcijoje, seka Kubernetes ir papildinių leidimų pastabas, repetuoja atkūrimus ir turi budėjimo aprėptį, savarankiškas talpinimas yra pagrįstas esamos praktikos tęsinys. Tai taip pat tinkamas pasirinkimas, kai reikia kontrolės, kurios valdoma paslauga suteikti negali, pavyzdžiui, pasirinktinės valdymo plokštumos konfigūracijos ar visiškai izoliuotos aplinkos. Komandai, kuri tokio gebėjimo dar neturi, kiekviena aukščiau aprašyta dalis tampa naujų, nuolatinių darbų našta.
Šaltiniai
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Susipažinkite su platforma
Cloud Acropolis Kube-DC suteikia jums savo nuomininko valdomus Kubernetes klasterius — talpinamas valdymo plokštumas, worker telkinius ir etapinius atnaujinimus — su dedikuotais vCPU, Ceph pagrįsta NVMe saugykla, dedikuotu viešuoju IPv4 ir su S3 suderinama objektų saugykla. Viską užsakote ir valdote savitarnos portale, o 24/7 pagalba el. paštu ir per užklausas bei 4 valandų sprendimo tikslas įskaičiuoti. Kiekvienas paketas apima įdėtuosius Kubernetes klasterius, o bendrai naudojamas GPU prieinamas kaip pasirinktinė papildoma galimybė.
Susipažinkite su Kube-DC Kubernetes