Kubernetes 1.14: berritasunaren aipagarrienak

Gau honetan ospatuko da Kubernetes-en hurrengo bertsioa - 1.14. Gure blogerako garatu den tradizioaren arabera, Open Source produktu zoragarri honen bertsio berriaren funtsezko aldaketez ari gara.

Material hau prestatzeko erabilitako informazioa bertatik atera da Kubernetesen hobekuntzak jarraitzeko taulak, ALDAKETAK-1.14 eta lotutako gaiak, tira eskaerak, Kubernetes Hobekuntza Proposamenak (KEP).

Has gaitezen SIG kluster-bizi-zikloaren sarrera garrantzitsu batekin: failover dinamikoko klusterrak Kubernetes (edo zehatzago esateko, auto-ostatatutako HA inplementazioak) orain dago sor daitezke komando ezagunak erabiliz (nodo bakarreko klusterren testuinguruan). kubeadm (init и join). Laburbilduz, honetarako:

• klusterrak erabiltzen dituen ziurtagiriak sekretuetara transferitzen dira;
• K8s kluster barruan etcd klusterra erabiltzeko aukeragatik (hau da, lehen zegoen kanpoko menpekotasuna kentzeko) etcd-eragilea;
• Akatsekiko tolerantzia duen konfigurazio bat eskaintzen duen kanpoko karga-orekatzaile baterako gomendatutako ezarpenak dokumentatzen ditu (etorkizunean mendekotasun hori ezabatzea aurreikusi da, baina ez fase honetan).

Kubeadm-ekin sortutako Kubernetes HA kluster baten arkitektura

Ezarpenaren xehetasunak atalean aurki daitezke diseinu proposamena. Ezaugarri hau benetan itxaroten zen: alfa bertsioa espero zen K8s 1.9-n, baina orain bakarrik agertu zen.

API

Team apply eta oro har objektu deklaratiboaren kudeaketa gainditu - kubectl apiserver-en. Garatzaileek beraiek laburki azaltzen dute euren erabakia hori esanez kubectl apply - Kubernetes-en konfigurazioekin lan egiteko oinarrizko atala, ordea, "akatsez beteta dago eta konpontzen zaila da" eta, beraz, funtzionalitate hori normaltasunera itzuli eta kontrol-planora eraman behar da. Gaur egun dauden arazoen adibide sinple eta argiak:

Inplementazioari buruzko xehetasunak daude CAP. Uneko presttasuna alfa da (beta-rako sustapena Kubernetes-en hurrengo bertsiorako aurreikusita dago).

Alfa bertsioan eskuragarri dago aukera OpenAPI v3 eskema erabiliz CustomResources-erako OpenAPI dokumentazioa sortu eta argitaratzea (CR) K8s erabiltzaileak definitutako baliabideak (CustomResourceDefinition, CRD) balioztatzeko erabiltzen da (zerbitzariaren aldetik). CRDrako OpenAPI argitaratzeak bezeroei (adibidez. kubectl) egin baliozkotzea zure alde (barruan kubectl create и kubectl apply) eta dokumentazioa eman erregimenaren arabera (kubectl explain). Xehetasunak - in CAP.

Aurretik dauden erregistroak orain irekitzen ari dira banderarekin O_APPEND (baina ez O_TRUNC) zenbait egoeratan erregistroak galtzea saihesteko eta errotaziorako kanpoko utilitateekin erregistroak mozteko erosotasunerako.

Era berean, Kubernetes APIaren testuinguruan, kontuan izan daiteke PodSandbox и PodSandboxStatus gehitu eremu runtime_handler buruzko informazioa grabatzeko RuntimeClass ontzian (irakurri horri buruz gehiago testuan Kubernetes 1.12 bertsioa, non klase hau alfa bertsio gisa agertzen zen), eta Admission Webhooks-en ezarrita zein bertsio zehazteko gaitasuna AdmissionReview onartzen dute. Azkenik, Onarpen Webhooks arauak daude orain mugatua izan daiteke izen-espazioek eta cluster-esparruek duten erabileraren neurria.

gangak

PersistentLocalVolumes, kaleratu zenetik beta egoera zuena K8ak 1.10, iragarri egonkorra (GA): eginbide-ate hau ez dago desgaituta eta Kubernetes 1.17-n kenduko da.

Aukera izeneko ingurune-aldagaiak erabiliz Beheranzko APIa (adibidez, pod izena) gisa muntatutako direktorioen izenetarako subPath, garatu zen - eremu berri baten moduan subPathExpr, orain nahi den direktorio-izena zehazteko erabiltzen dena. Ezaugarri hori Kubernetes 1.11-n agertu zen hasieran, baina 1.14-rako alfa bertsioan geratu zen.

