ProHoster > Blog > Administrim > Kubernetes 1.16: përmbledhje e risive kryesore

Kubernetes 1.16: përmbledhje e risive kryesore

Kubernetes 1.16: përmbledhje e risive kryesore

Sot, në merkur, do të ndodhë është një lëshim tjetër i Kubernetes - 1.16. Sipas traditës për blogun tonë, për herë të dhjetë jubile prej themelimit, ne do të flasim për ndryshimet më të rëndësishme në versionin e ri.

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga tabela e ndjekjes së përmirësimeve të Kubernetes, CHANGELOG-1.16 dhe problemet, kërkesat për tërheqje, si dhe Propozimet për Përmirësim të Kubernetes (KEP). Pra, le të fillojmë!..

Nyjet

Një numër të vërtetë të madh ndryshimesh të dukshme (në statusin alfa) është paraqitur në anën e nyjeve të grupeve K8s (Kubelet).

Para se gjithash, janë paraqitur të ashtuquajturat «kontejnerët efemerë» (Ephemeral Containers), të cilët synojnë të lehtësojnë proceset e debug në POD-e. Mekanizmi i ri lejon nisjen e kontejnerëve të veçantë, të cilët fillojnë në hapësirën e emrave të POD-eve ekzistues dhe jetojnë për një kohë të shkurtër. Qëllimi i tyre është ndërveprimi me POD-et dhe kontejnerët e tjerë për të zgjidhur ndonjë problem dhe për debug. Për këtë mundësi është realizuar një komandë e re kubectl debug, e cila është e ngjashme në thelb me kubectl exec: vetëm se në vend të nisjes së një procesi në kontejner (si në rastin e exec) ajo nis një kontejner në POD. Për shembull, një komandë e tillë do të lidhi një kontejner të ri me POD-in:

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

Detajet mbi kontejnerët efemerë (dhe shembujt e përdorimit të tyre) mund të gjenden në KEP-in përkatës. Implementimi aktual (në K8s 1.16) është një version alfa, dhe mes kritereve për kalimin e tij në versionin beta është "testimi i API-t të kontejnerëve efemerë për të paktën 2 lëshime [Kubernetes]."

NB: Në thelb dhe madje edhe me emrin, kjo veçori i kujton një plugin ekzistues kubectl-debug, për të cilin ne kemi shkruar më parë. Parashikohet që me shfaqjen e kontejnerëve efemerë, zhvillimi i plugin-it të veçantë të jashtëm do të ndalet.

NjĂ« tjetĂ«r risi Ă«shtĂ« PodOverhead — e cila ka si qĂ«llim tĂ« ofrojĂ« mekanizmin e llogaritjes sĂ« kostove pĂ«r POD-et, tĂ« cilat mund tĂ« ndryshojnĂ« ndjeshĂ«m nĂ« varĂ«si tĂ« mjedisit tĂ« ekzekutimit tĂ« pĂ«rdorur (runtime). Si njĂ« shembull, autorĂ«t e kĂ«tij KEP pĂ«rmendin Kata Containers, tĂ« cilat kĂ«rkojnĂ« nisjen e njĂ« bĂ«rthame tĂ« mysafirĂ«ve, agjenti kata, sistemin init etj. Kur overhead-i bĂ«het kaq i madh, nuk mund tĂ« injorohet, domethĂ«nĂ« - kĂ«rkohet njĂ« mĂ«nyrĂ« pĂ«r ta marrĂ« parasysh atĂ« pĂ«r kuotat e mĂ«tejshme, planifikimin etj. PĂ«r ta realizuar kĂ«tĂ«, nĂ« PodSpec Ă«shtĂ« shtuar njĂ« fushĂ« Overhead *ResourceList (pĂ«rcaktohet me tĂ« dhĂ«nat nĂ« RuntimeClass, nĂ«se ekzsiton).

