🥇Kubernetes 1.16: ülevaade peamistest uuendustest

Täna, kolmapäeval, toimub Kubernetese järgmine väljalase - 1.16. Meie ajaveebi jaoks välja kujunenud traditsiooni kohaselt räägime uue versiooni olulisematest muudatustest juba kümnendat korda.

Selle materjali ettevalmistamiseks kasutatud teave on võetud Kubernetese täiustuste jälgimistabelid, MUUTUS-1.16 ja sellega seotud probleemid, tõmbetaotlused ja Kubernetes Enhancement Proposals (KEP). Nii et lähme!..

Sõlmed

K8s klastri sõlmede (Kubelet) küljel on esitatud tõeliselt suur hulk märkimisväärseid uuendusi (alfa versiooni olekus).

Esiteks nn «efemeersed mahutid» (Efemeraalsed konteinerid), mis on loodud kaunade silumisprotsesside lihtsustamiseks. Uus mehhanism võimaldab käivitada spetsiaalseid konteinereid, mis algavad olemasolevate kaunade nimeruumist ja elavad lühikest aega. Nende eesmärk on suhelda teiste kaustade ja konteineritega, et probleeme lahendada ja siluda. Selle funktsiooni jaoks on rakendatud uus käsk kubectl debug, mis on sisuliselt sarnane kubectl exec: ainult selle asemel, et protsessi konteineris käivitada (nagu exec) laseb see kaunas oleva konteineri vette. Näiteks ühendab see käsk uue konteineri kaustaga:

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

Üksikasjad lühiajaliste konteinerite kohta (ja nende kasutamise näited) leiate aadressilt vastav KEP. Praegune juurutus (K8s 1.16-s) on alfaversioon ja selle beetaversioonile ülekandmise kriteeriumide hulgas on "Ephemeral Containers API testimine vähemalt kahe [Kubernetese] versiooni jaoks".

NB: Oma olemuselt ja isegi nime poolest meenutab funktsioon juba olemasolevat pistikprogrammi kubectl-debugmille kohta me juba kirjutas. Eeldatakse, et efemeersete konteinerite tulekuga peatub eraldi välise plugina arendamine.

Veel üks uuendus - PodOverhead - mõeldud pakkuma kaunade üldkulude arvutamise mehhanism, mis võib olenevalt kasutatavast käitusajast oluliselt erineda. Näiteks autorid see KEP tulemuseks on Kata konteinerid, mis nõuavad külalistuuma, kata agenti, init-süsteemi jne käivitamist. Kui üldkulud muutuvad nii suureks, ei saa seda ignoreerida, mis tähendab, et peab olema võimalus seda arvesse võtta edasiste kvootide, planeerimise jms jaoks. Selle rakendamiseks PodSpec väli lisatud Overhead *ResourceList (võrreldes andmetega RuntimeClass, kui seda kasutatakse).

Teine tähelepanuväärne uuendus on sõlme topoloogiahaldur (sõlme topoloogiahaldur), mille eesmärk on ühtlustada lähenemisviisi Kubernetese erinevate komponentide riistvararessursside jaotamisel. Selle algatuse põhjuseks on kasvav vajadus erinevate kaasaegsete süsteemide (telekommunikatsiooni, masinõppe, finantsteenuste jne valdkonnast) suure jõudlusega paralleelarvutite ja toimingute sooritamise viivituste minimeerimise järele, milleks nad kasutavad täiustatud protsessorit ja protsessorit. riistvaralise kiirenduse võimalused. Sellised optimeerimised Kubernetes on seni saavutatud tänu erinevatele komponentidele (CPU haldur, seadmehaldur, CNI) ja nüüd lisatakse neile ühtne sisemine liides, mis ühtlustab lähenemist ja lihtsustab uute sarnaste – nn topoloogia- ühendamist. teadlik - komponendid Kubeleti poolel. Üksikasjad - sisse vastav KEP.

Topoloogiahalduri komponentskeem

