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ë).

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ë:

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) поддержка 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».

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:

• Kubelet tani (një herë) provon të ndalojë kontratë në gjendje të panjohur (unknown) para operacioneve të rinisjes dhe fshirjes.
• Kur përdoret PodPresets tani i shtohet init-kontenerit informacioni i njëjtë si për kontratën normale. Kubelet
• ka filluar të përdorë usageNanoCores nga furnizuesi i statistikave CRI, dhe për nodet dhe kontratat në Windows statistat e rrjetit. është shtuar Informacioni mbi sistemin operativ dhe arkitekturën tani regjistrohet në etiketa
• kubernetes.io/os kubernetes.io/arch dhe objekteve Node (përkthyer nga beta në GA). Mundësia për të specifikuar një grup të caktuar përdoruesish të sistemit për kontratat në pod (
• RunAsGroup, u shfaq nëK8s 1.11 kaloi) në versionin beta (e përfshirë si parazgjedhje). du dhe find, të përdorura në cAdvisor,
• u zëvendësuan me realizime Go. Në cli-runtime dhe kubectl

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):

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

• , i përdorur në specifikimin e pod-it për të përcaktuar kushte shtesë që merren parasysh në gatishmërinë e pod-it;, используемый в спецификации pod’а для определения дополнительных условий, учитываемых в готовности pod’а;
• Mbështetje për faqe të mëdha (feature gate e quajtur HugePages);
• CustomPodDNS;
• API i Prioritetit të Klasës, Prioriteti i Pod-it dhe Planifikimi.

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 или 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ë:

• «Kubernetes 1.13: përmbledhje e risive kryesore»;
• «Kubernetes 1.12: përmbledhje e risive kryesore»;
• «Kubernetes 1.11: përmbledhje e risive kryesore»;
• «Kubernetes 1.10: përmbledhje e risive kryesore».

Burimi: habr.com