🥇Kubernetes 1.16: superrigardo de la ĉefaj novigoj

Hodiaŭ, merkredo, okazos sekva eldono de Kubernetes - 1.16. Laŭ la tradicio, kiu disvolviĝis por nia blogo, ĉi tiu estas la deka datreveno kiam ni parolas pri la plej signifaj ŝanĝoj en la nova versio.

Informoj uzataj por prepari ĉi tiun materialon estas prenita de Kubernetes-plibonigoj spurantaj tabeloj, ŜANĜOLOGO-1.16 kaj rilataj aferoj, tirpetoj kaj Kubernetes Enhancement Proposals (KEP). Do, ni iru!...

Nodoj

Vere granda nombro da rimarkindaj novigoj (en alfa-versiostatuso) estas prezentita flanke de la K8s-aretnodoj (Kubelet).

Unue, la tn «efemeraj ujoj» (Efemeraj Ujoj), dizajnita por simpligi sencimigajn procezojn en podoj. La nova mekanismo ebligas al vi lanĉi specialajn ujojn, kiuj komenciĝas en la nomspaco de ekzistantaj podoj kaj vivas por mallonga tempo. Ilia celo estas interagi kun aliaj podoj kaj ujoj por solvi ajnajn problemojn kaj sencimigi. Nova komando estis efektivigita por ĉi tiu funkcio kubectl debug, simila en esenco al kubectl exec: nur anstataŭ ruli procezon en ujo (kiel en exec) ĝi lanĉas ujon en balgo. Ekzemple, ĉi tiu komando konektos novan ujon al pod:

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

Detaloj pri efemeraj ujoj (kaj ekzemploj de ilia uzo) troviĝas en responda KEP. La nuna efektivigo (en K8s 1.16) estas alfa versio, kaj inter la kriterioj por ĝia translokigo al beta-versio estas "testi la Ephemeral Containers API por almenaŭ 2 eldonoj de [Kubernetes]."

NB: En ĝia esenco kaj eĉ ĝia nomo, la trajto similas jam ekzistantan kromprogramon kubectl-debugpri kiu ni jam skribis. Oni atendas, ke kun la apero de efemeraj ujoj ĉesos la disvolviĝo de aparta ekstera kromaĵo.

Alia novigo - PodOverhead - desegnita por provizi mekanismo por kalkuli superkostojn por podoj, kiu povas multe varii depende de la rultempo uzata. Ekzemple, la aŭtoroj ĉi tiu KEP rezultigas Kata Containers, kiuj postulas ruli la gastkernon, kata-agenton, initsistemon ktp. Kiam la superkosto fariĝas tiel granda, ĝi ne povas esti ignorita, kio signifas, ke necesas esti maniero konsideri ĝin por pliaj kvotoj, planado ktp. Por efektivigi ĝin en PodSpec kampo aldonita Overhead *ResourceList (komparas kun datumoj en RuntimeClass, se oni uzas).

Alia rimarkinda novigo estas noda topologia administranto (Noda Topologia Administranto), dizajnita por unuigi la aliron al fajnagordado de la asigno de hardvarresursoj por diversaj komponentoj en Kubernetes. Ĉi tiu iniciato estas movita de la kreskanta bezono de diversaj modernaj sistemoj (el la kampo de telekomunikado, maŝinlernado, financaj servoj, ktp.) por alt-efikeca paralela komputado kaj minimumigi prokrastojn en la plenumado de operacioj, por kiuj ili uzas altnivelan CPU kaj hardvaraj akcelkapabloj. Tiaj optimumigoj en Kubernetes ĝis nun estis atingitaj danke al malsimilaj komponantoj (CPU-administranto, Aparato-administranto, CNI), kaj nun ili estos aldonitaj ununura interna interfaco, kiu unuigas la aliron kaj simpligas la konekton de novaj similaj - t.n. topologio- konsciaj - komponantoj ĉe la flanko de Kubelet. Detaloj - en responda KEP.

Topology Manager Komponento Diagramo

