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

Kubernetes 1.16: një përmbledhje e risive kryesore

Kubernetes 1.16: një përmbledhje e risive kryesore

Sot, e mĂ«rkurĂ«, do tĂ« ndodhi njĂ« tjetĂ«r lirimi i Kubernetes — 1.16. Sipas traditĂ«s sonĂ« pĂ«r blogun, pĂ«r herĂ« tĂ« dhjetĂ« po 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 Kubernetes, CHANGELOG-1.16 dhe issues, pull requests përkatëse, si dhe Propozimet për përmirësimin e Kubernetes (KEP). Pra, fillojmë!...

Nodet

Një numër të vërtetë të dukshëm të risive (në statusin e versionit alfa) janë paraqitur në anën e nodëve të klastereve K8s (Kubelet).

NĂ« radhĂ« tĂ« parĂ«, janĂ« paraqitur tĂ« ashtuquajturat «kontejnerĂ« efemerë» (Ephemeral Containers), tĂ« destinuara pĂ«r tĂ« thjeshtuar proceset e debugimit nĂ« pod’ë.Mekanizmi i ri lejon nisjen e konteinerĂ«ve tĂ« veçantĂ«, tĂ« cilĂ«t fillojnĂ« nĂ« hapĂ«sirĂ«n emĂ«rore tĂ« pod’ëve ekzistues dhe jetojnĂ« pĂ«r njĂ« periudhĂ« tĂ« shkurtĂ«r kohe. QĂ«llimi i tyre Ă«shtĂ« tĂ« lidhen me pod’ët dhe konteinerĂ«t e tjerĂ« pĂ«r tĂ« zgjidhur probleme dhe pĂ«r debugim. PĂ«r kĂ«tĂ« mundĂ«si Ă«shtĂ« implementuar njĂ« komandĂ« e re kubectl debug, e ngjashme me kubectl exec: vetĂ«m se nĂ« vend tĂ« nisjes sĂ« procesit nĂ« konteiner (si nĂ« rastin e exec) ajo nis njĂ« konteiner nĂ« pod. PĂ«r shembull, njĂ« komandĂ« e tillĂ« do tĂ« lidhi njĂ« konteiner tĂ« ri me pod’in:

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

Detajet rreth kontejnerëve efemer (dhe shembuj të përdorimit të tyre) mund të gjenden në KEP përkatës. Realizimi aktual (në K8s 1.16) është një version alfa, dhe midis kritereve për kalimin në versionin beta përfshihet "testimi i Ephemeral Containers API për gjithsej të paktën 2 lëshime [Kubernetes]".

NB: Në thelb dhe madje edhe me emrin e saj, karakteristika i ngjan tashmë ekzistuesit plugin kubectl-debug, për të cilin ne kemi shkruar. Pritet që me shfaqjen e kontejnerëve efemer, zhvillimi i një plugini të jashtëm të veçantë do të pezullohet.

NjĂ« tjetĂ«r novitet Ă«shtĂ« PodOverhead — e cila synon tĂ« ofrojĂ« mekanizmin pĂ«r llogaritjen e kostove mbĂ«shtetĂ«se pĂ«r pod-in, tĂ« cilat mund tĂ« ndryshojnĂ« ndjeshĂ«m nĂ« varĂ«si tĂ« mjedisit tĂ« ekzekutimit (runtime) tĂ« pĂ«rdorur. Si shembuj, autorĂ«t e kĂ«tij KEP pĂ«rmendin Kata Containers, tĂ« cilat kĂ«rkojnĂ« aktivizimin e njĂ« bĂ«rthame mysafire, agjentit kata, sistemit init etj. Kur overhead-i bĂ«het aq i madh, nuk mund tĂ« injorohet, andaj kĂ«rkohet njĂ« mĂ«nyrĂ« pĂ«r ta llogaritur atĂ« pĂ«r kuotime tĂ« mĂ«tejshme, planifikim etj. PĂ«r t'u realizuar, nĂ« PodSpec Ă«shtĂ« shtuar fusha Overhead *ResourceList (e cila korrespondon me tĂ« dhĂ«nat nĂ« RuntimeClass, nĂ«se Ă«shtĂ« e tillĂ« e pĂ«rdorur).

