🥇Kubernetes 1.16: ringkesan saka inovasi utama

Dina iki, Rebo, bakal njupuk Panggonan release sabanjure Kubernetes - 1.16. Miturut tradhisi sing wis dikembangake kanggo blog kita, iki minangka ulang tahun kaping sepuluh kita ngomong babagan owah-owahan sing paling penting ing versi anyar.

Informasi sing digunakake kanggo nyiapake materi iki dijupuk saka Tabel nelusuri paningkatan Kubernetes, CHANGELOG-1.16 lan masalah sing gegandhengan, panjaluk tarik, lan Usul Peningkatan Kubernetes (KEP). Dadi, ayo! ..

Kelenjar

A nomer saestu akeh inovasi kacathet (ing status versi alpha) presented ing sisih K8s kluster kelenjar (Kubelet).

Kaping pisanan, sing diarani «wadhah ephemeral» (Wadhah Ephemeral), dirancang kanggo nyederhanakake proses debugging ing pods. Mekanisme anyar ngidini sampeyan miwiti wadhah khusus sing diwiwiti ing ruang jeneng polong sing ana lan urip ing wektu sing cendhak. Tujuane kanggo sesambungan karo polong lan wadhah liyane kanggo ngrampungake masalah lan debug. A printah anyar wis dipun ginakaken kanggo fitur iki kubectl debug, padha ing inti saka kubectl exec: mung tinimbang nglakokake proses ing wadhah (kayata ing exec) iku mbukak wadhah ing pod. Contone, printah iki bakal nyambungake wadhah anyar menyang pod:

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

Rincian babagan wadhah ephemeral (lan conto panggunaane) bisa ditemokake ing cocog KEP. Implementasi saiki (ing K8s 1.16) minangka versi alpha, lan ing antarane kritéria kanggo transfer menyang versi beta yaiku "nguji API Kontainer Ephemeral paling ora 2 rilis [Kubernetes]."

NB: Ing inti lan malah jenenge, fitur kasebut meh padha karo plugin sing wis ana kubectl-debugbab kang kita wis nulis. Dikarepake yen karo tekane wadhah ephemeral, pangembangan plugin eksternal sing kapisah bakal mandheg.

Inovasi liyane - PodOverhead - dirancang kanggo nyedhiyani mekanisme kanggo ngitung biaya overhead kanggo pods, sing bisa beda-beda gumantung saka runtime sing digunakake. Minangka conto, penulis iki KEP asil ing Kata Containers, sing mbutuhake mbukak kernel tamu, agen kata, sistem init, etc. Nalika nduwur sirah dadi gedhe, ora bisa digatekake, tegese kudu ana cara kanggo nggatekake kuota, perencanaan, lsp. Kanggo ngleksanakake ing PodSpec lapangan ditambahake Overhead *ResourceList (dibandhingake karo data ing RuntimeClass, yen digunakake).

Inovasi liyane sing misuwur yaiku manajer topologi node (Manajer Topologi Node), dirancang kanggo nyawiji pendekatan kanggo fine-tuning alokasi sumber daya hardware kanggo macem-macem komponen ing Kubernetes. Inisiatif iki didorong dening kebutuhan sing akeh saka macem-macem sistem modern (saka bidang telekomunikasi, pembelajaran mesin, layanan finansial, lan sapiturute) kanggo komputasi paralel kinerja dhuwur lan nyilikake wektu tundha ing eksekusi operasi, sing nggunakake CPU canggih lan kemampuan akselerasi hardware. Optimisasi kasebut ing Kubernetes nganti saiki wis digayuh amarga komponen sing beda-beda (manajer CPU, Manajer piranti, CNI), lan saiki bakal ditambahake antarmuka internal siji sing nyawiji pendekatan lan nyederhanakake sambungan anyar sing padha - sing diarani topologi- weruh - komponen ing sisih Kubelet. Rincian - ing cocog KEP.

Diagram Komponen Manajer Topologi

