🥇Kubernetes 1.16: ülevaade peamistest uuendustest

Täna, kolmapäeval, toimub on välja antud järgmine versioon Kubernetes — 1.16. Jätkates meie blogi traditsiooniga, räägime juba kümnendat korda olulisematest muudatustest uues versioonis.

Selle refleksiooni ettevalmistamiseks kasutatud teave on võetud Kubernetes'i täiustuste jälgimise tabelist, CHANGELOG-1.16 ja vastavatest probleemidest, pull request'idest, samuti Kubernetes Enhancement Proposals (KEP) dokumentidest. Nii et, alaku siis!..

Sõlmed

Koguni suur hulk märgatavaid uudsusi (alfaversioonis) on esindatud K8s-klastrite sõlmedes (Kubelet).

Esiteks tutvustatakse nn «efemereid konteinerid» (Ephemeral Containers), mis on mõeldud pod'ide debugimise protsesside lihtsustamiseks.Uus mehhanism võimaldab käivitada spetsiaalseid konteinerid, mis alustavad olemasolevate pod'ide nimete ruumis ja elavad lühikese aja. Nende eesmärk on suhelda teiste pod'ide ja konteineridega probleemide lahendamise ja debugimise eesmärgil. Selle funktsiooni jaoks on läbi viidud uus käsk kubectl debug, mis on sarnane oma olemuselt kubectl exec: ainult et käima ei anta protsessi konteineris (nagu juhtus exec) see ühendab konteineri pod'iga. Näiteks selline käsk ühendab uue konteineri pod'iga:

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

Teavet efemeersete konteinerite kohta (ja näiteid nende kasutamisest) leiate vastavast KEP-ist. Praegune rakendus (K8s 1.16-s) on alfa-versioon ja selle üleminekuks beetaversiooniks on oluline kriteerium "efemeersete konteinerite API testimine vähemalt kahe väljalaske jooksul [Kubernetes]".

NB: Oma olemuse ja isegi nime poolest sarnaneb funktsioon juba olemasoleva pistikprogrammiga kubectl-debug, millest me oleme juba kirjutanud. Eeldatakse, et efemeersete konteinerite eelkäijate edasiarendamine lõpeb.

Teine uuendus — PodOverhead — eesmärk on pakkuda mekanismi pod'ide ülekatte arvutamiseks, mis võib erineda sõltuvalt kasutatavast käituskeskkonnast (runtime). Näitena toovad autorid seda KEP-i , tuues välja Kata konteinerid, mis nõuavad külgtoega põhi, kata-agent, alglaadimise süsteem jne. Kui ülejääk on nii suur, et seda ei saa ignoreerida, on vajalik viis seda edasise kvoteerimise, planeerimise jne jaoks arvesse võtta. Selle rakendamiseks on PodSpec lisatud väli Pealne *ResourceList (vastandub andmetele RuntimeClass, kui selline on kasutusel).

Veel üks märkimisväärne uuendus — sõlme topoloogia haldur (Node Topology Manager), mille eesmärk on ühtlustada lähenemist riistvararesursside täpselt jaotamisele erinevates komponentides Kuberneteses. See algatus on tingitud erinevate kaasaegsete süsteemide (telekommunikatsiooni, masinõppe, finantsteenuste jne valdkondadest) suurenevast vajadusest kõrge jõudlusega paralleelsete arvutuste ja töötlusoperatsioonide viivituste vähendamise järele, milleks nad kasutavad CPU ja riistvara kiirendamise edasijõudnud võimalusi. Sellised optimeerimised Kuberneteses on seni saavutatud killustatud komponentide (CPU manager, Device manager, CNI) kaudu, kuid nüüd lisatakse neile ühtne sisemine liides, mis ühtlustab lähenemist ja lihtsustab uute sarnaste — nn topoloogia teadlike — komponentide ühendamist Kubeleti küljes. Üksikasjad — vastavast KEP-ist.

Topoloogia halduri komponentide skeem

Järgmine funktsioon — konteinerite kontrollimine nende käivitamise ajal (startup probe). Nagu teada, on konteinerite puhul, mis aeglaselt käivituvad, keeruline saada ajakohast staatust: neid kas "tapetakse" enne reaalse töö alustamist või satuvad nad pikaks ajaks deadlock’i. Uus kontroll (lülitatakse sisse feature gate nimega StartupProbeEnabled) tühistab — täpsemalt, lükkab edasi — kõik ülejäänud kontrollid kuni hetkeni, mil pod on oma käivitamise lõpetanud. Selle põhjusel kutsuti funktsiooni algselt pod-startup liveness-probe holdoff. Aeglaselt käivituvate pod'ide jaoks on võimalik teha olekukuulamist otsesemates ajavahemikes.