Një tjetër risi e dukshme është menaxheri i topologjisë së nyjës (Menaxheri i Topologjisë së Nyjës), i krijuar për të unifikuar qasjen ndaj optimizimit të ndarjes së burimeve harduerike për komponentë të ndryshëm në Kubernetes. Kjo nismë është e shkaktuar nga nevoja në rritje e sistemeve moderne të ndryshme (nga fushat e telekomunikacionit, të mësimit të makinerive, shërbimeve financiare, etj.) për llogaritje paralelesh me performancë të lartë dhe minimizimin e vonesave gjatë realizimit të operacioneve, për këtë ato përdorin kapacitetet e avancuara të CPU-së dhe përshpejtimin harduerik. Të tilla optimizime në Kubernetes deri tani janë arritur përmes komponentëve të shkëputur (menaxheri i CPU-së, menaxheri i pajisjeve, CNI), dhe tani do t'u shtohet një ndërfaqe e brendshme e njëjtë, e cila do të unifikoje qasjen dhe do të thjeshtojë lidhjen e komponentëve të ngjashëm të quajtur topology-aware në anën e Kubelet. Detajet janë në KEP përkatës.

Kubernetes 1.16: një përmbledhje e risive kryesore
Skema e komponentëve të Menaxherit të Topologjisë

Tipari tjetĂ«r Ă«shtĂ« kontrolli i kontejnerĂ«ve gjatĂ« nisjes sĂ« tyre (verifikimi i nisjes). Si e dihet, pĂ«r konteinerĂ«t qĂ« ngadalĂ« fillojnĂ«, Ă«shtĂ« e vĂ«shtirĂ« tĂ« merret njĂ« status aktual: ato ose 'vriten' para se tĂ« fillojnĂ« funksionimin real, ose bien nĂ« njĂ« gjendje deadlock pĂ«r njĂ« kohĂ« tĂ« gjatĂ«. Kontrolli i ri (aktivehet pĂ«rmes njĂ« feature gate tĂ« quajtur StartupProbeEnabled) e anulon – pĂ«r tĂ« qenĂ« mĂ« saktĂ«, e vonon – veprimin e çdo kontrolli tjetĂ«r deri nĂ« momentin kur pod-i pĂ«rfundon fillimin e tij. PĂ«r kĂ«tĂ« arsye, funksioni fillimisht u quajt pod-startup liveness-probe holdoff. PĂ«r pod-et qĂ« fillojnĂ« ngadalĂ«, mund tĂ« kryhen kontrolle tĂ« gjendjes nĂ« intervale tĂ« arsyeshme tĂ« shkurtra.

PĂ«r mĂ« tepĂ«r, menjĂ«herĂ« nĂ« statusin e versionit beta Ă«shtĂ« paraqitur njĂ« pĂ«rmirĂ«sim pĂ«r RuntimeClass, qĂ« shton mbĂ«shtetje pĂ«r 'klasterĂ«t heterogjenĂ«'. Tani RuntimeClass Scheduling nuk Ă«shtĂ« aspak e domosdoshme 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Ă« – qĂ« pod-et tĂ« pĂ«rfundojnĂ« nĂ« nyje me mbĂ«shtetjen e gjithçkaje qĂ« u nevojitej – ishte e nevojshme tĂ« emĂ«rtoheshin rregulla pĂ«r NodeSelector dhe tolerances. NĂ« KEP shpjegohen shembuj tĂ« pĂ«rdorimit dhe, sigurisht, detaje tĂ« implementimit.

RRjeti

Dy funksione të rëndësishme një rrjete, të cilat u shfaqën për herë të parë (në versionin alfa) në Kubernetes 1.16 - janë:

  • MbĂ«shtetje steka e dyfishtĂ« e rrjetit - IPv4/IPv6 dhe kuptimi i tij pĂ«rkatĂ«s nĂ« nivelin e pod’ave, nyjeve, shĂ«rbimeve. Kjo pĂ«rfshin ndĂ«rveprimin IPv4-to-IPv4 dhe IPv6-to-IPv6 midis pod’ave, nga pod’ët nĂ« shĂ«rbime tĂ« jashtme, implementimet referuese (nĂ« kuadĂ«r tĂ« plugin-eve Bridge CNI, PTP CNI dhe Host-Local IPAM), si dhe mbĂ«shtetje pĂ«r versionet e mĂ«parshme me Kubernetes qĂ« funksionojnĂ« vetĂ«m me IPv4 ose IPv6. Detajet e implementimit - nĂ« KEP.

    Shembulli i shfaqjes sĂ« adresave IP tĂ« dy llojeve (IPv4 dhe IPv6) nĂ« listĂ«n e pod’ave:

    kube-master# kubectl get pods -o wide
EMRI               GATI     STATUS    RIKTHESA   MOSHAT     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 API tĂ« ekzistueshĂ«m Endpoint me performancĂ«n/zhvillimin, qĂ« ndihin komponentet e ndryshme nĂ« control-plane (apiserver, etcd, endpoints-controller, kube-proxy). API i ri do tĂ« shtohet nĂ« grupin e API Discovery dhe do tĂ« mund tĂ« shĂ«rbejĂ« dhjetĂ«ra mijĂ«ra endpoint’esh ndaj secilit shĂ«rbim nĂ« njĂ« klaster me mijĂ«ra nyje. PĂ«r kĂ«tĂ«, çdo ShĂ«rbim pĂ«rfaqĂ«sohet nĂ« N objekte EndpointSlice, secili prej tĂ« cilĂ«ve pĂ«r defolt ka jo mĂ« shumĂ« se 100 endpoint-e (vlera Ă«shtĂ« e konfigurueshme). NĂ« API-nĂ« EndpointSlice janĂ« parashikuar edhe mundĂ«sitĂ« pĂ«r zhvillimin e tij tĂ« ardhshĂ«m: mbĂ«shtetje pĂ«r shumĂ« IP adresash pĂ«r secilin pod, gjendje tĂ« reja pĂ«r endpoint-et (jo vetĂ«m Gati dhe NotReady), nĂ«ngrup tĂ« dinamik pĂ«r endpoint-et.

Ka arritur në versionin beta përpara paraqitur në riparimin e kaluar finalizer, i quajtur service.kubernetes.io/load-balancer-cleanup dhe i lidhur me çdo shërbim me tipin LoadBalancer. Në momentin e fshirjes së këtij shërbimi, ai parandalon fshirjen efektive të burimit derisa të përfundojë "pastrimi" i të gjitha burimeve përkatëse të ekuilibrit.

API Machinery

Kjo "pikë referimi për stabilizimin" është regjistruar në fushën e API serverit Kubernetes dhe ndërveprimit me të. Kjo ndodhi kryesisht falë shkarkimit në statusin stable të cilat nuk kanë nevojë për paraqitje të veçantë CustomResourceDefinitions (CRD), që kishin statusin beta që nga Kubernetes 1.7 (dhe kjo është qershor 2017!). Stabilizimi i njëjtë ka ardhur gjithashtu në funksionet e lidhura me to:

  • "nĂ«nburimet" (subresources) me /status dhe /scale pĂ«r CustomResources;
  • konvertimi versionet pĂ«r CRD, tĂ« bazuara nĂ« njĂ« webhook tĂ« jashtĂ«m;
  • tĂ« paraqitura sĂ« fundmi (nĂ« K8s 1.15) vlerat e paracaktuara (defaulting) dhe fshirja automatike e fushave (pruning) pĂ«r CustomResources;
  • 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 bĂ«rĂ« njĂ« kohĂ« tĂ« gjatĂ« pjesĂ« tĂ« jetĂ«s sĂ« administratorĂ«ve Kubernetes: webhook pranimi – gjithashtu ka qenĂ« pĂ«r njĂ« kohĂ« tĂ« gjatĂ« nĂ« statusin beta (nga K8s 1.9) dhe tani Ă«shtĂ« shpallur stabil.

Dy karakteristika të tjera arritën versionin beta: aplikimi në anën e serverit dhe shikimi i shënimeve.

