🥇Kubernetes 1.16: përmbledhje e inovacioneve kryesore

Sot, e mërkurë, do të zhvillohet lëshimi tjetër i Kubernetes - 1.16. Sipas traditës që është zhvilluar për blogun tonë, ky është përvjetori i dhjetë që po flasim për ndryshimet më domethënëse në versionin e ri.

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga Tabelat e gjurmimit të përmirësimeve të Kubernetes, NDRYSHIMI-1.16 dhe çështje të ndërlidhura, kërkesat për tërheqje dhe Propozimet e Përmirësimit të Kubernetes (KEP). Pra, le të shkojmë!..

Nyjet

Një numër vërtet i madh i risive të dukshme (në statusin e versionit alfa) janë paraqitur në anën e nyjeve të grupimit K8 (Kubelet).

Së pari, të ashtuquajturat «enë kalimtare» (Enë kalimtare), i krijuar për të thjeshtuar proceset e korrigjimit në pods. Mekanizmi i ri ju lejon të lëshoni kontejnerë të veçantë që fillojnë në hapësirën e emrave të pods ekzistuese dhe jetojnë për një kohë të shkurtër. Qëllimi i tyre është të ndërveprojnë me pods dhe kontejnerë të tjerë për të zgjidhur çdo problem dhe korrigjim. Një komandë e re është zbatuar për këtë veçori kubectl debug, e ngjashme në thelb me kubectl exec: vetëm në vend që të ekzekutoni një proces në një kontejner (si në exec) lëshon një enë në një pod. Për shembull, kjo komandë do të lidhë një enë të re me një pod:

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

Detaje rreth kontejnerëve kalimtarë (dhe shembuj të përdorimit të tyre) mund të gjenden në KEP përkatës. Implementimi aktual (në K8s 1.16) është një version alfa, dhe ndër kriteret për transferimin e tij në një version beta është "testimi i API-së Ephemeral Containers për të paktën 2 lëshime të [Kubernetes]".

NB: Në thelb dhe madje edhe në emrin e tij, veçoria i ngjan një shtojce tashmë ekzistuese kubectl-debugpër të cilat ne tashmë ka shkruar. Pritet që me ardhjen e kontejnerëve kalimtarë, zhvillimi i një shtojce të veçantë të jashtme do të pushojë.

Një risi tjetër - PodOverhead - projektuar për të siguruar mekanizëm për llogaritjen e kostove të përgjithshme për pods, të cilat mund të ndryshojnë shumë në varësi të kohës së përdorimit të përdorur. Si shembull, autorët ky KEP rezultojnë në Kata Containers, të cilat kërkojnë ekzekutimin e kernelit mysafir, agjentit të kata-s, sistemit init, etj. Kur shpenzimet e përgjithshme bëhen kaq të mëdha, nuk mund të injorohen, që do të thotë se duhet të ketë një mënyrë për ta marrë parasysh për kuotat e mëtejshme, planifikimin, etj. Për ta zbatuar atë në PodSpec fusha e shtuar Overhead *ResourceList (krahasohet me të dhënat në RuntimeClass, nëse përdoret një).

Një risi tjetër e dukshme është menaxher i topologjisë së nyjeve (Menaxheri i Topologjisë së Nyjeve), i krijuar për të unifikuar qasjen për rregullimin e saktë të shpërndarjes së burimeve harduerike për komponentë të ndryshëm në Kubernetes. Kjo nismë nxitet nga nevoja në rritje e sistemeve të ndryshme moderne (nga fusha e telekomunikacionit, mësimi i makinerive, shërbimet financiare, etj.) për llogaritje paralele me performancë të lartë dhe minimizimin e vonesave në ekzekutimin e operacioneve, për të cilat ata përdorin CPU dhe CPU të avancuara dhe aftësitë e përshpejtimit të harduerit. Optimizime të tilla në Kubernetes janë arritur deri më tani falë komponentëve të ndryshëm (menaxheri i CPU, menaxheri i pajisjes, CNI), dhe tani atyre do t'u shtohet një ndërfaqe e vetme e brendshme që unifikon qasjen dhe thjeshton lidhjen e të ngjashmeve të reja - të ashtuquajturat topologji- i vetëdijshëm - komponentë në anën Kubelet. Detajet - në KEP përkatës.

Diagrami i komponentëve të menaxherit të topologjisë

