ProHoster > Kubernetes 1.14: pasqyra e novacioneve kryesore

Kubernetes 1.14: pasqyra e novacioneve kryesore

Kubernetes 1.14: pasqyra e novacioneve kryesore

KĂ«tĂ« natĂ« do tĂ« ndodhĂ« njĂ« tjetĂ«r lĂ«shim i Kubernetes — 1.14. Duke ndjekur traditĂ«n e kĂ«tij blogu, ne do tĂ« flasim pĂ«r ndryshimet kyçe nĂ« versionin e ri tĂ« kĂ«tij produkte tĂ« shkĂ«lqyer open source.

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.14 dhe çështjet, kërkesat për tërheqje, Propozimet e Përmirësimit të Kubernetes (KEP) përkatëse.

Le të fillojmë me një hyrje të rëndësishme nga SIG cluster-lifecycle: klasterat dinamik të qëndrueshmërisë Kubernetes (ndërsa nëse do të shprehemi më saktë, rikthimet e HA të vetëpritur) tani mund të krijohen nëpërmjet komandave të njohura (në kontekstin e klasterave me një nod) kubeadm (init dhe bashkohu). Në përmbledhje, për këtë:

  • certifikatat e pĂ«rdorura nga klasteri janĂ« transferuar nĂ« sekrete;
  • pĂ«r tĂ« lejuar pĂ«rdorimin e klasterit etcd brenda klasterit K8s (nĂ« kuptimin e heqjes sĂ« varĂ«sisĂ« ekzistuese tĂ« jashtme) Ă«shtĂ« angazhuar etcd-operator;
  • janĂ« dokumentuar konfigurimet e rekomanduara pĂ«r njĂ« balancues tĂ« ngarkesĂ«s tĂ« jashtĂ«m, qĂ« ofron njĂ« konfigurim tĂ« qĂ«ndrueshmĂ«risĂ« (nĂ« tĂ« ardhmen planifikohet mundĂ«sia pĂ«r t'u hequr nga kjo varĂ«si, por jo nĂ« kĂ«tĂ« fazĂ«).

Kubernetes 1.14: pasqyra e novacioneve kryesore
Arkitektura e klasterit të HA të Kubernetes, e krijuar me kubeadm

Detajet e zbatimit mund të shihen në propozimin e dizajnit. Kjo veçori ishte vërtet e pritur: versioni alfa pritej që në K8s 1.9, por doli vetëm tani.

API

Ekipa aplikoni dhe në përgjithësi menaxhimi deklarativ i objekteve janë transferuar nga kubectl në apiserver. Vetë zhvilluesit e shpjegojnë shkurtimisht vendimin e tyre duke thënë se kubectl apply është një pjesë themelore e punës me konfigurimet në Kubernetes, megjithatë "është plot me gabime dhe e vështirë për t'u riparuar", prandaj kjo funksionalitet duhet të përmirësohet dhe të transferohet në plani i kontrollit. Shembujt e thjeshtë dhe të qartë të problemeve që ekzistojnë sot janë:

Kubernetes 1.14: pasqyra e novacioneve kryesore

Detajet e zbatimit janë në KEP. Gatiësia aktuale është version alfa (e avancuar për beta planifikohet për lëshimin e ardhshëm të Kubernetes).

Në versionin alfa bëhet e disponueshme mundësia përdorimi i skemës OpenAPI v3 për krijimin dhe publikimin e dokumentacionit OpenAPI për Resurset e Personalizuara (CR), të përdorura për validimin (në anën e serverit) e resurseve K8s, të përcaktuar nga përdoruesi (Definimi i Resurseve të Personalizuara, CRD). Publikimi i OpenAPI për CRD u lejon klientëve (p.sh., kubectl) të kryejnë validimin në anën e tyre (brenda kubectl krijo dhe kubectl apply) dhe të ofrojnë dokumentacionin për skemën (kubectl shpjego). Detajet janë në KEP.

Logët e mëparshme tani hapen me flamurin O_APPEND (dhe jo O_TRUNC) për të shmangur humbjen e logëve në disa situata dhe për lehtësinë e trunkejve të logëve me utilitarët e jashtëm për rotacionin.

Gjithashtu në kontekstin e API-ve të Kubernetes mund të theksojmë se në PodSandbox dhe PodSandboxStatus filtrimi i pakove dhe përditësimet me "një klik". fushën runtime_handler për të evidentuar informacionin mbi RuntimeClass në pod (më shumë për të lexoni në tekstin rreth lëshimi Kubernetes 1.12, ku kjo klasë u shfaq si një version alfa), dhe në Admission Webhooks është implementuar mundësia për të përcaktuar se cilat versione AdmissionReview ato mbështesin. Përfundimisht, në rregullat e Admission Webhooks tani mund të kufizohen përdorimi i tyre në namespace dhe kufij të klasterit.

Të dhënat

VëllimetLokalePërhershëm, të cilat kishin status beta-që nga lëshimi K8s 1.10, u shpallën të stabilizuara (GA): ky feature gate nuk do të çaktivizohet më dhe do të hiqet në Kubernetes 1.17.

MundĂ«sia pĂ«rdorimi i variablave tĂ« mjedisit tĂ« ashtuquajtur Downward API (pĂ«r shembull, emri i pod-it) pĂ«r emrat e direktorive, tĂ« montuara si subPath, mori zhvillim — nĂ« formĂ«n e njĂ« fushe tĂ« re subPathExpr, me ndihmĂ«n e sĂ« cilĂ«s tani pĂ«rcaktohet emri i nevojshĂ«m i direktorive. Fillimisht, kjo veçori u shfaq nĂ« Kubernetes 1.11, por pĂ«r 1.14 mbeti ende nĂ« statusin e versionit alfa.

Si dhe në lëshimin e kaluar të Kubernetes, shumë ndryshime të rëndësishme janë paraqitur për CSI (Container Storage Interface) në zhvillim aktiv:

CSI

Èshtë bërë e disponueshme (në kuadër të versionit alfa) mbështetje ndryshimi i madhësisë për volume të CSI.Për ta përdorur këtë, do të nevojitet aktivizimi i feature gate me emrin ExpandCSIVolumes, si dhe mbështetje për këtë operacion në drejtuesin përkatës të CSI.

NjĂ« tjetĂ«r veçori pĂ«r CSI nĂ« versionin alfa — mundĂ«sia tĂ« referoheni drejtpĂ«rdrejt (dmth, pa pĂ«rdorur PV/PVC) nĂ« volume tĂ« CSI brenda specifikimit tĂ« pod-eve. Kjo heq kufizimin pĂ«r pĂ«rdorimin e CSI si njĂ« depo tĂ« shpĂ«rndara, duke i hapur dyert pĂ«r ato nĂ« botĂ«n volumes ephemerale lokale.PĂ«r pĂ«rdorimin (shembuj nga dokumentacioni) duhet tĂ« aktivizohet CSIInlineVolume feature gate.

Ka pasur pĂ«rparim dhe nĂ« 'brendĂ«sitĂ«' e Kubernetes, tĂ« lidhura me CSI, tĂ« cilat nuk janĂ« aq tĂ« dukshme pĂ«r pĂ«rdoruesit pĂ«rfundimtarĂ« (administratorĂ«t e sistemeve)... NĂ« kĂ«tĂ« moment zhvilluesit janĂ« tĂ« detyruar tĂ« mbĂ«shtesin dy versione tĂ« çdo plugin-i tĂ« depozitĂ«s: njĂ« — 'me stilin e vjetĂ«r', brenda kodit tĂ« bazĂ«s K8s (in-tree), dhe tjetra — nĂ« kuadĂ«r tĂ« ri CSI (mĂ« shumĂ« pĂ«r tĂ« lexoni, pĂ«r shembull, nĂ« kĂ«tu). Kjo shkakton shqetĂ«sime tĂ« kuptueshme qĂ« duhet tĂ« zgjidhen me kalimin nĂ« CSI si tĂ« tillĂ«. Nuk Ă«shtĂ« e mundur thjesht tĂ« shpallen si tĂ« vjetra (deprecated) API tĂ« plugins pĂ«rbrenda (in-tree) pĂ«r shkak tĂ« politikĂ«s pĂ«rkatĂ«se tĂ« Kubernetes.

. E gjithë kjo ka çuar në faktin që versionet alfa arritën procesin e migrimit të kodit të brendshëm të plugins, të implementuara si in-tree, në plugins CSI, duke e bërë që shqetësimet e zhvilluesve të reduktohen në mbështetje të një versioni të vetëm të plugins të tyre, ndërsa ruhet përputhshmëria me API-të e vjetra dhe ato mund të shpallen si të vjetra sipas skenarit të zakonshëm. Pritet që me lëshimin e ardhshëm të Kubernetes (1.15) të përfundojë migrimi i të gjithë plugins të ofruesve të cloud, implementimi do të marrë statusin beta dhe do të aktivizohet në instalimet e K8s me parazgjedhje. Detaje në propozimin e dizajnit. Pasojat e kësaj migrimi gjithashtu ishin heqja e kufizimeve për volumet që përcaktohen nga ofruesit specifikë të cloud (AWS, Azure, GCE, Cinder).

Për më tepër, mbështetje për pajisje bllokuese me CSI (CSIBlockVolume) u kalua në version beta.

Nodet / Kubelet

U prezantua versioni alfa i endpoint-it të ri në Kubelet, i cili është i destinuar për drejtimin e metrikave për burimet kryesore. Në përgjithësi, nëse më parë Kubelet merrte statistikë mbi përdorimin e konteinerëve nga cAdvisor, tani këto të dhëna vijnë nga mjedisi i ekzekutimit të konteinerit përmes CRI (Container Runtime Interface), megjithatë mbetet edhe përputhshmëria për të punuar me versionet e vjetra të Docker. Statistikat që u grumbulluan më parë në Kubelet u drejtuan përmes REST API, tani për këtë përdoret një endpoint, i vendosur në adresën /metrics/resource/v1alpha1. Strategjia afatgjatë e zhvilluesve është për të minimizuar setin e metrikave që ofrohen nga Kubelet. Për më tepër, këto metrika tani quhen jo "metrika thelbësore", por "metrika burimore", dhe përshkruhen si "burime të klasës së parë, si CPU dhe memorie".

Një detaj interesant: pavarësisht përparësisë evidente në performancë të endpoint-it gRPC krahasuar me raste të ndryshme përdorimi të formatit Prometheus (rezultati i një nga benchmark-ët e shihni më poshtë), autorët preferuan formatin tekstual të Prometheus për shkak të dominimit të qartë të këtij sistemi monitorimi në komunitet.

«gRPC nuk është i përputhshëm me kanalet kryesore të monitorimit. Endpoint do të jetë i dobishëm vetëm për dorëzimin e metrikave në Metrics Server ose komponentët e monitorimit që integrohen drejtpërdrejt me të. Kur përdorim caching në Metrics Server, performanca e formatit tekstual Prometheus është mjaft e mirë për ne, për të preferuar Prometheus në vend të gRPC, duke marrë parasysh përhapjen e gjerë të Prometheus në komunitet. Kur formati OpenMetrics të bëhet më stabil, ne mund të arrijmë afërsisht performancën e gRPC me një format të bazuar në proto».

Kubernetes 1.14: pasqyra e novacioneve kryesore
Një nga testet krahasuese të performancës së përdorimit të formateve gRPC dhe Prometheus në endpoint-in e ri të Kubelet për metrika. Më shumë grafikë dhe detaje të tjera mund të gjenden në KEP.

Midis ndryshimeve të tjera:

CLI

flagu -k për integrim me është shtuar kustomize (për t'iu thënë, zhvillimi tani po bëhet në një repository të veçantë), pra për të përpunuar YAML-të shtesë nga direktori të veçanta kustomization (detajet për përdorimin e tyre shih në Shembulli i një përdorimi të thjeshtë të skedarit KEP):

Kubernetes 1.14: pasqyra e novacioneve kryesore
kustomization (edhe përdorime më të komplikuara të kustomize brenda overlays komanda e re)

Për më tepër:

  • Shtuar kubectl create cronjob , emri i sĂ« cilĂ«s flet pĂ«r vete.kubectl logs
  • NĂ« tani mund tĂ« kombinohen flags -f --follow (pĂ«r streaming tĂ« logeve) dhe -l --selector (pĂ«r kĂ«rkimin e etiketave). mĂ«suan
  • kubectl tĂ« kopjojnĂ« skedarĂ«, tĂ« pĂ«rzgjidhur me wildcard. NĂ« komandĂ«n
  • kubectl wait flagu shtuan --all pĂ«r tĂ« zgjedhur tĂ« gjitha burimet nĂ« hapĂ«sirĂ«n e emrave tĂ« llojit tĂ« burimeve tĂ« caktuara. Statusi i qĂ«ndrueshĂ«m (GA) e morĂ«n kĂ«to mundĂ«si:

TĂ« tjera

ReadinessGate

Ndryshime të tjera të prezantuara në Kubernetes 1.14:

  • Politika RBAC e paracaktuar tani nuk i jep akses API discovery dhe access-review pĂ«rdoruesve pa autentikim (unauthenticated).
  • MbĂ«shtetje zyrtare pĂ«r CoreDNS sigurohet vetĂ«m pĂ«r Linux, prandaj kur pĂ«rdorni kubeadm pĂ«r implementimin e tij (CoreDNS) nĂ« kluster, nodet duhet tĂ« funksionojnĂ« vetĂ«m nĂ« Linux (pĂ«r kĂ«tĂ« kufizim pĂ«rdoren nodeSelectors).
  • Konfigurimi i CoreDNS i paracaktuar tani pĂ«rdor plugin forward nĂ« vend tĂ« proxy. pĂ«r mĂ« tepĂ«r, nĂ« CoreDNS Ă«shtĂ« shtuar readinessProbe, e cila parandalon balancimin e ngarkesĂ«s nĂ« podĂ«t e caktuar (tĂ« pa gatshĂ«m pĂ«r shĂ«rbim).
  • NĂ« kubeadm, nĂ« fazat init ose upload-certs, ka bĂ«rĂ« tĂ« mundur ngarkimin e certifikatave tĂ« nevojshme pĂ«r lidhjen e njĂ« control-plane tĂ« ri me sekretin kubeadm-certs (pĂ«rdoret flag --experimental-upload-certs).
  • PĂ«r instalimet Windows ka njĂ« version alfa i mbĂ«shtetjes gMSA (Group Managed Service Account) — llogari tĂ« veçanta nĂ« Active Directory, tĂ« cilat mund tĂ« pĂ«rdoren gjithashtu nga kontejnerĂ«t.
  • PĂ«r GCE janĂ« aktivizuar kriptimi mTLS midis etcd dhe kube-apiserver.
  • PĂ«rditĂ«simet nĂ« softuerin e pĂ«rdorur/varĂ«sisĂ«: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, mbĂ«shtetje pĂ«r Docker 18.09 nĂ« kubeadm, dhe versione minimale e mbĂ«shtetur e API-sĂ« Docker tani Ă«shtĂ« 1.26.

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