ProHoster >> Kubernetes 1.14: një përmbledhje e risive kryesore

Kubernetes 1.14: një përmbledhje e risive kryesore

Kubernetes 1.14: një përmbledhje e risive kryesore

Sonte do tĂ« ndodhi njĂ« version i ri i Kubernetes — 1.14. Sipas traditĂ«s sĂ« vendosur pĂ«r blogun tonĂ«, ne po ndajmĂ« ndryshimet kyçe nĂ« kĂ«tĂ« version tĂ« kĂ«tij produkti 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 Kubernetes, CHANGELOG-1.14 dhe çështjet përkatëse, kërkesat për tërheqje, Propozimet e Përmirësimeve të Kubernetes (KEP).

Le të fillojmë me një hyrje të rëndësishme nga SIG cluster-lifecycle: klasterë dinamikë të qëndrueshëm Kubernetes (dhe nëse e shprehëm më saktë, atëherë realizimet HA me vetë-hostim) tani mund të krijohen duke përdorur komandat e njohura (në kontekstin e klasterëve me një nyje) kubeadm (procesi dhe join). Nëse e përmbledhim, atëherë për këtë:

  • çertifikatat e pĂ«rdorura nga klasteri transferohen nĂ« sekretet;
  • pĂ«r tĂ« mundĂ«suar pĂ«rdorimin e klasterit etcd brenda klasterit K8s (dmth. duke u liruar nga varĂ«sia ekzistuese e jashtme) Ă«shtĂ« angazhuar etcd-operator;
  • dokumentohen konfigurimet e rekomanduara pĂ«r balancuesin e ngarkesĂ«s jashtme qĂ« siguron njĂ« konfigurim tĂ« qĂ«ndrueshĂ«m (nĂ« tĂ« ardhmen planifikohet tĂ« mund tĂ« hiqet edhe kjo varĂ«si, por jo nĂ« kĂ«tĂ« etapĂ«).

Kubernetes 1.14: një përmbledhje e risive kryesore
Arkitektura HA-kllusterit Kubernetes, e cila është krijuar me kubeadm

Informacionet mbi implementimin mund të gjenden në propozimin për dizajn. Kjo karakteristikë ishte me të vërtetë e shumëpritur: versione alfa ishte e pritur që të dilte në K8s 1.9, por doli vetëm tani.

API

Ekipa apliko dhe në përgjithësi menaxhimi deklarativ i objekteve u nxorrën nga kubectl në apiserver. Vetë zhvilluesit e shpjegojnë shkurtimisht vendimin e tyre me të vërtetë se kubectl aplikoni është një pjesë themelore e punës me konfigurimet në Kubernetes, megjithatë "është e mbushur me bugs dhe është e vështirë të rregullohet", për shkak të së cilës kjo funksionalitet duhet të sillet në një formë normale dhe të kalojë në kontrollin e planeve. Shembuj të thjeshtë dhe të qartë të problemeve aktuale janë:

Kubernetes 1.14: një përmbledhje e risive kryesore

Detajet mbi implementimin - në KEP. Gatishmëria aktuale - versioni alfa (promovimi në beta është planifikuar për versionin e ardhshëm të Kubernetes).

NĂ« versionin alfa Ă«shtĂ« bĂ«rĂ« e disponueshme mundĂ«sia pĂ«rdorimi i skemĂ«s OpenAPI v3 pĂ«r krijimin dhe publikimin e dokumentacionit OpenAPI pĂ«r CustomResources (CR), qĂ« pĂ«rdoren pĂ«r validimin (nĂ« anĂ«n e serverit) e burimeve K8s, tĂ« pĂ«rcaktuar nga pĂ«rdoruesi (CustomResourceDefinition, CRD). Publikimi i OpenAPI pĂ«r CRD lejon klientĂ«t (p.sh., kubectl) tĂ« kryejnĂ« validim nĂ« anĂ«n e tyre (nĂ« kuadĂ«r tĂ« kubectl krijo dhe kubectl aplikoni) dhe tĂ« jepni dokumentacionin rreth skemĂ«s (kubectl shpjego). Detajet — nĂ« KEP.

Logët që ekzistonin më parë tani hapen me flamur O_APPEND ([ O_TRUNC) për të shmangur humbjen e logëve në disa situata dhe për lehtësim të truncimit të logëve nga utilitë e jashtme për rotacionin.

Gjithashtu, nĂ« kontekstin e API-sĂ« sĂ« Kubernetes mund tĂ« theksohet se nĂ« PodSandbox dhe PodSandboxStatus shtuar fusha runtime_handler pĂ«r tĂ« mbajtur informacionin nĂ« lidhje me RuntimeClass nĂ« pod (pĂ«r mĂ« shumĂ« mbi tĂ«, lexoni tekstin nĂ« lidhje me Çlirimi i Kubernetes 1.12, ku ky klasĂ« u shfaq si version alfa), dhe nĂ« Admission Webhooks Ă«shtĂ« realizuar mundĂ«sia pĂ«r tĂ« pĂ«rcaktuar cilat versione AdmissionReview ata mbĂ«shtesin. PĂ«rfundimisht, nĂ« rregullat e Admission Webhooks tani mund tĂ« kufizojnĂ« shtrirjen e aplikimit tĂ« tyre nĂ«pĂ«rmjet emrave tĂ« hapĂ«sirave dhe kuadrove tĂ« klashtĂ«r.

Kasa

VOLUMET E QËNDROSHME TË DËRGESAVE, qĂ« patĂ«n status beta qĂ« nga lĂ«shimi K8s 1.10, u shpallĂ«n tĂ« stabilizuar (GA): ky feature gate nuk ndalet 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 qĂ« montohen si subPath, zhvilloi—nĂ« formĂ«n e njĂ« fushe tĂ« re subPathExpr, me ndihmĂ«n e tĂ« cilit tani pĂ«rcaktohet emri i nevojshĂ«m i direktoriumit. Funksionaliteti fillimisht u shfaq nĂ« Kubernetes 1.11, por mbeti nĂ« statusin alfa deri nĂ« 1.14.

Si në versionin e kaluar të Kubernetes, shumë ndryshime të rëndësishme janë paraqitur për CSI (Container Storage Interface) të zhvilluar aktivisht:

CSI

Bëri të mundur (në kuadër të versionit alfa) mbështetje ndryshimin e madhësisë për volumin CSI. Për ta përdorur atë, do të nevojitet aktivizimi i porteve të funksioneve të quajtura ExpandCSIVolumes, si dhe mbështetje për këtë operacion në drejtuesin e veçantë të CSI.

NjĂ« tjetĂ«r funksionalitet pĂ«r CSI nĂ« versionin alfa Ă«shtĂ« mundĂ«sia tĂ« referohesh drejtpĂ«rdrejt (dmth. pa pĂ«rdorur PV/PVC) nĂ« volumin CSI brenda specifikacionit tĂ« pod’ave. Kjo heq kufizimin nĂ« pĂ«rdorimin e CSI si depo tĂ« largĂ«ta ekskluzivisht, duke hapur dyert pĂ«r ta nĂ« botĂ«n e volumene lokale ephemeral. PĂ«r ta pĂ«rdorur (shembulli nga dokumenti) nevojitet aktivizimi i CSIInlineVolume portes sĂ« funksioneve.

Ka progress i është bërë edhe në "brendinë" e Kubernetes, që lidhen me CSI, të cilat nuk janë aq të dukshme për përdoruesit e fundit (administratorët e sistemeve)... Në këtë moment, zhvilluesit janë të detyruar të mbështesin dy versione të çdo plugin ruajtjeje: njërën - "si më parë", brenda kodit K8s (in-tree), dhe tjetrën - në kuadër të CSI të ri. (lexoni më shumë për të, për shembull, në këtu). Kjo shkakton shqetësime të qarta që duhet të adresohen ndërsa stabilizohet CSI si i tillë. Thjesht të merrni dhe të shpallni API-të e brendshme (in-tree) si të vjetra (deprecated) nuk është e mundur për shkak të politikat përkatëse të Kubernetesit..

E gjithë kjo ka çuar në arritjen e versioneve alfa procesi i migrimit të kodit të brendshëm të plugineve., realizuar si in-tree, në plugin-e CSI, duke e bërë kështu që shqetësimet e zhvilluesve të reduktohen në mbështetje të një versioni të vetëm të plugins-eve të tyre, ndërsa kompatibiliteti me API-të e vjetra do të ruhet dhe ato do të mund të shpallen të vjetruara sipas skenarit të zakonshëm. Pritet që në versionin e ardhshëm të Kubernetes (1.15) të bëhet migrimi i të gjithë plugin-eve të ofruesve të cloud, implementimi do të marrë statusin beta dhe do të aktivizohet në instalimet K8s si standard. Detajet mund të shihen në propozimin për dizajn. Pasojë e kësaj migrimi gjithashtu ishte refuzimi i kufizimeve për volumet e përcaktuara nga ofruesit e caktuar të cloud (AWS, Azure, GCE, Cinder).

Përveç kësaj, mbështetja për pajisjet bllokuese me CSI (CSIBlockVolume) u kalua në versionin beta.

Nodet / Kubelet

Versioni alfa i endpoint-it të ri në Kubelet, i destinuar për raportimin e metrikeve për burimet kryesore. Në përgjithësi, nëse më parë Kubelet merrte statistikat për përdorimin e konteinerëve nga cAdvisor, tani këto të dhëna vijnë nga ambienti ekzekutiv i konteinerit nëpërmjet CRI (Container Runtime Interface), megjithatë ruhet edhe përputhshmëria për të punuar me versionet e vjetra të Docker. Më parë, statistikat e mbledhura në Kubelet jepeshin përmes REST API, por tani për këtë përdoret një endpoint i vendosur në adresën /metrics/resource/v1alpha1. Strategjia afatgjatë e zhvilluesve është të minimizojë grupin e metrikave që ofrohen nga Kubelet. Nga ana tjetër, këto metrika tani quhen jo «core metrics», por «resource metrics», dhe përshkruhen si «first-class resources, such as cpu, and memory».

Një nuancë interesante: megjithë avantazhin e dukshëm në performancë të endpoint-it gRPC në krahasim me rastet e ndryshme të përdorimit të formatit Prometheus (rezultati i një benchmark-i më poshtë), autorët preferuan formatin tekstual të Prometheus për shkak të lidershipit të dukshëm të këtij sistemi monitorimi në komunitet.

«gRPC nuk është në përputhje me linjat kryesore të monitorimit. Endpoint-i do të jetë i dobishëm vetëm për të dërguar metrika në Metrics Server ose komponentët e monitorimit që integrohen direkt me të. Kur përdoret caching në Metrics Server, performanca e formatit të tekstit Prometheus është më e lartë. 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ë në performancën e gRPC me formatin e bazuar në proto.»

Kubernetes 1.14: një përmbledhje e risive kryesore
Një nga testet krahasuese të performancës midis formateve gRPC dhe Prometheus në endpoint-in e ri të Kubelet për metrika. Më shumë grafike dhe detaje të tjera mund të gjenden në KEP.

Ndër ndryshimet e tjera:

  • Kubelet tani (njĂ« herĂ«) pĂ«rpiqet tĂ« ndalĂ« konteinerĂ«t nĂ« gjendje tĂ« panjohur (unknown) pĂ«rpara operacioneve tĂ« rinisjes dhe fshirjes.
  • Kur pĂ«rdoret PodPresets tani init-konteineri shtohet ka tĂ« njĂ«jtĂ«n informacion si konteineri normal.
  • Kubelet ka filluar tĂ« pĂ«rdorĂ« usageNanoCores nga ofruesi i statistikave CRI, dhe pĂ«r nodet dhe konteinerĂ«t nĂ« Windows shtuar statistikat e rrjetit.
  • Informacion mbi sistemin operativ dhe arkitekturĂ«n tani regjistrohet nĂ« etiketa kubernetes.io/os dhe kubernetes.io/arch objekteve Node (e kaluar nga beta nĂ« GA).
  • MundĂ«sia pĂ«r tĂ« specifikuar njĂ« grup tĂ« caktuar pĂ«rdoruesish pĂ«r konteinerĂ«t nĂ« podRunAsGroup, Ă«shtĂ« prezantuar nĂ« K8s 1.11) ka pĂ«rparuar nĂ« versionin beta (aktivizuar nga e para).
  • du dhe find, tĂ« pĂ«rdorura nĂ« cAdvisor, u zĂ«vendĂ«suan me implementime nĂ« Go.

CLI

Në cli-runtime dhe kubectl u shtua flaga -k për integrim me kustomize (për më tepër, zhvillimi i tij tani është në një depozitë të veçantë), dmth. për procesimin e skedarëve YAML shtesë nga direktorive të veçanta kustomizimi (detajet mbi përdorimin e tyre shihni në KEP):

Kubernetes 1.14: një përmbledhje e risive kryesore
Shembulli i përdorimit të thjeshtë të skedarit kustomization (ndërsa mund të ketë aplikime më të komplikuara kustomize brenda overlays)

Për më tepër:

  • Shtuar komanda e re kubectl create cronjob, emri i sĂ« cilĂ«s flet pĂ«r vete.
  • NĂ« kubectl logs tani mund tĂ« kombinojĂ« flagat -f (--follow pĂ«r rrjedhjen e logeve) dhe -l (--selector pĂ«r pyetjen e etiketimeve).
  • kubectl mĂ«suam tĂ« kopjojmĂ« skedarĂ«t, tĂ« pĂ«rzgjedhur me ndihmĂ«n e wild card.
  • NĂ« komandĂ«n kubectl wait u shtua flaga --all pĂ«r tĂ« pĂ«rzgjedhur tĂ« gjitha burimet nĂ« hapĂ«sirĂ«n emĂ«rtuese tĂ« llojit tĂ« caktuar tĂ« burimeve.

TĂ« tjera

Statusi i qëndrueshëm (GA) u dha mundësive të mëposhtme:

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

  • Politika RBAC pĂ«r parazgjedhje nuk jep mĂ« akses nĂ« API discovery dhe access-review pĂ«rdoruesve pa autentifikim (unauthenticated).
  • MbĂ«shtetje zyrtare pĂ«r CoreDNS sigurohet vetĂ«m pĂ«r Linux, kĂ«shtu qĂ« kur pĂ«rdorni kubeadm pĂ«r implementimin e tij (CoreDNS) nĂ« klaster, nyjet duhet tĂ« funksionojnĂ« vetĂ«m nĂ« Linux (pĂ«r kĂ«tĂ« kufizim pĂ«rdoren nodeSelectors).
  • Konfigurimi i CoreDNS pĂ«r parazgjedhje tani pĂ«rdor pluginin forward nĂ« vend tĂ« proxy. PĂ«r mĂ« tepĂ«r, nĂ« CoreDNS shtuar readinessProbe, qĂ« parandalon ngarkimin e trafikut nĂ« pod’it pĂ«rkatĂ«s (jo tĂ« gatshĂ«m pĂ«r shĂ«rbim).
  • NĂ« kubeadm, nĂ« fazat procesi ose upload-certs, ka bĂ«rĂ« tĂ« mundur ngarkimin e certifikatave, tĂ« kĂ«rkuara pĂ«r lidhjen e njĂ« control-plane tĂ« ri me sekretin kubeadm-certs (pĂ«rdoret flags --experimental-upload-certs).
  • PĂ«r instalimet Windows ka dalĂ« njĂ« version alfa mbĂ«shtetje gMSA (Group Managed Service Account) — llogari tĂ« veçanta nĂ« Active Directory, qĂ« mund tĂ« pĂ«rdoren edhe nga konteineret.
  • PĂ«r GCE aktivizuar kriptimi mTLS midis etcd dhe kube-apiserver.
  • PĂ«rditĂ«simet nĂ« software-n e pĂ«rdorur/zbatuar: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, mbĂ«shtetje pĂ«r Docker 18.09 nĂ« kubeadm, ndĂ«rsa versioni minimal i mbĂ«shtetur i API Docker tani Ă«shtĂ« 1.26.

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