🥇Kubernetes 1.16: berrikuntza nagusien ikuspegi orokorra

Gaur, asteazkena, ospatuko da Kubernetes-en hurrengo bertsioa - 1.16. Gure blogerako garatu den tradizioaren arabera, hamargarren urteurreneko aldia da bertsio berriaren aldaketa esanguratsuenei buruz hitz egiten ari garela.

Material hau prestatzeko erabilitako informazioa bertatik atera da Kubernetesen hobekuntzak jarraitzeko taulak, ALDAKETAK-1.16 eta lotutako gaiak, tira-eskaerak eta Kubernetes Hobekuntza-Proposamenak (KEP). Beraz, goazen!...

Nodoak

Berrikuntza nabarmen ugari (alfa bertsioan) K8s klusterreko nodoen alboan (Kubelet) aurkezten dira.

Lehenik eta behin, deiturikoak «ontzi iragankorrak» (Ontziak iragankorrak), podetan arazketa-prozesuak sinplifikatzeko diseinatua. Mekanismo berriak lehendik dauden leken izen-eremuan hasi eta denbora laburrean bizi diren edukiontzi bereziak abiarazteko aukera ematen du. Haien helburua beste ontzi eta edukiontzi batzuekin elkarreragina da, edozein arazo konpontzeko eta arazketa egiteko. Eginbide honetarako komando berri bat ezarri da kubectl debug, funtsean antzekoa kubectl exec: prozesu bat edukiontzi batean exekutatu beharrean (in exec) edukiontzi bat leka batean jaurtitzen du. Adibidez, komando honek edukiontzi berri bat ontzi batera konektatuko du:

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

Edukiontzi iragankorrei buruzko xehetasunak (eta haien erabileraren adibideak) hemen aurki daitezke dagokion KEP. Egungo inplementazioa (K8s 1.16-n) alfa bertsioa da, eta beta bertsio batera transferitzeko irizpideen artean "Ephemeral Containers APIa [Kubernetes]-en gutxienez 2 bertsioetarako probatzea" dago.

NB: Bere funtsean eta baita bere izena ere, funtzioak lehendik dagoen plugin baten antza du kubectl-arazteahorri buruz guk dagoeneko idatzia. Espero da edukiontzi iragankorren etorrerarekin, kanpoko plugin bereizi baten garapena geldituko dela.

Beste berrikuntza bat - PodOverhead - eskaintzeko diseinatua leken kostu orokorrak kalkulatzeko mekanismoa, erabilitako denboraren arabera asko alda daitekeena. Adibide gisa, egileak KEP hau emaitza Kata Containers-en, gonbidatutako nukleoa, kata agentea, hasierako sistema, etab. Gastuak hain handiak direnean, ezin dira alde batera utzi, hau da, kuota, plangintza eta abar gehiagorako kontuan hartzeko modu bat egon behar da. Inplementatzeko PodSpec eremua gehitu da Overhead *ResourceList (Datuekin alderatzen da RuntimeClass, bat erabiltzen bada).

Beste berrikuntza nabarmen bat da nodo topologia kudeatzailea (Nodo topologia kudeatzailea), Kubernetes-en hainbat osagairen hardware-baliabideen esleipena finkatzeko ikuspegia bateratzeko diseinatua. Ekimen hau errendimendu handiko konputazio paralelorako hainbat sistema modernoren (telekomunikazioen, ikaskuntza automatikoaren, finantza zerbitzuen, etab. arlokoak) gero eta behar handiagoak bultzatuta dago eta eragiketen exekuzioan atzerapenak gutxitzeko, horretarako CPU aurreratuak eta aurreratuak erabiltzen dituzte. hardware azelerazio gaitasunak. Kubernetesen horrelako optimizazioak osagai desberdinei esker lortu dira orain arte (CPU kudeatzailea, Gailuen kudeatzailea, CNI), eta orain barne-interfaze bakarra gehituko zaie, hurbilketa bateratu eta antzeko berrien konexioa errazten duena -topologia deritzona-. jakitun - osagaiak Kubelet aldean. Xehetasunak - in dagokion KEP.

Topologia-kudeatzailearen osagaien diagrama