Karakteristika tjetër - kontrollimi i kontejnerëve ndërsa ato janë në punë (sonda e nisjes). Siç e dini, për kontejnerët që kërkojnë shumë kohë për t'u nisur, është e vështirë të marrin një status të përditësuar: ose "vriten" përpara se të fillojnë të funksionojnë, ose përfundojnë në bllokim për një kohë të gjatë. Kontroll i ri (i aktivizuar përmes portës së veçorive të thirrur StartupProbeEnabled) anulon - ose më saktë, shtyn - efektin e çdo kontrolli tjetër deri në momentin që pod ka përfunduar funksionimin. Për këtë arsye, funksioni u quajt fillimisht pod-startup liveness-probe holdoff. Për grupet që kërkojnë një kohë të gjatë për të filluar, ju mund të anketoni gjendjen në intervale kohore relativisht të shkurtra.

Përveç kësaj, një përmirësim për RuntimeClass është menjëherë i disponueshëm në statusin beta, duke shtuar mbështetje për "grupe heterogjene". C Planifikimi i klasës së ekzekutimit Tani nuk është aspak e nevojshme që çdo nyje të ketë mbështetje për secilën RuntimeClass: për pods mund të zgjidhni një RuntimeClass pa menduar për topologjinë e grupimit. Më parë, për të arritur këtë - në mënyrë që pod-et të përfundojnë në nyje me mbështetje për gjithçka që u nevojitet - ishte e nevojshme të caktoheshin rregullat e duhura për NodeSelector dhe tolerimet. NË CEP Ai flet për shembuj të përdorimit dhe, natyrisht, detajet e zbatimit.

Сеть

Dy veçori të rëndësishme të rrjetit që u shfaqën për herë të parë (në versionin alfa) në Kubernetes 1.16 janë:

Mbështetje pirg i dyfishtë i rrjetit - IPv4/IPv6 - dhe "kuptimi" i tij përkatës në nivelin e pods, nyjeve, shërbimeve. Ai përfshin ndërveprueshmërinë IPv4-në-IPv4 dhe IPv6-në-IPv6 ndërmjet pod-ve, nga pod-et tek shërbimet e jashtme, implementimet e referencës (brenda shtojcave Bridge CNI, PTP CNI dhe Host-Local IPAM), si dhe të kundërt të pajtueshme me grupet Kubernetes që funksionojnë Vetëm IPv4 ose IPv6. Detajet e zbatimit janë në CEP.
Një shembull i shfaqjes së adresave IP të dy llojeve (IPv4 dhe IPv6) në listën e pods:
```
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#
```
API e re për Endpoint - EndpointSlice API. Ai zgjidh problemet e performancës/shkallëzueshmërisë së API-së ekzistuese të pikës së fundit që prekin komponentë të ndryshëm në planin e kontrollit (apiserver, etj, pikat e fundit-kontrollues, kube-proxy). API i ri do t'i shtohet grupit Discovery API dhe do të jetë në gjendje të shërbejë dhjetëra mijëra pika fundore në fund të çdo shërbimi në një grup të përbërë nga mijëra nyje. Për ta bërë këtë, çdo shërbim është hartuar me N objekte EndpointSlice, secila prej të cilave si parazgjedhje nuk ka më shumë se 100 pika përfundimtare (vlera është e konfigurueshme). EndpointSlice API do të ofrojë gjithashtu mundësi për zhvillimin e tij në të ardhmen: mbështetje për adresa të shumta IP për çdo pod, gjendje të reja për pikat fundore (jo vetëm Ready и NotReady), nënvendosje dinamike për pikat fundore.

Ai i paraqitur në versionin e fundit ka arritur në versionin beta finalizues, i quajtur service.kubernetes.io/load-balancer-cleanup dhe i bashkëngjitet çdo shërbimi me tip LoadBalancer. Në momentin e fshirjes së një shërbimi të tillë, ai parandalon fshirjen aktuale të burimit derisa të përfundojë "pastrimi" i të gjitha burimeve përkatëse të balancuesit.

Makineri API

"Politika e stabilizimit" e vërtetë është në zonën e serverit Kubernetes API dhe ndërveprimin me të. Kjo ndodhi kryesisht falë duke transferuar në status stabil ata që nuk kanë nevojë për prezantim të veçantë Përkufizimet e Burimeve me porosi (CRD), të cilat kanë pasur status beta që nga ditët e largëta të Kubernetes 1.7 (dhe ky është qershor 2017!). I njëjti stabilizim erdhi në veçoritë përkatëse:

"nënburimet" me /status и /scale për Burimet e personalizuara;
transformim versionet për CRD, bazuar në uebhook të jashtëm;
paraqitur së fundmi (në K8s 1.15) vlerat e paracaktuara (i parazgjedhur) dhe heqja automatike e fushës (krasitje) për Burimet e personalizuara;
mundësi duke përdorur skemën OpenAPI v3 për të krijuar dhe publikuar dokumentacionin OpenAPI të përdorur për të vërtetuar burimet CRD në anën e serverit.

Një mekanizëm tjetër që është bërë prej kohësh i njohur për administratorët e Kubernetes: uebhook pranimi - gjithashtu mbeti në statusin beta për një kohë të gjatë (që nga K8s 1.9) dhe tani është shpallur i qëndrueshëm.

Dy veçori të tjera kanë arritur në beta: aplikohet nga ana e serverit и faqeshënuesit e orës.

Dhe e vetmja risi domethënëse në versionin alfa ishte отказ nga SelfLink — një URI speciale që përfaqëson objektin e specifikuar dhe që është pjesë e tij ObjectMeta и ListMeta (p.sh. pjesë e ndonjë objekti në Kubernetes). Pse po e braktisin? Motivimi në një mënyrë të thjeshtë Tinguj si mungesë e arsyeve reale (dërrmuese) që kjo fushë të ekzistojë ende. Arsyet më formale janë për të optimizuar performancën (duke hequr një fushë të panevojshme) dhe për të thjeshtuar punën e apiserver-it gjenerik, i cili detyrohet të trajtojë një fushë të tillë në një mënyrë të veçantë (kjo është e vetmja fushë që vendoset pikërisht përpara objektit është i serializuar). Vjetërim i vërtetë (brenda beta) SelfLink do të ndodhë nga versioni 1.20 i Kubernetes, dhe i fundit - 1.21.

Ruajtja e të dhënave

Puna kryesore në zonën e ruajtjes, si në publikimet e mëparshme, vërehet në zonë Mbështetje CSI. Ndryshimet kryesore këtu ishin:

për herë të parë (në versionin alfa) u shfaq Mbështetje e shtojcave CSI për nyjet e punonjësve të Windows: mënyra aktuale e punës me hapësirën ruajtëse do të zëvendësojë gjithashtu shtojcat brenda pemës në bazën Kubernetes dhe shtojcat FlexVolume nga Microsoft bazuar në Powershell;

Skema për zbatimin e shtojcave CSI në Kubernetes për Windows
mundësi ndryshimi i madhësisë së vëllimeve CSI, i prezantuar përsëri në K8s 1.12, është rritur në një version beta;
Një "promovim" i ngjashëm (nga alfa në beta) u arrit nga aftësia për të përdorur CSI për të krijuar vëllime lokale kalimtare (Mbështetja e vëllimit të brendshëm të CSI).

Prezantuar në versionin e mëparshëm të Kubernetes funksioni i klonimit të vëllimit (duke përdorur PVC ekzistuese si DataSource për të krijuar PVC të re) tashmë ka marrë statusin beta.

Programuesi

Dy ndryshime të dukshme në planifikim (të dyja në alfa):

EvenPodsSpreading - mundësi përdorni pods në vend të njësive të aplikimit logjik për "shpërndarjen e drejtë" të ngarkesave (si Deployment dhe ReplicaSet) dhe rregullimi i kësaj shpërndarjeje (si një kërkesë e vështirë ose si një kusht i butë, d.m.th. prioritet). Veçoria do të zgjerojë aftësitë ekzistuese të shpërndarjes së pod-ve të planifikuara, aktualisht të kufizuara nga opsionet PodAffinity и PodAntiAffinity, duke u dhënë administratorëve kontroll më të mirë në këtë çështje, që do të thotë disponueshmëri më e lartë dhe konsum i optimizuar i burimeve. Detajet - në CEP.
Përdorim Politika BestFit в Funksioni prioritar i kërkuar në raportin e kapacitetit gjatë planifikimit të pod, i cili do të lejojë përdorim paketim koshi (“paketim në kontejnerë”) si për burimet bazë (procesor, memorie) dhe për ato të zgjeruara (si GPU). Për më shumë detaje, shihni CEP.

Planifikimi i grupeve: përpara se të përdorni politikën e përshtatjes më të mirë (drejtpërsëdrejti nëpërmjet programuesit të paracaktuar) dhe me përdorimin e saj (nëpërmjet zgjeruesit të planifikuesit)

Përveç kësaj, të përfaqësuar nga aftësia për të krijuar shtojcat tuaja të planifikuesit jashtë pemës kryesore të zhvillimit të Kubernetes (jashtë pemës).

Ndryshime të tjera