Kubernetes-en aurreko bertsioarekin bezala, aldaketa esanguratsu asko sartzen dira aktiboki garatzen ari den CSI (Container Storage Interface):

CSI

Eskuragarri bihurtu zen (alfa bertsioaren zati gisa) onartzen CSI bolumenetarako tamaina aldatzea. Erabiltzeko deitutako funtzio-atea gaitu beharko duzu ExpandCSIVolumes, baita eragiketa honetarako euskarriaren erabilgarritasuna CSI kontrolatzaile zehatz batean.

CSIren beste ezaugarri bat alfa bertsioan - aukera erreferentzia zuzenean (hots, PV/PVC erabili gabe) CSI bolumenetara pod zehaztapenaren barruan. Hau urruneko datuen biltegiratze esklusibo gisa CSI erabiltzearen muga kentzen du, munduari ateak irekiz tokiko bolumen iragankorrak. Erabiltzeko (dokumentaziotik ateratako adibidea) gaituta egon behar da CSIInlineVolume ezaugarrien atea.

CSIrekin erlazionatutako Kubernetes-en "barnekoetan" ere aurrerapenak izan dira, azken erabiltzaileentzat (sistema-administratzaileentzat) hain ikusten ez direnak... Gaur egun, garatzaileek biltegiratze-plugin bakoitzaren bi bertsio onartzera behartuta daude: bata - "en modu zaharra”, K8s kode-basearen barruan (-zuhaitzean), eta bigarrena - CSI berriaren zati gisa (irakurri horri buruz gehiago, adibidez, atalean Hemen). Horrek eragozpen ulergarriak eragiten ditu, CSI bera egonkortzen den heinean konpondu beharrekoak. Ezin da barneko (zuhaitzean) pluginen APIa besterik gabe kendu dagokion Kubernetes politika.

Horrek guztiak alfa bertsiora iristea ekarri zuen migrazio prozesua barneko plugin kodea, zuhaitz barnean ezarrita, CSI pluginetan, eta horri esker garatzaileen kezkak beren pluginen bertsio bat onartzera murriztuko dira, eta API zaharrekin bateragarritasuna mantenduko da eta zaharkituta deklaratu daitezke ohiko eszenatokian. Kubernetes-en hurrengo bertsioan (1.15) hodeiko hornitzaileen plugin guztiak migratuko direla espero da, inplementazioak beta egoera jasoko duela eta lehenespenez K8s instalazioetan aktibatuko da. Xehetasunetarako, ikus diseinu proposamena. Migrazio horrek ere eragin zuen porrota hodeiko hornitzaile espezifikoek (AWS, Azure, GCE, Cinder) definitutako bolumen mugetatik.

Gainera, CSI duten blokeatutako gailuetarako laguntza (CSIBlockVolume) transferitu beta bertsiora.

Nodoak/Kubelet

Alpha bertsioa aurkeztu da amaierako puntu berria Kubelet-en, horretarako diseinatua baliabide gakoei buruzko metrika itzultzea. Orokorrean esanda, lehenago Kubelet-ek cAdvisor-en edukiontzien erabilerari buruzko estatistikak jaso bazituen, orain datu hauek CRI (Container Runtime Interface) bidez edukiontzien exekuzio-ingurunetik datoz, baina Docker-en bertsio zaharragoekin lan egiteko bateragarritasuna ere gordetzen da. Lehen, Kubelet-en bildutako estatistikak REST APIaren bidez bidaltzen ziren, baina gaur egun amaierako puntu bat dago. /metrics/resource/v1alpha1. Garatzaileen epe luzerako estrategia da Kubelet-ek emandako metrika multzoa minimizatzea da. Bide batez, neurri horiek beraiek orain deitzen dute ez "oinarrizko neurketak", "baliabideen neurketak" baizik, eta "lehen mailako baliabideak, hala nola CPUa eta memoria" gisa deskribatzen dira.

Ñabardura oso interesgarria: gRPC amaierako puntuaren errendimendu abantaila argia izan arren, Prometheus formatua erabiltzearen hainbat kasurekin alderatuta. (ikus behean erreferentzietako baten emaitza), egileek Prometheus-en testu formatua hobetsi zuten komunitatean jarraipen-sistema honek duen lidergo argiagatik.

"gRPC ez da bateragarria monitorizazio kanalizazio handiekin. Endpoint-a Metrics Server-era neurketak bidaltzeko edo harekin zuzenean integratzen diren osagaiak monitorizatzeko soilik izango da erabilgarria. Prometheus testu-formatuaren errendimendua Metrics Server-en cachea erabiltzean nahikoa guk Prometheus gRPC baino gehiago nahiago dugula komunitatean Prometheus-en harrera zabala ikusita. OpenMetrics formatua egonkorrago bihurtzen denean, gRPC-ren errendimendura hurbildu ahal izango gara proto-oinarritutako formatu batekin".

GRPC eta Prometheus formatuak erabiltzearen errendimendu-proba konparatiboetako bat Kubelet amaierako neurgailuetarako. Hemen grafiko gehiago eta beste xehetasun batzuk aurki daitezke CAP.

Beste aldaketa batzuen artean:

• Kubelet orain (behin batean) gelditu nahian ontziak egoera ezezagun batean berrabiarazi eta ezabatu eragiketak baino lehen.
• Noiz erabiliz PodPresets orain hasierako edukiontzira erantsi da ohiko edukiontzi baten informazio bera.
• kubelet erabiltzen hasi zen usageNanoCores CRI estatistiken hornitzailetik, eta Windows-eko nodo eta edukiontzietarako gehitu sareko estatistikak.
• Sistema eragilearen eta arkitekturaren informazioa etiketetan erregistratzen da kubernetes.io/os и kubernetes.io/arch Nodo objektuak (beta-tik GAra transferitu dira).
• Sistema-erabiltzaile talde espezifiko bat ontzi bateko edukiontzietarako zehazteko gaitasuna (RunAsGroup, urtean agertu zen K8ak 1.11) aurreratua beta baino lehen (lehenespenez gaituta).
• du eta aurkitu cAdvisor-en erabiltzen da, ordezkatu on Go ezarpena.

CLI

Cli-runtime eta kubectl-en gehitu du -k banderarekin integratzeko pertsonalizatu (bide batez, orain bere garapena biltegi bereizi batean egiten da), hau da. Kustomization direktorio berezietako YAML fitxategi gehigarriak prozesatzeko (hauek erabiltzeko xehetasunak ikusteko, ikus CAP):

Fitxategien erabilera sinplearen adibidea pertsonalizazioa (kustomize-ren aplikazio konplexuagoa posible da barruan geruza)

Horrez gain:

• Gehituta talde berria kubectl create cronjob, bere izenak hitz egiten du.
• В kubectl logs orain ahal duzu konbinatzeko banderak -f (--follow streaming erregistroetarako) eta -l (--selector etiketa kontsultarako).
• kubectl irakatsi kopiatu komodinaren bidez hautatutako fitxategiak.
• Taldeari kubectl wait gehitu du bandera --all zehaztutako baliabide motaren izen-eremuan baliabide guztiak hautatzeko.

Beste batzuk

Gaitasun hauek egonkorra (GA) egoera jaso dute:

• ReadinessGate, lekaren zehaztapenean erabiltzen den lekaren prestazioan kontuan hartutako baldintza osagarriak definitzeko;
• Orrialde handietarako euskarria (eginbide atea izenekoa HugePages);
• CustomPodDNS;
• PriorityClass APIa Pod lehentasuna eta lehentasuna.

Kubernetes 1.14-n sartutako beste aldaketa batzuk:

• RBAC gidalerro lehenetsiak jada ez du onartzen APIrako sarbidea discovery и access-review autentifikaziorik gabeko erabiltzaileak (autentifikatu gabe).
• CoreDNS laguntza ofiziala ziurtatua Linux soilik, beraz, kubeadm (CoreDNS) kluster batean inplementatzeko erabiltzen denean, nodoek Linux-en soilik exekutatu behar dute (muga honetarako nodeSelectors erabiltzen dira).
• CoreDNS konfigurazio lehenetsia da orain erabilerak aurreratu plugina proxyaren ordez. Gainera, CoreDNS-en gehitu ReadinessProbe, karga orekatzea eragozten duena (zerbitzurako prest ez dauden) podetan.
• Kubeadm-en, faseetan init edo upload-certs, posible bihurtu zen kargatu kontrol-plano berria kubeadm-certs sekretuarekin konektatzeko beharrezkoak diren ziurtagiriak (erabili bandera --experimental-upload-certs).
• Windows-en instalazioetarako alfa bertsio bat agertu da laguntza gMSA (Group Managed Service Account) - Active Directory-ko kontu bereziak, edukiontziak ere erabil ditzaketenak.
• G.C.E.rentzat. aktibatuta Etcd eta kube-apiserver arteko mTLS enkriptatzea.
• Erabilitako/menpeko softwarearen eguneraketak: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 euskarria kubeadm-en, eta onartzen den gutxieneko Docker API bertsioa 1.26 da orain.

PS

Irakurri ere gure blogean:

• «Kubernetes 1.13: berritasunaren aipagarrienak»;
• «Kubernetes 1.12: berritasunaren aipagarrienak»;
• «Kubernetes 1.11: berritasunaren aipagarrienak»;
• «Kubernetes 1.10: berritasunaren aipagarrienak'.

Iturria: www.habr.com