🥇Kubernetes 1.16: muhtasari wa ubunifu mkuu

Leo, Jumatano, utafanyika toleo linalofuata la Kubernetes - 1.16. Kulingana na mila ambayo imetengenezwa kwa blogi yetu, hii ni wakati wa kumbukumbu ya miaka kumi tunazungumza juu ya mabadiliko muhimu zaidi katika toleo jipya.

Taarifa iliyotumiwa kuandaa nyenzo hii inachukuliwa kutoka Kubernetes majedwali ya ufuatiliaji ya maboresho, MABADILIKO-1.16 na masuala yanayohusiana, maombi ya kuvuta, na Mapendekezo ya Kuboresha Kubernetes (KEP). Kwa hivyo, twende! ..

Nodi

Idadi kubwa kweli ya ubunifu mashuhuri (katika hali ya toleo la alfa) imewasilishwa kwenye kando ya nodi za nguzo za K8s (Kubelet).

Kwanza, kinachojulikana «vyombo vya ephemeral» (Vyombo vya Ephemeral), iliyoundwa ili kurahisisha michakato ya utatuzi katika maganda. Utaratibu mpya hukuruhusu kuzindua vyombo maalum vinavyoanza katika nafasi ya majina ya maganda yaliyopo na kuishi kwa muda mfupi. Madhumuni yao ni kuingiliana na maganda na vyombo vingine ili kutatua matatizo yoyote na utatuzi. Amri mpya imetekelezwa kwa kipengele hiki kubectl debug, sawa kwa asili na kubectl exec: badala ya kuendesha mchakato kwenye kontena (kama ilivyo exec) inazindua chombo kwenye ganda. Kwa mfano, amri hii itaunganisha chombo kipya kwenye ganda:

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

Maelezo kuhusu vyombo vya ephemeral (na mifano ya matumizi yao) yanaweza kupatikana katika sambamba KEP. Utekelezaji wa sasa (katika K8s 1.16) ni toleo la alpha, na miongoni mwa vigezo vya uhamisho wake hadi toleo la beta ni "kujaribu API ya Ephemeral Containers kwa angalau matoleo 2 ya [Kubernetes]."

NB: Kwa asili yake na hata jina lake, kipengele kinafanana na programu-jalizi iliyopo tayari kubectl-debugambayo sisi tayari imeandikwa. Inatarajiwa kwamba pamoja na ujio wa vyombo vya ephemeral, maendeleo ya programu-jalizi tofauti ya nje yatakoma.

Ubunifu mwingine - PodOverhead - iliyoundwa kutoa utaratibu wa kukokotoa gharama za uendeshaji wa maganda, ambayo inaweza kutofautiana sana kulingana na wakati wa kukimbia uliotumiwa. Kwa mfano, waandishi hii KEP husababisha Vyombo vya Kata, ambavyo vinahitaji kuendesha kernel ya wageni, wakala wa kata, mfumo wa init, nk. Wakati overhead inakuwa kubwa sana, haiwezi kupuuzwa, ambayo ina maana kuna haja ya kuwa na njia ya kuzingatia kwa upendeleo zaidi, kupanga, nk. Ili kuitekeleza katika PodSpec uwanja umeongezwa Overhead *ResourceList (inalinganisha na data katika RuntimeClass, ikiwa moja inatumiwa).

Ubunifu mwingine mashuhuri ni meneja wa topolojia ya nodi (Meneja wa Topolojia wa Nodi), iliyoundwa ili kuunganisha mbinu ya kurekebisha vyema ugawaji wa rasilimali za maunzi kwa vipengele mbalimbali katika Kubernetes. Mpango huu unasukumwa na hitaji linalokua la mifumo mbalimbali ya kisasa (kutoka uwanja wa mawasiliano, kujifunza kwa mashine, huduma za kifedha, n.k.) kwa utendaji wa juu wa kompyuta sambamba na kupunguza ucheleweshaji katika utekelezaji wa shughuli, ambazo hutumia CPU ya hali ya juu na. uwezo wa kuongeza kasi ya vifaa. Uboreshaji kama huo katika Kubernetes hadi sasa umepatikana shukrani kwa vifaa tofauti (meneja wa CPU, meneja wa Kifaa, CNI), na sasa wataongezwa kiolesura kimoja cha ndani ambacho kinaunganisha mbinu na kurahisisha unganisho la mpya sawa - kinachojulikana kama topolojia- kufahamu - vipengele upande wa Kubelet. Maelezo - ndani sambamba KEP.

Mchoro wa Sehemu ya Meneja wa Topolojia

Kipengele kinachofuata - kuangalia vyombo wakati vinaendesha (uchunguzi wa kuanza). Kama unavyojua, kwa kontena zinazochukua muda mrefu kuzinduliwa, ni vigumu kupata hali ya kisasa: "huuawa" kabla ya kuanza kufanya kazi, au huishia kwenye msuguano kwa muda mrefu. Cheki mpya (imewezeshwa kupitia lango la kipengele linaloitwa StartupProbeEnabled) hughairi - au tuseme, inaahirisha - athari ya ukaguzi mwingine wowote hadi wakati ganda linapomaliza kufanya kazi. Kwa sababu hii, kipengele kiliitwa awali pod-startup liveness-probe kushikilia. Kwa maganda ambayo huchukua muda mrefu kuanza, unaweza kupigia kura jimbo katika vipindi vya muda mfupi.

Zaidi ya hayo, uboreshaji wa RuntimeClass unapatikana mara moja katika hali ya beta, na kuongeza usaidizi kwa "makundi tofauti". C Upangaji wa RuntimeClass Sasa si lazima hata kidogo kwa kila nodi kuwa na usaidizi kwa kila RuntimeClass: kwa maganda unaweza kuchagua RuntimeClass bila kufikiria juu ya topolojia ya nguzo. Hapo awali, ili kufikia hili - ili pods kuishia kwenye nodi na usaidizi wa kila kitu wanachohitaji - ilikuwa ni lazima kupeana sheria zinazofaa kwa NodeSelector na uvumilivu. KATIKA CAP Inazungumza juu ya mifano ya matumizi na, bila shaka, maelezo ya utekelezaji.

Mtandao

Vipengele viwili muhimu vya mtandao ambavyo vilionekana kwa mara ya kwanza (katika toleo la alpha) katika Kubernetes 1.16 ni:

Support mrundikano wa mtandao wa pande mbili - IPv4/IPv6 - na "uelewa" wake unaolingana katika kiwango cha maganda, nodi, huduma. Inajumuisha ushirikiano wa IPv4-to-IPv4 na IPv6-kwa-IPv6 kati ya ganda, kutoka kwa maganda hadi huduma za nje, utekelezaji wa marejeleo (ndani ya Bridge CNI, PTP CNI na programu-jalizi za Host-Local IPAM), pamoja na kubadili nyuma Inaoana na nguzo za Kubernetes zinazoendesha. IPv4 au IPv6 pekee. Maelezo ya utekelezaji yapo CAP.
Mfano wa kuonyesha anwani za IP za aina mbili (IPv4 na IPv6) katika orodha ya maganda:
```
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 mpya ya Endpoint - EndpointSlice API. Husuluhisha masuala ya utendaji/uwezo wa API ya Endpoint iliyopo ambayo huathiri vipengele mbalimbali katika ndege-dhibiti (apiserver, etcd, endpoints-controller, kube-proksi). API mpya itaongezwa kwenye kikundi cha API ya Ugunduzi na itaweza kuhudumia makumi ya maelfu ya sehemu za nyuma kwa kila huduma katika kundi linalojumuisha maelfu ya nodi. Ili kufanya hivyo, kila Huduma imepangwa kwa vitu vya N EndpointSlice, ambayo kila moja kwa chaguo-msingi haina ncha zaidi ya 100 (thamani inaweza kusanidiwa). API ya EndpointSlice pia itatoa fursa kwa maendeleo yake ya siku za usoni: usaidizi wa anwani nyingi za IP kwa kila ganda, majimbo mapya kwa ncha (sio tu). Ready и NotReady), mpangilio mdogo unaobadilika wa sehemu za mwisho.

Ile iliyowasilishwa katika toleo la mwisho imefikia toleo la beta mkamilishaji, jina lake service.kubernetes.io/load-balancer-cleanup na kushikamana na kila huduma na aina LoadBalancer. Wakati wa kufuta huduma hiyo, inazuia uondoaji halisi wa rasilimali hadi "kusafisha" kwa rasilimali zote za usawazishaji kukamilika.

Mitambo ya API

"Hatua ya uimarishaji" halisi iko katika eneo la seva ya Kubernetes API na mwingiliano nayo. Hii ilitokea kwa kiasi kikubwa shukrani kwa kuhamisha kwa hali thabiti wale ambao hawahitaji utangulizi maalum CustomResourceDefinitions (CRD), ambazo zimekuwa na hali ya beta tangu siku za mbali za Kubernetes 1.7 (na hii ni Juni 2017!). Utulivu sawa ulikuja kwa vipengele vinavyohusiana:

"rasilimali ndogo" na /status и /scale kwa CustomResources;
uongofu matoleo ya CRD, kulingana na webhook ya nje;
iliyotolewa hivi karibuni (katika K8s 1.15) maadili chaguo-msingi (chaguo-msingi) na kuondolewa kwa shamba moja kwa moja (kupogoa) kwa CustomResources;
nafasi kwa kutumia schema ya OpenAPI v3 kuunda na kuchapisha hati za OpenAPI zinazotumiwa kuthibitisha rasilimali za CRD kwenye upande wa seva.

Utaratibu mwingine ambao umejulikana kwa muda mrefu kwa wasimamizi wa Kubernetes: kiingilio cha wavuti - pia ilibaki katika hali ya beta kwa muda mrefu (tangu K8s 1.9) na sasa imetangazwa kuwa thabiti.

Vipengele vingine viwili vimefikia beta: upande wa seva unatumika и tazama alamisho.

Na uvumbuzi muhimu pekee katika toleo la alpha ulikuwa kushindwa kutoka SelfLink - URI maalum inayowakilisha kitu maalum na kuwa sehemu yake ObjectMeta и ListMeta (yaani, sehemu ya kitu chochote katika Kubernetes). Kwa nini wanaiacha? Kuhamasisha kwa njia rahisi sauti kama kutokuwepo kwa sababu za kweli (zito) za uwanja huu bado upo. Sababu rasmi zaidi ni kuongeza utendaji (kwa kuondoa uwanja usio wa lazima) na kurahisisha kazi ya generic-apiserver, ambayo inalazimika kushughulikia uwanja kama huo kwa njia maalum (hii ndio uwanja pekee ambao umewekwa mbele ya kitu. ni serialized). Uzamani wa kweli (ndani ya beta) SelfLink itatokea kwa toleo la Kubernetes 1.20, na la mwisho - 1.21.

Uhifadhi wa data

Kazi kuu katika eneo la uhifadhi, kama katika matoleo ya awali, inazingatiwa katika eneo hilo Msaada wa CSI. Mabadiliko kuu hapa yalikuwa:

kwa mara ya kwanza (katika toleo la alpha) alionekana Msaada wa programu-jalizi ya CSI kwa nodi za mfanyakazi wa Windows: njia ya sasa ya kufanya kazi na hifadhi pia itachukua nafasi ya programu-jalizi za ndani ya mti katika msingi wa Kubernetes na programu jalizi za FlexVolume kutoka Microsoft kulingana na Powershell;

Mpango wa kutekeleza programu-jalizi za CSI katika Kubernetes kwa Windows
nafasi kubadilisha ukubwa wa ujazo wa CSI, iliyoletwa nyuma katika K8s 1.12, imekua toleo la beta;
"Matangazo" sawa (kutoka alpha hadi beta) yalipatikana kwa uwezo wa kutumia CSI kuunda viwango vya ndani vya muda mfupi (Usaidizi wa Kiasi cha Inline cha CSI).

Ilianzishwa katika toleo la awali la Kubernetes kazi ya cloning kiasi (kwa kutumia PVC iliyopo kama DataSource kuunda PVC mpya) pia sasa imepokea hali ya beta.

Mratibu

Mabadiliko mawili mashuhuri katika kuratibu (zote katika alpha):

EvenPodsSpreading - fursa tumia maganda badala ya vitengo vya maombi vya kimantiki kwa "usambazaji wa haki" wa mizigo (kama vile Deployment na ReplicaSet) na kurekebisha usambazaji huu (kama hitaji gumu au hali laini, i.e. kipaumbele). Kipengele hiki kitapanua uwezo uliopo wa usambazaji wa maganda yaliyopangwa, ambayo kwa sasa yamepunguzwa na chaguo PodAffinity и PodAntiAffinity, kuwapa wasimamizi udhibiti bora zaidi katika suala hili, ambayo inamaanisha upatikanaji bora wa juu na matumizi bora ya rasilimali. Maelezo - ndani CAP.
Matumizi ya Sera ya BestFit в Kipengele cha Kipaumbele cha RequestedToCapacityRatio wakati wa kupanga pod, ambayo itaruhusu tumia ufungaji wa pipa (“kupakia kwenye vyombo”) kwa rasilimali zote mbili (kichakataji, kumbukumbu) na zile zilizopanuliwa (kama GPU). Kwa maelezo zaidi, tazama CAP.

Kupanga maganda: kabla ya kutumia sera bora zaidi (moja kwa moja kupitia kipanga ratiba chaguo-msingi) na matumizi yake (kupitia kipanga ratiba)

Aidha, kuwakilishwa na uwezo wa kuunda programu-jalizi zako za kipanga ratiba nje ya mti mkuu wa ukuzaji wa Kubernetes (nje ya mti).

Mabadiliko mengine

Pia katika toleo la Kubernetes 1.16 inaweza kuzingatiwa mpango kwa kuleta vipimo vinavyopatikana kwa mpangilio kamili, au kwa usahihi zaidi, kwa mujibu wa kanuni rasmi kwa vifaa vya K8s. Kwa kiasi kikubwa wanategemea sambamba Nyaraka za Prometheus. Kutoendana kulizuka kwa sababu mbalimbali (kwa mfano, baadhi ya vipimo viliundwa tu kabla ya maagizo ya sasa kuonekana), na watengenezaji waliamua kuwa ni wakati wa kuleta kila kitu kwa kiwango kimoja, "kulingana na mfumo wa ikolojia wa Prometheus." Utekelezaji wa sasa wa mpango huu uko katika hali ya alpha, ambayo itakuzwa hatua kwa hatua katika matoleo yajayo ya Kubernetes hadi beta (1.17) na thabiti (1.18).

Kwa kuongeza, mabadiliko yafuatayo yanaweza kuzingatiwa:

Maendeleo ya usaidizi wa Windows с mwonekano Kubeadm huduma za OS hii (toleo la alpha), fursa RunAsUserName kwa vyombo vya Windows (toleo la alpha), uboreshaji Akaunti ya Huduma Inayodhibitiwa na Kikundi (gMSA) inasaidia hadi toleo la beta, msaada weka/ambatisha kwa viwango vya vSphere.
Imetengenezwa upya utaratibu wa kubana data katika majibu ya API. Hapo awali, kichujio cha HTTP kilitumiwa kwa madhumuni haya, ambayo iliweka vikwazo kadhaa ambavyo vilizuia kuwezeshwa kwa chaguo-msingi. "Mfinyazo wa ombi la uwazi" sasa unafanya kazi: kutuma kwa wateja Accept-Encoding: gzip katika kichwa, wanapokea jibu la GZIP-compressed ikiwa ukubwa wake unazidi 128 KB. Wateja wa Go huauni kiotomatiki ukandamizaji (kutuma kichwa kinachohitajika), kwa hivyo wataona kupungua kwa trafiki mara moja. (Marekebisho kidogo yanaweza kuhitajika kwa lugha zingine.)
Ikawezekana kuongeza HPA kutoka/hadi sifuri maganda kulingana na vipimo vya nje. Ukiweka vipimo kulingana na vitu/vipimo vya nje, basi upakiaji wa kazi unapokuwa bila kazi unaweza kuongeza kiotomatiki hadi nakala 0 ili kuhifadhi rasilimali. Kipengele hiki kinafaa kuwa muhimu hasa kwa hali ambapo wafanyakazi wanaomba rasilimali za GPU, na idadi ya aina tofauti za wafanyakazi wasio na kazi huzidi idadi ya GPU zinazopatikana.
Mteja mpya - k8s.io/client-go/metadata.Client — kwa ufikiaji wa "jumla" kwa vitu. Imeundwa kurejesha metadata kwa urahisi (yaani, kifungu kidogo metadata) kutoka kwa rasilimali za nguzo na kufanya shughuli za ukusanyaji wa takataka na ugawaji nazo.
Jenga Kubernetes sasa unaweza bila urithi ("imejengwa ndani" ndani ya mti) watoa huduma za wingu (toleo la alpha).
Kwa matumizi ya kubeadm imeongezwa uwezo wa majaribio (toleo la alpha) wa kutumia viraka kubinafsisha wakati wa utendakazi init, join и upgrade. Pata maelezo zaidi kuhusu jinsi ya kutumia bendera --experimental-kustomize, tazama ndani CAP.
Mwisho mpya wa apiserver - readyz, - inakuwezesha kuuza nje habari kuhusu utayari wake. Seva ya API pia sasa ina bendera --maximum-startup-sequence-duration, hukuruhusu kudhibiti uanzishaji wake upya.
Mbili Vipengele vya Azure alitangaza kuwa imara: msaada maeneo ya upatikanaji (Maeneo ya Upatikanaji) na kikundi cha rasilimali (RG). Kwa kuongezea, Azure ameongeza:
- usaidizi wa uthibitishaji AAD na ADFS;
- ufafanuzi service.beta.kubernetes.io/azure-pip-name kutaja IP ya umma ya usawazishaji wa mzigo;
- nafasi настройки LoadBalancerName и LoadBalancerResourceGroup.
AWS sasa ina kusaidia kwa EBS kwenye Windows na iliyoboreshwa Simu za EC2 API DescribeInstances.
Kubeadm sasa ni huru huhama Usanidi wa CoreDNS wakati wa kuboresha toleo la CoreDNS.
Binari nk kwenye picha inayolingana ya Docker kumaliza inayoweza kutekelezwa ulimwenguni, ambayo hukuruhusu kuendesha picha hii bila hitaji la haki za mizizi. Pia, picha ya uhamiaji nk kusimamishwa Msaada wa toleo la etcd2.
В Cluster Autoscaler 1.16.0 imebadilishwa kwa kutumia distroless kama taswira ya msingi, utendakazi ulioboreshwa, iliongeza watoa huduma wapya wa wingu (DigitalOcean, Magnum, Packet).
Masasisho katika programu inayotumika/tegemezi: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Soma pia kwenye blogi yetu:

Chanzo: mapenzi.com

Kubernetes 1.16: Vivutio vya kile kipya