NjĂ« tjetĂ«r ndryshim i dukshĂ«m Ă«shtĂ« menaxheri i topologjisĂ« sĂ« nyjeve (Node Topology Manager), i cili synon tĂ« unifikojĂ« qasjen pĂ«r konfigurimin e ndarjes sĂ« burimeve harduerike pĂ«r komponentĂ«t e ndryshĂ«m nĂ« Kubernetes. Kjo iniciativĂ« Ă«shtĂ« shkaktuar nga nevoja nĂ« rritje e sistemeve moderne tĂ« ndryshme (nga fusha e telekomunikacionit, mĂ«simit tĂ« makinerive, shĂ«rbimeve financiare etj.) pĂ«r llogaritje paralele me performancĂ« tĂ« lartĂ« dhe minimizimin e vonesave gjatĂ« ekzekutimit tĂ« operacioneve, pĂ«r tĂ« cilat ata pĂ«rdorin mundĂ«sitĂ« pĂ«rparimtare tĂ« CPU-sĂ« dhe pĂ«rshpejtimin harduerik. Optimizimet e tilla nĂ« Kubernetes deri mĂ« sot janĂ« arritur pĂ«rmes komponenteve tĂ« ndryshme (menaxheri i CPU-sĂ«, menaxheri i pajisjeve, CNI), dhe tani do t’i shtohet njĂ« ndĂ«rfaqe e brendshme e vetme, e cila unifikon qasjen dhe thjeshton lidhjen e komponenteve tĂ« ngjashme tĂ« quajtura topology-aware nga ana e Kubelet. Detajet – nĂ« KEP-in pĂ«rkatĂ«s.

Kubernetes 1.16: përmbledhje e risive kryesore
Skema e komponenteve të Menaxherit të Topologjisë

Tipari tjetër është kontrolli i konteinerëve gjatë nisjes së tyre (starter probe). Siç dihet, për konteinerët që nisën ngadalë, është e vështirë të merret statusi aktual: ata ose 'vriten' para se të fillojnë në të vërtetë funksionimin e tyre, ose bien në një deadlock për një periudhë të gjatë. Kontrolli i ri (aktivizohet përmes një gate funksioni të quajtur StartupProbeEnabled) anulon - më saktësisht, shtyn veprimin e çdo kontrolli tjetër deri në momentin kur pod-i ka përfunduar nisjen e tij. Për këtë arsye, ky tipar fillimisht u quajt pod-startup liveness-probe holdoff. Për pod-et që nisën ngadalë, mund të kryhen pyetje për statusin në intervale të shkurtra kohore.

Për më tepër, menjëherë në statusin beta është paraqitur një përmirësim për RuntimeClass, duke shtuar mbështetje për 'klastere heterogjene'. C RuntimeClass Scheduling tani nuk është e nevojshme që çdo nyje të ketë mbështetje për çdo RuntimeClass: për pod-et mund të zgjidhet RuntimeClass, pa menduar për topologjinë e klasterit. Më parë, për të arritur këtë - për të siguruar që pod-et ishin në nyje me mbështetje për gjithçka që iu duhej - ishte e nevojshme të caktoheshin rregullat për NodeSelector dhe tolerimet. Në KEP shkruhet për shembuj të përdorimit dhe, sigurisht, detajet e implementimit.

Rrjeti

Dy tipare të rëndësishme rrjeti, që u shfaqën për herë të parë (në versionin alpha) në Kubernetes 1.16 - janë:

  • MbĂ«shtetje steka dyfishe e rrjetit – IPv4/IPv6 — dhe pĂ«rkatĂ«sja e tij "kuptimi" nĂ« nivelin e pod-Ă«ve, nyjave, shĂ«rbimeve. Kjo pĂ«rfshin ndĂ«rveprimin IPv4-to-IPv4 dhe IPv6-to-IPv6 midis pod-Ă«ve, nga pod-et nĂ« shĂ«rbime tĂ« jashtme, implementime referuese (nĂ« kuadĂ«r tĂ« plug-in-eve Bridge CNI, PTP CNI dhe Host-Local IPAM), si dhe mbĂ«shtetje pĂ«r backward compatibility me klasterĂ«t Kubernetes qĂ« punojnĂ« vetĂ«m me IPv4 ose IPv6. Detajet e implementimit janĂ« nĂ« KEP.

    Shembulli i daljes së IP-adresave të dy llojeve (IPv4 dhe IPv6) në listën e pod-ëve:

    kube-master# kubectl get pods -o wide
