Kubernetes 1.16: Hoogtepunte van wat nuut is

Kubernetes 1.16: Hoogtepunte van wat nuut is

Vandag, Woensdag, sal plaasvind volgende weergawe van Kubernetes - 1.16. Volgens die tradisie wat vir ons blog ontwikkel het, is dit die tiende herdenking dat ons praat oor die belangrikste veranderinge in die nuwe weergawe.

Inligting wat gebruik word om hierdie materiaal voor te berei, is geneem uit Kubernetes-verbeteringsopsporingstabelle, VERANDERINGSLOG-1.16 en verwante kwessies, trekversoeke en Kubernetes Enhancement Proposals (KEP). So, kom ons gaan! ..

Knope

'n Werklik groot aantal noemenswaardige innovasies (in alfa-weergawestatus) word aan die kant van die K8s-klusternodusse (Kubelet) aangebied.

Eerstens, die sg «kortstondige houers» (Efemere houers), ontwerp om ontfoutingsprosesse in peule te vereenvoudig. Die nuwe meganisme laat jou toe om spesiale houers te begin wat in die naamruimte van bestaande peule begin en vir 'n kort tydjie lewe. Hulle doel is om met ander peule en houers te kommunikeer om enige probleme op te los en te ontfout. 'n Nuwe opdrag is vir hierdie kenmerk geïmplementeer kubectl debug, soortgelyk in wese aan kubectl exec: slegs in plaas daarvan om 'n proses in 'n houer te laat loop (soos in exec) dit lanseer 'n houer in 'n peul. Byvoorbeeld, hierdie opdrag sal 'n nuwe houer aan 'n peul koppel:

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

Besonderhede oor kortstondige houers (en voorbeelde van hul gebruik) kan gevind word in ooreenstemmende KEP. Die huidige implementering (in K8s 1.16) is 'n alfa-weergawe, en een van die kriteria vir die oordrag daarvan na 'n beta-weergawe is "toetsing van die Ephemeral Containers API vir ten minste 2 vrystellings van [Kubernetes]."

NB: In sy wese en selfs sy naam, die kenmerk lyk soos 'n reeds bestaande inprop kubectl-ontfoutwaaroor ons reeds geskryf. Daar word verwag dat met die koms van kortstondige houers, die ontwikkeling van 'n aparte eksterne inprop sal ophou.

Nog 'n innovasie - PodOverhead - ontwerp om te voorsien meganisme vir die berekening van bokoste vir peule, wat baie kan verskil afhangende van die looptyd wat gebruik word. As voorbeeld, die skrywers hierdie KEP lei tot Kata-houers, wat vereis dat die gaskern, kata-agent, init-stelsel, ens. Wanneer bokoste so groot word, kan dit nie geïgnoreer word nie, wat beteken daar moet 'n manier wees om dit in ag te neem vir verdere kwotas, beplanning, ens. Om dit te implementeer in PodSpec veld bygevoeg Overhead *ResourceList (vergelyk met data in RuntimeClass, indien een gebruik word).

Nog 'n noemenswaardige innovasie is nodus topologie bestuurder (Node Topologie Bestuurder), wat ontwerp is om die benadering tot die fyninstelling van die toewysing van hardewarehulpbronne vir verskeie komponente in Kubernetes te verenig. Hierdie inisiatief word aangedryf deur die groeiende behoefte van verskeie moderne stelsels (van die veld van telekommunikasie, masjienleer, finansiële dienste, ens.) vir hoëprestasie parallelle rekenaars en die minimalisering van vertragings in die uitvoering van bedrywighede, waarvoor hulle gevorderde SVE en hardeware versnelling vermoëns. Sulke optimaliserings in Kubernetes is tot dusver bereik danksy uiteenlopende komponente (SVE-bestuurder, Toestelbestuurder, CNI), en nou sal hulle 'n enkele interne koppelvlak bygevoeg word wat die benadering verenig en die verbinding van nuwe soortgelyke - sogenaamde topologie - vereenvoudig. bewus - komponente aan die Kubelet-kant. Besonderhede - in ooreenstemmende KEP.

Kubernetes 1.16: Hoogtepunte van wat nuut is
Topologie Bestuurder Komponent Diagram

Volgende kenmerk - houers nagaan terwyl hulle loop (opstartsonde). Soos u weet, vir houers wat lank neem om te loods, is dit moeilik om 'n bygewerkte status te kry: hulle word óf "gedood" voordat hulle werklik begin funksioneer, óf hulle beland vir 'n lang tyd in dooiepunt. Nuwe tjek (geaktiveer deur kenmerkhek genoem StartupProbeEnabled) kanselleer - of eerder, stel die effek van enige ander kontrole uit tot die oomblik dat die peul klaar geloop het. Om hierdie rede is die kenmerk oorspronklik genoem peul-opstart lewendig-sonde houoff. Vir peule wat lank neem om te begin, kan jy die toestand in relatief kort tydintervalle peil.

Daarbenewens is 'n verbetering vir RuntimeClass onmiddellik beskikbaar in beta-status, wat ondersteuning vir "heterogene groepe" byvoeg. C RuntimeClass-skedulering Nou is dit glad nie nodig vir elke nodus om ondersteuning vir elke RuntimeClass te hê nie: vir peule kan jy 'n RuntimeClass kies sonder om aan die klustertopologie te dink. Om dit te bereik - sodat peule op nodusse beland met ondersteuning vir alles wat hulle nodig het - was dit voorheen nodig om toepaslike reëls aan NodeSelector en tolerasies toe te ken. IN Kep Dit praat oor voorbeelde van gebruik en, natuurlik, implementeringsbesonderhede.

Netwerk

Twee belangrike netwerkkenmerke wat vir die eerste keer (in alfa-weergawe) in Kubernetes 1.16 verskyn het, is:

  • Ondersteun dubbele netwerkstapel - IPv4/IPv6 - en die ooreenstemmende "begrip" op die vlak van peule, nodusse, dienste. Dit sluit IPv4-tot-IPv4 en IPv6-tot-IPv6-interoperabiliteit tussen peule, van peule tot eksterne dienste, verwysingsimplementerings (binne die Bridge CNI, PTP CNI en Host-Local IPAM-inproppe), sowel as omgekeerde Versoenbaar met Kubernetes-klusters wat loop Slegs IPv4 of IPv6. Implementering besonderhede is in Kep.

    'n Voorbeeld van die vertoon van IP-adresse van twee tipes (IPv4 en IPv6) in die lys van peule:

    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#

  • Nuwe API vir eindpunt - EndpointSlice API. Dit los die prestasie-/skaalbaarheidskwessies van die bestaande Eindpunt-API op wat verskeie komponente in die beheervlak (apiserver, ens., eindpuntbeheerder, kube-instaanbediener) beïnvloed. Die nuwe API sal by die Discovery API-groep gevoeg word en sal tienduisende backend-eindpunte op elke diens in 'n groep wat uit duisende nodusse bestaan, kan bedien. Om dit te doen, word elke diens na N voorwerpe gekarteer EndpointSlice, wat elkeen by verstek nie meer as 100 eindpunte het nie (die waarde is konfigureerbaar). Die EndpointSlice API sal ook geleenthede bied vir sy toekomstige ontwikkeling: ondersteuning vir veelvuldige IP-adresse vir elke peul, nuwe state vir eindpunte (nie net Ready и NotReady), dinamiese subopstelling vir eindpunte.

Die een wat in die laaste weergawe aangebied is, het die beta-weergawe bereik finaliseerder, genoem service.kubernetes.io/load-balancer-cleanup en aangeheg aan elke diens met tipe LoadBalancer. Ten tyde van die verwydering van so 'n diens, verhoed dit die werklike uitvee van die hulpbron totdat die "opruiming" van alle relevante balanseerderhulpbronne voltooi is.

API Masjinerie

Die werklike "stabiliseringsmylpaal" is in die gebied van die Kubernetes API-bediener en interaksie daarmee. Dit het grootliks gebeur te danke aan diegene wat nie spesiale bekendstelling nodig het nie, na 'n stabiele status oor te dra CustomResourceDefinitions (CRD), wat beta-status het sedert die verre dae van Kubernetes 1.7 (en dit is Junie 2017!). Dieselfde stabilisering het by die verwante kenmerke gekom:

  • "subbronne" met /status и /scale vir CustomResources;
  • transformasie weergawes vir CRD, gebaseer op eksterne webhook;
  • onlangs aangebied (in K8s 1.15) verstekwaardes (verstek) en outomatiese veldverwydering (snoei) vir CustomResources;
  • geleentheid die OpenAPI v3-skema te gebruik om OpenAPI-dokumentasie te skep en te publiseer wat gebruik word om CRD-hulpbronne aan die bedienerkant te valideer.