Hurrengo ezaugarria - ontziak martxan dauden bitartean egiaztatzea (abiarazteko zunda). Dakizuenez, abian jartzeko denbora asko behar duten edukiontziei dagokienez, zaila da egoera eguneratua lortzea: benetan funtzionatzen hasi baino lehen “hiltzen” dira, edo denbora luzez blokeoan geratzen dira. Egiaztapen berria (deitutako funtzio-atearen bidez gaituta StartupProbeEnabled) ezeztatu egiten du -edo hobeto esanda, atzeratzen du- beste edozein egiaztapenen eragina, poda martxan amaitu arte. Hori dela eta, ezaugarria jatorriz deitzen zen pod-startup liveness-probe holdoff. Abiarazteko denbora luzea behar duten gailuetarako, egoera denbora-tarte nahiko laburrean galde dezakezu.

Horrez gain, RuntimeClass-en hobekuntza bat berehala eskuragarri dago beta egoeran, "kluster heterogeneoetarako" laguntza gehituz. C RuntimeClass Programazioa Orain ez da batere beharrezkoa nodo bakoitzak RuntimeClass bakoitzerako euskarria izatea: podetarako RuntimeClass bat hauta dezakezu cluster topologian pentsatu gabe. Aurretik, hori lortzeko, lekak behar duten guztiaren laguntza duten nodoetan bukatzeko, beharrezkoa zen NodeSelector eta tolerantziari arau egokiak esleitzea. IN CAP Erabilera-adibideez hitz egiten du eta, noski, ezarpen-xehetasunez.

Sarea

Kubernetes 1.16-n lehen aldiz (alfa bertsioan) agertu diren sareko bi ezaugarri esanguratsu hauek dira:

Lagundu sare bikoitzeko pila - IPv4/IPv6 - eta dagokion "ulermena" lekak, nodoak, zerbitzuen mailan. IPv4-to-IPv4 eta IPv6-to-IPv6 poden arteko elkarreragingarritasuna barne hartzen ditu, podetatik kanpoko zerbitzuetara, erreferentziazko inplementazioak (Bridge CNI, PTP CNI eta Host-Local IPAM pluginen barruan), baita alderantzizko bateragarria ere Kubernetes kluster exekutatzen ari direnekin. IPv4 edo IPv6 soilik. Ezarpenaren xehetasunak daude CAP.
Bi motatako (IPv4 eta IPv6) IP helbideak pods zerrendan bistaratzeko adibide bat:
```
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#
```
Endpoint-erako API berria - EndpointSlice APIa. Kontrol-planoko hainbat osagairi eragiten dioten Endpoint APIaren errendimendu/eskalagarritasun arazoak konpontzen ditu (apiserver, etcd, endpoints-controller, kube-proxy). API berria Discovery API taldean gehituko da eta milaka nodoz osatutako kluster batean zerbitzu bakoitzean hamar mila backend puntu zerbitzatzeko gai izango da. Horretarako, Zerbitzu bakoitza N objekturekin mapatzen da EndpointSlice, eta horietako bakoitzak berez 100 puntu baino gehiago ditu (balioa konfiguragarria da). EndpointSlice API-k bere etorkizuneko garapenerako aukerak ere emango ditu: pod bakoitzerako IP helbide anitzentzako laguntza, amaiera puntuentzako egoera berriak (ez bakarrik Ready и NotReady), amaierako puntuetarako azpimultzo dinamikoa.

Azken bertsioan aurkeztutakoa beta bertsiora iritsi da finalizatzaile, izendatua service.kubernetes.io/load-balancer-cleanup eta mota batekin zerbitzu bakoitzari atxikita LoadBalancer. Zerbitzu hori ezabatzeko unean, baliabidea benetako ezabatzea eragozten du orekatzaileen baliabide garrantzitsu guztien "garbiketa" amaitu arte.

API Makineria

Benetako "egonkortze-mugarria" Kubernetes API zerbitzariaren eta harekin elkarrekintzan dago. Hau neurri handi batean esker gertatu da sarrera berezirik behar ez dutenak egoera egonkorrera pasatzea Pertsonalizatutako baliabideen definizioak (CRD), Kubernetes 1.7ren urruneko egunetatik beta egoera izan dutenak (eta hau 2017ko ekaina da!). Egonkortze bera etorri zen erlazionatutako ezaugarrietara:

"azpibaliabideak" batera /status и /scale CustomResources-entzat;
eraldaketa CRDrako bertsioak, kanpoko webhook-ean oinarrituta;
aurkeztu berri du (K8s 1.15) balio lehenetsiak (lehenetsia) eta eremua automatikoki kentzea (inausketa) CustomResources-entzat;
aukera OpenAPI v3 eskema erabiltzea zerbitzariaren aldean CRD baliabideak balioztatzeko erabiltzen den OpenAPI dokumentazioa sortzeko eta argitaratzeko.