Dhe e vetmja risi e rĂ«ndĂ«sishme nĂ« versionin alfa ishte refuzimi nga SelfLink – njĂ« URI i veçantĂ« qĂ« paraqet objektin e caktuar dhe Ă«shtĂ« pjesĂ« e ObjectMeta dhe ListMeta (dmth. njĂ« pjesĂ« e çdo objekti nĂ« Kubernetes). Pse refuzohet ai? Motivimi "nĂ« mĂ«nyrĂ« tĂ« thjeshtĂ«" tingĂ«llon si mungesa e arsyeve tĂ« vĂ«rteta (tĂ« pa pĂ«rballueshme) pĂ«r tĂ« cilat ky fushĂ« duhet tĂ« ekzistojĂ« ende. Arsyet mĂ« formale – pĂ«r tĂ« optimizuar performancĂ«n (duke hequr fushĂ«n e panevojshme) dhe pĂ«r tĂ« thjeshtuar punĂ«n e generic-apiserver, i cili Ă«shtĂ« i detyruar tĂ« trajtojĂ« njĂ« fushĂ« tĂ« tillĂ« nĂ« njĂ« mĂ«nyrĂ« tĂ« veçantĂ« (ky Ă«shtĂ« fushĂ« e vetme qĂ« vendoset menjĂ«herĂ« para serializimit tĂ« objektit). „Pranimi i vĂ«rtetĂ« tĂ« "mosdaljes" (dhe pĂ«r versionin beta) SelfLink do tĂ« ndodhĂ« nĂ« versionin Kubernetes 1.20, dhe pĂ«rfundimtar – 1.21.

Ruajtja e të dhënave

Veprimtaria kryesore në fushën e ruajtjes, ashtu si në versionet e mëparshme, vërehet në fushën përkrahjes CSI. Ndryshimet kryesore këtu ishin:

  • pĂ«r herĂ« tĂ« parĂ« (nĂ« versionin alpha) ka arritur pĂ«rkrahja e plugineve CSI pĂ«r nodet e Windows: mĂ«nyra aktuale e punĂ«s me ruajtjet dhe kĂ«tu do tĂ« zĂ«vendĂ«sojĂ« pluginĂ«t in-tree nĂ« kernelin e Kubernetes dhe pluginĂ«t FlexVolume nga Microsoft tĂ« bazuar nĂ« Powershell;

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

  • mundĂ«sia ndryshimi i madhĂ«sive tĂ« volumeve CSI, e paraqitur qĂ« nĂ« K8s 1.12, arriti nĂ« versionin beta;
  • njĂ« "pĂ«rmirĂ«sim" tĂ« ngjashĂ«m (nga versi alpha nĂ« beta) arriti mundĂ«sia e pĂ«rdorimit tĂ« CSI pĂ«r krijimin e volumeve lokalesh efemere (PĂ«rkrahja e Volumes Inline CSI).

Funksioni i klonimit të volumeve (përdorimi i PVC-ve ekzistuese si DataSource për të krijuar PVC të rinj) tani gjithashtu ka marrë statusin beta. Dy ndryshime të dukshme në planifikim (të dyjat në versionin alpha):

Planifikuesi

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

  • EvenPodsSpreading — mundĂ«sia pĂ«r tĂ« pĂ«rdorur pod’ët pĂ«r "shpĂ«rndarjen e drejtĂ«" tĂ« ngarkesave nĂ« vend tĂ« njĂ«sive logjike tĂ« aplikacionit (si Deployment dhe ReplicaSet) dhe rregullat e shpĂ«rndarjes sĂ« kĂ«tij (si kĂ«rkesĂ« tĂ« fortĂ« apo si kush tĂ« butĂ«, pra si prioritet). Kjo veçori do tĂ« zgjasĂ« mundĂ«sitĂ« ekzistuese pĂ«r shpĂ«rndarjen e pod-eve tĂ« planifikuara, aktualisht tĂ« kufizuara nga opsionet PodAffinity dhe PodAntiAffinity, duke iu dhĂ«nĂ« administratorĂ«ve kontroll mĂ« tĂ« hollĂ«sishĂ«m nĂ« kĂ«tĂ« aspekt, e cila do tĂ« thotĂ« mĂ« shumĂ« disponueshmĂ«ri dhe konsum tĂ« optimizuar tĂ« burimeve. MĂ« shumĂ« detaje - nĂ« KEP.
  • PĂ«rdorimi Politika BestFit nĂ« Funksioni i Prioritetit RequestedToCapacityRatio gjatĂ« planifikimit tĂ« pod-eve, qĂ« do tĂ« lejojĂ« tĂ« aplikoni bin packing («paketim nĂ« konteiner») si pĂ«r burimet kryesore (procesori, memorja), ashtu edhe pĂ«r ato tĂ« avancuara (si GPU). MĂ« shumĂ« informacion nĂ« KEP.

    Kubernetes 1.16: një përmbledhje e risive kryesore
    Planifikimi i pod-eve: deri në përdorimin e politikës best fit (drejt për drejt përmes planifikuesit të parazgjedhur) dhe me përdorimin e saj (përmes zgjeruesit të planifikuesit)