Järgmine funktsioon - konteinerite kontrollimine nende töötamise ajal (käivitussond). Teatavasti on konteinerite puhul, mille käivitamine võtab kaua aega, raske saada ajakohast staatust: need kas "tõrjutakse" enne, kui nad tegelikult tööle hakkavad, või satuvad nad pikaks ajaks ummikusse. Uus kontroll (lubatud funktsioonivärava kaudu StartupProbeEnabled) tühistab või pigem lükkab edasi kõigi muude kontrollide mõju hetkeni, mil pod on töötamise lõpetanud. Sel põhjusel nimetati seda funktsiooni algselt pod-startup liveness-probe kinnipidamine. Kaunade puhul, mille käivitamine võtab kaua aega, saate oleku küsitluse teha suhteliselt lühikeste ajavahemike järel.

Lisaks on RuntimeClassi täiustus kohe saadaval beetaversioonis, lisades toe heterogeensetele klastritele. C RuntimeClassi ajakava Nüüd pole üldse vaja, et igal sõlmel oleks iga RuntimeClassi tugi: kaustade jaoks saate valida RuntimeClassi ilma klastri topoloogiale mõtlemata. Varem oli selle saavutamiseks - et kaunad jõuaksid sõlmedesse, mis toetavad kõike, mida nad vajavad -, oli vaja määrata NodeSelectorile ja tolerantidele vastavad reeglid. IN KEP Räägitakse kasutusnäidetest ja muidugi teostuse üksikasjadest.

Сеть

Kaks olulist võrgufunktsiooni, mis ilmusid Kubernetes 1.16-s esimest korda (alfaversioonis), on järgmised:

Toetama kahe võrgu virn – IPv4/IPv6 - ja sellele vastav "mõistmine" kaunade, sõlmede, teenuste tasemel. See sisaldab IPv4-lt IPv4-le ja IPv6-le IPv6-le koostalitlusvõimet kabikute vahel, alates kaustadest kuni välisteenusteni, viiterakendusi (Bridge CNI, PTP CNI ja Host-Local IPAM-i pistikprogrammides), samuti vastupidist ühilduvust töötavate Kubernetese klastritega. Ainult IPv4 või IPv6. Rakenduse üksikasjad on saadaval KEP.
Näide kahte tüüpi IP-aadresside (IPv4 ja IPv6) kuvamise kohta kaustade 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 lõpp-punkti jaoks - EndpointSlice API. See lahendab olemasoleva Endpoint API jõudluse/mastaapsuse probleemid, mis mõjutavad juhttasandi erinevaid komponente (apiserver jne, lõpp-kontroller, kube-puhverserver). Uus API lisatakse Discovery API rühma ja see suudab teenindada kümneid tuhandeid taustalõpp-punkte igas teenuses tuhandetest sõlmedest koosnevas klastris. Selleks kaardistatakse iga teenus N objektiga EndpointSlice, millest igaühel ei ole vaikimisi rohkem kui 100 lõpp-punkti (väärtus on konfigureeritav). EndpointSlice API pakub ka võimalusi selle edasiseks arendamiseks: tugi mitmele IP-aadressile igale kaustale, uued olekud lõpp-punktidele (mitte ainult Ready и NotReady), lõpp-punktide dünaamiline alamseade.

Viimases versioonis esitatud versioon on jõudnud beetaversiooni lõpetaja, nimega service.kubernetes.io/load-balancer-cleanup ja lisatud igale teenusele koos tüübiga LoadBalancer. Sellise teenuse kustutamise ajal takistab see ressursi tegelikku kustutamist, kuni kõigi asjakohaste tasakaalustaja ressursside "puhastamine" on lõpetatud.

API masinad

Tõeline "stabiliseerimise verstapost" on Kubernetes API serveri ja sellega suhtlemise valdkonnas. See juhtus suuresti tänu stabiilsesse staatusesse üleviimine need, kes ei vaja erilist tutvustamist CustomResourceDefinitions (CRD), millel on beetaversioon olnud Kubernetes 1.7 kaugetest aegadest (ja see on juuni 2017!). Sama stabiliseerimine tuli seotud funktsioonidega:

"allressursid" koos /status и /scale CustomResourcesi jaoks;
teisendamine CRD versioonid, mis põhinevad välisel veebihaagil;
hiljuti esitletud (K8s 1.15-s) vaikeväärtused (vaikimisi) ja automaatne põllu eemaldamine (pügamine) CustomResourcesi jaoks;
võimalus kasutades OpenAPI v3 skeemi OpenAPI dokumentatsiooni loomiseks ja avaldamiseks, mida kasutatakse serveripoolse CRD ressursside valideerimiseks.