Sekva funkcio - kontrolante ujojn dum ili funkcias (startenketo). Kiel vi scias, por ujoj, kiuj bezonas longan tempon por lanĉi, estas malfacile akiri ĝisdatigitan statuson: ili aŭ estas "mortigitaj" antaŭ ol ili efektive ekfunkcias, aŭ ili finiĝas en blokiĝo dum longa tempo. Nova ĉeko (ebligita per trajtopordego nomita StartupProbeEnabled) nuligas - aŭ pli ĝuste, prokrastas - la efikon de iuj aliaj kontroloj ĝis la momento, kiam la pod finiĝos. Tial, la trajto estis origine nomita pod-startup liveness-probe holdoff. Por balgoj kiuj bezonas longan tempon por komenci, vi povas sondi la ŝtaton en relative mallongaj tempointervaloj.

Krome, plibonigo por RuntimeClass estas tuj havebla en beta-statuso, aldonante subtenon por "heterogenaj aretoj". C RuntimeClass Planado Nun tute ne necesas, ke ĉiu nodo havu subtenon por ĉiu RuntimeClass: por podoj vi povas elekti RuntimeClass sen pensi pri la cluster-topologio. Antaŭe, por atingi ĉi tion - por ke balgoj finiĝas sur nodoj kun subteno por ĉio, kion ili bezonas - estis necese asigni taŭgajn regulojn al NodeSelector kaj toleroj. EN Kep Ĝi parolas pri ekzemploj de uzo kaj, kompreneble, realigaj detaloj.

Reto

Du signifaj interkonektaj funkcioj, kiuj aperis unuafoje (en alfa versio) en Kubernetes 1.16, estas:

subteno duobla reto stako - IPv4/IPv6 - kaj ĝia responda "kompreno" je la nivelo de podoj, nodoj, servoj. Ĝi inkluzivas IPv4-al-IPv4 kaj IPv6-al-IPv6-kunfunkcieblecon inter balgoj, de balgoj ĝis eksteraj servoj, referencaj efektivigoj (ene de la aldonaĵoj Bridge CNI, PTP CNI kaj Host-Local IPAM), same kiel inversan Kongruan kun Kubernetes-aretoj kurantaj. IPv4 aŭ IPv6 nur. Detaloj pri efektivigo estas en Kep.
Ekzemplo de montrado de IP-adresoj de du tipoj (IPv4 kaj IPv6) en la listo de podoj:
```
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#
```
Nova API por Endpoint - EndpointSlice API. Ĝi solvas la problemojn pri rendimento/skaleblo de la ekzistanta Endpoint API, kiuj influas diversajn komponentojn en la kontrolaviadilo (apiserver, etcd, endpoints-controller, kube-proxy). La nova API estos aldonita al la grupo Discovery API kaj povos servi dekojn da miloj da backend finpunktoj sur ĉiu servo en areto konsistanta el miloj da nodoj. Por fari tion, ĉiu Servo estas mapita al N objektoj EndpointSlice, ĉiu el kiuj defaŭlte havas ne pli ol 100 finpunktojn (la valoro estas agordebla). La EndpointSlice API ankaŭ provizos ŝancojn por sia estonta evoluo: subteno por multoblaj IP-adresoj por ĉiu pod, novaj ŝtatoj por finpunktoj (ne nur Ready и NotReady), dinamika subaro por finpunktoj.

Tiu prezentita en la lasta eldono atingis la beta-version finigilo, nomita service.kubernetes.io/load-balancer-cleanup kaj alkroĉita al ĉiu servo kun tipo LoadBalancer. En la momento de forigo de tia servo, ĝi malhelpas la realan forigon de la rimedo ĝis la "purigado" de ĉiuj koncernaj ekvilibraj rimedoj finiĝos.

API-Maŝinaro

La vera "stabiliga mejloŝtono" estas en la areo de la Kubernetes API-servilo kaj interago kun ĝi. Ĉi tio okazis plejparte danke al transdonante al stabila statuso tiujn, kiuj ne bezonas specialan enkondukon Propraj RimedajDifinoj (CRD), kiuj havas beta-statuson ekde la foraj tagoj de Kubernetes 1.7 (kaj ĉi tio estas junio 2017!). La sama stabiligo venis al la rilataj ecoj:

"subrimedoj" el /status и /scale por CustomResources;
transformo versioj por CRD, surbaze de ekstera rethoko;
lastatempe prezentita (en K8s 1.15) defaŭltaj valoroj (defaŭlte) kaj aŭtomata forigo de kampoj (tondado) por CustomResources;
ŝanco uzante la OpenAPI v3-skemon por krei kaj publikigi OpenAPI-dokumentadon uzatan por validigi CRD-resursojn ĉe la servilflanko.

Alia mekanismo, kiu longe familiariĝis al administrantoj de Kubernetes: agnosko rethook - ankaŭ restis en beta-stato dum longa tempo (ekde K8s 1.9) kaj nun estas deklarita stabila.

Du aliaj funkcioj atingis beta-on: servil-flanko apliki и spekti legosignojn.

Kaj la sola signifa novigo en la alfa versio estis malsukceso el SelfLink — speciala URI reprezentanta la specifitan objekton kaj estante parto de ObjectMeta и ListMeta (t.e. parto de iu ajn objekto en Kubernetes). Kial ili forlasas ĝin? Instigo en simpla maniero sonas kiel la foresto de realaj (superfortaj) kialoj por tiu ĉi kampo ankoraŭ ekzisti. Pli formalaj kialoj estas optimumigi rendimenton (forigante nenecesan kampon) kaj simpligi la laboron de la generic-apiserver, kiu estas devigita trakti tian kampon en speciala maniero (ĉi tiu estas la nura kampo kiu estas agordita ĝuste antaŭ la objekto. estas seriigita). Vera malnoviĝo (ene de betao) SelfLink okazos per Kubernetes versio 1.20, kaj fina - 1.21.

Stokado de datumoj

La ĉefa laboro en la areo de stokado, kiel en antaŭaj eldonoj, estas observita en la areo CSI-subteno. La ĉefaj ŝanĝoj ĉi tie estis:

unuafoje (en alfa-versio) aperis CSI-kromsubteno por Windows-labornodoj: la nuna maniero labori kun stokado ankaŭ anstataŭigos enarbajn kromaĵojn en la Kubernetes-kerno kaj FlexVolume-aldonaĵojn de Microsoft bazitaj sur Powershell;

Skemo por efektivigi CSI-kromaĵojn en Kubernetes por Vindozo
ŝanco regrandigi CSI-volumojn, enkondukita reen en K8s 1.12, kreskis al beta-versio;
Simila "reklamo" (de alfao ĝis betao) estis atingita per la kapablo uzi CSI por krei lokajn efemerajn volumojn (CSI Inline Volume Subteno).

Enkondukite en la antaŭa versio de Kubernetes volumena klona funkcio (uzante ekzistantan PVC kiel DataSource krei novan PVC) ankaŭ nun ricevis beta-statuson.

Planilo

Du rimarkindaj ŝanĝoj al planado (ambaŭ en alfao):

EvenPodsSpreading - ŝanco uzu podojn anstataŭ logikaj aplikaĵunuoj por "justa distribuo" de ŝarĝoj (kiel Deployment kaj ReplicaSet) kaj ĝustigante ĉi tiun distribuon (kiel malfacila postulo aŭ kiel mola kondiĉo, t.e. prioritato). La funkcio vastigos la ekzistantajn distribuajn kapablojn de planitaj podoj, nuntempe limigitaj de elektoj PodAffinity и PodAntiAffinity, donante al administrantoj pli fajnan kontrolon en ĉi tiu afero, kio signifas pli bonan altan haveblecon kaj optimumigitan resursan konsumon. Detaloj - en Kep.
Uzo Politiko de BestFit в RequestedToCapacityRatio Prioritata Funkcio dum podplanado, kio permesos uzi pakado de rubujo ("pakado en ujoj") kaj por bazaj rimedoj (procesoro, memoro) kaj plilongigitaj (kiel GPU). Por pliaj detaloj, vidu Kep.

Planado de podoj: antaŭ ol uzi plej bone taŭgan politikon (rekte per defaŭlta planilo) kaj kun ĝia uzo (per planilo-etendilo)

Krome, РїСЂРµРґСЃС‚Р ° РІР »РµРЅР ° la kapablo krei viajn proprajn programilajn kromaĵojn ekster la ĉefa disvolva arbo de Kubernetes (ekstere).

Aliaj ŝanĝoj

Ankaŭ en la eldono de Kubernetes 1.16 ĝi povas esti notita iniciato por alportante disponeblaj metrikoj en plena ordo, aŭ pli precize, konforme al oficialaj regularoj al K8s-instrumentado. Ili plejparte dependas de la responda Prometheus-dokumentado. Nekongruoj aperis pro diversaj kialoj (ekzemple, iuj metrikoj estis simple kreitaj antaŭ ol la nunaj instrukcioj aperis), kaj la programistoj decidis, ke estas tempo alporti ĉion al ununura normo, "laŭ la resto de la Prometheus-ekosistemo." La nuna efektivigo de ĉi tiu iniciato estas en alfa statuso, kiu estos laŭstadie antaŭenigita en postaj versioj de Kubernetes al beta (1.17) kaj stabila (1.18).

Krome, la sekvaj ŝanĝoj povas esti notitaj:

Vindozo subtenas evoluon с aspekto Kubeadm-utiloj por ĉi tiu OS (alfa-versio), ŝanco RunAsUserName por Vindozaj ujoj (alfa-versio), plibonigo Subteno de Group Managed Service Account (gMSA) ĝis beta-versio, subteno munti/alfiksi por vSphere-volumoj.
Reciklita datumkunprema mekanismo en API-respondoj. Antaŭe, HTTP-filtrilo estis uzita por ĉi tiuj celoj, kiu trudis kelkajn restriktojn kiuj malhelpis ĝin esti ebligita defaŭlte. "Travidebla peto kunpremo" nun funkcias: klientoj sendante Accept-Encoding: gzip en la kaplinio, ili ricevas GZIP-kunpremitan respondon se ĝia grandeco superas 128 KB. Go-klientoj aŭtomate subtenas kunpremadon (sendante la bezonatan kaplinion), do ili tuj rimarkos redukton de trafiko. (Eble necesas etaj modifoj por aliaj lingvoj.)
Iĝis ebla grimpi HPA de/al nul balgoj bazitaj sur eksteraj metrikoj. Se vi skalas laŭ objektoj/eksteraj metrikoj, tiam kiam laborkvantoj estas neaktivaj, vi povas aŭtomate grimpi al 0 kopioj por ŝpari rimedojn. Ĉi tiu funkcio devus esti speciale utila por kazoj kie laboristoj petas GPU-resursojn, kaj la nombro da malsamaj specoj de neaktivaj laboristoj superas la nombron da disponeblaj GPUoj.
Nova kliento - k8s.io/client-go/metadata.Client — por "ĝeneraligita" aliro al objektoj. Ĝi estas dizajnita por facile preni metadatenojn (t.e. subfako metadata) de aretresursoj kaj fari rubkolekton kaj kvotoperaciojn kun ili.
Konstruu Kubernetes nun vi povas sen heredaĵo ("enkonstruita" en-arbo) nubaj provizantoj (alfa-versio).
Al la ilo kubeadm aldonis eksperimenta (alfa-versio) kapablo apliki personecigajn flikaĵojn dum operacioj init, join и upgrade. Lernu pli pri kiel uzi la flagon --experimental-kustomize, vidu en Kep.
Nova finpunkto por apiserver - readyz, - permesas eksporti informojn pri ĝia preteco. La API-servilo ankaŭ nun havas flagon --maximum-startup-sequence-duration, permesante al vi reguligi ĝiajn rekomencojn.
Du funkcioj por Azure deklarita stabila: subteno haveblecaj zonoj (Haveblecaj Zonoj) kaj transrimeda grupo (RG). Krome, Azure aldonis:
- aŭtentikiga subteno AAD kaj ADFS;
- komentario service.beta.kubernetes.io/azure-pip-name specifi la publikan IP de la ŝarĝbalancilo;
- ŝanco agordojn LoadBalancerName и LoadBalancerResourceGroup.
AWS nun havas subteno por EBS sur Vindozo kaj optimumigita Vokoj de EC2 API DescribeInstances.
Kubeadm nun estas sendependa migras CoreDNS-agordo dum ĝisdatigo de la CoreDNS-versio.
Binaroj ktp en la responda bildo de Docker farita mond-efektivebla, kiu ebligas al vi ruli ĉi tiun bildon sen la bezono de radikaj rajtoj. Ankaŭ, etcd migra bildo haltis etcd2 versio subteno.
В Cluster Autoscaler 1.16.0 ŝanĝis al uzado de distroless kiel la baza bildo, plibonigita efikeco, aldonis novajn nubajn provizantoj (DigitalOcean, Magnum, Packet).
Ĝisdatigoj en uzata/dependa programaro: Iru 1.12.9, ktpd 3.3.15, CoreDNS 1.6.2.

PS

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Kubernetes 1.16: Kulminaĵoj de kio estas nova