EMRI              GATI     STATUS    RIKTHIME   MOSHA      IP                          NYJA
nginx-controller   1/1       Duke funksionuar   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#

  • API i ri pĂ«r Endpoint — EndpointSlice API. Ai zgjidh problemet e performancĂ«s/skallarizueshmĂ«risĂ« sĂ« API ekzistues pĂ«r Endpoint qĂ« prekin komponente tĂ« ndryshme nĂ« control-plane (apiserver, etcd, endpoints-controller, kube-proxy). API i ri do tĂ« shtohet nĂ« grupin e API-ve Discovery dhe do tĂ« jetĂ« nĂ« gjendje tĂ« shĂ«rbejĂ« dhjetĂ«ra mijĂ«ra endpoint-e tĂ« backend nĂ« çdo shĂ«rbim nĂ« klasterin qĂ« pĂ«rbĂ«het nga mijĂ«ra nyja. PĂ«r kĂ«tĂ«, çdo ShĂ«rbim shfaqet nĂ« N objekte EndpointSlice, secili prej tĂ« cilĂ«ve ka siç Ă«shtĂ« parazgjedhur jo mĂ« shumĂ« se 100 endpoint-e (vlera Ă«shtĂ« e konfiguruar). NĂ« API EndpointSlice do tĂ« parashikohen dhe mundĂ«sitĂ« pĂ«r zhvillimin e tij tĂ« ardhshĂ«m: mbĂ«shtetje pĂ«r shumĂ« IP-adresa pĂ«r çdo pod, gjendje tĂ« reja pĂ«r endpoint-et (jo vetĂ«m Gati dhe JoGati), subsetim dinamik pĂ«r endpoint-et.

Derisa beta-vedja e paraqitur në lëshimin e kaluar finalizer, e quajtur service.kubernetes.io/load-balancer-cleanup e cila është e lidhur me çdo shërbim me lloj LoadBalancer. Në momentin e fshirjes së këtij shërbimi, ai parandalon fshirjen e vërtetë të burimit, derisa të përfundojë "pastrimi" i të gjitha burimeve përkatëse të balancuesit.

API Machinery

Një "pika ndalimi" e vërtetë është regjistruar në fushën e serverit API Kubernetes dhe ndërveprimit me të. Kjo ndodhi në masë të madhe për shkak të kalimit në statusin stable të CustomResourceDefinitions (CRD) nuk kërkuan përfaqësim të veçantë që ishin në statusin beta që nga Kubernetes 1.7 (kjo është qershor 2017!). Të njëjtën stabilizim e morën edhe funksionet që lidhen me to:"nënburimet" (subresources)

  • me pĂ«r CustomResources; /status dhe /scale versionet pĂ«r CRD, e bazuar nĂ« webhook tĂ« jashtĂ«m;
  • konvertimi vlerat e paracaktuara tĂ« paraqitur rishtazi
  • (defaulting) dhe fshirja automatike e fushave (pruning) pĂ«rdorimi i skemĂ«s OpenAPI v3 pĂ«r krijimin dhe publikimin e dokumentacionit OpenAPI, qĂ« pĂ«rdoret pĂ«r validimin e burimeve CRD nĂ« anĂ«n e serverit. (pruning) versionet pĂ«r CRD, e bazuar nĂ« webhook tĂ« jashtĂ«m;
  • mundĂ«sia pĂ«rdorimi i skemĂ«s OpenAPI v3 pĂ«r krijimin dhe publikimin e dokumentacionit OpenAPI, qĂ« pĂ«rdoret pĂ«r validimin e burimeve CRD nĂ« anĂ«n e serverit.

Një mekanizëm tjetër, që ka kohë që është bërë i njohur për administratorët e Kubernetes: webhooki i pranimit po ashtu ka qëndruar për një kohë të gjatë në statusin beta (në K8s 1.9) dhe tani është shpallur stabil.

Dy karakteristika të tjera arritën versionin beta: aplikimi në anën e serverit dhe shënimet e vëzhgimit.

NdĂ«rsa zhvillimi i vetĂ«m i rĂ«ndĂ«sishĂ«m nĂ« versionin alfa ishte heqja nga SelfLink - njĂ« URI speciale qĂ« pĂ«rfaqĂ«son objektin e caktuar dhe Ă«shtĂ« pjesĂ« e ObjectMeta dhe ListMeta (dmth pjesĂ« e çdo objekti nĂ« Kubernetes). Pse po braktiset? Motivimi "thjesht" tingĂ«llon si mungesa e arsyeve tĂ« vĂ«rteta (tĂ« pakalueshme) pĂ«r qĂ« ky fushĂ« tĂ« ekzistojĂ« ende. Arsyet mĂ« formale janĂ« optimizimi i performancĂ«s (duke zhdukur fushĂ«n e panevojshme) dhe thjeshtimi i funksionimit tĂ« generic-apiserver, i cili detyrohet tĂ« pĂ«rpunojĂ« kĂ«tĂ« fushĂ« nĂ« njĂ« mĂ«nyrĂ« tĂ« veçantĂ« (kjo Ă«shtĂ« fushĂ« e vetme qĂ« vendoset menjĂ«herĂ« para serializimit tĂ« objektit). VĂ«rtet "shkalla e vjetĂ«rsimit" (nĂ« kuadĂ«r tĂ« versionit beta) SelfLink do tĂ« ndodhi deri nĂ« versionin Kubernetes 1.20, ndĂ«rsa pĂ«rfundimtare – 1.21.

Ruajtja e të dhënave

Puna kryesore në fushën e ruajtjes, si në versionet e mëparshme, vërehet në fushën mbështetjes CSI. Ndryshimet kryesore këtu ishin:

  • pĂ«r herĂ« tĂ« parĂ« (nĂ« versionin alfa) ka dalĂ« mbĂ«shtetje pĂ«r plugins CSI pĂ«r nodet punuese nĂ« Windows: njĂ« mĂ«nyrĂ« aktuale pĂ«r tĂ« punuar me ruajtjet dhe kĂ«tu do tĂ« zĂ«vendĂ«sojĂ« plugins in-tree nĂ« kernelin Kubernetes dhe plugins FlexVolume nga Microsoft bazuar nĂ« Powershell;

    Kubernetes 1.16: përmbledhje e risive kryesore
    Skema e implementimit të plugins CSI në Kubernetes për Windows

  • mundĂ«sia ndryshimi i madhĂ«sive tĂ« volumeve CSI, e prezantuar gjithashtu nĂ« K8s 1.12, arriti nĂ« versionin beta;
  • njĂ« "rritje" tĂ« ngjashme (nga versioni alfa nĂ« versionin beta) arriti edhe mundĂ«sia e pĂ«rdorimit tĂ« CSI pĂ«r krijimin e volumeve efemerĂ« lokalĂ« (MbĂ«shtetje pĂ«r Volume inline CSI).

Funksioni i klonimit të volumeve, që shfaqet në versionin e kaluar të Kubernetes (përdorimi i PVC ekzistues si DataSource për krijimin e PVC-ve të reja) gjithashtu tani ka marrë statusin beta. Planifikuesi

Dy ndryshime të dukshme në planifikim (të dyja në versionin alfa):

EvenPodsSpreading

  • - mundĂ«sia pĂ«r "distribuimin e ndershĂ«m" tĂ« ngarkesave pĂ«rmes pod'ave nĂ« vend tĂ« njĂ«sive logjike tĂ« aplikacionit (si Deployment dhe ReplicaSet) dhe rregullimi i kĂ«tij shpĂ«rndarjeje (si njĂ« kĂ«rkesĂ« tĂ« rreptĂ« ose si njĂ« kusht tĂ« butĂ«, dmth. prioriteti). Karakteristika do tĂ« zgjasĂ« mundĂ«sitĂ« aktuale tĂ« shpĂ«rndarjes sĂ« pods tĂ« planifikuar, tĂ« cilat tani kufizohen nga opsionet PodAffinity PodAntiAffinity dhe PodAntiAffinity, duke ofron administratorĂ«ve kontroll mĂ« tĂ« hollĂ«sishĂ«m nĂ« kĂ«tĂ« çështje, dhe pĂ«r pasojĂ« - njĂ« disponibilitet mĂ« tĂ« lartĂ« dhe njĂ« konsum mĂ« tĂ« optimizuar tĂ« burimeve. Detajet - nĂ« KEP.
  • PĂ«rdorimi Politika BestFit nĂ« Funksioni Prioriteti RequestedToCapacityRatio nĂ« kohĂ«n e planifikimit tĂ« pod’ave, qĂ« do tĂ« lejojĂ« aplikohen bin packing ("paketimi nĂ« enĂ«") si pĂ«r burimet kryesore (procesori, memoria), ashtu edhe pĂ«r ato tĂ« avancuara (si GPU). PĂ«r mĂ« shumĂ«, shih nĂ« KEP.

    Kubernetes 1.16: përmbledhje e risive kryesore
    Planifikimi i pod’ave: deri nĂ« pĂ«rdorimin e politikĂ«s best fit (drejtpĂ«rdrejt pĂ«rmes planifikuesit default) dhe me pĂ«rdorimin e saj (pĂ«rmes scheduler extender)

Për më tepër, është paraqitur. mundësia për të krijuar plugujtë tuaj për planifikuesin jashtë pemës kryesore të zhvillimit të Kubernetes (out-of-tree).

Ndryshime të tjera

Gjithashtu në versionin Kubernetes 1.16 mund të theksohet inisiativa për rregullimin e metrikave ekzistuese në një rend të plotë, dhe nëse jemi më të saktë - përputhjen me rregulloret zyrtare për instrumentimin e K8s. Ato në thelb mbështeten në dokumentacionin përkatës të Prometheus. Mospërputhjet kanë ndodhur për arsye të ndryshme (p.sh., disa metrika ishin krijuar thjesht para se të shfaqeshin udhëzimet aktuale), dhe zhvilluesit vendosën se ishte koha për ta sjellë gjithçka në një standard të vetëm, "në përputhje me pjesën tjetër të ekosistemit Prometheus". Aktualisht kjo iniciativë ka statusin alfa, i cili do të rritet gradualisht në versionet e ardhshme të Kubernetes deri në beta (1.17) dhe stabil (1.18).

Për më tepër, mund të theksohen ndryshime të tjera:

  • Zhvillimi i mbĂ«shtetjes pĂ«r Windows me me utilitarin Kubeadm pĂ«r kĂ«tĂ« OS (version alfa), mundĂ«sia RunAsUserName pĂ«r enĂ« Windows (version alfa), pĂ«rmirĂ«simin e mbĂ«shtetjes pĂ«r Group Managed Service Account (gMSA) deri nĂ« version beta, tekstit alternativ mount/attach pĂ«r volume vSphere.
  • Rishikimi i mekanizmit tĂ« kompresimit tĂ« tĂ« dhĂ«nave nĂ« pĂ«rgjigjet API. MĂ« parĂ«, pĂ«r kĂ«to qĂ«llime pĂ«rdorej njĂ« filtrues HTTP, i cili vendoste njĂ« sĂ«rĂ« kufizimesh, duke penguar aktivizimin e tij si tĂ« par preset. Tani funksionon "kompresimi transparent i kĂ«rkesave": klientĂ«t qĂ« dĂ«rgojnĂ« Accept-Encoding: gzip nĂ« lidhjen e kĂ«rkesĂ«s, marrin njĂ« pĂ«rgjigje tĂ« kompresuar GZIP, nĂ«se pesha e saj kalonte 128 Kb. KlientĂ«t nĂ« Go automatikisht mbĂ«shtesin kompresimin (dĂ«rgojnĂ« lidhjen e nevojshme), kĂ«shtu qĂ« menjĂ«herĂ« do tĂ« vĂ«rejnĂ« njĂ« ulje tĂ« trafikut. (PĂ«r gjuhĂ« tĂ« tjera, mund tĂ« nevojiten modifikime tĂ« vogla.)
  • Ka bĂ«rĂ« tĂ« mundur shkallĂ«zimin e HPA nga/nĂ« zero pod’ash nĂ« bazĂ« tĂ« metrikave tĂ« jashtme. NĂ«se shkallĂ«zimi bĂ«het nĂ« bazĂ« tĂ« objekteve/metrikave tĂ« jashtme, kur ngarkesat e punĂ«s janĂ« nĂ« pritje, mund tĂ« shkallĂ«zohet automatikisht nĂ« 0 kopje pĂ«r tĂ« kursyer burimet. Kjo veçori duhet tĂ« jetĂ« veçanĂ«risht e dobishme nĂ« rastet kur punĂ«torĂ«t kĂ«rkojnĂ« burime GPU, kur numri i llojeve tĂ« ndryshme tĂ« punĂ«torĂ«ve nĂ« pritje kalon numrin e GPU-ve tĂ« disponueshme.
  • Konsumatori i ri — k8s.io/client-go/metadata.Client — pĂ«r akses "tĂ« pĂ«rgjithshĂ«m" nĂ« objekte. Ai Ă«shtĂ« projektuar pĂ«r tĂ« marrĂ« lehtĂ«sisht metadatĂ« (dmth. nĂ«nkategoritĂ« metadata) nga burimet e klashtit dhe pĂ«r tĂ« kryer operacione si mbledhja e mbetjeve dhe kuotimi.
  • Mbledh Kubernetes kombinohen pa ofrues tĂ« rinj cloud (versioni alfa).
  • NĂ« utilitarin kubeadm shtuan ka njĂ« mundĂ«si eksperimentale (versioni alfa) pĂ«r tĂ« aplikuar patch-e kustomize gjatĂ« operacioneve init, bashkohu dhe upgrade. MĂ« shumĂ« mbi si tĂ« pĂ«rdorni flagun --experimental-kustomize, shih nĂ« KEP.
  • Pika e re pĂ«r apiserver — readyz, — qĂ« lejon eksportin e informacionit mbi gatishmĂ«rinĂ« e tij (readiness). Gjithashtu, api-serveri tani ka njĂ« flag --maximum-startup-sequence-duration, qĂ« lejon rregullimin e rikthimeve tĂ« tij.
  • Dy veçori pĂ«r Azure u shpallĂ«n tĂ« stabilizuara: mbĂ«shtetje zonash tĂ« disponueshmĂ«risĂ« (Availability Zones) dhe grupe burimesh tĂ« kryqĂ«zuara (RG). PĂ«r mĂ« tepĂ«r, nĂ« Azure janĂ« shtuar:
  • AWS tani ka mbĂ«shtetje pĂ«r EBS nĂ« Windows dhe optimizuar Thirrjet API EC2 DescribeInstances.
  • Kubeadm tani migron vetĂ« konfigurimin e CoreDNS gjatĂ« pĂ«rditĂ«simit tĂ« versionit CoreDNS. BinarĂ«t
  • nĂ« imazhin pĂ«rkatĂ«s Docker etcd u bĂ«nĂ« dhe mund tĂ« ekzekutohen nga çdo pĂ«rdorues, duke lejuar ekzekutimin e kĂ«tij imazhi pa nevojĂ«n pĂ«r tĂ« drejtat root. PĂ«r mĂ« tepĂ«r, imazhi i migrimit tĂ« etcd ka mbĂ«shtetje pĂ«r versionin etcd2. ndaloi Cluster Autoscaler 1.16.0
  • NĂ« kaloi nĂ« pĂ«rdorimin e distroless si imazh bazĂ«, pĂ«rmirĂ«soi performancĂ«n, shtoi ofrues tĂ« rinj cloud (DigitalOcean, Magnum, Packet). PĂ«rditĂ«sime nĂ« softuerin e pĂ«rdorur/variable: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
  • đŸ„‡Kubernetes 1.16: njĂ« pĂ«rmbledhje e noviteteve kryesore | ProHoster

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster