🥇Kubernetes 1.16: pagrindinių naujovių apžvalga

Šiandien, trečiadienį, vyks Kitas Kubernetes leidimas - 1.16. Pagal mūsų tinklaraščiui susiklosčiusią tradiciją, tai jau dešimtmetis, kai kalbame apie reikšmingiausius naujosios versijos pokyčius.

Informacija, naudota ruošiant šią medžiagą, paimta iš Kubernetes patobulinimų stebėjimo lentelės, PAKEITIMAS-1.16 ir susijusias problemas, ištraukimo užklausas ir Kubernetes patobulinimo pasiūlymus (KEP). Taigi, eime!..

Mazgai

Išties daug pastebimų naujovių (alfa versijos būsenoje) pristatoma K8s klasterio mazgų (Kubelet) šone.

Pirma, vadinamasis «trumpalaikiai konteineriai» (Efemeriniai konteineriai), skirtas supaprastinti derinimo procesus ankštyse. Naujasis mechanizmas leidžia paleisti specialius konteinerius, kurie prasideda esamų podų vardų erdvėje ir gyvena trumpai. Jų tikslas yra sąveikauti su kitais ankštimis ir konteineriais, siekiant išspręsti visas problemas ir derinti. Šiai funkcijai įdiegta nauja komanda kubectl debug, savo esme panašus į kubectl exec: tik vietoj proceso vykdymo konteineryje (kaip nurodyta exec) jis paleidžia konteinerį ankštyje. Pavyzdžiui, ši komanda sujungs naują konteinerį prie podelio:

kubectl debug -c debug-shell --image=debian target-pod -- bash

Išsamią informaciją apie efemerinius konteinerius (ir jų naudojimo pavyzdžius) rasite atitinkamas KEP. Dabartinis diegimas (K8s 1.16) yra alfa versija, o vienas iš kriterijų, kad jis būtų perkeltas į beta versiją, yra „išbandyti Ephemeral Containers API bent 2 [Kubernetes] leidimuose“.

NB: Savo esme ir net pavadinimu ši funkcija primena jau esamą įskiepį kubectl-debugapie kuriuos mes jau rašė. Tikimasi, kad atsiradus trumpalaikiams konteineriams atskiro išorinio įskiepio kūrimas nutrūks.

Dar viena naujovė - PodOverhead - skirtas teikti ankščių pridėtinių išlaidų apskaičiavimo mechanizmas, kuris gali labai skirtis priklausomai nuo naudojamo vykdymo laiko. Pavyzdžiui, autoriai šis KEP rezultatas yra Kata konteineriai, kuriems reikia paleisti svečio branduolį, kata agentą, inicijavimo sistemą ir kt. Kai pridėtinės išlaidos tampa tokios didelės, jų negalima ignoruoti, o tai reiškia, kad reikia atsižvelgti į jas tolimesnėms kvotoms, planavimui ir pan. Norėdami tai įgyvendinti PodSpec pridėtas laukas Overhead *ResourceList (palyginti su duomenimis RuntimeClass, jei toks naudojamas).

Dar viena pastebima naujovė yra mazgo topologijos tvarkyklė (mazgo topologijos tvarkyklė), skirtas suvienodinti požiūrį į aparatinės įrangos išteklių paskirstymą įvairiems Kubernetes komponentams. Šią iniciatyvą skatina didėjantis įvairių modernių sistemų (telekomunikacijų, mašininio mokymosi, finansinių paslaugų ir kt.) poreikis didelio našumo lygiagrečiam skaičiavimui ir iki minimumo sumažinti operacijų vykdymo vėlavimus, kurioms jos naudoja pažangų CPU ir aparatinės įrangos spartinimo galimybės. Tokie „Kubernetes“ optimizavimai iki šiol buvo pasiekti dėl skirtingų komponentų (procesoriaus tvarkyklės, įrenginių tvarkyklės, CNI), o dabar jiems bus pridėta viena vidinė sąsaja, kuri suvienodins požiūrį ir supaprastins naujų panašių - vadinamųjų topologijos - prijungimą. žino - komponentai Kubelet pusėje. Išsami informacija – in atitinkamas KEP.

Topologijos tvarkyklės komponentų diagrama

Kita funkcija - tikrinti konteinerius jiems veikiant (paleidimo zondas). Kaip žinote, konteineriams, kurių paleidimas užtrunka, sunku gauti naujausią būseną: jie arba „nužudomi“ nepradėję realiai funkcionuoti, arba ilgam atsiduria aklavietėje. Naujas patikrinimas (įjungtas per iškviestą funkcijų vartus StartupProbeEnabled) atšaukia – tiksliau, atideda – bet kokių kitų patikrinimų poveikį iki to momento, kai podukas baigs veikti. Dėl šios priežasties ši funkcija iš pradžių buvo vadinama pod-startup gyvumas-zondas holdoff. Ankštyse, kurių paleidimas trunka ilgai, galite apklausti būseną per palyginti trumpus laiko intervalus.

Be to, „RuntimeClass“ patobulinimas iš karto pasiekiamas beta versijos būsenoje, pridedant „heterogeninių grupių“ palaikymą. C RuntimeClass planavimas Dabar visai nebūtina, kad kiekvienas mazgas palaikytų kiekvieną RuntimeClass: podams galite pasirinkti RuntimeClass negalvodami apie klasterio topologiją. Anksčiau, norint tai pasiekti – kad ankštys patektų į mazgus, palaikančius viską, ko jiems reikia – reikėjo priskirti atitinkamas taisykles NodeSelector ir tolerancijas. IN KEP Jame kalbama apie naudojimo pavyzdžius ir, žinoma, įgyvendinimo detales.

Tinklas

Dvi svarbios tinklo funkcijos, kurios pirmą kartą (alfa versijoje) pasirodė Kubernetes 1.16:

Remti dvigubas tinklo krūvas - IPv4 / IPv6 - ir atitinkamas „supratimas“ ankščių, mazgų, paslaugų lygiu. Tai apima IPv4 į IPv4 ir IPv6 į IPv6 suderinamumą tarp blokų, nuo podų iki išorinių paslaugų, nuorodų diegimus (su Bridge CNI, PTP CNI ir Host-Local IPAM papildiniais), taip pat atvirkštiniu suderinamumu su veikiančiais Kubernetes klasteriais. Tik IPv4 arba IPv6. Įdiegimo informacija pateikta KEP.
Dviejų tipų IP adresų (IPv4 ir IPv6) rodymo rinkinių sąraše pavyzdys:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
Nauja galutinio taško API - EndpointSlice API. Jis išsprendžia esamos Endpoint API našumo / mastelio keitimo problemas, turinčias įtakos įvairiems valdymo plokštumos komponentams (apiserveriui ir kt., galutinių taškų valdikliui, kube-proxy). Naujoji API bus įtraukta į Discovery API grupę ir galės aptarnauti dešimtis tūkstančių galinių taškų kiekvienoje tarnyboje klasteryje, kurį sudaro tūkstančiai mazgų. Norėdami tai padaryti, kiekviena paslauga susieta su N objektų EndpointSlice, kurių kiekvienas pagal numatytuosius nustatymus turi ne daugiau kaip 100 galinių taškų (vertę galima konfigūruoti). „EndpointSlice“ API taip pat suteiks galimybių ją plėtoti ateityje: palaikys kelis IP adresus kiekviename bloke, naujas galinių taškų būsenas (ne tik Ready и NotReady), dinaminis galinių taškų pogrupis.

Paskutiniame leidime pateikta versija pasiekė beta versiją užbaigėjas, pavadintas service.kubernetes.io/load-balancer-cleanup ir pridedamas prie kiekvienos paslaugos su tipu LoadBalancer. Tokios paslaugos ištrynimo metu ji neleidžia realiai ištrinti ištekliaus, kol nebus baigtas visų atitinkamų balansavimo išteklių „išvalymas“.

API mašinos

Tikrasis „stabilizavimo etapas“ yra Kubernetes API serverio ir sąveikos su juo srityje. Tai įvyko daugiausia dėka perkeliant į stabilų statusą tuos, kuriems nereikia specialaus pristatymo CustomResourceDefinitions (CRD), kurie turėjo beta būseną nuo tolimų Kubernetes 1.7 laikų (ir tai yra 2017 m. birželis!). Tas pats stabilizavimas buvo susijęs su susijusiomis savybėmis:

"antriniai ištekliai" su /status и /scale „CustomResources“;
konversija CRD versijos, pagrįstos išoriniu „webhook“;
neseniai pristatytas (K8s 1.15) numatytosios reikšmės (numatytasis) ir automatinis lauko pašalinimas (genėjimas) „CustomResources“;
galimybė naudojant OpenAPI v3 schemą kuriant ir paskelbiant OpenAPI dokumentaciją, naudojamą CRD ištekliams patvirtinti serverio pusėje.

Kitas mechanizmas, kuris jau seniai buvo pažįstamas Kubernetes administratoriams: priėmimo internetinis kabliukas - taip pat ilgą laiką išliko beta būsenoje (nuo K8s 1.9) ir dabar paskelbta stabilia.

Dar dvi funkcijos pasiekė beta versiją: taikomos serverio pusės и žiūrėti žymes.

Ir vienintelė reikšminga naujovė alfa versijoje buvo atmetimas nuo SelfLink — specialus URI, vaizduojantis nurodytą objektą ir esantis jo dalis ObjectMeta и ListMeta (t. y. bet kurio „Kubernetes“ objekto dalis). Kodėl jie to atsisako? Motyvacija paprastu būdu garsai kaip realių (didžiulių) priežasčių, dėl kurių ši sritis vis dar egzistuoja, nebuvimas. Formalesnės priežastys yra optimizuoti našumą (pašalinus nereikalingą lauką) ir supaprastinti generic-apiserver darbą, kuris yra priverstas tvarkyti tokį lauką ypatingu būdu (tai vienintelis laukas, nustatytas prieš pat objektą yra serializuotas). Tikras pasenimas (beta versijoje) SelfLink vyks Kubernetes 1.20 versija, o galutinė - 1.21.

Duomenų saugykla

Pagrindinis darbas saugojimo srityje, kaip ir ankstesniuose leidimuose, stebimas šioje srityje CSI palaikymas. Pagrindiniai pakeitimai čia buvo šie:

pirmą kartą (alfa versijoje) pasirodė CSI papildinio palaikymas „Windows“ darbuotojų mazgams: dabartinis darbo su saugykla būdas taip pat pakeis in-tree įskiepius Kubernetes branduolyje ir Microsoft FlexVolume papildinius, pagrįstus Powershell;

CSI įskiepių diegimo „Kubernetes for Windows“ schema
galimybė keisti CSI apimtis, pristatytas dar K8s 1.12 versijoje, išaugo iki beta versijos;
Panaši „reklama“ (iš alfa į beta) buvo pasiekta dėl galimybės naudoti CSI vietiniams trumpalaikiams tomams kurti (CSI Inline apimties palaikymas).

Pristatyta ankstesnėje Kubernetes versijoje tūrio klonavimo funkcija (naudojant esamą PVC kaip DataSource sukurti naują PVC) taip pat gavo beta būseną.

Tvarkaraštis

Du žymūs planavimo pakeitimai (abu alfa):

EvenPodsSpreading - galimybė naudokite ankštis, o ne loginius taikymo vienetus, kad apkrovos būtų „teisingai paskirstytos“. (pvz., Deployment ir ReplicaSet) ir koreguoti šį paskirstymą (kaip griežtą reikalavimą arba kaip neaiškią sąlygą, t. y. prioritetą). Ši funkcija išplės esamas planuojamų rinkinių platinimo galimybes, kurias šiuo metu riboja parinktys PodAffinity и PodAntiAffinity, suteikiant administratoriams geresnę kontrolę šiuo klausimu, o tai reiškia geresnį pasiekiamumą ir optimizuotą išteklių naudojimą. Išsami informacija – in KEP.
Naudoti „BestFit“ politika в „RequestedToCapacityRatio“ prioriteto funkcija ankšties planavimo metu, o tai leis taikyti šiukšliadėžės pakavimas („pakavimas į konteinerius“) tiek pagrindiniams ištekliams (procesoriaus, atminties), tiek išplėstiniams (pvz., GPU). Norėdami gauti daugiau informacijos, žr KEP.

Planavimo rinkiniai: prieš naudojant geriausio tinkamumo politiką (tiesiogiai per numatytąjį planuoklį) ir naudojant ją (naudojant planavimo priemonės plėtiklį)

be to, atstovaujama galimybė kurti savo planavimo įskiepius už pagrindinio Kubernetes kūrimo medžio (ne medžio).

Kiti pakeitimai

Taip pat galite atkreipti dėmesį į Kubernetes 1.16 leidimą iniciatyva už atnešant turimos metrikos visa tvarka, o tiksliau, pagal oficialiais nuostatais į K8s prietaisus. Jie daugiausia remiasi atitinkamu Prometėjo dokumentacija. Dėl įvairių priežasčių atsirado neatitikimų (pavyzdžiui, kai kurios metrikos buvo tiesiog sukurtos prieš pasirodant dabartinėms instrukcijoms), ir kūrėjai nusprendė, kad laikas viską suderinti su vienu standartu, „atitinkančiu likusią Prometėjo ekosistemą“. Šiuo metu įgyvendinama ši iniciatyva yra alfa būsena, kuri bus palaipsniui skatinama vėlesnėse Kubernetes versijose į beta (1.17) ir stabilią (1.18).

Be to, galima pastebėti šiuos pakeitimus:

Windows palaikymo plėtra с išvaizda „Kubeadm“ paslaugos, skirtos šiai OS (alfa versija), galimybė RunAsUserName „Windows“ konteineriams (alfa versija), tobulinimas Grupės valdomos paslaugos paskyros (gMSA) palaikymas iki beta versijos, parama montuoti / pritvirtinti vSphere tomus.
Perdirbta duomenų glaudinimo mechanizmas API atsakymuose. Anksčiau šiems tikslams buvo naudojamas HTTP filtras, kuris nustatė daugybę apribojimų, neleidžiančių jo įjungti pagal numatytuosius nustatymus. Dabar veikia „Skaidrus užklausų suspaudimas“: klientai siunčia Accept-Encoding: gzip antraštėje jie gauna GZIP suglaudintą atsakymą, jei jo dydis viršija 128 KB. „Go“ klientai automatiškai palaiko glaudinimą (reikiamos antraštės siuntimą), todėl iš karto pastebės srauto sumažėjimą. (Kitas kalbas gali prireikti šiek tiek pataisyti.)
Tapo įmanoma HPA mastelio keitimas nuo / iki nulio, remiantis išorine metrika. Jei mastelį nustatote pagal objektus / išorinę metriką, tada, kai darbo krūviai neveikia, galite automatiškai pakeisti mastelį iki 0 kopijų, kad sutaupytumėte išteklių. Ši funkcija turėtų būti ypač naudinga tais atvejais, kai darbuotojai prašo GPU išteklių, o skirtingų tipų neaktyvių darbuotojų skaičius viršija galimų GPU skaičių.
Naujas klientas - k8s.io/client-go/metadata.Client — „apibendrintai“ prieigai prie objektų. Jis skirtas lengvai gauti metaduomenis (t. y. poskyrį metadata) iš klasterio išteklių ir su jais atlikti šiukšlių surinkimo ir kvotų operacijas.
Sukurkite Kubernetes dabar gali be senųjų („įmontuotų“ medyje) debesies tiekėjų (alfa versija).
Į kubeadm naudingumą pridėta eksperimentinė (alfa versija) galimybė operacijų metu pritaikyti tinkintus pataisymus init, join и upgrade. Sužinokite daugiau, kaip naudoti vėliavą --experimental-kustomize, žr KEP.
Naujas apiserverio galutinis taškas – readyz, - leidžia eksportuoti informaciją apie jos pasirengimą. API serveris dabar taip pat turi vėliavėlę --maximum-startup-sequence-duration, leidžiantis reguliuoti jo paleidimus iš naujo.
Du „Azure“ funkcijos paskelbta stabilia: parama prieinamumo zonos (Pasiekiamumo zonos) ir kryžminė išteklių grupė (RG). Be to, Azure pridėjo:
- autentifikavimo palaikymas AAD ir ADFS;
- anotacija service.beta.kubernetes.io/azure-pip-name nurodyti viešąjį apkrovos balansavimo įrenginio IP;
- galimybė nustatymai LoadBalancerName и LoadBalancerResourceGroup.
AWS dabar turi parama skirta EBS sistemoje Windows ir optimizuotas EC2 API skambučiai DescribeInstances.
Kubeadm dabar yra nepriklausomas migruoja CoreDNS konfigūracija atnaujinant CoreDNS versiją.
Dvejetainiai ir tt atitinkamame Docker paveikslėlyje pagamintas world-executable, kuri leidžia paleisti šį vaizdą be root teisių. Taip pat etcd migracijos vaizdas nustojo veikti etcd2 versijos palaikymas.
В Cluster Autoscaler 1.16.0 perjungta į distroless naudojimą kaip pagrindinį vaizdą, pagerintas našumas, pridėta naujų debesų paslaugų teikėjų („DigitalOcean“, „Magnum“, „Packet“).
Naudotos / priklausomos programinės įrangos atnaujinimai: eikite į 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Taip pat skaitykite mūsų tinklaraštyje:

Šaltinis: www.habr.com

Kubernetes 1.16: pagrindinių naujovių apžvalga