Kuberneteseko administratzaileek aspalditik ezagutzen duten beste mekanismo bat: onarpen webhook - beta egoeran ere denbora luzez egon zen (K8s 1.9tik aurrera) eta orain egonkor deklaratu da.

Beste bi ezaugarri beta-ra iritsi dira: zerbitzariaren aldetik aplikatzen da и ikusi laster-markak.

Eta alpha bertsioan berrikuntza esanguratsu bakarra izan zen porrota tik SelfLink — Zehaztutako objektua adierazten duen eta horren parte den URI berezi bat ObjectMeta и ListMeta (hau da, Kubernetes-eko edozein objekturen zati bat). Zergatik uzten dute bertan behera? Motibazioa modu errazean soinuak alor hori oraindik existitzeko benetako arrazoirik (ikaragarririk) ez dagoen bezala. Arrazoi formalagoak errendimendua optimizatzea (alferrikako eremu bat kenduz) eta generic-apiserver-aren lana erraztea dira, eremu hori modu berezi batean kudeatzera behartuta dagoena (objektuaren aurretik ezartzen den eremu bakarra da hau). seriatuta dago). Egiazko zaharkitzea (beta barruan) SelfLink Kubernetes 1.20 bertsioan gertatuko da, eta azken - 1.21.

Datuak biltegiratzea

Biltegiratze arloko lan nagusia, aurreko argitalpenetan bezala, eremuan ikusten da CSI laguntza. Hona hemen aldaketa nagusiak:

lehen aldiz (alfa bertsioan) agertu CSI plugin-en euskarria Windows langile-nodoetarako: biltegiratzearekin lan egiteko egungo moduak zuhaitz barruko pluginak ere ordezkatuko ditu Kubernetes nukleoan eta Microsoft-en FlexVolume pluginak Powershell-en oinarrituta;

Windows-erako Kubernetes-en CSI pluginak ezartzeko eskema
aukera CSI bolumenak tamainaz aldatzea, K8s 1.12-n sartua, beta bertsiora hazi da;
Antzeko "promozio" bat (alfatik beta-ra) lortu zen CSI erabili ahal izateko tokiko bolumen iragankorrak sortzeko (CSI Inline Bolumen-laguntza).

Kubernetesen aurreko bertsioan sartua bolumena klonatzeko funtzioa (lehendik dagoen PVCa erabiliz DataSource PVC berria sortzeko) beta egoera ere jaso du orain.

Antolatzailea

Bi aldaketa nabarmen programazioan (biak alfa-n):

EvenPodsSpreading - aukera erabili pods aplikazio-unitate logikoen ordez kargak "bidezko banaketa" egiteko (Deployment eta ReplicaSet bezalakoak) eta banaketa hau doitzea (eskakizun gogor gisa edo baldintza bigun gisa, hau da, lehentasuna). Eginbide honek aurreikusitako leken banaketa-gaitasunak zabalduko ditu, gaur egun aukerek mugatuta PodAffinity и PodAntiAffinity, administratzaileei gai honetan kontrol finagoa emanez, eta horrek erabilgarritasun handia eta baliabideen kontsumo optimizatua esan nahi du. Xehetasunak - in CAP.
Erabili BestFit politika в RequestedToCapacityRatio Lehentasun-funtzioa pod plangintzan, horrek ahalbidetuko du aplikatzeko paperontzien paketea ("edukiontzietan paketatzea") bai oinarrizko baliabideetarako (prozesadorea, memoria) bai hedatutakoetarako (GPU bezalakoak). Xehetasun gehiagorako, ikus CAP.

Programazioa: egokitze onenaren gidalerroa erabili aurretik (zuzenean programatzaile lehenetsiaren bidez) eta bere erabilerarekin (planifikatzaileen luzatzailearen bidez)

Horrez gain, ordezkatuta zure programatzaile-pluginak sortzeko gaitasuna Kubernetes garapen-zuhaitz nagusitik kanpo (zuhaitzetik kanpo).

Beste aldaketa batzuk

Kubernetes 1.16 bertsioan ere nabarmen daiteke ekimena ekartzen eskuragarri dauden metrik ordena osoan, edo zehatzago esanda, -ren arabera araudi ofiziala K8s instrumentaziora. Dagokionean oinarritzen dira neurri handi batean Prometheus dokumentazioa. Inkoherentziak hainbat arrazoirengatik sortu ziren (adibidez, neurketa batzuk egungo argibideak agertu baino lehen sortu ziren), eta garatzaileek erabaki zuten dena estandar bakar batera eramateko garaia zela, "Prometheus ekosistemaren gainerakoarekin bat". Ekimen honen egungo ezarpena alfa egoeran dago, eta Kubernetes-en hurrengo bertsioetan pixkanaka beta (1.17) eta egonkorra (1.18) igoko da.

