Kubernetes 1.37 iznāk 26. augustā, un divas izmaiņas šajā laidienā var apturēt mezglus, kuri līdz šim strādāja bez sūdzībām. Ja mezgls joprojām balstās uz containerd 1.x vai cgroup v1, kubelet uz jaunās versijas nemaz nestartēs. Mezgls kļūst NotReady, un podi no tā tiek izlikti. Pārbaude notiek pašā kubelet startā, bez brīdinājuma perioda.
Laidiena grafiks jau ir fiksēts. Koda iesaldēšana bija 22. jūlijā, pirmā laidiena kandidāte v1.37.0-rc.0 iznāca 5. augustā, un stabilā versija pienāk 26. augustā. Tas atstāj administratoriem dažas nedēļas, lai pārbaudītu mezglus un salabotu tos, kas neatbilst prasībām. Grafiku publicē Kubernetes laidiena komanda.
containerd 1.x vairs neder
Mezgls, kas izmanto containerd 1.x, uz 1.37 kubelet nedarbosies. Pirms jaunināšanas jāpāriet uz containerd 2.0 vai jaunāku. Kubernetes projekts izmaiņu grafiku saskaņoja ar containerd 1.7 atbalsta beigām, tāpēc administratoriem bija viss 1.36 cikls, lai migrāciju pabeigtu.
Pārbaude sākas ar containerd --version. Ja versija ir vecāka par 1.7.21, vispirms jāatjaunina uz to, un tikai tad jāpāriet uz 2.0. Pirms lielā lēciena der palaist ctr deprecations list — tas parāda, kas mezglā vēl izmanto novecojušus izsaukumus. Divas lietas noķer visbiežāk: CRI v1alpha2 saskarne ir izņemta, tāpēc rīki jāpārliek uz CRI v1, un vecie Docker Schema 1 attēli jāpārvērš uz Schema 2 vai OCI formātu.
cgroup v1 mezgli nepaceļ kubelet
Otrā izmaiņa skar vēl vairāk instalāciju. Karogs FailCgroupV1 pēc noklusējuma ir true kopš 1.35, bet 1.37 to sāk īsti piespiest. Mezgls, kas darbojas uz cgroup v1 un kuram kubelet konfigurācijā nav skaidra failCgroupV1: false apiešana, kubelet nepalaidīs vispār.
Vissmagāk cieš pašu uzturēti klasteri — dzelzs serveri, vecākas virtuālās mašīnas, viss, kas vēl balstās uz CentOS 7 laikmeta bāzi, kur cgroup v1 bija noklusējums. Jaunākās sistēmas šeit ir drošas: Ubuntu 22.04, RHEL 9 un Debian 12 pēc noklusējuma jau lieto cgroup v2.
Pārvaldītos klasteros situācija ir vieglāka, bet ne bezrūpīga. AWS EKS, GKE un līdzīgi pakalpojumi mezglu attēlus pārceļ uz cgroup v2 paši, tāpēc lielā daļa slodzes migrē līdz ar mezglu grupu jaunināšanu. Problēma paliek tur, kur komanda uztur savus mezglu attēlus vai izmanto vecākus pašbūvētus AMI. Tur neviens fonā neko nepārceļ, un 1.37 kubelet uz šāda mezgla apstāsies.
Pārbaudīt konkrētu mezglu var ar vienu komandu:
stat -fc %T /sys/fs/cgroup/— ja atbilde ircgroup2fs, mezgls ir gatavs; jatmpfs, tas vēl ir uz cgroup v1.
Ja mezglu līdz 26. augustam nesanāk pārcelt, kubelet konfigurācijā var uzstādīt failCgroupV1: false kā pagaidu risinājumu. Tas ļauj kubelet startēt uz cgroup v1, bet par to nākas maksāt.
Ar
failCgroupV1: falsetu atsakies no Memory QoS, PSI metrikām un swap atbalsta, līdz mezglu pārcel uz cgroup v2 pareizi.
Šīs funkcijas cgroup v1 vienkārši nepastāv, tāpēc apiešana atrisina startēšanu, nevis pašu problēmu. Memory QoS ļauj kodolam saudzīgāk apieties ar podiem, kas tuvojas atmiņas limitam, PSI metrikas rāda, cik ilgi procesi gaida uz CPU, atmiņu vai I/O, un swap atbalsts kubelet ir iespējams tikai uz cgroup v2. Uz cgroup v1 mezgla visas trīs paliek nepieejamas. Sarunu par cgroup v1 izņemšanu var izsekot Kubernetes enhancements repozitorijā, un tehniskās detaļas apraksta oficiālā cgroup v2 dokumentācija.
Noņemtais –cgroup-driver karogs
Trešā izmaiņa ir mazāka, bet klusa. Iespēja KubeletCgroupDriverFromCRI kļuva par GA jau 1.36, un līdz ar to atkritusi vecā --cgroup-driver karoga rezerve. Ja systemd vienībās vai konfigurācijas failos vēl kaut kur ir --cgroup-driver, tas jāizrevidē un jānoņem, pirms mezgls saņem 1.37 kubelet.
Ko darīt pirms 26. augusta
Praktiskā secība ir īsa:
- Uz staging klastera palaid
containerd --versionunstat -fc %T /sys/fs/cgroup/katram mezglu tipam. - Atjaunini containerd uz 2.0+, vispirms izejot cauri 1.7.21, un pārbaudi ar
ctr deprecations list. - Pārcel mezglu OS uz cgroup v2 bāzi vai apzināti uzstādi
failCgroupV1: falsear skaidru izpratni par zaudēto funkcionalitāti. - Izmet
--cgroup-driverno visām konfigurācijām. - Validē uz staging, tikai tad jaunini ražošanu.
Kas vēl jaunajā versijā
Ne visas izmaiņas ir sāpīgas. Dynamic Resource Allocation saņem Partitionable Devices (KEP-4815), kas ļauj sadalīt vienu GPU starp vairākiem podiem, izmantojot ResourceClaim objektus, nevis piešķirot podam veselu karti. Praksē tas nozīmē, ka NVIDIA MIG šķēles var izdalīt tieši caur Kubernetes, un vairāki darbi dala vienu fizisko GPU. Komandām, kas rēķina AI slodzes uz dārgām kartēm, tas maina, cik daudz darba iespiežas vienā mezglā.
Detalizētu izmaiņu sarakstu un atbalsta grafiku uztur VersionLog. Taču pēc 26. augusta izšķirīgā daļa ir vienkārša: mezgls ar containerd 1.x vai cgroup v1 vairs neceļas augšā.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.