Nog 'n meganisme wat al lank aan Kubernetes-administrateurs bekend geraak het: toelating webhook - het ook lank in beta-status gebly (sedert K8s 1.9) en is nou stabiel verklaar.

Twee ander kenmerke het beta bereik: bediener-kant van toepassing и kyk boekmerke.

En die enigste betekenisvolle innovasie in die alfa-weergawe was mislukking van SelfLink — 'n spesiale URI wat die gespesifiseerde voorwerp verteenwoordig en deel is van ObjectMeta и ListMeta (d.w.s. deel van enige voorwerp in Kubernetes). Hoekom laat vaar hulle dit? Motivering op 'n eenvoudige manier klanke as die afwesigheid van werklike (oorweldigende) redes waarom hierdie veld nog bestaan. Meer formele redes is om werkverrigting te optimaliseer (deur 'n onnodige veld te verwyder) en om die werk van die generiese apibediener te vereenvoudig, wat gedwing word om so 'n veld op 'n spesiale manier te hanteer (dit is die enigste veld wat reg voor die objek gestel is is in reeksvorm). Ware veroudering (binne beta) SelfLink sal gebeur deur Kubernetes weergawe 1.20, en finaal - 1.21.

Datastoor

Die hoofwerk op die gebied van berging, soos in vorige uitgawes, word in die omgewing waargeneem CSI ondersteuning. Die belangrikste veranderinge hier was:

  • vir die eerste keer (in alfa weergawe) verskyn CSI-inpropondersteuning vir Windows-werkknooppunte: die huidige manier van werk met berging sal ook in-boom-inproppe in die Kubernetes-kern vervang en FlexVolume-inproppe van Microsoft gebaseer op Powershell;

    Kubernetes 1.16: Hoogtepunte van wat nuut is
    Skema vir die implementering van CSI-inproppe in Kubernetes vir Windows

  • geleentheid die grootte van CSI-volumes verander, wat terug in K8s 1.12 bekendgestel is, het gegroei tot 'n beta-weergawe;
  • 'n Soortgelyke "promosie" (van alfa na beta) is bereik deur die vermoë om CSI te gebruik om plaaslike kortstondige volumes te skep (CSI Inline Volume Ondersteuning).

Bekendgestel in die vorige weergawe van Kubernetes volume kloning funksie (gebruik bestaande PVC as DataSource om nuwe PVC te skep) het ook nou beta-status ontvang.

Skeduleerder

Twee noemenswaardige veranderinge aan skedulering (albei in alfa):

  • EvenPodsSpreading - geleentheid gebruik peule in plaas van logiese toepassingseenhede vir "billike verspreiding" van vragte (soos Deployment en ReplicaSet) en die aanpassing van hierdie verspreiding (as 'n harde vereiste of as 'n sagte toestand, d.w.s. prioriteit). Die kenmerk sal die bestaande verspreidingsvermoëns van beplande peule uitbrei, tans beperk deur opsies PodAffinity и PodAntiAffinity, wat administrateurs fyner beheer in hierdie saak gee, wat beter hoë beskikbaarheid en geoptimaliseerde hulpbronverbruik beteken. Besonderhede - in Kep.
  • Gebruik BestFit-beleid в RequestedToCapacity Ratio Prioriteitsfunksie tydens peulbeplanning, wat sal toelaat gebruik vullisverpakking ("verpak in houers") vir beide basiese hulpbronne (verwerker, geheue) en uitgebreide (soos GPU). Vir meer besonderhede, sien Kep.

    Kubernetes 1.16: Hoogtepunte van wat nuut is
    Skeduleer peule: voordat die beste pas-beleid gebruik word (direk via verstekskeduleerder) en met die gebruik daarvan (via skeduleerverlenger)

Daarbenewens, verteenwoordig deur die vermoë om jou eie skeduleerder-inproppe buite die hoof Kubernetes-ontwikkelingsboom (buite-boom) te skep.

Ander veranderinge

Ook in die Kubernetes 1.16-vrystelling kan daar kennis geneem word inisiatief vir bring beskikbare maatstawwe in volle volgorde, of meer presies, in ooreenstemming met amptelike regulasies na K8s instrumentasie. Hulle maak grootliks staat op die ooreenstemmende Prometheus dokumentasie. Inkonsekwenthede het om verskeie redes ontstaan ​​(byvoorbeeld, sommige metrieke is eenvoudig geskep voordat die huidige instruksies verskyn het), en die ontwikkelaars het besluit dat dit tyd is om alles op 'n enkele standaard te bring, "in lyn met die res van die Prometheus-ekosisteem." Die huidige implementering van hierdie inisiatief is in alfa-status, wat in opvolgende weergawes van Kubernetes progressief bevorder sal word na beta (1.17) en stabiel (1.18).

Daarbenewens kan die volgende veranderinge opgemerk word:

  • Windows ondersteun ontwikkeling с die opkoms Kubeadm nutsprogramme vir hierdie bedryfstelsel (alfa weergawe), geleentheid RunAsUserName vir Windows-houers (alfa-weergawe), verbetering Groepbestuurde diensrekening (gMSA) ondersteuning tot beta weergawe, ondersteuning monteer/heg aan vir vSphere-volumes.
  • Herwin datakompressiemeganisme in API-antwoorde. Voorheen is 'n HTTP-filter vir hierdie doeleindes gebruik, wat 'n aantal beperkings opgelê het wat verhoed het dat dit by verstek geaktiveer word. "Deursigtige versoekkompressie" werk nou: kliënte stuur Accept-Encoding: gzip in die kopskrif ontvang hulle 'n GZIP-saamgeperste antwoord as die grootte 128 KB oorskry. Go-kliënte ondersteun outomaties kompressie (stuur die vereiste kopskrif), sodat hulle onmiddellik 'n vermindering in verkeer sal opmerk. (Effense wysigings mag nodig wees vir ander tale.)
  • Het moontlik geword skaal HPA van/na nul peule gebaseer op eksterne statistieke. As jy skaal op grond van voorwerpe/eksterne maatstawwe, dan kan jy, wanneer werkladings onaktief is, outomaties skaal na 0 replikas om hulpbronne te bespaar. Hierdie kenmerk behoort veral nuttig te wees vir gevalle waar werkers GPU-hulpbronne versoek, en die aantal verskillende tipes ledige werkers die aantal beskikbare GPU's oorskry.
  • Nuwe kliënt - k8s.io/client-go/metadata.Client - vir "algemene" toegang tot voorwerpe. Dit is ontwerp om maklik metadata te herwin (d.w.s. onderafdeling metadata) uit groeperingshulpbronne en voer vullisverwydering en kwota-operasies daarmee uit.
  • Bou Kubernetes nou kan jy sonder nalatenskap ("ingeboude" in-boom) wolkverskaffers (alfa-weergawe).
  • Na die kubeadm nut bygevoeg eksperimentele (alfa weergawe) vermoë om pasgemaakte kolle tydens bedrywighede toe te pas init, join и upgrade. Kom meer te wete oor hoe om die vlag te gebruik --experimental-kustomize, sien in Kep.
  • Nuwe eindpunt vir apibediener - readyz, - laat jou toe om inligting oor sy gereedheid uit te voer. Die API-bediener het ook nou 'n vlag --maximum-startup-sequence-duration, wat jou toelaat om sy herbegins te reguleer.
  • twee kenmerke vir Azure stabiel verklaar: ondersteuning beskikbaarheid sones (Beskikbaarheidsones) en kruishulpbrongroep (RG). Daarbenewens het Azure bygevoeg:
  • AWS het nou ondersteun vir EBS op Windows en geoptimaliseer EC2 API oproepe DescribeInstances.
  • Kubeadm is nou onafhanklik migreer CoreDNS-konfigurasie wanneer die CoreDNS-weergawe opgegradeer word.
  • Binêre ens in die ooreenstemmende Docker-beeld gemaak wêreld-uitvoerbaar, wat jou toelaat om hierdie prent te laat loop sonder die behoefte aan wortelregte. Ook, ens migrasie beeld gestop etcd2 weergawe ondersteuning.
  • В Cluster Autoscaler 1.16.0 oorgeskakel na die gebruik van distroless as die basisbeeld, verbeterde werkverrigting, bygevoeg nuwe wolkverskaffers (DigitalOcean, Magnum, Packet).
  • Opdaterings in gebruikte/afhanklike sagteware: Gaan 1.12.9, ens 3.3.15, CoreDNS 1.6.2.

PS

Lees ook op ons blog:

Bron: will.com

Voeg 'n opmerking