🥇Kubernetes 1.16: pangkalahatang-ideya ng mga pangunahing inobasyon

Ngayon, Miyerkules, magaganap susunod na paglabas ng Kubernetes - 1.16. Ayon sa tradisyon na binuo para sa aming blog, ito ang ikasampung anibersaryo ng oras na pinag-uusapan natin ang mga pinakamahalagang pagbabago sa bagong bersyon.

Ang impormasyong ginamit sa paghahanda ng materyal na ito ay kinuha mula sa Mga talahanayan ng pagsubaybay sa mga pagpapahusay ng Kubernetes, CHANGELOG-1.16 at mga kaugnay na isyu, pull request, at Kubernetes Enhancement Proposals (KEP). Kaya tara na!..

Mga node

Ang isang tunay na malaking bilang ng mga kapansin-pansing inobasyon (sa alpha version status) ay ipinakita sa gilid ng mga K8s cluster node (Kubelet).

Una, ang tinatawag na «ephemeral na mga lalagyan» (Ephemeral Container), na idinisenyo upang pasimplehin ang mga proseso ng pag-debug sa mga pod. Ang bagong mekanismo ay nagbibigay-daan sa iyo na maglunsad ng mga espesyal na lalagyan na nagsisimula sa namespace ng mga umiiral nang pod at mabuhay sa maikling panahon. Ang kanilang layunin ay makipag-ugnayan sa iba pang mga pod at container upang malutas ang anumang mga problema at pag-debug. Isang bagong command ang ipinatupad para sa feature na ito kubectl debug, katulad sa esensya sa kubectl exec: lamang sa halip na magpatakbo ng isang proseso sa isang lalagyan (tulad ng sa exec) naglulunsad ito ng lalagyan sa isang pod. Halimbawa, ang utos na ito ay magkokonekta ng isang bagong lalagyan sa isang pod:

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

Ang mga detalye tungkol sa mga ephemeral na lalagyan (at mga halimbawa ng kanilang paggamit) ay matatagpuan sa kaukulang KEP. Ang kasalukuyang pagpapatupad (sa K8s 1.16) ay isang alpha na bersyon, at kabilang sa mga pamantayan para sa paglipat nito sa isang beta na bersyon ay ang "pagsubok sa Ephemeral Containers API para sa hindi bababa sa 2 release ng [Kubernetes]."

NB: Sa kakanyahan nito at maging ang pangalan nito, ang tampok ay kahawig ng isang umiiral nang plugin kubectl-debugtungkol sa kung saan kami nagsulat na. Inaasahan na sa pagdating ng mga ephemeral na lalagyan, ang pagbuo ng isang hiwalay na panlabas na plugin ay titigil.

Isa pang pagbabago - PodOverhead - dinisenyo upang magbigay mekanismo para sa pagkalkula ng mga gastos sa overhead para sa mga pod, na maaaring mag-iba nang malaki depende sa runtime na ginamit. Bilang halimbawa, ang mga may-akda itong KEP magreresulta sa Kata Containers, na nangangailangan ng pagpapatakbo ng guest kernel, kata agent, init system, atbp. Kapag ang overhead ay naging napakalaki, hindi ito maaaring balewalain, na nangangahulugang mayroong isang paraan upang isaalang-alang ito para sa karagdagang mga quota, pagpaplano, atbp. Upang ipatupad ito sa PodSpec idinagdag ang field Overhead *ResourceList (kumpara sa data sa RuntimeClass, kung ang isa ay ginagamit).