Për më tepër, është paraqitur mundësia për të krijuar plugina të veta për planifikuesin jashtë pemës kryesore të zhvillimit të Kubernetes (jashtë pemës).

Ndryshime të tjera

Gjithashtu nĂ« lĂ«shimin e Kubernetes 1.16, mund tĂ« theksohet inisiativa pĂ«r organizatĂ«n e metrikave ekzistuese nĂ« njĂ« sistem tĂ« plotĂ«, dhe nĂ«se tĂ« saktĂ«sojmĂ« — nĂ« pĂ«rputhje me udhĂ«zimet zyrtare pĂ«r instrumentimin e K8s. NĂ« thelb, ato mbĂ«shteten nĂ« dokumentacionin pĂ«rkatĂ«s tĂ« Prometheus. DĂ«shironi tĂ« dini se pse ndodhi kĂ«to ndryshime? Ka disa arsye (pĂ«r shembull, disa metrika ishin thjesht krijuar para se udhĂ«zimet aktuale tĂ« shfaqeshin), dhe zhvilluesit vendosĂ«n se ishte koha pĂ«r tĂ« sjellĂ« gjithçka nĂ« njĂ« standard tĂ« unifikuar, "nĂ« pĂ«rputhje me ekosistemĂ«n tjetĂ«r tĂ« Prometheus". Implementimi aktual i kĂ«saj iniciative ka statusin beta, qĂ« do tĂ« rritet gradualisht nĂ« versionet e ardhshme tĂ« Kubernetes deri nĂ« stabilen (1.18).