Lisaks on beetaversioonis esitatud täiendus RuntimeClass’ile, mis lisab toe "heterogeensetele klastritele". C RuntimeClass Scheduling ei ole nüüd vajalik, et igal sõlmel oleks tugi iga RuntimeClass’i jaoks: pod’ide jaoks on võimalik valida RuntimeClass ilma klastrite topoloogiast muretsemata. Varem tuli selle saavutamiseks — et pod’id paikneksid sõlmedes, kus on toetatud nende vajadused — määrata vastavad reeglid NodeSelectorile ja toleratsioonidele. K KEP selgitab kasutusnäidete ja loomulikult teostuse üksikasju.

Võrk

Kaks olulist võrgu funktsiooni, mis ilmnesid esmakordselt (alfa-versioonis) Kubernetes 1.16 – need on:

Toetamine topeltvõrgustik – IPv4/IPv6 — ja selle vastav «mõistmine» podide, sõlmede ja teenuste tasandil. See hõlmab IPv4-to-IPv4 ja IPv6-to-IPv6 suhtlemist podide vahel, podid väliste teenuste jaoks, viidatud rakendusi (Bridge CNI, PTP CNI ja Host-Local IPAM pluginate raames) ja tagasipöördumise ühilduvust Kubernetes klastritega, mis töötavad ainult IPv4 või IPv6 alusel. Tehnilised üksikasjad on KEP.
Kaks tüüpi IP-aadresse (IPv4 ja IPv6) podide loendis:
```
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#
```
Uus API Endpoint jaoks — EndpointSlice API. See lahendab olemasoleva Endpoint API probleemid seoses jõudluse/mastaapsusega, mis mõjutavad erinevaid komponente control-plane’is (apiserver, etcd, endpoints-controller, kube-proxy). Uus API lisatakse Discovery API rühma ja suudab teenindada kümneid tuhandeid backend endpoint'e igas teenuses klastris, mis koosneb tuhandetest sõlmedest. Selle jaoks kaardistatakse iga Teenus N objektiks EndpointSlice, igaühel neljast on vaikimisi maksimaalselt 100 endpoint’i (väärtust saab seadistada). EndpointSlice API pakub ka tulevikus arenguvõimalusi: toetust mitmele IP-aadressile iga pod’i kohta, uusi oleketeenuseid endpoint’idele (mitte ainult Valmis ja NotReady), dünaamilise alampuhastuse endpoint’idele.

Beeta versioonini on edasi arendatud eelmine väljaanne finalizer, mille nimi on service.kubernetes.io/load-balancer-cleanup ja millel on lisatud iga servi, mille tüüp on LoadBalancer. Sellise teenuse eemaldamise hetkel takistab see ressursi tegelikku kustutamist, kuni kõik vastavad tasakaalustaja ressursid on «puhastatud».

API Machinery

See «stabiliseerimise verstapost» on dokumenteeritud Kubernetes API-serveri valdkonnas ja selle interaktsioonides. Suur osa sellest on toimunud stabiilseks staatuseks muudetud CustomResourceDefinitions (CRD) , mis olid b-eta staatuses alates kaugest Kubernetes 1.7-st (ja see on juuni 2017!). Samasugune stabiliseerimine on toimunud ka nendega seotud funktsioonides:«alamressursid» (subresources)

CustomResourceide jaoks; ja /status ja /scale versioonide CRD jaoks, mis põhineb välisel webhook'il;
muundamine hiljuti esitatud
(K8s 1.15) vaikimisi väärtused (defaulting) (defaulting) ja automaatne väljade eemaldamine (kärpimine) versioonide CRD jaoks, mis põhineb välisel webhook'il;
võimalus OpenAPI v3 skeemi rakendamine OpenAPI-dokumentatsiooni loomisel ja avaldamisel, mida kasutatakse CRD-resursside valideerimiseks serveri küljel.

Veel üks mehhanism, mis on Kubernetes' administaratoritele juba tuttav: vastuvõtmise webhook — oli samuti pikka aega beetaversioonis (K8s 1.9) ja on nüüd kuulutatud stabiilseks.