Ang isa pang kapansin-pansing pagbabago ay manager ng node topology (Node Topology Manager), na idinisenyo upang pag-isahin ang diskarte sa pag-fine-tune ng paglalaan ng mga mapagkukunan ng hardware para sa iba't ibang bahagi sa Kubernetes. Ang inisyatiba na ito ay hinihimok ng lumalaking pangangailangan ng iba't ibang modernong sistema (mula sa larangan ng telekomunikasyon, machine learning, mga serbisyo sa pananalapi, atbp.) para sa high-performance parallel computing at pagliit ng mga pagkaantala sa pagsasagawa ng mga operasyon, kung saan ginagamit nila ang advanced na CPU at mga kakayahan ng hardware acceleration. Ang ganitong mga pag-optimize sa Kubernetes ay hanggang ngayon ay nakamit salamat sa magkakaibang mga bahagi (CPU manager, Device manager, CNI), at ngayon ay idadagdag sila ng isang panloob na interface na pinag-iisa ang diskarte at pinapasimple ang koneksyon ng mga bagong katulad - tinatawag na topology- may kamalayan - mga bahagi sa panig ng Kubelet. Mga Detalye - sa kaukulang KEP.

Topology Manager Component Diagram

Susunod na tampok - sinusuri ang mga lalagyan habang tumatakbo ang mga ito (pagsisiyasat sa pagsisimula). Tulad ng alam mo, para sa mga container na tumatagal ng mahabang panahon upang ilunsad, mahirap makakuha ng up-to-date na status: sila ay maaaring "pinatay" bago sila aktwal na magsimulang gumana, o sila ay napupunta sa deadlock sa mahabang panahon. Bagong check (pinagana sa pamamagitan ng feature gate na tinatawag na StartupProbeEnabled) kinakansela - o sa halip, ipinagpaliban - ang epekto ng anumang iba pang mga pagsusuri hanggang sa sandaling matapos na ang pod sa pagtakbo. Dahil dito, orihinal na tinawag ang feature pod-startup liveness-probe holdoff. Para sa mga pod na tumatagal ng mahabang panahon upang magsimula, maaari mong i-poll ang estado sa medyo maikling pagitan ng oras.

Bilang karagdagan, ang isang pagpapabuti para sa RuntimeClass ay magagamit kaagad sa beta status, na nagdaragdag ng suporta para sa "mga magkakaibang kumpol." C Pag-iiskedyul ng RuntimeClass Ngayon ay hindi na kailangan para sa bawat node na magkaroon ng suporta para sa bawat RuntimeClass: para sa mga pod maaari kang pumili ng RuntimeClass nang hindi iniisip ang tungkol sa cluster topology. Dati, upang makamit ito - upang ang mga pod ay mapunta sa mga node na may suporta para sa lahat ng kailangan nila - kinakailangan na magtalaga ng mga naaangkop na panuntunan sa NodeSelector at mga pagpapaubaya. SA KEP Pinag-uusapan nito ang tungkol sa mga halimbawa ng paggamit at, siyempre, mga detalye ng pagpapatupad.

Сеть

Dalawang makabuluhang networking feature na lumitaw sa unang pagkakataon (sa alpha version) sa Kubernetes 1.16 ay:

Suporta dalawahang network stack - IPv4/IPv6 - at ang kaukulang "pag-unawa" nito sa antas ng mga pod, node, mga serbisyo. Kabilang dito ang IPv4-to-IPv4 at IPv6-to-IPv6 interoperability sa pagitan ng mga pod, mula sa mga pod hanggang sa mga panlabas na serbisyo, mga pagpapatupad ng sanggunian (sa loob ng Bridge CNI, PTP CNI at Host-Local IPAM plugin), pati na rin ang reverse Compatible sa mga Kubernetes cluster na tumatakbo IPv4 o IPv6 lang. Ang mga detalye ng pagpapatupad ay nasa KEP.
Isang halimbawa ng pagpapakita ng mga IP address ng dalawang uri (IPv4 at IPv6) sa listahan ng mga pod:
```
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#
```
Bagong API para sa Endpoint - EndpointSlice API. Niresolba nito ang mga isyu sa performance/scalability ng kasalukuyang Endpoint API na nakakaapekto sa iba't ibang bahagi sa control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Ang bagong API ay idaragdag sa Discovery API group at makakapaghatid ng libu-libong backend endpoint sa bawat serbisyo sa isang cluster na binubuo ng libu-libong node. Upang gawin ito, ang bawat Serbisyo ay nakamapa sa N mga bagay EndpointSlice, na ang bawat isa bilang default ay hindi hihigit sa 100 mga endpoint (ang halaga ay maaaring i-configure). Magbibigay din ang EndpointSlice API ng mga pagkakataon para sa pag-unlad nito sa hinaharap: suporta para sa maraming IP address para sa bawat pod, mga bagong estado para sa mga endpoint (hindi lamang Ready и NotReady), dynamic na subsetting para sa mga endpoint.

