🥇Kubernetes 1.16: peamiste uuenduste ülevaade

Täna, kolmapäeval, toimub on uuendatud Kubernetes — 1.16. Meie blogi traditsioonide kohaselt räägime juba kümnendat korda olulisematest muudatustest uues versioonis.

Selle materjali koostamiseks kasutatud teave on saadud Kubernetes'i täiustuste jälgimise tabelist, CHANGELOG-1.16 ja vastavatest probleemidest, tõmbenõuetest ning Kubernetes Enhancement Proposals (KEP). Nii et, alustame!..

Sõlmed

Kubelet'i K8s-klastrite sõlmedes on esitatud tõeliselt suur hulk märkimisväärseid uuendusi (alpha-versioonis).

Esiteks, tutvustatakse nn «ajutisi konteinereid» (Ephemeral Containers), mille eesmärk on lihtsustada pod'ide silumise protsesse. Uus mehhanism võimaldab käivitada spetsiaalseid konteinereid, mis käivituvad olemasolevate pod'ide nimedetailis ja elavad lühikest aega. Nende eesmärk on suhelda teiste pod'ide ja konteineritega, et lahendada mingeid probleeme ja siluda vigu. Selle funktsiooni jaoks on kasutusele võetud uus käsk kubectl debug, mis sarnaneb oma olemuselt kubectl exec: kuid erinevalt konteineris protsessi käivitamisest (nagu juhtum on exec) käivitab see konteineri pod'is. Näiteks selline käsk ühendab uue konteineri pod'iga:

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

Ajakohase teabe ajutiste konteinerite kohta (ja nende kasutamise näidised) on võimalik leida vastavast KEP-ist. Praegune rakendus (K8s 1.16-s) on alpha-versioon, ja üheks kriteeriumiks, mille alusel see muudetakse beetaversiooniks, on "Ephemeral Containers API testimine vähemalt kahe Kubernetes'i väljaande jooksul."

NB: Oma olemuselt ja isegi nime poolest meenutab see funktsioon juba olemasolevat pluginat kubectl-debug, millest me oleme juba kirjutanud. Eeldatakse, et ajutiste konteinerite tekkimisega lakkab eksisteerima eraldi väline plugin.

Teine uuendus — PodOverhead — on kavandatud pakkuma mehhanismi pod'ide kulude arvestamiseks, mis võivad sõltuvalt kasutatavast käituskeskkonnast (runtime) oluliselt erineda. Näiteks toovad autorid selle KEP-i näitena välja Kata Containers, mis nõuab külgjuhtme, kata agendi, algus süsteemi jne käivitamist. Kui overhead on nii suur, et seda ei saa ignoreerida, on vajalik meetod selle arvessevõtmiseks edasise kvootide määramisel, planeerimisel jne. Selle rakendamiseks on PodSpec lisatud väli Overhead *ResourceList (seostatakse andmetega RuntimeClass, kui selline on olemas).

Veel üks tähelepanuväärne uuendus — sõlmede topoloogia haldur (Node Topology Manager), misjoni on ühtlustada lähenemist riistvaraliste ressursside täpsustamisele erinevates komponentides Kubernetes. See algatus tuleneb kasvavast vajadusest erinevate tänapäevaste süsteemide (telekommunikatsiooni, masinõppe, finantsteenuste jne valdkondades) järele, mis vajavad kõrge jõudlusega paralleelseid arvutusi ja viivituste minimeerimist operatsioonide täitmisel, kasutades selleks edasijõudnud CPU ja riistvarakiirenduse võimalusi. Sellised optimeeringud Kuberneteses on siiani saavutatud erinevate komponentidega (CPU manager, Device manager, CNI), kuid nüüd lisatakse neile ühtne sisemine liides, mis ühtlustab lähenemist ja lihtsustab sarnaste – nn topology-aware – komponentide ühendamist Kubeleti poolel. Üksikasjad – vastavast KEP-ist.

Topology Manager komponentide skeem