Kaks muud funktsiooni on saavutanud beetaversiooni: serveripoolne rakendamine ja vaata järjehoidjaid.

Ja ainus märkimisväärne uuendus alfa-versioonis oli SelfLink alates — spetsiaalne URI, mis esindab määratud objekti ja on osa ObjectMeta ListMeta ja (st on osa mis tahes objektist Kubernetes'eis). Miks sellest loobutakse? „Lihtne“ motiiv kõlab nagu tõeliste (ületamatute) põhjuste puudumine, miks see väli peaks endiselt olemas olema. Formaalseteks põhjusteks on jõudluse optimeerimine (kui eemaldada mittevajalik väli) ja generic-apiserver'i töö lihtsustamine, mis peab sellist välja eranditult käsitlema (see on ainus väli, mis määratakse otse enne objekti serialiseerimist). Tõeline „vananemine“ (beetaversiooni raames) toimub Kubernetes'e versioonis 1.20 ja lõplikult — 1.21. — spetsiaalne URI, mis esindab määratud objekti ja on osa toimub Kubernetesi versioonile 1.20, ja lõplikult — 1.21.

Andmete salvestamine

Peamine tegevusala salvestamiseks, nagu ka varasemates versioonides, täheldatakse valdkonnas CSI toe. Peamisteks muudatusteks on:

esmakordselt (alfa-versioonis) ilmus CSI-pluginite tugi Windowsi töövoogudele: sobiv meetod salvestuslahendustega ning see asendab in-tree pluginad Kubernetes'i tuumas ja Microsofti PowerShelli põhised FlexVolume pluginad;

CSI-pluginite rakendusskeem Kubernetes'is Windows jaoks
võimalus CSI-mahtude suuruse muutmine, mis tutvustati juba K8s 1.12, on jõudnud beeta-versiooni;
sarnast «tõstmist» (alfa- kuni beeta-versioonini) on saavutanud ka CSI kasutamise võimalus kohalike ajutiste mahtude loomisel (CSI Inline Volume Support).

Eelmise Kubernetes'i versioonis mahud kloonimise funktsioon (olemasolevate PVC-de kasutamine DataSource uute PVC-de loomiseks) on nüüd samuti saanud beeta-versiooni staatuse.

Ajakava

Kaks märkimisväärset muudatust planeerimises (mõlemad alfa-versioonis):

EvenPodsSpreading — võimalus kasutada 'ausa jaotuse' jaoks pod'e, mitte rakenduse loogilisi üksuseid (näiteks Deployment ja ReplicaSet) ja selle jaotuse reguleerimine (kas rangete nõudmiste või pehme tingimusena, st prioriteedina). See funktsioon laiendab olemasolevaid võimalusi kavandatavate pod'ide jaotuseks, mis praegu on piiratud valikutega PodAffinity ja PodAntiAffinity, andes süsteemiadministraatoritele peenemad kontrollivõimalused selle küsimuse üle, mis tähendab paremat kõrge saadavuse ja optimeeritud ressursitarbimist. Üksikasjad — KEP.
Kasutamine BestFit Policy ühes RequestedToCapacityRatio Priority Function pod'ide planeerimise ajal, mis võimaldab rakendama bin packing („konteinerite pakkimine”) nii põhivahendite (protsessor, mälu) kui ka laiendatud ressursside (nt GPU) osas. Lisainfot leiate KEP.

Pod'ide planeerimine: enne best fit policy kasutamist (otseselt vaikimisi ajakava kaudu) ja selle kasutamisega (scheduler extender'i kaudu)

Lisaks toetab esitatud võimalus luua oma pluginaid ajakava jaoks väljaspool Kubernetes'e põhiarenduse puu (out-of-tree).

Muudatused

Kubernetes 1.16 väljaandes on samuti tähelepanuväärne algatus olemasolevate mõõdikute korrastamiseks , täpsemalt – vastavusse viimiseks, ja kui täpsemalt — vastavuses ametlike nõuete K8s instrumenteerimise osas. Need põhinevad suuresti vastaval Prometheuse dokumentatsioonil. Erinevad lahknevused on tekkinud erinevatel põhjustel (näiteks mõned mõõdikud loodi enne, kui praegused juhised ilmusid), ning arendajad otsustasid, et on aeg kõik ühtsesse standardisse viia, „vastavusse ülejäänud Prometheuse ökosüsteemiga”. Käesolev algatuse rakendamine on alfa-versioonis, mille staatust tõstetakse järk-järgult järgmistes Kubernetes'i versioonides beetaversiooniks (1.17) ja stabiilseks (1.18).

