Kubernetes 1.14: përmbledhje e inovacioneve kryesore

Kete nate do të zhvillohet publikimi tjetër i Kubernetes - 1.14. Sipas traditës që është zhvilluar për blogun tonë, po flasim për ndryshimet kryesore në versionin e ri të këtij produkti të mrekullueshëm Open Source.

Informacioni i përdorur për përgatitjen e këtij materiali është marrë nga Tabelat e gjurmimit të përmirësimeve të Kubernetes, NDRYSHIMI-1.14 dhe çështjet e lidhura me to, kërkesat për tërheqje, Propozimet e Përmirësimit të Kubernetes (KEP).

Le të fillojmë me një hyrje të rëndësishme nga cikli i jetës së grupit SIG: grupet dinamike të dështimit Kubernetes (ose për të qenë më të saktë, vendosjet e HA të vetë-pritura) është tani mund të krijohen duke përdorur komanda të njohura (në kontekstin e grupimeve me një nyje). kubeadm (init и join). Me pak fjalë, për këtë:

• certifikatat e përdorura nga grupi transferohen në sekrete;
• për mundësinë e përdorimit të grupit etcd brenda grupit K8s (d.m.th. të heqësh qafe varësinë e jashtme ekzistuese më parë) etjd-operator;
• Dokumenton cilësimet e rekomanduara për një balancues të jashtëm të ngarkesës që ofron një konfigurim tolerant ndaj gabimeve (në të ardhmen është planifikuar të eliminohet kjo varësi, por jo në këtë fazë).

Arkitektura e një grupi Kubernetes HA të krijuar me kubeadm

Detajet e zbatimit mund të gjenden në propozim projektimi. Kjo veçori ishte vërtet e shumëpritur: versioni alfa pritej përsëri në K8s 1.9, por u shfaq vetëm tani.

API

Ekip apply dhe në përgjithësi menaxhimi i objekteve deklarative kaloi nga kubectl në apiserver. Vetë zhvilluesit shpjegojnë shkurtimisht vendimin e tyre duke thënë këtë kubectl apply - një pjesë themelore e punës me konfigurimet në Kubernetes, megjithatë, "është plot me gabime dhe e vështirë për t'u rregulluar", dhe për këtë arsye ky funksionalitet duhet të kthehet në normalitet dhe të transferohet në planin e kontrollit. Shembuj të thjeshtë dhe të qartë të problemeve që ekzistojnë sot:

Detajet rreth zbatimit janë në CEP. Gatishmëria aktuale është alfa (promovimi në beta është planifikuar për lëshimin e ardhshëm të Kubernetes).

E disponueshme në versionin alfa mundësi duke përdorur skemën OpenAPI v3 për krijimin dhe publikimin e dokumentacionit OpenAPI për CustomResources (CR) përdoret për të vërtetuar (nga ana e serverit) burimet e përcaktuara nga përdoruesi K8s (CustomResourceDefinition, CRD). Publikimi i OpenAPI për CRD lejon klientët (p.sh. kubectl) kryeni vërtetimin nga ana juaj (brenda kubectl create и kubectl apply) dhe lëshon dokumentacion sipas skemës (kubectl explain). Detajet - në CEP.

Regjistrat para-ekzistues tani po hapen me flamur O_APPEND (por jo O_TRUNC) për të shmangur humbjen e shkrimeve në disa situata dhe për lehtësinë e prerjes së trungjeve me pajisje të jashtme për rrotullim.

Gjithashtu në kontekstin e Kubernetes API, mund të vërehet se në PodSandbox и PodSandboxStatus shtuar поле runtime_handler për të regjistruar informacione rreth RuntimeClass në pod (lexoni më shumë rreth tij në tekstin rreth Publikimi i Kubernetes 1.12, ku kjo klasë u shfaq si një version alfa), dhe në Admission Webhooks zbatuar aftësia për të përcaktuar se cilat versione AdmissionReview ata mbështesin. Më në fund, rregullat e Admission Webhooks janë tani mund të kufizohet shtrirja e përdorimit të tyre nga hapësirat e emrave dhe kornizat e grupimeve.

Magazinimi

PersistentLocalVolumes, e cila kishte status beta që nga publikimi K8s 1.10, i shpallur stabile (GA): kjo portë veçorie nuk është më e çaktivizuar dhe do të hiqet në Kubernetes 1.17.

mundësi duke përdorur variablat e mjedisit të quajtur API poshtë (për shembull, emri i pod) për emrat e drejtorive të montuara si subPath, u zhvillua - në formën e një fushe të re subPathExpr, i cili tani përdoret për të përcaktuar emrin e dëshiruar të drejtorisë. Veçoria fillimisht u shfaq në Kubernetes 1.11, por për 1.14 mbeti në statusin e versionit alfa.

Ashtu si me lëshimin e mëparshëm të Kubernetes, shumë ndryshime të rëndësishme janë futur për CSI (Ndërfaqja e ruajtjes së kontejnerëve) në zhvillim aktiv:

CSI

U bë i disponueshëm (si pjesë e versionit alfa) mbështetje ndryshimi i madhësisë për vëllimet CSI. Për ta përdorur atë, do t'ju duhet të aktivizoni portën e veçorive të thirrur ExpandCSIVolumes, si dhe disponueshmëria e mbështetjes për këtë operacion në një drejtues specifik CSI.

Një veçori tjetër për CSI në versionin alfa - mundësi referojuni drejtpërdrejt (d.m.th. pa përdorur PV/PVC) vëllimeve CSI brenda specifikimit të pod. Kjo heq kufizimin për përdorimin e CSI si ruajtje ekskluzivisht në distancë të të dhënave, duke hapur dyert e botës për ta vëllime kalimtare lokale. Per perdorim (shembull nga dokumentacioni) duhet të aktivizohet CSIInlineVolume porta tipare.

Ka pasur gjithashtu përparim në "të brendshmet" e Kubernetes në lidhje me CSI, të cilat nuk janë aq të dukshme për përdoruesit përfundimtarë (administratorët e sistemit) ... Aktualisht, zhvilluesit janë të detyruar të mbështesin dy versione të çdo shtojce ruajtëse: një - "në mënyra e vjetër”, brenda bazës së kodit K8s (në -pemë), dhe e dyta - si pjesë e CSI-së së re (lexoni më shumë rreth tij, për shembull, në këtu). Kjo shkakton shqetësime të kuptueshme që duhen adresuar pasi vetë CSI stabilizohet. Nuk është e mundur që thjesht të zhvlerësohet API-ja e shtojcave të brendshme (në pemë) për shkak të politika përkatëse e Kubernetes.

E gjithë kjo çoi në faktin se versioni alfa arriti procesi i migrimit kodi i brendshëm i shtojcës, i implementuar si in-tree, në shtojcat CSI, falë të cilave shqetësimet e zhvilluesve do të reduktohen në mbështetjen e një versioni të shtojcave të tyre dhe përputhshmëria me API-të e vjetra do të mbetet dhe ato mund të deklarohen të vjetëruara në skenarin e zakonshëm. Pritet që deri në lëshimin e ardhshëm të Kubernetes (1.15) të gjitha shtojcat e ofruesve të cloud të migrohen, zbatimi do të marrë statusin beta dhe do të aktivizohet në instalimet e K8s si parazgjedhje. Për detaje, shih propozim projektimi. Ky migrim rezultoi gjithashtu në отказ nga kufijtë e volumit të përcaktuar nga ofruesit specifikë të cloud (AWS, Azure, GCE, Cinder).

Për më tepër, mbështetja për pajisjet bllokuese me CSI (CSIBlockVolume) të transferuara në versionin beta.

Nyjet / Kubelet

Versioni alfa i paraqitur pikë e re përfundimtare në Kubelet, projektuar për matjet e kthimit në burimet kryesore. Në përgjithësi, nëse më parë Kubelet merrte statistika mbi përdorimin e kontejnerëve nga cAdvisor, tani këto të dhëna vijnë nga mjedisi i kohës së funksionimit të kontejnerit nëpërmjet CRI (Container Runtime Interface), por përputhshmëria për të punuar me versionet më të vjetra të Docker ruhet gjithashtu. Më parë, statistikat e mbledhura në Kubelet dërgoheshin nëpërmjet API-së REST, por tani një pikë përfundimtare e vendosur në /metrics/resource/v1alpha1. Strategjia afatgjatë e zhvilluesve përbëhet është të minimizoni grupin e metrikës së ofruar nga Kubelet. Nga rruga, këto metrika vetë tani ata thërrasin jo "metrika thelbësore", por "metrika e burimeve" dhe përshkruhen si "burime të klasit të parë, të tilla si CPU dhe memorie".

Një nuancë shumë interesante: pavarësisht avantazhit të qartë të performancës së pikës fundore gRPC në krahasim me raste të ndryshme të përdorimit të formatit Prometheus (shih rezultatin e një prej standardeve më poshtë), autorët preferuan formatin e tekstit të Prometeut për shkak të lidershipit të qartë të këtij sistemi monitorimi në komunitet.

“gRPC nuk është në përputhje me tubacionet kryesore të monitorimit. Pika përfundimtare do të jetë e dobishme vetëm për dërgimin e metrikës në Serverin Metrics ose për monitorimin e komponentëve që integrohen drejtpërdrejt me të. Performanca e formatit të tekstit Prometheus kur përdorni caching në Metrics Server mjaft mirë që ne të preferojmë Prometheun mbi gRPC duke pasur parasysh adoptimin e gjerë të Prometheus në komunitet. Sapo formati OpenMetrics të bëhet më i qëndrueshëm, ne do të jemi në gjendje t'i qasemi performancës së gRPC me një format të bazuar në proto."

Një nga testet krahasuese të performancës së përdorimit të formateve gRPC dhe Prometheus në pikën e re përfundimtare të Kubelet për metrikë. Më shumë grafikë dhe detaje të tjera mund të gjenden në CEP.

Ndër ndryshimet e tjera:

• Kubelet tani (një herë) duke u përpjekur për të ndaluar kontejnerët në një gjendje të panjohur përpara rinisjes dhe fshirjes së operacioneve.
• Kur duke përdorur PodPresets tani në enën fillestare shtuar të njëjtin informacion si për një enë të rregullt.
• kubelet filloi të përdorte usageNanoCores nga ofruesi i statistikave CRI dhe për nyjet dhe kontejnerët në Windows shtuar statistikat e rrjetit.
• Informacioni i sistemit operativ dhe arkitekturës tani regjistrohet në etiketa kubernetes.io/os и kubernetes.io/arch Objektet e nyjës (transferuar nga beta në GA).
• Aftësia për të specifikuar një grup specifik përdoruesish të sistemit për kontejnerët në një pod (RunAsGroup, u shfaq në K8s 1.11) i avancuar përpara beta (e aktivizuar si parazgjedhje).
• du dhe gjeni të përdorura në cAdvisor, zëvendësohet në zbatim.

CLI

Në cli-runtime dhe kubectl shtuar -k flamur për integrim me personalizoj (nga rruga, zhvillimi i tij tani kryhet në një depo të veçantë), d.m.th. për të përpunuar skedarë shtesë YAML nga drejtoritë speciale të kustomizimit (për detaje mbi përdorimin e tyre, shihni CEP):

Shembull i përdorimit të thjeshtë të skedarit personalizimi (një aplikim më kompleks i kustomize është i mundur brenda overlays)

Кроме того:

• Shtuar ekip i ri kubectl create cronjob, emri i të cilit flet vetë.
• В kubectl logs tani mundesh të kombinohen flamuj -f (--follow për regjistrat e transmetimit) dhe -l (--selector për pyetjen e etiketës).
• kubectl mësuar kopjoni skedarët e zgjedhur nga karta e egër.
• Tek ekipi kubectl wait shtuar flamur --all për të zgjedhur të gjitha burimet në hapësirën e emrave të llojit të burimit të specifikuar.

Të tjerët

Aftësitë e mëposhtme kanë marrë status të qëndrueshëm (GA):

• ReadinessGate, përdoret në specifikimin e pod për të përcaktuar kushte shtesë të marra parasysh në gatishmërinë e pod;
• Mbështetje për faqe të mëdha (thirret porta e veçorive HugePages);
• CustomPodDNS;
• PriorityClass API Prioriteti dhe Parandalimi i Pod.

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

• Politika e parazgjedhur e RBAC nuk lejon më qasjen në API discovery и access-review përdoruesit pa vërtetim (i paautentikuar).
• Mbështetje zyrtare CoreDNS siguruar Vetëm Linux, kështu që kur përdorni kubeadm për ta vendosur atë (CoreDNS) në një grup, nyjet duhet të funksionojnë vetëm në Linux (për këtë kufizim përdoren nodeSelectors).
• Konfigurimi i parazgjedhur i CoreDNS është tani përdor shtojca përpara në vend të përfaqësuesit. Gjithashtu, në CoreDNS shtuar ReadinessProbe, e cila parandalon balancimin e ngarkesës në podat e përshtatshme (jo të gatshme për shërbim).
• Në kubeadm, në faza init ose upload-certs, u bë e mundur ngarkoni certifikatat e nevojshme për të lidhur planin e ri të kontrollit me sekretin kubeadm-certs (përdorni flamurin --experimental-upload-certs).
• Një version alfa është shfaqur për instalimet e Windows mbështetje gMSA (Group Managed Service Account) - llogari të veçanta në Active Directory që mund të përdoren gjithashtu nga kontejnerët.
• Për G.C.E. aktivizuar Kriptimi mTLS midis etcd dhe kube-apiserver.
• Përditësimet në softuerin e përdorur/varur: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, mbështetje Docker 18.09 në kubeadm dhe versioni minimal i mbështetur Docker API tani është 1.26.

PS

Lexoni edhe në blogun tonë:

• «Kubernetes 1.13: përmbledhje e inovacioneve kryesore"?
• «Kubernetes 1.12: përmbledhje e inovacioneve kryesore"?
• «Kubernetes 1.11: përmbledhje e inovacioneve kryesore"?
• «Kubernetes 1.10: përmbledhje e inovacioneve kryesore'.

Burimi: www.habr.com