Järgmine funktsioon on konteinerite kontrollimise ajal nende käivitamisest (startup probe). Nagu teada, on konteinerite, mis kaua käivituvad, käimasoleva oleku saamine keeruline: neid võib "tappa" enne tõelist käivitumist või nad satuvad kaua aega deadlock'i. Uus kontroll (mille aktiveerib funktsioonivärav nimega StartupProbeEnabled) tühistab - täpsemalt, lükkab edasi - kõigi teiste kontrollide rakendamise kuni hetkeni, mil pod on oma käivitamise lõpetanud. Sellest tulenevalt nimetati funktsiooni algselt pod-startup liveness-probe holdoff. Pikalt käivitatavate pod'ide kohta saab küsida olekut suhteliselt lühikeste ajavahemike tagant.

Lisaks on kohe beetaversioonis esitatud täiustamine RuntimeClass jaoks, mis lisab toe "heterogeensetele klastritele". C RuntimeClass Scheduling ei ole enam vajalik, et igal sõlmel oleks tugi igale RuntimeClass'ile: pod'ide jaoks saab valida RuntimeClass'i, mõtlemata klastri topoloogiale. Varem oli selle saavutamiseks – et pod'id paikneksid sõlmedes, millel on toetust kõigile nendele vajalikele – vajalik vastavate reeglite määramine NodeSelector'ile ja tolerations'ile. KEP-is käsitletakse kasutusnäiteid ja muidugi rakendamise üksikasju.

Võrk

Kaks olulist võrgufunktsiooni, mis ilmusid esmakordselt (alpha versioonis) Kubernetes 1.16 – need on:

Tugi topoloogilise võrgu steki – IPv4/IPv6 — ja vastav tema "mõistmine" pod'ide, sõlmede ja teenuste tasandil. See hõlmab IPv4-to-IPv4 ja IPv6-to-IPv6 suhtlust pod'ide vahel, pod'ide ja väliste teenuste vahel, viidatud rakendusi (Bridge CNI, PTP CNI ja Host-Local IPAM liideste kaudu) ning tagasipöördumise ühisuses Kubernetes klastritega, mis töötavad ainult IPv4 või IPv6 kaudu. Rakenduse üksikasjad — KEP-is.
Kaks tüüpi IP-aadresside (IPv4 ja IPv6) väljundite näide pod'ide 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 jõudlus-/skaalaprobleemid, mis mõjutavad erinevaid komponente control-plane'is (apiserver, etcd, endpoints-controller, kube-proxy). Uus API lisatakse Discovery API rühma ja võib teenindada kümneid tuhandeid tagasiside (backend) lõpp-punkte iga teenuse kohta klastris, mis koosneb tuhandetest sõlmedest. Selle saavutamiseks kuvatakse iga teenus N objektina EndpointSlice, millest igaühel on vaikimisi mitte rohkem kui 100 lõpp-punkti (väärtus on seadistatav). EndpointSlice API-s on ette nähtud ka võimalused selle tulevase arendamise jaoks: toetada mitmeid IP-aadresse iga pod'i jaoks, uusi olekuid lõpp-punktide jaoks (mitte ainult Valmis ja NotReady), dünaamiline alamgrupp lõpp-punktide jaoks.

Käesoleva versiooni beetaversioon on arenenud eelmisel väljaandel finalizer, mida nimetatakse service.kubernetes.io/load-balancer-cleanup ja mis on iga teenuse juurde kinnitatud, mille tüüp on LoadBalancer. Sellise teenuse eemaldamise hetkel takistab see ressursi tegelikku eemaldamist, kuni kõik vastavad koormusbalansi ressursside "puhtaks tegemise" protsessid on lõpule viidud.

API Machinery

Praegune "stabiliseerimise oluline verstapost" on fikseeritud Kubernetes API serveri ja selle vahetuse valdkonnas. Suurel määral juhtus see tänu töötlemise edasiviimise staatusest välja viimisele, mis ei nõudnud erilist esitlemist CustomResourceDefinitions (CRD), mis olid olnud beetaversioonis alates kaugest Kubernetes 1.7 (see on juuni 2017!). Sama stabiliseerimine sai ka seotud funktsioonidele:

"alalise ressursside" (subresources) koos /status ja /scale CustomResources;
versioonide konverteerimisprotsess CRD jaoks, mis põhineb välisel webhook'il;
hiljuti esitatud (K8s 1.15) vaikimisi väärtused (defaulting) ja automaatne väljaheide valdkondadele (pruning) CustomResources;
võimaluse OpenAPI v3 skeemi rakendamine ja avaldamine OpenAPI dokumentatsiooni loomiseks ja avaldamiseks, mida kasutatakse CRD-resursside valideerimiseks serveri küljes.

Veel tuttav mehhanism Kubernetes'i administraatoritele: admission webhook — on samuti pikka aega olnud beetastaadiumis (alates K8s 1.9) ja nüüd kuulutatud stabiilseks.

Kaks muud funktsiooni on jõudnud beetaversiooni: server-side apply ja watch bookmarks.

Ja ainus oluline uuendus alfa-versioonis oli keeldumine alates SelfLink — eriline URI, mis esindab määratud objekti ja on osa ObjectMeta ja ListMeta (st osa igast objektist Kuberneteses). Miks sellest loobutakse? Motivatsioon "lihtsustatult" kõlab nagu tõeliste (ületamatute) põhjuste puudumine, miks see väli peaks veel olemas olema. Formaalsed põhjused on siiski jõudluse optimeerimine (ebavajaliku välja eemaldamine) ja generic-apiserveri töö lihtsustamine, mis peab sellist välja eriliselt käsitlema (see on ainus väli, mis seatakse otse objekti serialiseerimise eel). Tõeline "aegumise" (beetaversioonis) SelfLink toimub Kubernetes 1.20 versioonis, ja lõplik — 1.21.

Andmete salvestamine

Nagu eelmistes väljaannetes, on peamine töö salvestuses valdkonnas CSI toe toetamine. Peamised muudatused on:

esmakordselt (alfa-versioonis) on CSI-pluginite tugi Windowsi tööjaamadele: aktuaalne viis salvestusruumide haldamiseks, mis asendab in-tree pluginaid Kubernetes'i tuumas ja Microsofti Powershellil põhinevaid FlexVolume pluginaid;

CSI-pluginite rakendusskeem Kubernetes'es Windowsile
võimaluse CSI-mahtude suuruse muutmine, mis esitati juba K8s 1.12-s, on jõudnud beetaversioonini;
sarnase "kõrgendamise" (alfa- kuni beetaversioonini) on saanud ka võimalus kasutada CSI-d kohalike efemeraalsete mahtude loomiseks (CSI Inline Volume Support).

Eelmises versioonis Kubernetes'es tuli üles mahutite kloonimise funktsioon (olemasolevate PVC-de kasutamine DataSource uute PVC-de loomiseks) on nüüd samuti saavutanud beetaversiooni staatuse.

Planeerija

Kaks silmapaistvat muudatust planeerimises (mõlemad alfa-versioonis):

EvenPodsSpreading — võimalus kasutada "ausaks jaotamiseks" pod'e mitte loogilisi rakenduse üksusi (nagu Deployment ja ReplicaSet) ja reguleerida seda jaotust (kas rangete nõudmiste või pehme tingimusena, st prioriteedina). Funktsioon laiendab olemasolevaid plaanejate pod'ide jaotuse võimekusi, mis on praegu piiratud valikutega PodAffinity ja PodAntiAffinity, and providing administrators with finer control over this matter, thus ensuring better high availability and optimized resource consumption. For details, see KEP-is.
Kasutamine BestFit Policy ja RequestedToCapacityRatio Priority Function during pod planning, which will allow rakendama bin packing (“container packing”) for both primary resources (CPU, memory) and extended ones (such as GPU). For more details, see KEP-is.

Pod planning: before the use of the best fit policy (directly via the default scheduler) and using it (through the scheduler extender)

Lisaks, esitati the ability to create custom plugins for the scheduler outside the main Kubernetes development tree (out-of-tree).

Teised muudatused