Gjithashtu në lëshimin e Kubernetes 1.16 mund të vërehet iniciativë për duke sjellë metrikat e disponueshme në rend të plotë, ose më saktë, në përputhje me rregulloret zyrtare në instrumentet K8s. Ata kryesisht mbështeten në përkatësinë Dokumentacioni i Prometeut. Mospërputhjet lindën për arsye të ndryshme (për shembull, disa metrikë u krijuan thjesht përpara se të shfaqeshin udhëzimet aktuale), dhe zhvilluesit vendosën që ishte koha për të sjellë gjithçka në një standard të vetëm, "në përputhje me pjesën tjetër të ekosistemit Prometheus". Zbatimi aktual i kësaj nisme është në statusin alfa, i cili do të promovohet në mënyrë progresive në versionet pasuese të Kubernetes në beta (1.17) dhe stabil (1.18).

Përveç kësaj, mund të vërehen ndryshimet e mëposhtme:

Zhvillimi i mbështetjes së Windows с pamjen Shërbimet Kubeadm për këtë OS (version alfa), mundësi RunAsUserName për kontejnerët e Windows (versioni alfa), përmirësim Mbështetja e llogarisë së shërbimit të menaxhuar të grupit (gMSA) deri në versionin beta, mbështetje montimi/bashkëngjitja për vëllimet vSphere.
Riciklohen mekanizmi i kompresimit të të dhënave në përgjigjet API. Më parë, për këto qëllime përdorej një filtër HTTP, i cili vendosi një sërë kufizimesh që e pengonin atë të aktivizohej si parazgjedhje. "Ngjeshja transparente e kërkesës" tani funksionon: dërgojnë klientët Accept-Encoding: gzip në kokë, ata marrin një përgjigje të ngjeshur me GZIP nëse madhësia e saj tejkalon 128 KB. Klientët Go mbështesin automatikisht kompresimin (duke dërguar kokën e kërkuar), kështu që ata menjëherë do të vërejnë një reduktim të trafikut. (Mund të nevojiten modifikime të vogla për gjuhë të tjera.)
U bë e mundur shkallëzimi i HPA nga/në zero pods bazuar në metrikat e jashtme. Nëse shkallëzoni në bazë të objekteve/metrikave të jashtme, atëherë kur ngarkesat e punës janë të papunë, ju mund të shkallëzoni automatikisht në 0 kopje për të kursyer burime. Kjo veçori duhet të jetë veçanërisht e dobishme për rastet kur punëtorët kërkojnë burime GPU dhe numri i llojeve të ndryshme të punëtorëve të papunë tejkalon numrin e GPU-ve të disponueshme.
Klient i ri - k8s.io/client-go/metadata.Client - për qasje "të përgjithësuar" në objekte. Është projektuar për të marrë lehtësisht meta të dhënat (d.m.th. nënseksioni metadata) nga burimet e grupimeve dhe të kryejë me to operacione grumbullimi dhe kuotimi të plehrave.
Ndërtoni Kubernetes tani mundesh pa ofrues të resë së vjetër ("të integruar" në pemë) (versioni alfa).
Tek programi kubeadm shtuar aftësia eksperimentale (versioni alfa) për të aplikuar arna të personalizuara gjatë operacioneve init, join и upgrade. Mësoni më shumë se si të përdorni flamurin --experimental-kustomize, shih në CEP.
Pika e re përfundimtare për apiserver - readyz, - ju lejon të eksportoni informacion në lidhje me gatishmërinë e tij. Serveri API gjithashtu tani ka një flamur --maximum-startup-sequence-duration, duke ju lejuar të rregulloni rinisjet e tij.
dy veçoritë për Azure shpallur stabil: mbështetje zonat e disponueshmërisë (Zonat e disponueshmërisë) dhe grup burimesh të kryqëzuara (RG). Përveç kësaj, Azure ka shtuar:
- mbështetje për autentifikimin AAD dhe ADFS;
- abstrakt service.beta.kubernetes.io/azure-pip-name për të specifikuar IP-në publike të balancuesit të ngarkesës;
- mundësi настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS tani ka mbështetje për EBS në Windows dhe optimizuar Thirrjet EC2 API DescribeInstances.
Kubeadm tani është i pavarur migron Konfigurimi i CoreDNS kur përmirësohet versioni CoreDNS.
Binarët etj në imazhin përkatës të Docker bërë i ekzekutueshëm në botë, i cili ju lejon të ekzekutoni këtë imazh pa pasur nevojë për të drejta rrënjësore. Gjithashtu, imazhi i migrimit etj ndaloi Mbështetja e versionit etcd2.
В Cluster Autoscaler 1.16.0 kaloi në përdorimin e pa shpërndarë si imazhin bazë, performancën e përmirësuar, shtoi ofruesit e rinj të cloud (DigitalOcean, Magnum, Packet).
Përditësimet në softuerin e përdorur/varur: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Lexoni edhe në blogun tonë:

Burimi: www.habr.com

Kubernetes 1.16: përmbledhje e inovacioneve kryesore