Kubernetes 1.14: Vivutio vya kile kipya

Usiku huu utafanyika toleo linalofuata la Kubernetes - 1.14. Kulingana na mila ambayo imeundwa kwa blogi yetu, tunazungumza juu ya mabadiliko muhimu katika toleo jipya la bidhaa hii nzuri ya Open Source.

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

Wacha tuanze na utangulizi muhimu kutoka kwa mzunguko wa maisha ya nguzo ya SIG: nguzo za kushindwa kwa nguvu Kubernetes (au kuwa sahihi zaidi, uwekaji wa HA unaojipangisha) ni sasa inaweza kuundwa kutumia amri zinazojulikana (katika muktadha wa nguzo za nodi moja). kubeadm (init и join) Kwa kifupi, kwa hili:

• vyeti vinavyotumiwa na nguzo huhamishiwa kwa siri;
• kwa uwezekano wa kutumia nguzo ya etcd ndani ya nguzo ya K8s (yaani, kuondoa utegemezi wa nje uliokuwepo hapo awali) etcd-opereta;
• Hati za mipangilio iliyopendekezwa kwa usawazishaji wa mzigo wa nje ambao hutoa usanidi unaostahimili hitilafu (katika siku zijazo imepangwa kuondokana na utegemezi huu, lakini si katika hatua hii).

Usanifu wa nguzo ya Kubernetes HA iliyoundwa kwa kubeadm

Maelezo ya utekelezaji yanaweza kupatikana katika pendekezo la kubuni. Kipengele hiki kilisubiriwa kwa muda mrefu sana: toleo la alpha lilitarajiwa nyuma katika K8s 1.9, lakini limeonekana sasa tu.

API

Timu apply na kwa ujumla kuzungumza usimamizi wa kitu cha kutangaza kupita ya kubectl katika apiserver. Watengenezaji wenyewe wanaelezea kwa ufupi uamuzi wao kwa kusema hivyo kubectl apply - sehemu ya kimsingi ya kufanya kazi na usanidi katika Kubernetes, hata hivyo, "imejaa hitilafu na ni ngumu kurekebisha," na kwa hivyo utendakazi huu unahitaji kurejeshwa kwa kawaida na kuhamishiwa kwa ndege ya kudhibiti. Mifano rahisi na wazi ya matatizo yaliyopo leo:

Maelezo kuhusu utekelezaji yapo CAP. Utayari wa sasa ni alpha (utangazaji hadi beta umepangwa kwa toleo lijalo la Kubernetes).

Imetolewa katika toleo la alpha nafasi kwa kutumia mpango wa OpenAPI v3 wa kuunda na kuchapisha hati za OpenAPI za CustomResources (CR) inayotumika kuhalalisha (upande wa seva) rasilimali za K8 zilizobainishwa na mtumiaji (CustomResourceDefinition, CRD). Kuchapisha OpenAPI kwa CRD huruhusu wateja (k.m. kubectl) fanya uthibitisho kwa upande wako (ndani kubectl create и kubectl apply) na kutoa nyaraka kulingana na mpango (kubectl explain) Maelezo - ndani CAP.

Kumbukumbu zilizopo sasa wanafungua na bendera O_APPEND (lakini sivyo O_TRUNC) ili kuepuka upotevu wa magogo katika hali fulani na kwa urahisi wa kukata magogo na huduma za nje kwa mzunguko.

Pia katika muktadha wa Kubernetes API, inaweza kuzingatiwa kuwa in PodSandbox и PodSandboxStatus aliongeza shamba runtime_handler kurekodi habari kuhusu RuntimeClass kwenye ganda (soma zaidi juu yake katika maandishi kuhusu Kubernetes 1.12 kutolewa, ambapo darasa hili lilionekana kama toleo la alpha), na katika Viingilio vya Webhooks kutekelezwa uwezo wa kuamua ni matoleo gani AdmissionReview wanaunga mkono. Mwishowe, sheria za Webhook za Uandikishaji ni sasa inaweza kuwa mdogo kiwango cha matumizi yao kwa nafasi za majina na mifumo ya nguzo.

Vituo vya uhifadhi

PersistentLocalVolumes, ambayo ilikuwa na hali ya beta tangu kutolewa K8s 1.10, alitangaza thabiti (GA): lango la kipengele hiki halijazimwa tena na litaondolewa katika Kubernetes 1.17.

Fursa kutumia vigezo vya mazingira vinavyoitwa API ya chini (kwa mfano, jina la ganda) kwa majina ya saraka zilizowekwa kama subPath, ilitengenezwa - kwa namna ya uwanja mpya subPathExpr, ambayo sasa inatumiwa kuamua jina la saraka inayotaka. Kipengele hapo awali kilionekana katika Kubernetes 1.11, lakini kwa 1.14 kilibaki katika hali ya toleo la alpha.

Kama ilivyokuwa kwenye toleo la awali la Kubernetes, mabadiliko mengi muhimu yanaletwa kwa CSI inayoendelea (Kiolesura cha Kuhifadhi Kontena):

CSI

Ilipatikana (kama sehemu ya toleo la alpha) kusaidia kubadilisha ukubwa kwa viwango vya CSI. Ili kuitumia utahitaji kuwezesha lango la kipengele linaloitwa ExpandCSIVolumes, pamoja na kuwepo kwa msaada kwa operesheni hii katika dereva maalum wa CSI.

Kipengele kingine cha CSI katika toleo la alpha - nafasi rejelea moja kwa moja (yaani bila kutumia PV/PVC) kwa viwango vya CSI ndani ya vipimo vya pod. Hii huondoa kizuizi cha matumizi ya CSI kama hifadhi ya data ya mbali pekee, kuwafungulia milango ya ulimwengu kiasi cha ephemeral za mitaa. Kwa matumizi (mfano kutoka kwa nyaraka) lazima kuwezeshwa CSIInlineVolume lango la kipengele.

Pia kumekuwa na maendeleo katika "za ndani" za Kubernetes zinazohusiana na CSI, ambazo hazionekani sana kwa watumiaji wa mwisho (wasimamizi wa mfumo) ... Hivi sasa, watengenezaji wanalazimika kuunga mkono matoleo mawili ya kila programu-jalizi ya uhifadhi: moja - "katika zamani", ndani ya codebase ya K8s (in -tree), na ya pili - kama sehemu ya CSI mpya. (soma zaidi juu yake, kwa mfano, in hapa). Hii husababisha usumbufu unaoeleweka ambao unahitaji kushughulikiwa kadri CSI yenyewe inavyotengemaa. Haiwezekani kuacha tu API ya programu-jalizi za ndani (ndani ya mti) kwa sababu ya sera husika ya Kubernetes.

Yote hii ilisababisha ukweli kwamba toleo la alpha lilifikia mchakato wa uhamiaji msimbo wa programu-jalizi wa ndani, kutekelezwa kama ndani ya mti, katika programu-jalizi za CSI, kutokana na hilo wasiwasi wa wasanidi programu utapunguzwa ili kusaidia toleo moja la programu-jalizi zao, na uoanifu na API za zamani zitasalia na zinaweza kutangazwa kuwa hazitumiki katika hali ya kawaida. Inatarajiwa kuwa ifikapo toleo lijalo la Kubernetes (1.15) programu-jalizi zote za watoa huduma za wingu zitahamishwa, utekelezaji utapokea hali ya beta na utawashwa katika usakinishaji wa K8s kwa chaguomsingi. Kwa maelezo, tazama pendekezo la kubuni. Uhamiaji huu pia ulisababisha kushindwa kutoka kwa mipaka ya kiasi iliyofafanuliwa na watoa huduma maalum wa wingu (AWS, Azure, GCE, Cinder).

Zaidi ya hayo, msaada wa kuzuia vifaa na CSI (CSIBlockVolume) kuhamishwa kwa toleo la beta.

Nodi/Kubelet

Toleo la alfa limewasilishwa mwisho mpya katika Kubelet, iliyoundwa kwa ajili ya kurejesha metriki kwenye rasilimali muhimu. Kwa ujumla, ikiwa hapo awali Kubelet ilipokea takwimu za matumizi ya kontena kutoka kwa cAdvisor, sasa data hii inatoka kwa mazingira ya matumizi ya kontena kupitia CRI (Kiolesura cha Muda wa Kontena), lakini utangamano wa kufanya kazi na matoleo ya zamani ya Docker pia huhifadhiwa. Hapo awali, takwimu zilizokusanywa katika Kubelet zilitumwa kupitia API ya REST, lakini sasa sehemu ya mwisho iko katika /metrics/resource/v1alpha1. Mkakati wa muda mrefu wa watengenezaji inajumuisha ni kupunguza seti ya vipimo vilivyotolewa na Kubelet. Kwa njia, metriki hizi zenyewe sasa wanapiga simu si "metrics za msingi", lakini "metrics za rasilimali", na zinafafanuliwa kama "rasilimali za daraja la kwanza, kama vile cpu, na kumbukumbu".

Nuance ya kuvutia sana: licha ya faida ya wazi ya utendaji wa mwisho wa gRPC kwa kulinganisha na matukio mbalimbali ya kutumia umbizo la Prometheus. (tazama matokeo ya mojawapo ya vigezo hapa chini), waandishi walipendelea muundo wa maandishi wa Prometheus kutokana na uongozi wazi wa mfumo huu wa ufuatiliaji katika jamii.

"gRPC haioani na mabomba makubwa ya ufuatiliaji. Endpoint itakuwa muhimu tu kwa kuwasilisha vipimo kwenye Seva ya Metrics au vipengele vya ufuatiliaji vinavyounganishwa nayo moja kwa moja. Utendaji wa umbizo la maandishi ya Prometheus unapotumia akiba kwenye Seva ya Metrics nzuri ya kutosha kwa sisi kupendelea Prometheus kuliko gRPC kutokana na kupitishwa kwa Prometheus katika jamii. Pindi umbizo la OpenMetrics linapokuwa thabiti zaidi, tutaweza kukabiliana na utendaji wa gRPC kwa umbizo la msingi wa proto."

Mojawapo ya majaribio ya utendakazi ya utumiaji wa fomati za gRPC na Prometheus katika ncha mpya ya Kubelet ya vipimo. Grafu zaidi na maelezo mengine yanaweza kupatikana ndani CAP.

Miongoni mwa mabadiliko mengine:

• Kubelet sasa (mara moja) kujaribu kuacha vyombo katika hali isiyojulikana kabla ya kuanzisha upya na kufuta shughuli.
• Wakati wa kutumia PodPresets sasa kwenye chombo cha init imeongezwa habari sawa na kwa chombo cha kawaida.
• kubelet kuanza kutumia usageNanoCores kutoka kwa mtoaji wa takwimu wa CRI, na kwa nodi na vyombo kwenye Windows aliongeza takwimu za mtandao.
• Mfumo wa uendeshaji na maelezo ya usanifu sasa yanarekodiwa katika lebo kubernetes.io/os и kubernetes.io/arch Vitu vya nodi (kuhamishwa kutoka beta hadi GA).
• Uwezo wa kutaja kikundi maalum cha watumiaji wa mfumo kwa vyombo kwenye ganda (RunAsGroup, alionekana ndani K8s 1.11) ya juu kabla ya beta (imewezeshwa kwa chaguomsingi).
• du na kupata kutumika katika cAdvisor, kubadilishwa kwenye utekelezaji wa Go.

CLI

Katika cli-runtime na kubectl imeongezwa -k bendera ya kuunganishwa na Customize (kwa njia, maendeleo yake sasa yanafanywa katika hifadhi tofauti), i.e. kuchakata faili za ziada za YAML kutoka saraka maalum za kustomization (kwa maelezo juu ya kuzitumia, ona CAP):

Mfano wa matumizi rahisi ya faili ubinafsishaji (matumizi magumu zaidi ya kustomize yanawezekana ndani kuingiliana)

Kwa kuongeza:

• Imeongezwa timu mpya kubectl create cronjob, ambaye jina lake linajieleza lenyewe.
• В kubectl logs sasa unaweza unganisha bendera -f (--follow kwa magogo ya utiririshaji) na -l (--selector kwa swali la lebo).
• kubectl kufundishwa nakala faili zilizochaguliwa na kadi ya mwitu.
• Kwa timu kubectl wait imeongezwa bendera --all kuchagua rasilimali zote katika nafasi ya majina ya aina ya rasilimali iliyobainishwa.

Wengine

Uwezo ufuatao umepokea hali thabiti (GA):

• ReadinessGate, kutumika katika vipimo vya ganda ili kufafanua masharti ya ziada yaliyozingatiwa katika utayari wa ganda;
• Msaada kwa kurasa kubwa (lango la kipengele linaitwa HugePages);
• CustomPodDNS;
• PriorityClass API Kipaumbele cha Pod & Uzuiaji.

Mabadiliko mengine yaliyoletwa katika Kubernetes 1.14:

• Sera chaguo-msingi ya RBAC hairuhusu tena ufikiaji wa API discovery и access-review watumiaji bila uthibitishaji (haijathibitishwa).
• Usaidizi rasmi wa CoreDNS kuhakikishwa Linux pekee, kwa hivyo unapotumia kubeadm kuipeleka (CoreDNS) kwenye nguzo, nodi lazima ziendeshwe kwenye Linux pekee (nodeSelectors hutumiwa kwa kizuizi hiki).
• Usanidi chaguo-msingi wa CoreDNS ni sasa hutumia mbele Plugin badala ya wakala. Pia, katika CoreDNS aliongeza ReadinessProbe, ambayo huzuia kusawazisha mzigo kwenye maganda yanayofaa (hayako tayari kwa huduma).
• Katika kubeadm, kwa awamu init au upload-certs, ikawa inawezekana pakia vyeti vinavyohitajika ili kuunganisha ndege-dhibiti mpya kwa siri ya kubeadm-certs (tumia bendera --experimental-upload-certs).
• Toleo la alpha limeonekana kwa usakinishaji wa Windows msaada gMSA (Akaunti ya Huduma Inayodhibitiwa na Kundi) - akaunti maalum katika Saraka Inayotumika ambazo zinaweza pia kutumiwa na vyombo.
• Kwa G.C.E. imeamilishwa usimbaji fiche wa mTLS kati ya etcd na kube-apiserver.
• Masasisho katika programu inayotumika/tegemezi: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 usaidizi katika kubeadm, na toleo la chini kabisa la API ya Docker inayotumika sasa ni 1.26.

PS

Soma pia kwenye blogi yetu:

• «Kubernetes 1.13: Vivutio vya kile kipya";
• «Kubernetes 1.12: Vivutio vya kile kipya";
• «Kubernetes 1.11: Vivutio vya kile kipya";
• «Kubernetes 1.10: Vivutio vya kile kipya'.

Chanzo: mapenzi.com