Also in the Kubernetes 1.16 release, it is worth noting the initiative for bringing existing metrics in line, or more precisely — in accordance with official guidelines for K8s instrumentation. They largely rely on the corresponding Prometheus documentation. Inconsistencies arose for various reasons (for example, some metrics were simply created before the current instructions appeared), and developers decided that it was time to bring everything to a single standard, “consistent with the rest of the Prometheus ecosystem.” The current implementation of this initiative is in alpha status, which will be progressively raised in subsequent Kubernetes versions to beta (1.17) and stable (1.18).

In addition, the following changes can be noted:

Development of Windows support jot ilmunud for Kubeadm utility for this OS (alpha version), the ability RunAsUserName for Windows containers (alpha version), parandamine support for Group Managed Service Account (gMSA) to beta version, toetuse mount/attach for vSphere volumes.
Revamped data compression mechanism in API responses. Previously, an HTTP filter was used for this purpose, which imposed a number of limitations preventing it from being enabled by default. Now “transparent request compression” works: clients that send Accept-Encoding: gzip in the header receive a GZIP compressed response if its size exceeds 128 KB. Go clients automatically support compression (send the required header), so they will immediately notice reduced traffic. (Other languages may require minor modifications.)
Nüüd on võimalik scaling HPA up/down to zero pods based on external metricsKui skaleerimine toimub objektide/väliste mõõdikute põhjal, siis kui töökoormused seisavad, saab automaatselt skaleeruda 0 koopiani, et ressursse säästa. See funktsioon peaks olema eriti kasulik olukordades, kus töötajad nõuavad GPU ressursse ja erinevate tüüpi seisev töötajate arv ületab saadaval olevate GPU-de arvu.
Uus klient — k8s.io/client-go/metadata.Client — „üldise“ juurdepääsu jaoks objektidele. See on mõeldud, et hõlpsasti saada metaandmeid (st alamnoodid metadata) klastrite ressurssidest ja teostada nendega toiminguid, mis on seotud prügikoristuse ja kvootidega.
Koguge Kubernetes --follow ilma aegunud („sisse ehitatud“ in-tree) pilveteenuse pakkujateta (alfa-versioon).
Kubeadm utiliit lisanud katsetab (alfa-versioon) kustomize'i plaastrite rakendamist Upgrade'i operatsioonide ajal — algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud., join ja upgrade. Lisainfot selle kohta, kuidas kasutada parameetrit --experimental-kustomize, vt KEP-is.
Uus endpoint apiserverile — readyz, — mis võimaldab eksportida teavet selle valmisoleku (readiness) kohta. Samuti on API-serveril nüüd parameeter --maximum-startup-sequence-duration, mis võimaldab reguleerida selle taaskäivitusi.
Kaks funktsiooni Azure'is on kuulutatud stabiilseks: tugi kättesaadavuse tsoonidele (Availability Zones) ja ristressursside grupile (RG). Lisaks on Azure'sse lisatud:
- tugi autentimiseks AAD ja ADFS;
- märkamine service.beta.kubernetes.io/azure-pip-name avaliku IP määramiseks koormuse tasakaalustajale;
- võimaluse seadistamiseks LoadBalancerName ja LoadBalancerResourceGroup.
AWS-l on nüüd toetamine EBS toetamine Windowsis ja optimeeritud API-kõned EC2-le DescribeInstances.
Kubeadm migreerib nüüd iseseisvalt CoreDNS-i konfiguratsiooni CoreDNS-i versiooni uuendamisel. Binaarfailid
vastavas Docker-pildis etcd world-executable, mis võimaldab selle pildi käivitamist ilma root õigusteta. Lisaks on etcd migratsiooni pildil on teinud tugi etcd2 versioonile. lõpetanud Cluster Autoscaler 1.16.0
Uues lähtus distroless kasutamisest põhja pildina, parandas jõudlust, lisas uusi pilveteenuse pakkujaid (DigitalOcean, Magnum, Packet). Uuendused kasutatavas/sõltuvas tarkvaras: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
🥇Kubernetes 1.16: peamiste uuenduste ülevaade | ProHoster

P.S.

Lugege ka meie blogist:

Allikas: habr.com