Fitur sabanjure - mriksa kontaner nalika lagi mlaku (probe wiwitan). Kaya sing sampeyan ngerteni, kanggo kontaner sing butuh wektu suwe kanggo diluncurake, angel entuk status sing paling anyar: dheweke "dipateni" sadurunge bener-bener bisa digunakake, utawa bakal dadi buntu kanggo wektu sing suwe. Priksa anyar (diaktifake liwat gerbang fitur sing diarani StartupProbeEnabled) mbatalake - utawa luwih, nundha - efek saka mriksa liyane nganti wayahe pod wis rampung mlaku. Kanggo alasan iki, fitur kasebut wiwitane diarani pod-wiwitan liveness-probe holdoff. Kanggo pods sing njupuk wektu dawa kanggo miwiti, sampeyan bisa polling negara ing interval wektu relatif cendhak.

Kajaba iku, dandan kanggo RuntimeClass langsung kasedhiya ing status beta, nambah dhukungan kanggo "kluster heterogen". C RuntimeClass Scheduling Saiki ora perlu kanggo saben simpul duwe dhukungan kanggo saben RuntimeClass: kanggo pod sampeyan bisa milih RuntimeClass tanpa mikir babagan topologi kluster. Sadurunge, kanggo entuk iki - supaya polong rampung ing simpul kanthi dhukungan kanggo kabeh sing dibutuhake - kudu menehi aturan sing cocog kanggo NodeSelector lan toleransi. ING KAB Ngomong babagan conto panggunaan lan, mesthi, rincian implementasine.

Jaringan

Rong fitur jaringan penting sing pisanan muncul (ing versi alpha) ing Kubernetes 1.16 yaiku:

support tumpukan jaringan dual - IPv4/IPv6 - lan "pangerten" sing cocog ing tingkat polong, simpul, layanan. Iki kalebu interoperabilitas IPv4-to-IPv4 lan IPv6-to-IPv6 antarane pods, saka pods menyang layanan eksternal, implementasi referensi (ing Bridge CNI, PTP CNI lan Host-Local IPAM plugins), uga mbalikke Kompatibel karo kelompok Kubernetes mlaku. IPv4 utawa IPv6 mung. Rincian implementasine ana ing KAB.
Conto nampilake alamat IP saka rong jinis (IPv4 lan IPv6) ing dhaptar pods:
```
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#
```
API anyar kanggo Endpoint - EndpointSlice API. Ngatasi masalah kinerja / skalabilitas saka API Endpoint sing ana sing mengaruhi macem-macem komponen ing bidang kontrol (apiserver, etcd, endpoints-controller, kube-proxy). API anyar bakal ditambahake menyang grup Discovery API lan bakal bisa nglayani puluhan ewu titik mburi mburi ing saben layanan ing kluster sing dumadi saka ewu simpul. Kanggo nindakake iki, saben Layanan dipetakan menyang N obyek EndpointSlice, sing saben standar ora duwe luwih saka 100 titik pungkasan (nilai bisa dikonfigurasi). EndpointSlice API uga bakal menehi kesempatan kanggo pangembangan mangsa ngarep: dhukungan kanggo sawetara alamat IP kanggo saben pod, negara anyar kanggo endpoints (ora mung Ready и NotReady), subset dinamis kanggo titik pungkasan.

Sing ditampilake ing rilis pungkasan wis tekan versi beta finalis, jenenge service.kubernetes.io/load-balancer-cleanup lan ditempelake ing saben layanan karo jinis LoadBalancer. Ing wektu mbusak layanan kasebut, nyegah pambusakan sumber daya kasebut nganti "reresik" kabeh sumber daya keseimbangan sing relevan rampung.

Mesin API

"Tonggak stabilisasi" nyata ana ing area server API Kubernetes lan interaksi karo. Iki kedaden umumé thanks kanggo nransfer menyang status stabil sing ora perlu introduksi khusus CustomResourceDefinitions (CRD), sing wis status beta wiwit dina adoh saka Kubernetes 1.7 (lan iki Juni 2017!). Stabilisasi sing padha teka ing fitur sing gegandhengan:

"subresources" saka /status и /scale kanggo CustomResources;
konversi versi kanggo CRD, adhedhasar webhook external;
bubar presented (ing K8s 1.15) nilai gawan (default) lan mbusak lapangan otomatis (Pruning) kanggo CustomResources;
kesempatan nggunakake skema OpenAPI v3 kanggo nggawe lan nerbitake dokumentasi OpenAPI sing digunakake kanggo validasi sumber daya CRD ing sisih server.