Ang ipinakita sa huling release ay umabot na sa beta na bersyon finalizer, pinangalanan service.kubernetes.io/load-balancer-cleanup at naka-attach sa bawat serbisyo na may uri LoadBalancer. Sa oras ng pagtanggal ng naturang serbisyo, pinipigilan nito ang aktwal na pagtanggal ng mapagkukunan hanggang sa makumpleto ang "paglilinis" ng lahat ng nauugnay na mapagkukunan ng balanse.

Makinarya ng API

Ang tunay na "milestone ng pagpapapanatag" ay nasa lugar ng server ng Kubernetes API at pakikipag-ugnayan dito. Nangyari ito higit sa lahat salamat sa paglilipat sa matatag na katayuan sa mga hindi nangangailangan ng espesyal na pagpapakilala CustomResourceDefinition (CRD), na nagkaroon ng beta status mula noong malayong mga araw ng Kubernetes 1.7 (at ito ay Hunyo 2017!). Ang parehong pagpapapanatag ay dumating sa mga kaugnay na tampok:

"subresources" may /status и /scale para sa CustomResources;
pagbabagong-anyo mga bersyon para sa CRD, batay sa panlabas na webhook;
kamakailang ipinakita (sa K8s 1.15) mga default na halaga (defaulting) at awtomatikong pag-alis ng field (pagputol) para sa CustomResources;
pagkakataon gamit ang schema ng OpenAPI v3 para gumawa at mag-publish ng dokumentasyon ng OpenAPI na ginamit upang patunayan ang mga mapagkukunan ng CRD sa gilid ng server.

Isa pang mekanismo na matagal nang naging pamilyar sa mga administrator ng Kubernetes: webhook ng pagpasok - nanatili din sa beta status sa loob ng mahabang panahon (mula noong K8s 1.9) at ngayon ay idineklara nang stable.

Dalawang iba pang mga tampok ang umabot sa beta: nalalapat sa panig ng server и manood ng mga bookmark.

At ang tanging makabuluhang pagbabago sa bersyon ng alpha ay pagkabigo mula sa SelfLink — isang espesyal na URI na kumakatawan sa tinukoy na bagay at pagiging bahagi ng ObjectMeta и ListMeta (ibig sabihin, bahagi ng anumang bagay sa Kubernetes). Bakit nila ito iniiwan? Pagganyak sa simpleng paraan tunog bilang kawalan ng tunay (napakalaki) na mga dahilan para umiral pa rin ang larangang ito. Ang mas pormal na mga dahilan ay upang i-optimize ang pagganap (sa pamamagitan ng pag-alis ng isang hindi kinakailangang field) at upang gawing simple ang gawain ng generic-apiserver, na pinipilit na hawakan ang naturang field sa isang espesyal na paraan (ito ang tanging field na nakatakda sa harap ng object ay serialized). Tunay na laos (sa loob ng beta) SelfLink ay mangyayari sa pamamagitan ng bersyon 1.20 ng Kubernetes, at panghuling - 1.21.

Imbakan ng data

Ang pangunahing gawain sa lugar ng imbakan, tulad ng sa mga nakaraang paglabas, ay sinusunod sa lugar suporta ng CSI. Ang mga pangunahing pagbabago dito ay:

sa unang pagkakataon (sa alpha version) lumitaw Suporta sa plugin ng CSI para sa mga node ng manggagawa sa Windows: ang kasalukuyang paraan ng pagtatrabaho sa storage ay papalitan din ng mga in-tree na plugin sa Kubernetes core at FlexVolume plugin mula sa Microsoft batay sa Powershell;

Scheme para sa pagpapatupad ng mga CSI plugin sa Kubernetes para sa Windows
pagkakataon pagbabago ng laki ng mga volume ng CSI, na ipinakilala pabalik sa K8s 1.12, ay lumago sa isang beta na bersyon;
Ang isang katulad na "promosyon" (mula sa alpha hanggang beta) ay nakamit sa pamamagitan ng kakayahang gumamit ng CSI upang lumikha ng mga lokal na ephemeral volume (Suporta sa Dami ng Inline ng CSI).

Ipinakilala sa nakaraang bersyon ng Kubernetes function ng pag-clone ng dami (gamit ang umiiral na PVC bilang DataSource upang lumikha ng bagong PVC) ay nakatanggap na rin ngayon ng beta status.

Tagapag-iskedyul

Dalawang kapansin-pansing pagbabago sa pag-iiskedyul (parehong nasa alpha):

EvenPodsSpreading - pagkakataon gumamit ng mga pod sa halip na mga lohikal na yunit ng aplikasyon para sa "patas na pamamahagi" ng mga pagkarga (tulad ng Deployment at ReplicaSet) at pagsasaayos ng distribusyon na ito (bilang isang mahirap na kinakailangan o bilang isang malambot na kondisyon, ibig sabihin, priyoridad). Palalawakin ng feature ang mga kasalukuyang kakayahan sa pamamahagi ng mga nakaplanong pod, na kasalukuyang nililimitahan ng mga opsyon PodAffinity и PodAntiAffinity, na nagbibigay sa mga administrator ng mas pinong kontrol sa bagay na ito, na nangangahulugan ng mas mataas na kakayahang magamit at na-optimize na pagkonsumo ng mapagkukunan. Mga Detalye - sa KEP.
Gamitin Patakaran sa BestFit в RequestedToCapacityRatio Priority Function sa panahon ng pagpaplano ng pod, na magpapahintulot gamitin pag-iimpake ng basurahan (“pagpapakete sa mga lalagyan”) para sa parehong mga pangunahing mapagkukunan (processor, memory) at mga pinalawig (tulad ng GPU). Para sa higit pang mga detalye, tingnan KEP.

Pag-iiskedyul ng mga pod: bago gamitin ang patakarang best fit (direkta sa pamamagitan ng default na scheduler) at sa paggamit nito (sa pamamagitan ng scheduler extender)

Bilang karagdagan, kinakatawan ng ang kakayahang lumikha ng sarili mong mga plugin ng scheduler sa labas ng pangunahing Kubernetes development tree (out-of-tree).

Iba pang mga pagbabago

Gayundin sa paglabas ng Kubernetes 1.16 ito ay mapapansin inisyatiba para sa nagdadala magagamit na mga sukatan sa buong pagkakasunud-sunod, o mas tiyak, alinsunod sa opisyal na mga regulasyon sa K8s instrumentation. Sila ay higit na umaasa sa kaukulang Dokumentasyon ng Prometheus. Ang mga hindi pagkakapare-pareho ay lumitaw para sa iba't ibang mga kadahilanan (halimbawa, ang ilang mga sukatan ay ginawa lamang bago lumitaw ang kasalukuyang mga tagubilin), at nagpasya ang mga developer na oras na upang dalhin ang lahat sa isang solong pamantayan, "alinsunod sa natitirang bahagi ng Prometheus ecosystem." Ang kasalukuyang pagpapatupad ng inisyatiba na ito ay nasa alpha status, na unti-unting ipo-promote sa mga susunod na bersyon ng Kubernetes sa beta (1.17) at stable (1.18).

Bilang karagdagan, ang mga sumusunod na pagbabago ay maaaring mapansin:

Pag-unlad ng suporta sa Windows с ang hitsura ng Kubeadm utility para sa OS na ito (alpha version), pagkakataon RunAsUserName para sa mga lalagyan ng Windows (alpha na bersyon), pagpapabuti Suporta ng Group Managed Service Account (gMSA) hanggang sa beta na bersyon, suporta mount/attach para sa mga volume ng vSphere.
Ni-recycle mekanismo ng pag-compress ng data sa mga tugon ng API. Dati, ginamit ang isang HTTP filter para sa mga layuning ito, na nagpataw ng ilang mga paghihigpit na pumipigil dito na ma-enable bilang default. Gumagana na ngayon ang "transparent request compression": nagpapadala ang mga kliyente Accept-Encoding: gzip sa header, makakatanggap sila ng GZIP-compressed na tugon kung ang laki nito ay lumampas sa 128 KB. Awtomatikong sinusuportahan ng mga kliyente ng Go ang compression (nagpapadala ng kinakailangang header), kaya agad nilang mapapansin ang pagbawas sa trapiko. (Maaaring kailanganin ang mga bahagyang pagbabago para sa ibang mga wika.)
Naging posible pag-scale ng HPA mula/hanggang zero pods batay sa mga panlabas na sukatan. Kung nagsusukat ka batay sa mga bagay/panlabas na sukatan, kapag ang mga workload ay idle maaari mong awtomatikong i-scale sa 0 replika upang makatipid ng mga mapagkukunan. Ang feature na ito ay dapat maging partikular na kapaki-pakinabang para sa mga kaso kung saan humihiling ang mga manggagawa ng mga mapagkukunan ng GPU, at ang bilang ng iba't ibang uri ng mga idle na manggagawa ay lumampas sa bilang ng mga available na GPU.
Bagong kliyente - k8s.io/client-go/metadata.Client — para sa "generalized" na pag-access sa mga bagay. Idinisenyo ito upang madaling makuha ang metadata (ibig sabihin, subsection metadata) mula sa mga mapagkukunan ng cluster at magsagawa ng koleksyon ng basura at mga operasyon ng quota sa kanila.
Bumuo ng mga Kubernetes ngayon kaya mo na walang legacy (“built-in” in-tree) cloud provider (alpha version).
Sa kubeadm utility idinagdag kakayahang pang-eksperimentong (alpha version) na maglapat ng mga custom na patch sa panahon ng operasyon init, join и upgrade. Matuto nang higit pa tungkol sa kung paano gamitin ang bandila --experimental-kustomize, tingnan sa KEP.
Bagong endpoint para sa apiserver - readyz, - nagbibigay-daan sa iyo na mag-export ng impormasyon tungkol sa pagiging handa nito. Ang server ng API ay mayroon na ngayong bandila --maximum-startup-sequence-duration, na nagbibigay-daan sa iyong ayusin ang mga pag-restart nito.
Dalawang mga tampok para sa Azure ipinahayag na matatag: suporta mga availability zone (Mga Availability Zone) at cross resource group (RG). Bilang karagdagan, idinagdag ni Azure:
- suporta sa pagpapatunay AAD at ADFS;
- anotasyon service.beta.kubernetes.io/azure-pip-name upang tukuyin ang pampublikong IP ng load balancer;
- pagkakataon mga setting LoadBalancerName и LoadBalancerResourceGroup.
Ang AWS ay mayroon na ngayon sinusuportahan para sa EBS sa Windows at na-optimize Mga tawag sa EC2 API DescribeInstances.
Nagsasarili na ngayon ang Kubeadm nagmigrate Configuration ng CoreDNS kapag ina-upgrade ang bersyon ng CoreDNS.
Binary atbp sa kaukulang larawan ng Docker nagawa na world-executable, na nagpapahintulot sa iyo na patakbuhin ang larawang ito nang hindi nangangailangan ng mga karapatan sa ugat. Gayundin, etcd migration image tumigil suporta sa bersyon ng etcd2.
В Cluster Autoscaler 1.16.0 lumipat sa paggamit ng distroless bilang base na imahe, pinahusay na performance, nagdagdag ng mga bagong cloud provider (DigitalOcean, Magnum, Packet).
Mga update sa ginamit/umaasa na software: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Kubernetes 1.16: pangkalahatang-ideya ng mga pangunahing inobasyon