🥇Vëllimet efemere me ndjekjen e kapacitetit të ruajtjes: EmptyDir mbi steroide

Disa disa aplikacioneve kërkojnë gjithashtu të ruajnë të dhëna, por ato e pranojnë qetësisht atë që të dhënat nuk do të ruajnë pas rinisjes.

Për shembull, shërbimet për caching janë të kufizuara nga memoria e përkohshme, por gjithashtu mund të zhvendosin të dhënat që përdoren rrallë në një depo që funksionon më ngadalë sesa memoria e përkohshme, me ndikim të vogël në performancën totale. Aplikacioneve të tjera u nevojitet të dinë se në skedarë mund të ketë disa të dhëna vetëm për lexim, për shembuj konfigurime ose çelësa sekretë.

Në Kubernetes tashmë ka disa lloje të volumin efemer, por funksionaliteti i tyre është i kufizuar nga ajo që është implementuar në K8s.

Të volumin efemer CSI lejuan zgjerimin e Kubernetes me anë të shoferëve CSI për të ofruar mbështetje për volumin lokal të lehtë. Në këtë mënyrë është e mundur të aplikohen struktura të ndryshme: konfigurime, sekrete, të dhëna për identifikim, variabla dhe kështu me radhë. Shoferët CSI duhet të përmirësohen për të mbështetur këtë funksion të Kubernetes, pasi supozohet se shoferët standardizues të zakonshëm nuk do të funksionojnë - por supozohet se këto volume mund të përdoren në çdo nyje që është zgjedhur për podin.

Kjo mund të bëhet një problem për volumin me konsum të konsiderueshëm të burimeve të nyjës ose për depozitimin e disponueshëm vetëm në disa nyje. Prandaj, në Kubernetes 1.19 janë prezantuar dy funksione të reja volumesh për testim alfa, konceptualisht të ngjashme me volumin EmptyDir:

volumet efemere të përgjithshme;
ndjekja e kapacitetit të depozitimit CSI.

Përfitimet e qasjes së re:

depozita mund të jetë lokale ose e lidhur në rrjet;
volumet mund të kenë një madhësi të caktuar që nuk mund të kalojë aplikacioni;
punon me çdo shofer të CSI që mbështet ofrimin e volumve të përhershëm dhe (për të mbështetur monitorimin e kapacitetit) implementon thirrjen GetCapacity;
volumet mund të kenë disa të dhëna themelore, varësisht nga shoferi dhe parametrat;
të gjitha operacionet tipike me volum (të krijosh një snapshot, të ndryshosh madhësinë etj.) janë të mbështetura;
volumet mund të përdoren me çdo kontrollues aplikacionesh që pranon specifikimin e modulit ose volumit;
përgjegjësi për planifikimin e Kubernetes vetë zgjedh nyjet e përshtatshme, kështu që nuk është më e nevojshme të sigurohet dhe të konfigurohen zgjerimet e planifikimit dhe të ndryshohen webhook-et.

Mundësitë e përdorimit

Kështu, volumi efemer i përgjithshëm është i përshtatshëm për mundësitë e mëposhtme të përdorimit:

Memorie e përhershme si zëvendësim për memorie të përkohshme për memcached

Shpërndarjet e fundit të memcached kanë shtuar mbështetje për përdorimin e memories së përhershme (Intel Optane etj., shënim i përkthyesit) në vend të memories së zakonshme të përkohshme. Kur implementohet memcached nëpërmjet një kontrollues aplikacionesh, mund të bëhet një kërkesë për ndarjen e volumit të caktuar nga PMEM me anë të shoferit CSI, për shembull PMEM-CSI.

Depozita lokale LVM si hapësirë pune

Aplikacionet që punojnë me të dhëna që tejkalojnë madhësinë e memories së përkohshme, mund të kërkojnë depo lokale me madhësi ose matje performancë që nuk mund të sigurohen nga volumet e zakonshme EmptyDir nga Kubernetes. Për shembull, për këtë qëllim është shkruar TopoLVM.

Të dhëna në vetëm lexim për volumet me të dhëna

Ndarja e një volumi mund të çojë në krijimin e një volumi të mbushur kur:

Këto volume mund të montohen në modalitetin e vetëm për lexim.

Si funksionon

Volumet efemere të përgjithshme

Karakteristika kyçe e volumeve efemere të përgjithshme është burimi i ri i volumit, EphemeralVolumeSource, që përmban të gjitha fushat për krijimin e një kërkese për volum (historikisht e quajtur kërkesë për volum të përhershëm, PVC). Një kontrollues i ri në kube-controller-manager shikon pod-ët që krijojnë një burim të tillë volum dhe pastaj krijon PVC për këta pod. Për shoferin CSI, kjo kërkesë duket ashtu si kërkesat e tjera, kështu që këtu nuk ka nevojë për mbështetje të veçantë.

Sa kohë që këto PVC ekzistojnë - mund të përdoren, si dhe çdo kërkesë tjetër për volum. Në veçanti, ato mund të jenë një referencë si burim të dhënash kur kopjohet një volum ose krijohet një snapshot nga volumi. Objekti PVC gjithashtu përmban gjendjen aktuale të volumit.

Emrat e PVC-ve që krijohen automatikisht janë të paracaktuar: kjo është një kombinim i emrit të pod-it dhe emrit të volumit, të ndara me një lidhës. Paracaktimi i emrave e thjeshton ndërveprimin me PVC, pasi nuk është e nevojshme ta kërkosh nëse dihet emri i pod-it dhe emri i volumit. Disavantazhi është se emri mund të jetë përdorur tashmë, gjë që zbulohet nga Kubernetes dhe si rezultat, nisja e pod-it bllokohet.

Për të qenë i sigurt se volumi hiqet së bashku me podin, kontroluesi e bën volumin pronar të kërkesës për podin. Kur podi hiqet, funksionon mekanizmi standard i pastrimit që heq si kërkesën ashtu edhe volumet.

Kërkesat lidhën me drejtuesin e ruajtjes përmes një mekanizmi të zakonshëm të klasës së ruajtjes. Ndërsa klasat me lidhje të menjëhershme dhe të vonuar (të njohura gjithashtu si WaitForFirstConsumer) mbështeten, ka kuptim të përdoren për volumet efemere WaitForFirstConsumer, që lejon planifikuesin të marrë parasysh si përdorimin e nyjës ashtu edhe disponueshmërinë e ruajtjes gjatë zgjedhjes së nyjës. Këtu shfaqet një funksion i ri.

Ndjekja e kapacitetit të ruajtjes

Në përgjithësi, planifikuesi nuk ka të dhëna në lidhje me vendin ku drejtuesi i CSI do të krijojë volumet. Gjithashtu, planifikuesi nuk ka mundësi të kontaktojë drejtpërdrejt drejtuesin për të kërkuar këtë informacion. Prandaj, planifikuesi ndërmerr një proces pyetjeje ndaj nyjave derisa të gjejë atë ku volumi mund të jetë i disponueshëm (për lidhjen e vonuar) ose ta lërë plotësisht zgjedhjen e vendit te drejtuesi (për lidhjen e menjëhershme).

E re API CSIStorageCapacity, në fazën alpha, lejon ruajtjen e të dhënave të nevojshme në etcd, në mënyrë që ato të jenë të disponueshme për planifikuesin. Në krahasim me mbështetje për volumet efemere të zakonshme, gjatë shpërndarjes së drejtuesit duhet të aktivizohet ndjekja e kapacitetit të ruajtjes: external-provisioner duhet të publikojë informacionin mbi kapacitetin që merret nga drejtuesi përmes një mekanizmi të zakonshëm. GetCapacity.

Nëse planifikuesi duhet të zgjedhë një nyje për një pod me volum të pa lidhur, që përdor lidhjen e vonuar, dhe drejtuesi aktivizoi këtë funksion gjatë shpërndarjes duke vendosur flamurin CSIDriver.storageCapacity, atëherë do të përjashtohen automatikisht nyjet që nuk kanë kapacitet mjaftueshëm të ruajtjes. Kjo funksionon për volumet efemere të zakonshme si dhe për ato të përhershëm, por jo për volumet efemere të CSI, pasi parametrat e tyre nuk mund të lexohen nga Kubernetes.

Si zakonisht, volumet me lidhje të menjëhershme krijohen para planifikimit të podëve, dhe vendndodhja e tyre zgjidhet nga drejtuesi i ruajtjes, kështu që gjatë konfigurimit external-provisioner normalisht përjashtohen klasat e ruajtjes me lidhje të menjëhershme, pasi këto të dhëna s'ka si të përdoren.

Për shkak se planifikuesi i Kubernetes është i detyruar të punojë me informacione potencialisht të vjetra, nuk ka garanci që kapaciteti do të jetë i disponueshëm në çdo rast kur volumi të krijohet, megjithatë, është e sigurt se shanset që ai të krijohet pa provë të dytë rriten.

Shën. Më shumë informacione mund të merrni, si dhe mundësinë për të "praktikuar në një mjedis testimi", dhe në rast se ndodhin situata vërtet të paqarta, të merrni ndihmë të kualifikuar nga mbështetja teknike në sesione — Baza Kubernetes do të mbahet nga 28 deri më 30 Shtator, dhe për specialistët më të avancuar Kubernetes Mega 14–16 tetor.

Siguria

CSIStorageCapacity

Objektet e CSIStorageCapacity janë në hapësira emrash, dhe gjatë shpërndarjes së çdo drejtuesi të CSI, rekomandohet që të kufizohen të drejtat RBAC për CSIStorageCapacity në këtë hapësirë, pasi është e qartë se nga vijne të dhënat. Në çdo rast, Kubernetes nuk e verifikon këtë, dhe zakonisht drejtuesit vendosen në një hapësirë emrash të përbashkët, kështu që pritet që drejtuesit të funksionojnë dhe të mos publikojnë të dhëna të gabuara (dhe këtu më del një kartë e fortë, shënim i përkthyesit mbi bazën e një anekdote të njohur.)

Volumet efemere të përgjithshme

Nëse përdoruesit kanë të drejta për të krijuar podë (direkt ose nëpërmjet), ata gjithashtu do të mund të krijojnë volumet efemere të zakonshme, edhe nëse nuk kanë të drejta për të krijuar një kërkesë për volum. Kjo ndodh sepse kontrolli i të drejtave RBAC zbatohet për kontrolluesin që krijon PVC-në, jo për përdoruesin. Kjo është ndryshimi kryesor që duhet të shtohet në llogarinë, para se të aktivizohet ky funksion në klaster, nëse përdoruesit e pasigurt nuk duhet të kenë të drejta për krijimin e volumëve.

Shembuj

Një temë në PMEM-CSI përmban të gjitha ndryshimet e nevojshme për të funksionuar klasteri i Kubernetes 1.19 brenda makinave virtuale QEMU me të gjitha funksionet që janë në fazën alpha. Kodi i drejtuesit nuk është ndryshuar, vetëm shpërndarja është modifikuar.

Në një makinë të përshtatshme (Linux, përdoruesi normal mund të përdorë Docker, shihni këtu detajet) këto komanda do të ngrejnë klasterin dhe do të instalojnë drejtuesin PMEM-CSI:

git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh

Pas përfundimit të procesit, rezultati do të përmbajë udhëzime për përdorim:

Klastri i testit është gati. Hyni me [...]/pmem-csi/_work/pmem-govm/ssh.0, ekzekutoni
kubectl sapo të keni hyrë. Ndryshe, përdorni kubectl direkt me
variablin e mjedisit si më poshtë:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets u krijua
secret/pmem-csi-node-secrets u krijua
serviceaccount/pmem-csi-controller u krijua
...
Për të provuar volumet efemere të driver-it pmem-csi:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Objektet CSIStorageCapacity nuk janë të destinuara për lexim nga njerëzit, kështu që kërkohet një përpunim i caktuar. Me ndihmën e filtrave të shabllonit në Golang, do të shfaqen klasat e ruajtjes. Në këtë shembull do të shfaqen emri, topologjia dhe kapaciteti:

$ kubectl get 
        -o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}' 
        csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Një objekt i veçantë ka këtë përmbajtje:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Emri:         csisc-sqdnt
Kategoritë:    default
Etiketat:       <asnjë>
Annotacionet:  <asnjë>
Versio API:  storage.k8s.io/v1alpha1
Kapaciteti:     30716Mi
Lloji:         CSIStorageCapacity
Metadata:
  Koha e Krijimit:  2020-08-11T15:41:03Z
  Emri i Gjeneruar:       csisc-
  Fushat e Përdorura:
    ...
  Referencat e Pronarit:
    Versio API:     apps/v1
    Kontrolluesi:      e vërtetë
    Lloji:            StatefulSet
    Emri:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Versio e Burimeve:  2994
  Lidhja e Vet:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Etiketat e Pajtueshmërisë:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Emri i Klases së Ruajtjes:           pmem-csi-sc-late-binding
Ngjarjet:                       <asnjë>

Le të provojmë të krijojmë një aplikacion demonstrativ me një volum efemer të dukshëm. Përmbajtja e skedarit pmem-app-ephemeral.yaml:

# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app-inline-volume
spec:
  containers:
    - name: my-frontend
      image: intel/pmem-csi-driver-test:v0.7.14
      command: [ "sleep", "100000" ]
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-volume
  volumes:
  - name: my-csi-volume
    ephemeral:
      volumeClaimTemplate:
        spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 4Gi
          storageClassName: pmem-csi-sc-late-binding

Pas krijimit, ashtu siç përshkruhet në udhëzimin e mësipërm, kemi një pod dhe PVC shtesë:

$ kubectl get pods/my-csi-app-inline-volume -o wide
Emri                       Gati   Statusi    Rindërtimet   Mosha     IP          NODE                         NODE TË NOMINUAR   PORTAT E GATSHMËRISË
my-csi-app-inline-volume   1/1     Po funksionon   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <asnjë>           <asnjë>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
Emri                                     Statusi   VOLUMI                                     KAPACITETI   MODET E HAPJES   STORAGECLASS               MOSHA
my-csi-app-inline-volume-my-csi-volume   E lidhur    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

Pronari i PVC — pod:

$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
lloji: PersistentVolumeClaim
metadata:
  annotacionet:
    pv.kubernetes.io/bind-completed: "po"
    pv.kubernetes.io/bound-by-controller: "po"
    volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
    volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
  koha e krijimit: "2020-08-11T15:44:57Z"
  finalizuesit:
  - kubernetes.io/pvc-protection
  fushat e menaxhuara:
    ...
  emri: my-csi-app-inline-volume-my-csi-volume
  kategoritë: default
  referencat e pronarit:
  - versio API: v1
    blloku i Pronarit të Fshirjes: e vërtetë
    kontrolluesi: e vërtetë
    lloji: Pod
    emri: my-csi-app-inline-volume
    uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...

Informacioni për pmem-csi-pmem-govm-worker1:

csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Nëse një aplikacion tjetër do të duhet më shumë se 26620Mi, planifikuesi nuk do ta marrë parasysh pmem-csi-pmem-govm-worker1 në çdo rast.

Çfarë ndodh më tej?

Të dy funksionet ende janë në zhvillim. Janë hapur disa kërkesa gjatë testimit alpha. Në lidhje me propozimet për përmirësim, po dokumentohet puna që duhet të bëhet për të kaluar në fazën beta, si dhe cilat alternativa janë shqyrtuar dhe hedhur poshtë:

Burimi: habr.com