Mekanisme liyane sing wis suwe dadi akrab karo pangurus Kubernetes: diakoni webhook - uga tetep ing status beta kanggo dangu (wiwit K8s 1.9) lan saiki diumumake stabil.

Loro fitur liyane wis tekan beta: aplikasi sisih server и nonton tetenger.

Lan mung inovasi pinunjul ing versi alpha kegagalan saka SelfLink - URI khusus sing makili obyek sing ditemtokake lan dadi bagean saka ObjectMeta и ListMeta (yaiku bagean saka obyek apa wae ing Kubernetes). Yagene padha nilar? Motivasi kanthi cara sing prasaja swara minangka ora ana alesan nyata (akeh banget) kanggo lapangan iki isih ana. Alasan sing luwih formal yaiku kanggo ngoptimalake kinerja (kanthi mbusak lapangan sing ora perlu) lan nyederhanakake karya generik-apiserver, sing dipeksa kanggo nangani lapangan kasebut kanthi cara khusus (iki mung lapangan sing disetel sadurunge obyek kasebut. wis serial). Keusangan sejati (ing beta) SelfLink bakal kelakon dening Kubernetes versi 1.20, lan final - 1.21.

Panyimpenan data

Karya utama ing area panyimpenan, kaya ing rilis sadurunge, diamati ing wilayah kasebut Dhukungan CSI. Owah-owahan utama ing kene yaiku:

kanggo pisanan (ing versi alpha) muncul Dhukungan plugin CSI kanggo node pekerja Windows: cara saiki nggarap panyimpenan uga bakal ngganti plugin in-tree ing inti Kubernetes lan plugin FlexVolume saka Microsoft adhedhasar Powershell;

Skema kanggo ngetrapake plugin CSI ing Kubernetes kanggo Windows
kesempatan ngowahi ukuran volume CSI, ngenalaken bali ing K8s 1.12, wis thukul kanggo versi beta;
"Promosi" sing padha (saka alpha nganti beta) digayuh kanthi kemampuan nggunakake CSI kanggo nggawe volume ephemeral lokal (Dhukungan Volume Inline CSI).

Dipuntepangaken ing versi sadurungé saka Kubernetes fungsi kloning volume (nggunakake PVC ana minangka DataSource kanggo nggawe PVC anyar) uga saiki wis nampa status beta.

Penjadwal

Rong owah-owahan penting kanggo jadwal (loro ing alpha):

EvenPodsSpreading - kesempatan nggunakake pods tinimbang unit aplikasi logis kanggo "distribusi adil" kathah (kaya Deployment lan ReplicaSet) lan nyetel distribusi iki (minangka syarat hard utawa minangka kondisi alus, yaiku prioritas). Fitur kasebut bakal nggedhekake kemampuan distribusi sing wis ana ing pod sing wis direncanakake, sing saiki diwatesi dening opsi PodAffinity и PodAntiAffinity, menehi pangurus kontrol luwih apik ing prakara iki, kang tegese kasedhiyan dhuwur luwih apik lan konsumsi sumber optimized. Rincian - ing KAB.
Gunakake Kebijakan BestFit в Fungsi Prioritas RequestedToCapacityRatio sak planning pod, kang bakal ngidini nggunakake packing bin ("packing ing kontaner") kanggo loro sumber dhasar (prosesor, memori) lan lengkap (kaya GPU). Kanggo rincian liyane, ndeleng KAB.

Penjadwalan pods: sadurunge nggunakake kabijakan sing paling pas (langsung liwat panjadwal standar) lan kanthi nggunakake (liwat panjadwal extender)

Salajengipun, diwenehi kemampuan kanggo nggawe plugin panjadwal dhewe ing njaba wit pangembangan Kubernetes utama (out-of-tree).

Pangowahan liyane

Uga ing release Kubernetes 1.16 bisa dicathet inisiatif kanggo nggawa metrik kasedhiya ing urutan lengkap, utawa luwih tepate, sesuai karo peraturan resmi kanggo instrumentasi K8s. Padha umume gumantung ing cocog Dokumentasi Prometheus. Inkonsistensi muncul amarga macem-macem alasan (contone, sawetara metrik mung digawe sadurunge instruksi saiki muncul), lan para pangembang mutusake manawa wektune kanggo nggawa kabeh dadi standar siji, "selaras karo ekosistem Prometheus liyane." Implementasine inisiatif iki saiki ana ing status alpha, sing bakal dipromosekake kanthi bertahap ing versi Kubernetes sabanjure dadi beta (1.17) lan stabil (1.18).