Samuti võib märkida järgmisi muudatusi:

Windowsi toe arendamine koos tulemuseks Kubeadm utiliidi selle operatsioonisüsteemi jaoks (alfa-versioon), võimalus RunAsUserName Windowsi konteinerite jaoks (alfa-versioon), parandamine Group Managed Service Account'i (gMSA) toe muutmiseks beetaversiooniks, toetades mount/attach vSphere'i mahtudeks.
Uuendatud andmete tihendamise mehhanism API vastustes. Varem kasutati nende eesmärkide jaoks HTTP-filtrit, mis kehtestas mitmeid piiranguid, takistades selle vaikimisi lubamist. Nüüd töötab „läbipaistev päringute tihendamine”: kliendid, kes saadavad Accept-Encoding: gzip pealkirjas saavad kokku surutud GZIP vastuse, kui selle suurus ületas 128 KB. Go kliendid toetavad automaatselt tihendamist (saates vajaliku päise), seetõttu märkavad nad kohe liikluse vähenemist. (Muude keelte puhul võivad olla vajalikud mõned muudatused.)
On võimalik HPA skaalamine pod’ide põhjal väliste mõõdikute järgi nulli ja tagasi. Kui skaalamine toimub objektide/väliste mõõdikute põhjal, siis kui töökoormused seiskuvad, saab automaatselt skaalale langeda 0 replit, et ressursse säästa. See funktsioon peaks olema eriti kasulik juhtudel, kui töötajad küsivad GPU ressursse, ja erinevat tüüpi seisakute töötajate arv ületab saadaval olevate GPU-de arvu.
Uus klient — k8s.io/client-go/metadata.Client — „üldise“ juurdepääsu objektidele. See on mõeldud metainformatsiooni (st jaotis) lihtsaks hankimiseks metadata) klastrite ressurssidest ning teostama nende operatsioone nagu prahi kogumine ja kvoteerimine.
Kuberneteset koguda on nüüd võimalik ilma vananenud („sisse ehitatud“) pilveteenuse pakkujatega (alfa-versioon).
Kubeadmi utiliiti lisasid katse (alfa-versioon) võimalus rakendada kustomize'i plaastreid operatsioonide käigus init, liitu ja uuenda. Täiendavat teavet selle lipu kasutamise kohta --experimental-kustomize, vaata KEP.
Uus lõpp-punkt apiserverile — readyz, — mis võimaldab eksportida teavet selle valmiduse (readiness) kohta. Samuti on API-serveril uus lipp --maximum-startup-sequence-duration, mis võimaldab reguleerida selle taaskäivitusi.
Kaks funktsiooni Azure'is on kuulutatud stabiilseteks: tuge toetavad saite (Availability Zones) ja ristressursside grupp (RG). Lisaks on Azure'is lisatud: AAD ja ADFS autentimise tugi;
- annotation service.beta.kubernetes.io/azure-pip-name
- avaliku IP määramiseks koormuse tasakaalustaja juures; LoadBalancerName LoadBalancerResourceGroup
- võimalus seaded AWS-il on nüüd ja EBS tugi Windowsis ja.
optimeeritud toetamine API-kutsed EC2-le DescribeInstances Kubeadm nüüd iseseisvalt migreerib.
CoreDNS-i konfiguratsiooni, kui CoreDNS-i versioon uuendatakse. Binaarfailid CoreDNS-i konfiguratsioon versiooniuuenduse käigus.
Binaarfailid etcd vastavas Docker-pildis tegi world-executable, mis võimaldab selle pildi käivitamist ilma root'i õigusteta. Lisaks on etcd lõpetanud etcd2 versiooni toe.
V Cluster Autoscaler 1.16.0 oleme läinud üle distroless'i kasutamisele põhifailina, parandanud jõudlust ning lisanud uusi pilveteenuse pakkujaid (DigitalOcean, Magnum, Packet).
Värskendused kasutatavates/ sõltuvates programmides: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Lugege ka meie blogist:

Allikas: habr.com

Kubernetes 1.16: peamised uuendused