Disa disa aplikacioneve gjithashtu nevojitet të ruajnë të dhëna, por ato janë mjaft të qeta për faktin se të dhënat nuk do të ruhen pas rindizjes.
Për shembull, shërbimet për cache janë të kufizuara në memorjen RAM, por gjithashtu mund të transferojnë të dhëna që përdoren rrallë në një ruajtje që funksionon më ngadalë se memorja RAM, me një ndikim të vogël në performancën e përgjithshme. Aplikacioneve të tjera u nevojitet të dinë se në skedarët mund të ketë disa të dhëna vetëm për lexim, p.sh. konfigurimet ose çelësat sekretë.
Në Kubernetes tashmë ka disa lloje , por funksionaliteti i tyre është i kufizuar në atë që është zbatuar në K8s.
Volumet efemere lejojnë zgjerimin e Kubernetes me drejtuesit CSI për të ofruar mbështetje për volumat e lehta lokale. Në këtë mënyrë, është e mundur të aplikohet : konfigurime, sekrete, të dhëna identifikimi, variabla dhe kështu me radhë. Drejtuesit CSI duhet të përmirësohen për të mbështetur këtë funksion të Kubernetes, pasi supozohet se drejtuesit e standardizuar normalë nuk do të funksionojnë – por supozohet se këto volume mund të përdoren në çdo nodë të zgjedhur për podin.
Kjo mund të bëhet një problem për volumat me konsum të konsiderueshëm të burimeve të nodit ose për ruajtjen e disponueshme vetëm në disa nodë. Prandaj, në Kubernetes 1.19 janë paraqitur dy funksione të reja volumesh për testimin alpha, të ngjashme konceptualisht me volumet EmptyDir:
volumet efemere të qëllimit të përgjithshëm;
ndjekja e kapacitetit të ruajtjes CSI.
Përparësitë e qasjes së re:
ruajtja mund të jetë lokale, ose të lidhet në rrjet;
volumet mund të kenë një madhësi të caktuar, e cila nuk mund të tejkalohet nga aplikacioni;
punon me çdo drejtues CSI që mbështet ofrimin e volumeve të përhershme dhe (për mbështetje të ndjekjes së kapacitetit) zbatohet thirrja
GetCapacity;volumet mund të kenë disa të dhëna fillestare, të varura nga drejtuesi dhe parametrat;
të gjithë veprimet tipike me volum (krijimi i një kopjeje të gjendjes, rritja e madhësisë etj.) mbështeten;
volumet mund të përdoren me çdo kontrollues aplikacionesh që pranon specifikimin e modulit ose volumit;
Planifikuesi i Kubernetes vetë zgjedh node të përshtatshme, prandaj nuk është më e nevojshme të sigurohen dhe konfigurohen zgjerimet e planifikuesit dhe të ndryshohen webhook-ët.
Variantet e Përdorimit
Kështu që volumat efemere të përdorimit të përgjithshëm janë të përshtatshme për variantet e mëposhtme të përdorimit:
Memoria e përhershme si zëvendësim për memorjen e përkohshme për memcached
Lëshimet më të fundit të memcached për përdorim të memories së përhershme (Intel Optane etj., shën. e përkthyesit) në vend të memories së zakonshme të përkohshme. Kur deploy-oni memcached përmes kontrolluesit të aplikacioneve, është e mundur të bëni një kërkesë për alokim të një volumi me madhësi të caktuar nga PMEM duke përdorur driverin CSI, për shembull .
Ruajtja lokale LVM si hapësirë pune
Aplikacionet që punojnë me të dhëna, të cilat janë më të mëdha se madhësia e memories së përkohshme, mund të kërkojnë ruajtje lokale me madhësinë ose metrikat e performancës, të cilat nuk mund të ofrohen nga volumat e zakonshme EmptyDir të Kubernetes. Për këtë qëllim është shkruar .
Prona vetëm për lexim për volumat me të dhëna
Alokimi i një volumi mund të çojë në krijimin e një volumi të plotë kur:
rikuperimi ;
krijimi ;
punës .
Këto volume mund të montohen në modalitetin vetëm për lexim.
Si funksionon kjo
Volumat efemere të përdorimit të përgjithshëm
Karakteristika kryesore e volumeve efemere të përdorimit të përgjithshëm është burimi i ri i volumit, EphemeralVolumeSource, që përmban të gjitha fushat për të krijuar një kërkesë për volum (historikisht kjo quhet kërkesë për volum të përhershëm, PVC). Një kontrollues i ri në kube-controller-manager shikon pod-et që krijojnë një burim të tillë volum dhe pastaj krijon PVC për këto pod-e. Për driverin CSI, kjo kërkesë duket ashtu si të tjerat, prandaj këtu nuk nevojitet mbështetje e veçantë.
Sakësisht gjatë që ekzistojnë këto PVC — mund të përdoren si çdo tjetër kërkesë për volum. Veçanërisht ato mund të jenë një referencë si burim të dhënash gjatë kopjimit të një volumi ose krijimit të një snapshot-i nga volumi. Objekti PVC gjithashtu përmban gjendjen aktuale të volumit.
Emrat e PVC-ve të krijuara automatikisht janë të paracaktuara: ato janë një kombinim i emrit të pod-it dhe emrit të volumes, të ndara nga një presje. Paracaktimi i emrave e lehtëson ndërveprimin me PVC-në, pasi nuk ka nevojë të kërkoni për të, nëse e dini emrin e pod-it dhe emrin e volumes. Një disavantazh është se emri tashmë mund të jetë përdorur, gjë që zbulohet nga Kubernetes dhe si rezultat, ngarkesa e pod-it bllokohet.
Për të qenë të sigurt se volumi fshihet së bashku me pod-in, kontrolluesi e bën pod-in pronar të kërkesës për volum. Kur pod-i fshihet, mekanizmi i zakonshëm i pritjes për pastrimin ndodh, i cili fshin si kërkesën ashtu edhe volumin.
Kërkesave u caktohet një driver i ruajtjes përmes mekanizmit të zakonshëm të klasës së ruajtjes. Megjithatë, klasat me lidhje të menjëhershme dhe të vonuar (ato janë WaitForFirstConsumer) mbështeten, ka kuptim për të përdorur volumet efemerike WaitForFirstConsumer, atëherë planifikuesi mund të marrë parasysh përdorimin e nodit si dhe disponueshmërinë e ruajtjes kur zgjedh nodin. Këtu del një funksion i ri.
Përgjimi i kapacitetit të ruajtjes
Në përgjithësi, planifikuesi nuk ka të dhëna për atë se ku driver-i i CSI do të krijojë volum. Gjithashtu, planifikuesi nuk ka mundësi të kontaktojë drejtpërdrejt me driver-in për të kërkuar këtë informacion. Prandaj, planifikuesi pyet nodet derisa të gjejë atë, ku volumet mund të jenë të disponueshme (lidhje të vonuar), ose lënë plotësisht zgjedhjen e vendit te driver-i (lidhje të menjëhershme).
E re 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. Ndryshe nga mbështetja për volumet efemerike të përgjithshme, gjatë implementimit të driver-it duhet të aktivizohet përgjimi i kapacitetit të ruajtjes: external-provisioner duhet të publikojë informacionin në lidhje me kapacitetin, i marrë nga driver-i përmes mekanizmit të zakonshëm GetCapacity.
Nëse planifikuesit i nevojitet të zgjedhë një nod për pod-in me volum të pa lidhur, që përdor lidhje të vonuar, dhe driver-i gjatë implementimit ka aktivizuar këtë funksion duke vendosur flamurin CSIDriver.storageCapacity, atëherë do të eliminohen automatikisht nodet që nuk kanë kapacitet të mjaftueshëm ruajtjeje. Kjo funksionon si për volumet efemerike të përgjithshme ashtu edhe për volumet e përhershme, por jo për volumet efemerike të CSI, pasi parametrat e tyre nuk mund të lexohen nga Kubernetes.
Si zakonisht, volumat me lidhje të menjëhershme krijohen para planifikimit të podëve, dhe vendosja e tyre zgjidhet nga drivere i ruajtjes, prandaj gjatë konfigurimit external-provisioner klasat e ruajtjes me lidhje të menjëhershme anashkalohen si të parazgjedhura, pasi këto të dhëna çdo mënyrë nuk do të përdoren.
Duke pasur parasysh se planifikuesi i Kubernetes është i detyruar të punojë me informacion të mundshëm të prapambetur, nuk ka garanci që kapaciteti do të jetë i disponueshëm në çfarëdo kohe kur volumi të krijohet, megjithatë, shanset që ai të krijohet pa përpjekje të përsëritura rriten.
Shënim: Më shumë informacion mund të merrni, si dhe mundësinë për të "stërvitur mbi macet" në një podium praktik, dhe në rast të një situate të papërcaktuar mund të merrni ndihmë të kualifikuar nga mbështetje teknike në intensivet - do të zhvillohet më 28-30 Shtator, dhe për specialistët më të avancuar 14–16 tetor.
Siguria
CSIStorageCapacity
Objektet e CSIStorageCapacity gjenden në hapësira emrash, në rrethin e çdo drivere CSI është e rekomanduar të kufizohen të drejtat RBAC për CSIStorageCapacity në këtë hapësirë, pasi është e dukshme se nga vijnë të dhënat. Në çdo rast, Kubernetes nuk e verifikon këtë, dhe zakonisht driverët vendosen në një hapësirë emri, kështu që në fund pritet që driverët të punojnë dhe të mos publikojnë të dhëna të gabuara (dhe këtu më doli karta, shënim i përkthyesit sipas një anekdote të njohur)
Volumat efemere të përdorimit të përgjithshëm
Nëse përdoruesit kanë të drejtat për të krijuar një pod (direkt ose në mënyrë të tërthortë) - ata gjithashtu do të jenë në gjendje të krijojnë voluma efemere me qëllim të përgjithshëm edhe nëse nuk kanë të drejta për të krijuar kërkesë për volum. Kjo ndodh sepse verifikimet e të drejtave RBAC aplikohen në kontrolluesin që krijon PVC, dhe jo tek përdoruesi. Ky është ndryshimi kryesor që duhet shtuar , para se të aktivizohet kjo funksionalitet në klasterët, nëse përdoruesit e pasigurt nuk duhet të kenë të drejta për të krijuar voluma.
Shembulli
Një degë Në një makinë të përshtatshme (Linux, përdoruesi i zakonshëm mund të përdorë
, shih detajet) këto komanda do të ngrejnë klasterin dhe do të instalojnë driverin PMEM-CSI: këto komanda do të ngrejnë grumbullin dhe do të instalojnë shërbimin 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
Pasi që gjithçka të funksionojë, dalja do të përmbajë udhëzime për përdorim:
Klusteri i testit është gati. Hyni me [...]pmem-csi/_work/pmem-govm/ssh.0, ekzekutoni
kubectl pasi të jeni regjistruar. Si alternativë, përdorni kubectl direkt me
variablin ambient:
KUBECONFIG=[...]pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
Për të provuar volumet efemer të driverit 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ë dizajnuara për lexim nga njerëzit, prandaj kërkohet përpunim të caktuar. Me ndihmën e filtrave të shabllonit në Golang do të shfaqen klasat e depozitave; 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 përmbajtje si kjo:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Emri: csisc-sqdnt
Namespace: default
Etiketat:
Annotations:
API Version: storage.k8s.io/v1alpha1
Kapaciteti: 30716Mi
Lloji: CSIStorageCapacity
Metadata:
Kohëzgjatja e Krijimit: 2020-08-11T15:41:03Z
Genero Emrin: csisc-
Fushat e Menaxhuara:
...
Referencat e Pronarit:
API Version: apps/v1
Kontrolluesi: true
Lloji: StatefulSet
Emri: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Versioni i Burimeve: 2994
Lidhja Vetë: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Topologjia e Nodhës:
Etiketat e Përshtatjes:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Emri i Klasës së Depo: pmem-csi-sc-late-binding
Ngjarjet:
Le të provojmë të krijojmë një aplikacion demonstrues me një volum efemer të përbashkët. 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, siç është treguar në udhëzimin më sipër, kemi marrë një pod të shtuar dhe PVC:
$ kubectl get pods/my-csi-app-inline-volume -o wide
EMRI GATI STATUS RIKTHESET MOSHA IP NODI NODI I NOMINUAR PORTAT E GATSHMËRISË
my-csi-app-inline-volume 1/1 Duke funksionuar 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
EMRI STATUS VOLUMI KAPACITETI MODET E QASJES STORAGECLASS MOSHA
my-csi-app-inline-volume-my-csi-volume Këtheer pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
Pronari i PVC është podi:
$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
creationTimestamp: "2020-08-11T15:44:57Z"
finalizers:
- kubernetes.io/pvc-protection
managedFields:
...
name: my-csi-app-inline-volume-my-csi-volume
namespace: default
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: true
controller: true
kind: Pod
name: 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 ka nevojë për më shumë se 26620Mi, planifikuesi nuk do ta marrë parasysh pmem-csi-pmem-govm-worker1 në çfarëdo rasti.
Çfarë ndodh më tej?
Të dy funksionet janë ende në zhvillim. Janë hapur disa kërkesa gjatë testimit alpha. Dokumentimi po zhvillohet përmes lidhjeve me propozime për përmirësime, duke treguar punën që duhet bërë për t'u kaluar në fazën beta, si dhe cilat alternativa janë shqyrtuar dhe refuzuar:
Burimi: habr.com