Kajaba iku, owah-owahan ing ngisor iki bisa dicathet:

Pangembangan dhukungan Windows с katon Utilitas Kubeadm kanggo OS iki (versi alpha), kesempatan RunAsUserName kanggo wadhah Windows (versi alpha), dandan Group Managed Service Account (gMSA) ndhukung nganti versi beta, dhukungan gunung / masang kanggo volume vSphere.
Daur ulang mekanisme komprèsi data ing respon API. Sadurunge, panyaring HTTP digunakake kanggo tujuan kasebut, sing ngetrapake sawetara watesan sing nyegah supaya ora diaktifake kanthi standar. "Kompresi panyuwunan transparan" saiki bisa digunakake: ngirim klien Accept-Encoding: gzip ing header, padha nampa respon GZIP-kompress yen ukurane ngluwihi 128 KB. Klien Go kanthi otomatis ndhukung kompresi (ngirim header sing dibutuhake), saengga bakal langsung ngrasakake pengurangan lalu lintas. (Owah-owahan cilik bisa uga dibutuhake kanggo basa liyane.)
Dadi bisa skala HPA saka / menyang nul pods adhedhasar metrik external. Yen sampeyan skala adhedhasar obyek / metrik eksternal, banjur nalika beban kerja ora aktif, sampeyan bisa kanthi otomatis skala 0 replika kanggo ngirit sumber daya. Fitur iki kudu migunani utamane kanggo kasus nalika buruh njaluk sumber daya GPU, lan jumlah macem-macem jinis buruh nganggur ngluwihi jumlah GPU sing kasedhiya.
Klien anyar - k8s.io/client-go/metadata.Client - kanggo akses "umum" kanggo obyek. Iki dirancang kanggo gampang njupuk metadata (yaiku subsection metadata) saka sumber daya kluster lan nindakake operasi pengumpulan sampah lan kuota.
Mbangun Kubernetes saiki sampeyan bisa tanpa warisan ("dibangun ing" ing-wit) panyedhiya maya (versi alpha).
Kanggo utilitas kubeadm ditambahake kemampuan eksperimen (versi alpha) kanggo aplikasi patch khusus sajrone operasi init, join и upgrade. Sinau luwih lengkap babagan carane nggunakake gendera --experimental-kustomize, ndeleng ing KAB.
Titik pungkasan anyar kanggo apiserver - readyz, - ngidini sampeyan ngekspor informasi babagan kesiapane. Server API uga saiki duwe gendera --maximum-startup-sequence-duration, ngidini sampeyan ngatur wiwitan maneh.
Kaloro fitur kanggo Azure nyatakake stabil: support zona kasedhiyan (Zona kasedhiyan) lan klompok sumber daya silang (RG). Kajaba iku, Azure wis nambahake:
- dhukungan otentikasi AAD lan ADFS;
- anotasi service.beta.kubernetes.io/azure-pip-name kanggo nemtokake IP umum saka load balancer;
- kesempatan setelan LoadBalancerName и LoadBalancerResourceGroup.
AWS saiki wis dhukungan kanggo EBS ing Windows lan optimized EC2 API telpon DescribeInstances.
Kubeadm saiki merdika migrasi Konfigurasi CoreDNS nalika nganyarke versi CoreDNS.
binari lsp ing gambar Docker sing cocog wis rampung donya-eksekusi, sing ngijini sampeyan kanggo mbukak gambar iki tanpa perlu kanggo hak ROOT. Uga, gambar migrasi etcd mandheg Dhukungan versi etcd2.
В Cluster Autoscaler 1.16.0 diuripake nggunakake distroless minangka gambar dhasar, kinerja apik, nambah panyedhiya maya anyar (DigitalOcean, Magnum, Paket).
Nganyari ing digunakake / lunak gumantung: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Waca uga ing blog kita:

Source: www.habr.com

Kubernetes 1.16: ringkesan saka inovasi utama