Veel üks mehhanism, mis on Kubernetese administraatoritele juba ammu tuttavaks saanud: sissepääsu veebihaak - püsis ka pikka aega beeta staatuses (alates K8s 1.9) ja on nüüd kuulutatud stabiilseks.

Kaks muud funktsiooni on jõudnud beetaversiooni: serveripoolne rakendus и vaadata järjehoidjaid.

Ja ainus oluline uuendus alfaversioonis oli ebaõnnestumine pärit SelfLink — spetsiaalne URI, mis esindab määratud objekti ja on selle osa ObjectMeta и ListMeta (st osa Kubernetesis mis tahes objektist). Miks nad sellest loobuvad? Motivatsioon lihtsal viisil kõlab kui tegelike (ülekaalukate) põhjuste puudumine selle valdkonna endiselt eksisteerimiseks. Formaalsemad põhjused on jõudluse optimeerimine (ebavajaliku välja eemaldamisega) ja geneerilise apiserveri töö lihtsustamine, mis on sunnitud sellist välja eriliselt käsitlema (see on ainus väli, mis määratakse vahetult enne objekti on serialiseeritud). Tõeline vananemine (beetaversioonis) SelfLink toimub Kubernetese versiooniga 1.20 ja lõpliku versiooniga 1.21.

Andmekogu

Ladustamise valdkonnas tehakse põhitööd, nagu ka eelmistes väljaannetes, selles piirkonnas CSI tugi. Peamised muudatused siin olid järgmised:

esimest korda (alfa versioonis) ilmus CSI pistikprogrammi tugi Windowsi töötaja sõlmedele: praegune salvestusviisiga töötamise viis asendab ka Kubernetese tuumas olevad puusisesed pistikprogrammid ja Microsofti Powershellil põhinevad FlexVolume'i pistikprogrammid;

Skeem CSI pistikprogrammide juurutamiseks Kubernetes for Windowsis
võimalus CSI mahtude suuruse muutmine, mida tutvustati K8s 1.12-s, on kasvanud beetaversiooniks;
Sarnane "edendus" (alfast beetaversioonile) saavutati võimalusega kasutada CSI-d kohalike lühiajaliste köidete loomiseks (CSI sisemine helitugevuse tugi).

Kasutusele võetud Kubernetese eelmises versioonis mahu kloonimise funktsioon (kasutades olemasolevat PVC-d nagu DataSource uue PVC loomiseks) on nüüdseks saanud ka beetastaatuse.

Planeerija

Kaks märkimisväärset muudatust ajakavas (mõlemad alfa):

EvenPodsSpreading - võimalus kasutage koormate "õiglaseks jaotamiseks" loogiliste rakendusüksuste asemel kaustasid (nagu juurutamine ja ReplicaSet) ja selle jaotuse kohandamine (kas range nõudena või pehme tingimusena, st prioriteedina). Funktsioon laiendab kavandatud kaustade olemasolevaid levitamisvõimalusi, mida praegu piiravad valikud PodAffinity и PodAntiAffinity, mis annab administraatoritele selles küsimuses täpsema kontrolli, mis tähendab paremat kõrget kättesaadavust ja optimeeritud ressursitarbimist. Üksikasjad - sisse KEP.
Kasutama BestFiti poliitika в Prioriteedifunktsioon RequestedToCapacityRatio kaunade planeerimise ajal, mis võimaldab kohaldada prügikasti pakkimine ("konteineritesse pakkimine") nii põhiressursside (protsessor, mälu) kui ka laiendatud ressursside (nt GPU) jaoks. Täpsemalt vt KEP.

Kataloogide ajastamine: enne parima sobivuse poliitika kasutamist (otse vaikeplaneerija kaudu) ja selle kasutamisega (planeerija laiendi kaudu)

Lisaks on esitatud võimalus luua oma planeerija pluginaid väljaspool Kubernetese peamist arenduspuud (puuväline).

Muud muudatused

Samuti võite märkida Kubernetes 1.16 versiooni algatus toomine saadaolevad mõõdikud täielikus järjekorras, või täpsemalt kooskõlas ametlikud määrused K8s aparatuurile. Nad tuginevad suuresti vastavale Prometheuse dokumentatsioon. Ebakõlad tekkisid erinevatel põhjustel (näiteks mõned mõõdikud loodi lihtsalt enne praeguste juhiste ilmumist) ja arendajad otsustasid, et on aeg viia kõik ühtse standardi juurde, "kooskõlas ülejäänud Prometheuse ökosüsteemiga". Selle algatuse praegune rakendamine on alfaolekus, mis viiakse Kubernetese järgmistes versioonides järk-järgult üle beetaversiooniks (1.17) ja stabiilseks (1.18).

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

Windowsi tugi arendus с välimus Kubeadmi utiliidid selle OS-i jaoks (alfaversioon), võimalus RunAsUserName Windowsi konteinerite jaoks (alfaversioon), parandamine Grupi hallatava teenuse konto (gMSA) tugi kuni beetaversioonini, toetus paigalda/kinnita vSphere'i köidete jaoks.
Taaskasutatud andmete tihendamise mehhanism API vastustes. Varem kasutati nendel eesmärkidel HTTP-filtrit, mis kehtestas mitmeid piiranguid, mis takistasid selle vaikimisi lubamist. "Läbipaistev päringu tihendamine" töötab nüüd: kliendid saadavad Accept-Encoding: gzip päises saavad nad GZIP-tihendatud vastuse, kui selle suurus ületab 128 KB. Go kliendid toetavad automaatselt tihendamist (vajaliku päise saatmist), nii et nad märkavad koheselt liikluse vähenemist. (Teiste keelte puhul võib vaja minna kergeid muudatusi.)
Sai võimalikuks HPA skaleerimine nullist/null-punktist väliste mõõdikute põhjal. Kui skaleerite objektide/väliste mõõdikute põhjal, saate jõudeoleku ajal ressursside säästmiseks skaleerida automaatselt 0-le koopiatele. See funktsioon peaks olema eriti kasulik juhtudel, kui töötajad taotlevad GPU ressursse ja erinevat tüüpi tegevusetute töötajate arv ületab saadaolevate GPU-de arvu.
Uus klient - k8s.io/client-go/metadata.Client — "üldise" juurdepääsu jaoks objektidele. See on loodud metaandmete (st alamjaotise) hõlpsaks hankimiseks metadata) klastri ressurssidest ning teha nendega prügikoristus- ja kvooditoiminguid.
Ehitage Kubernetes nüüd sa saad ilma pärand („sisseehitatud“ puusiseste) pilvepakkujateta (alfaversioon).
Kubeadmi utiliidi juurde lisatud eksperimentaalne (alfaversioon) võimalus rakendada operatsioonide ajal kohandatud plaastreid init, join и upgrade. Lisateavet lipu kasutamise kohta --experimental-kustomize, vaata sisse KEP.
Apiserveri uus lõpp-punkt – readyz, - võimaldab eksportida teavet selle valmisoleku kohta. API serveril on nüüd ka lipp --maximum-startup-sequence-duration, mis võimaldab teil reguleerida selle taaskäivitamist.
Kaks funktsioonid Azure'i jaoks stabiilseks kuulutatud: toetus saadavuse tsoonid (Saadavaloleku tsoonid) ja ressursirühm (RG). Lisaks on Azure lisanud:
- autentimise tugi AAD ja ADFS;
- annotatsioon service.beta.kubernetes.io/azure-pip-name määrata koormuse tasakaalustaja avalik IP;
- võimalus настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS on nüüd olemas toetama EBS jaoks Windowsis ja optimeeritud EC2 API kõned DescribeInstances.
Kubeadm on nüüd iseseisev rändab CoreDNS-i konfiguratsioon CoreDNS-i versiooni uuendamisel.
Binaarid jne vastaval Dockeri pildil tehtud world-executable, mis võimaldab teil seda pilti käivitada ilma juurõigusi kasutamata. Samuti jne migratsioonipilt lõpetatud etcd2 versiooni tugi.
В Cluster Autoscaler 1.16.0 läks üle distrolessi kasutamisele põhipildina, paranes jõudlus, lisati uued pilvepakkujad (DigitalOcean, Magnum, Packet).
Värskendused kasutatud/sõltuvas tarkvaras: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Loe ka meie blogist:

Allikas: www.habr.com

Kubernetes 1.16: uudiste esiletõstmised