Gjithashtu, mund të theksohen ndryshime të tjera:

  • Zhvillimi i mbĂ«shtetjes pĂ«r Windows me me ardhjen e utilitarit Kubeadm pĂ«r kĂ«tĂ« OS (beta-variant), mundĂ«sia RunAsUserName pĂ«r kontejnerĂ«t Windows (beta-variant), pĂ«rmirĂ«simi mbĂ«shtetje pĂ«r Group Managed Service Account (gMSA) deri nĂ« stabilen, mbĂ«shtetje mount/attach pĂ«r volumin e vSphere.
  • Ri-projektimi i mekanizmit tĂ« kompresionit tĂ« tĂ« dhĂ«nave nĂ« pĂ«rgjigjet API. MĂ« parĂ« pĂ«r kĂ«to qĂ«llime pĂ«rdorej filtrin HTTP, i cili vendoste disa kufizime qĂ« pengonin aktivizimin e tij si parazgjedhje. Tani funksionon "kompresion i dukshĂ«m i kĂ«rkesave": klientĂ«t qĂ« dĂ«rgojnĂ« Accept-Encoding: gzip nĂ« titull, marrin pĂ«rgjigje tĂ« shkurtuar nĂ« GZIP nĂ«se e ndihmojnĂ« madhĂ«sinĂ« e tij pĂ«rtej 128 KB. KlientĂ«t nĂ« Go automatikisht mbĂ«shtesin kompresimin (dĂ«rgojnĂ« titullin e duhur), kĂ«shtu qĂ« menjĂ«herĂ« do tĂ« vĂ«rejnĂ« uljen e trafikut. (PĂ«r gjuhĂ« tĂ« tjera, mund tĂ« nevojiten modifikime tĂ« vogla.)
  • Kjo Ă«shtĂ« bĂ«rĂ« e mundur shkallĂ«zimi HPA nga/nĂ« zero pod’ash mbi bazĂ«n e metrikave ekst externe. NĂ«se shkallĂ«zimi bĂ«het mbi bazĂ«n e objekteve/metrikave ekstreme, mund tĂ« shkallĂ«zohet automatikisht deri nĂ« 0 replikash pĂ«r tĂ« kursyer burimet kur ngarkesat e punĂ«s janĂ« tĂ« papĂ«rdorura. Kjo veçori duhet tĂ« jetĂ« veçanĂ«risht e dobishme pĂ«r rastet kur punĂ«torĂ«t kĂ«rkojnĂ« burime GPU dhe numri i llojeve tĂ« ndryshme tĂ« punĂ«torĂ«ve tĂ« papĂ«rdorura tejkalon numrin e GPU-ve nĂ« dispozicion.
  • Klienti i ri — k8s.io/client-go/metadata.Client — pĂ«r qasje «tĂ« pĂ«rgjithshme» nĂ« objekte. Ai Ă«shtĂ« menduar pĂ«r tĂ« marr metadata lehtĂ«sisht (dmth. departamenti metadata) nga burimet e klasterit dhe pĂ«r tĂ« kryer operacione tĂ« tilla si mbledhja e mbeturinave dhe kuotimi.
  • TĂ« mbledhim Kubernetes tani mund tĂ« pa ofrues tĂ« vjetĂ«ruar («tĂ« integuar» nĂ« in-tree) tĂ« shĂ«rbimeve tĂ« mjeteve (versioni alfa).
  • NĂ« utilitarin kubeadm u shtua mundore experimental (alpha) pĂ«r tĂ« aplikuar patch-et e kustomize gjatĂ« operacioneve procesi, join dhe pĂ«rmirĂ«sim. MĂ« shumĂ« pĂ«r si tĂ« pĂ«rdorni flamurin --experimental-kustomize, shih nĂ« KEP.
  • Pika e re pĂ«r apiserver — readyz, e cila lejon eksportimin e informacionit mbi gatishmĂ«rinĂ« e tij (readiness). Gjithashtu, API-serveri tani ka flamurin --maximum-startup-sequence-duration, i cili lejon rregullimin e rilodhjeve tĂ« tij.
  • Dy funksionalitete pĂ«r Azure u shpallĂ«n stabile: mbĂ«shtetje pĂ«r zonat e disponueshmĂ«risĂ« (Availability Zones) dhe cross resource group (RG). PĂ«r mĂ« tepĂ«r, nĂ« Azure janĂ« shtuar:
  • AWS ka tani mbĂ«shtetje pĂ«r EBS nĂ« Windows dhe tĂ« optimizuar thirrjet API EC2 DescribeInstances.
  • Kubeadm tani migron vetĂ« konfigurimin e CoreDNS gjatĂ« pĂ«rditĂ«simit tĂ« versionit tĂ« CoreDNS. konfigurimin e CoreDNS gjatĂ« pĂ«rditĂ«simit tĂ« versionit CoreDNS.
  • BinarĂ«t etcd nĂ« imazhin pĂ«rkatĂ«s Docker e bĂ«nĂ« world-executable, qĂ« lejon ekzekutimin e kĂ«tij imazhi pa nevojĂ«n pĂ«r privilegje root. PĂ«r mĂ« tepĂ«r, imazhi i migrimit tĂ« etcd ka ndaluar mbĂ«shtetje pĂ«r versionin etcd2.
  • NĂ« Cluster Autoscaler 1.16.0 kaluan nĂ« pĂ«rdorimin e distroless si bazĂ«, pĂ«rmirĂ«suam performancĂ«n, shtuam ofrues tĂ« rinj nĂ« cloud (DigitalOcean, Magnum, Packet).
  • PĂ«rditĂ«sime nĂ« softuerin e pĂ«rdorur/varur: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster