🥇Kubernetes 1.16: pregled glavnih novosti

Danes, sreda, poteka naslednja izdaja Kubernetesa - 1.16. Po tradiciji, ki se je razvila za naš blog, je to deseta obletnica, ko govorimo o najpomembnejših spremembah v novi različici.

Podatki, uporabljeni za pripravo tega gradiva, so vzeti iz Tabele za sledenje izboljšav Kubernetes, DNEVNIK SPREMEMB-1.16 in sorodna vprašanja, zahteve za vlečenje in predloge za izboljšavo Kubernetes (KEP). Torej, gremo!..

Vozlišča

Resnično veliko število opaznih novosti (v statusu alfa različice) je predstavljenih na strani vozlišč gruče K8s (Kubelet).

Prvič, t.i «efemerne posode» (Efemerne posode), zasnovan za poenostavitev postopkov odpravljanja napak v pods. Nov mehanizem vam omogoča zagon posebnih vsebnikov, ki se začnejo v imenskem prostoru obstoječih sklopov in živijo kratek čas. Njihov namen je interakcija z drugimi sklopi in vsebniki za reševanje morebitnih težav in odpravljanje napak. Za to funkcijo je bil implementiran nov ukaz kubectl debug, v bistvu podoben kubectl exec: samo namesto izvajanja procesa v vsebniku (kot v exec) sproži vsebnik v pod. Ta ukaz bo na primer povezal nov vsebnik s podom:

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

Podrobnosti o efemernih vsebnikih (in primerih njihove uporabe) najdete v ustrezen KEP. Trenutna izvedba (v K8s 1.16) je različica alfa in med merili za njen prenos v različico beta je "testiranje API-ja Ephemeral Containers za vsaj 2 izdaji [Kubernetes]."

NB: Funkcija v svojem bistvu in celo po imenu spominja na že obstoječi vtičnik kubectl-debugo katerih smo že napisal. Pričakuje se, da se bo s prihodom efemernih vsebnikov razvoj ločenega zunanjega vtičnika prenehal.

Še ena novost - PodOverhead - zasnovan za zagotavljanje mehanizem za izračun režijskih stroškov za pods, ki se lahko močno razlikuje glede na uporabljeno izvajanje. Kot primer avtorji ta KEP povzroči vsebnike Kata, ki zahtevajo zagon gostujočega jedra, kata agenta, inicialnega sistema itd. Ko režijski stroški postanejo tako veliki, jih ni mogoče prezreti, kar pomeni, da mora obstajati način, kako jih upoštevati pri nadaljnjih kvotah, načrtovanju itd. Za implementacijo v PodSpec dodano polje Overhead *ResourceList (primerja s podatki v RuntimeClass, če se uporablja).

Druga pomembna novost je upravitelj topologije vozlišča (Upravitelj topologije vozlišča), zasnovan za poenotenje pristopa k natančnemu prilagajanju dodeljevanja virov strojne opreme za različne komponente v Kubernetesu. To pobudo poganja vse večja potreba različnih sodobnih sistemov (s področja telekomunikacij, strojnega učenja, finančnih storitev itd.) po visoko zmogljivem vzporednem računalništvu in minimiziranju zamud pri izvajanju operacij, za kar uporabljajo napredne procesorje in zmožnosti strojnega pospeševanja. Tovrstne optimizacije v Kubernetesu so doslej dosegali zahvaljujoč različnim komponentam (CPU manager, Device manager, CNI), sedaj pa jim bodo dodali enoten notranji vmesnik, ki poenoti pristop in poenostavi povezovanje novih podobnih - t.i. aware - komponente na strani Kubelet. Podrobnosti - v ustrezen KEP.

Diagram komponent upravitelja topologije

Naslednja funkcija - preverjanje posod med delovanjem (zagonska sonda). Kot veste, je za vsebnike, ki se zaženejo dolgo časa, težko pridobiti posodobljeno stanje: bodisi so »ubiti«, preden dejansko začnejo delovati, ali pa končajo v slepi ulici za dolgo časa. Novo preverjanje (omogočeno prek funkcijskih vrat, imenovanih StartupProbeEnabled) prekliče – ali bolje rečeno, odloži – učinek kakršnih koli drugih preverjanj do trenutka, ko se sklop konča z izvajanjem. Iz tega razloga je bila funkcija prvotno imenovana pod-startup liveness-probe holdoff. Pri sklopih, ki se zaženejo dolgo, lahko stanje anketirate v razmeroma kratkih časovnih intervalih.

Poleg tega je izboljšava za RuntimeClass takoj na voljo v statusu beta in dodaja podporo za "heterogene grozde". C Razporejanje RuntimeClass Zdaj sploh ni potrebno, da ima vsako vozlišče podporo za vsak RuntimeClass: za pods lahko izberete RuntimeClass, ne da bi razmišljali o topologiji gruče. Prej, da bi to dosegli – tako da so podi na koncu na vozliščih s podporo za vse, kar potrebujejo – je bilo treba NodeSelectorju in tolerancam dodeliti ustrezna pravila. IN KEP Govori o primerih uporabe in seveda podrobnostih implementacije.

Сеть

Dve pomembni omrežni funkciji, ki sta se prvič pojavili (v različici alfa) v Kubernetesu 1.16, sta:

Podpora dvojni omrežni sklad - IPv4/IPv6 - in njegovo ustrezno "razumevanje" na ravni podov, vozlišč, storitev. Vključuje interoperabilnost IPv4-IPv4 in IPv6-IPv6 med podi, od podov do zunanjih storitev, referenčne izvedbe (znotraj vtičnikov Bridge CNI, PTP CNI in Host-Local IPAM), kot tudi obratno združljivo z gručami Kubernetes, ki se izvajajo Samo IPv4 ali IPv6. Podrobnosti o izvedbi so v KEP.
Primer prikaza naslovov IP dveh vrst (IPv4 in IPv6) na seznamu sklopov:
```
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#
```
Nov API za končno točko - API EndpointSlice. Rešuje težave z zmogljivostjo/razširljivostjo obstoječega API-ja za končne točke, ki vplivajo na različne komponente v nadzorni ravnini (apiserver itd., krmilnik končnih točk, kube-proxy). Novi API bo dodan v skupino Discovery API in bo lahko služil več deset tisoč končnim točkam zaledja na vsaki storitvi v gruči, sestavljeni iz tisočih vozlišč. Za to je vsaka storitev preslikana v N objektov EndpointSlice, od katerih vsaka privzeto nima več kot 100 končnih točk (vrednost je nastavljiva). API EndpointSlice bo zagotovil tudi priložnosti za svoj prihodnji razvoj: podporo za več naslovov IP za vsak pod, nova stanja za končne točke (ne samo Ready и NotReady), dinamična podnastavitev za končne točke.

Tisti, predstavljen v zadnji izdaji, je dosegel različico beta finalizator, imenovan service.kubernetes.io/load-balancer-cleanup in priložen vsaki storitvi z vrsto LoadBalancer. V času izbrisa takšne storitve prepreči dejanski izbris vira, dokler ni končano »čiščenje« vseh ustreznih virov izravnave.

API stroji

Pravi "stabilizacijski mejnik" je na področju strežnika Kubernetes API in interakcije z njim. To se je zgodilo predvsem po zaslugi premestitev v stabilen status tistih, ki ne potrebujejo posebnega predstavljanja CustomResourceDefinitions (CRD), ki imajo status beta že od daljnih časov Kubernetesa 1.7 (in to je junij 2017!). Enaka stabilizacija je prišla do povezanih funkcij:

"podviri" s /status и /scale za CustomResources;
pretvorbo različice za CRD, ki temeljijo na zunanjem webhooku;
nedavno predstavljen (v K8s 1.15) privzete vrednosti (privzeto) in samodejno odstranjevanje polja (obrezovanje) za CustomResources;
priložnost uporabo sheme OpenAPI v3 za ustvarjanje in objavo dokumentacije OpenAPI, ki se uporablja za preverjanje virov CRD na strani strežnika.

Še en mehanizem, ki je skrbnikom Kubernetesa že dolgo znan: sprejem webhook - prav tako je dolgo časa ostal v statusu beta (od K8s 1.9) in je zdaj razglašen za stabilnega.

Dve drugi funkciji sta dosegli beta: na strani strežnika и zaznamki ure.

In edina pomembna novost v različici alfa je bila odpoved od SelfLink — poseben URI, ki predstavlja podani objekt in je njegov del ObjectMeta и ListMeta (tj. del katerega koli predmeta v Kubernetesu). Zakaj ga opuščajo? Motivacija na preprost način zvoki kot odsotnost pravih (prevladujočih) razlogov, da to področje še obstaja. Bolj formalni razlogi so optimizacija zmogljivosti (z odstranitvijo nepotrebnega polja) in poenostavitev dela generic-apiserverja, ki je prisiljen obravnavati takšno polje na poseben način (to je edino polje, ki je nastavljeno tik pred objektom je serializiran). Prava zastarelost (znotraj beta) SelfLink se bo zgodilo z različico Kubernetes 1.20 in končno - 1.21.

Shranjevanje podatkov

Glavno delo na področju shranjevanja, tako kot v prejšnjih izdajah, je opazovano na območju CSI podpora. Glavne spremembe tukaj so bile:

prvič (v alfa verziji) pojavil Podpora za vtičnik CSI za delovna vozlišča Windows: trenutni način dela s shrambo bo nadomestil tudi vtičnike v drevesu v jedru Kubernetes in vtičnike FlexVolume podjetja Microsoft, ki temeljijo na Powershellu;

Shema za implementacijo vtičnikov CSI v Kubernetes za Windows
priložnost spreminjanje velikosti nosilcev CSI, predstavljen v K8s 1.12, je zrasel v različico beta;
Podobno "napredovanje" (iz alfa v beta) je bilo doseženo z možnostjo uporabe CSI za ustvarjanje lokalnih kratkotrajnih nosilcev (CSI Inline Volume Podpora).

Predstavljeno v prejšnji različici Kubernetesa funkcija kloniranja volumna (z uporabo obstoječega PVC-ja kot DataSource za ustvarjanje novega PVC-ja) je prav tako zdaj prejel status beta.

Razporejevalnik

Dve pomembni spremembi razporejanja (obe v različici alfa):

EvenPodsSpreading - priložnost uporabite stroke namesto logičnih aplikacijskih enot za »pravično porazdelitev« obremenitev (kot sta Deployment in ReplicaSet) in prilagajanje te distribucije (kot trda zahteva ali kot mehki pogoj, tj. prioriteta). Funkcija bo razširila obstoječe distribucijske zmogljivosti načrtovanih podov, ki so trenutno omejene z možnostmi PodAffinity и PodAntiAffinity, kar skrbnikom omogoča boljši nadzor v tej zadevi, kar pomeni boljšo visoko razpoložljivost in optimizirano porabo virov. Podrobnosti - v KEP.
Uporaba Politika BestFit в Prednostna funkcija RequestedToCapacityRatio med načrtovanjem pod, ki bo omogočil uporabiti pakiranje v smeti (»pakiranje v zabojnike«) tako za osnovne vire (procesor, pomnilnik) kot za razširjene (kot je GPU). Za več podrobnosti glejte KEP.

Stroki za razporejanje: pred uporabo pravilnika najboljšega prileganja (neposredno prek privzetega razporejevalnika) in z njegovo uporabo (prek razširjevalnika razporejevalnika)

poleg tega ki jih zastopa zmožnost ustvarjanja lastnih vtičnikov planerja zunaj glavnega razvojnega drevesa Kubernetes (zunaj drevesa).

Druge spremembe

To je mogoče opaziti tudi v izdaji Kubernetes 1.16 pobudo za prinašanje razpoložljive meritve v popolnem redu, natančneje v skladu z uradni predpisi na instrumentacijo K8s. V veliki meri se zanašajo na ustrezne Dokumentacija Prometheus. Nedoslednosti so se pojavile zaradi različnih razlogov (na primer, nekatere metrike so bile preprosto ustvarjene, preden so se pojavila trenutna navodila), in razvijalci so se odločili, da je čas, da vse pripeljejo do enotnega standarda, "v skladu s preostalim ekosistemom Prometheus." Trenutna izvedba te pobude je v statusu alfa, ki bo postopoma napredoval v naslednjih različicah Kubernetesa v beta (1.17) in stabilno (1.18).

Poleg tega je mogoče opaziti naslednje spremembe:

Windows podpira razvoj с videz Pripomočki Kubeadm za ta OS (različica alfa), priložnost RunAsUserName za vsebnike Windows (različica alfa), izboljšava Podpora za skupinski upravljani račun storitve (gMSA) do različice beta, podporo namestitev/pritrditev za nosilce vSphere.
Reciklirano mehanizem stiskanja podatkov v odzivih API. Prej je bil za te namene uporabljen filter HTTP, ki je naložil številne omejitve, zaradi katerih ni bil privzeto omogočen. "Transparentno stiskanje zahtev" zdaj deluje: stranke pošiljajo Accept-Encoding: gzip v glavi prejmejo odgovor, stisnjen z GZIP, če njegova velikost preseže 128 KB. Odjemalci Go samodejno podpirajo stiskanje (pošiljanje zahtevane glave), tako da bodo takoj opazili zmanjšanje prometa. (Morda bodo potrebne manjše spremembe za druge jezike.)
Postalo mogoče skaliranje HPA z/na ničelne enote na podlagi zunanjih meritev. Če skalirate na podlagi objektov/zunanjih metrik, potem lahko, ko so delovne obremenitve nedejavne, samodejno skalirate na 0 replik, da prihranite vire. Ta funkcija bi morala biti še posebej uporabna v primerih, ko delavci zahtevajo sredstva GPE in število različnih vrst nedejavnih delavcev presega število razpoložljivih GPE.
Nova stranka - k8s.io/client-go/metadata.Client — za "generaliziran" dostop do objektov. Zasnovan je za preprosto pridobivanje metapodatkov (tj. podrazdelka metadata) iz virov gruče in z njimi izvajajo operacije zbiranja smeti in kvote.
Zgradite Kubernetes zdaj lahko brez podedovanih (»vgrajenih« drevesnih) ponudnikov v oblaku (različica alfa).
V pripomoček kubeadm dodano eksperimentalna (različica alfa) možnost uporabe prilagoditvenih popravkov med operacijami init, join и upgrade. Več o uporabi zastave --experimental-kustomize, glej v KEP.
Nova končna točka za apiserver - readyz, - omogoča izvoz informacij o njegovi pripravljenosti. Tudi strežnik API ima zdaj zastavico --maximum-startup-sequence-duration, kar vam omogoča, da regulirate njegove ponovne zagone.
Dva funkcije za Azure razglašeno za stabilno: podpora območja razpoložljivosti (območja razpoložljivosti) in navzkrižna skupina virov (RG). Poleg tega je Azure dodal:
- podpora za avtentikacijo AAD in ADFS;
- pripis service.beta.kubernetes.io/azure-pip-name za določitev javnega IP-ja izravnalnika obremenitve;
- priložnost nastavki LoadBalancerName и LoadBalancerResourceGroup.
AWS zdaj ima podporo za EBS v sistemu Windows in optimizirano Klici EC2 API DescribeInstances.
Kubeadm je zdaj neodvisen migrira Konfiguracija CoreDNS pri nadgradnji različice CoreDNS.
Binarne datoteke itdd v ustrezni sliki Docker Končano world-executable, ki vam omogoča zagon te slike brez potrebe po korenskih pravicah. Tudi migracijska slika etcd prenehala podpora za različico etcd2.
В Cluster Autoscaler 1.16.0 prešli na uporabo distroless kot osnovne slike, izboljšali delovanje, dodali nove ponudnike v oblaku (DigitalOcean, Magnum, Packet).
Posodobitve uporabljene/odvisne programske opreme: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Preberite tudi na našem blogu:

Vir: www.habr.com

Kubernetes 1.16: pregled glavnih novosti