Horrez gain, aldaketa hauek nabarmen daitezke:

Windows laguntza garapena с itxura OS honetarako Kubeadm utilitateak (alfa bertsioa), aukera RunAsUserName Windows edukiontzietarako (alfa bertsioa), hobekuntza Taldeko Kudeatutako Zerbitzu Kontua (gMSA) beta bertsiora arte onartzen da, laguntza muntatu/lotu vSphere bolumenetarako.
Birziklatua datuak konprimitzeko mekanismoa API erantzunetan. Aurretik, HTTP iragazkia erabiltzen zen helburu horietarako, eta horrek lehenespenez gaituta egotea eragozten zuen hainbat murrizketa ezartzen zituen. "Eskaera gardena konpresio" orain funtzionatzen du: bezeroak bidaltzen Accept-Encoding: gzip goiburuan, GZIP bidez konprimitutako erantzuna jasotzen dute bere tamaina 128 KB gainditzen badu. Go bezeroek automatikoki onartzen dute konpresioa (beharrezko goiburua bidaliz), beraz berehala nabarituko dute trafikoaren murrizketa. (Baliteke beste hizkuntzetarako aldaketa txikiak behar izatea.)
Posible bihurtu zen HPA eskalatzea kanpoko neurketetan oinarrituta. Objektu/kanpoko metriketan oinarrituta eskalatzen baduzu, lan-kargak inaktibo daudenean automatikoki eskala dezakezu 0 erreplika baliabideak aurrezteko. Eginbide hau bereziki erabilgarria izan behar da langileek GPU baliabideak eskatzen dituzten kasuetarako, eta inaktibo dauden langile mota ezberdinen kopuruak erabilgarri dauden GPU kopurua gainditzen duen kasuetarako.
Bezero berria - k8s.io/client-go/metadata.Client — objektuetarako sarbide “orokorizaturako”. Metadatuak erraz berreskuratzeko diseinatuta dago (hau da, azpiatala metadata) kluster baliabideetatik eta horiekin zabor bilketa eta kuota eragiketak egin.
Eraiki Kubernetes orain ahal duzu ondarerik gabeko hodeiko hornitzaileak (alfa bertsioa).
Kubeadm erabilgarritasunera gehitu du esperimentu (alfa bertsioa) pertsonalizatzeko adabakiak eragiketetan aplikatzeko gaitasuna init, join и upgrade. Lortu informazio gehiago bandera erabiltzeari buruz --experimental-kustomize, ikusi CAP.
Apiserver-en amaiera-puntu berria - readyz, - prest dagoen informazioa esportatzeko aukera ematen du. API zerbitzariak ere bandera bat du orain --maximum-startup-sequence-duration, bere berrabiarazteak erregulatzeko aukera emanez.
bi Azurerako ezaugarriak egonkor deklaratu: euskarria erabilgarritasun-eremuak (Eskuragarritasun Guneak) eta baliabideen arteko taldea (RG). Horrez gain, Azure-k gehitu du:
- autentifikazio-laguntza AAD eta ADFS;
- abstraktu service.beta.kubernetes.io/azure-pip-name karga-orekatzailearen IP publikoa zehazteko;
- aukera настройки LoadBalancerName и LoadBalancerResourceGroup.
AWSk orain dauka onartzen Windows-en EBSrako eta optimizatuta EC2 API deiak DescribeInstances.
Kubeadm independentea da orain migratzen du CoreDNS konfigurazioa CoreDNS bertsioa eguneratzean.
Bitarrak etab dagokion Docker irudian egina mundu-exekutagarria, irudi hau root eskubideen beharrik gabe exekutatzeko aukera ematen duena. Gainera, etcd migrazio irudia utzi zion etcd2 bertsioaren euskarria.
В Cluster Autoscaler 1.16.0 Oinarrizko irudi gisa distroless erabiltzera aldatu zen, errendimendua hobetu zen, hodeiko hornitzaile berriak gehitu ziren (DigitalOcean, Magnum, Packet).
Erabilitako/menpeko softwarearen eguneraketak: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Kubernetes 1.16: berritasunaren aipagarrienak