Disa aplikacione gjithashtu duhet të ruajnë të dhëna, por ata janë mjaft të kënaqur me faktin se të dhënat nuk do të ruhen pas një rifillimi.
Për shembull, shërbimet e memorizimit janë të kufizuara nga RAM-i, por gjithashtu mund të zhvendosin të dhënat që përdoren rrallë në ruajtje që është më e ngadaltë se RAM, me pak ndikim në performancën e përgjithshme. Aplikacionet e tjera duhet të jenë të vetëdijshëm se mund të ketë disa hyrje vetëm për lexim në skedarë, të tilla si cilësimet ose çelësat sekretë.
Kubernetes tashmë ka disa lloje , por funksionaliteti i tyre është i kufizuar në atë që zbatohet në K8.
Efemerale lejoi Kubernetes të zgjerohej me drejtues CSI për të ofruar mbështetje për vëllime të lehta lokale. Në këtë mënyrë është e mundur të përdoret : cilësimet, sekretet, të dhënat e identifikimit, variablat, etj. Drejtuesit CSI duhet të modifikohen për të mbështetur këtë veçori të Kubernetes, pasi supozohet se drejtuesit e rregullt të standardizuar nuk do të funksionojnë - por supozohet se vëllime të tilla mund të përdoren në çdo nyje të zgjedhur për pod.
Ky mund të jetë një problem për vëllimet që konsumojnë burime të konsiderueshme të hostit ose për ruajtjen që disponohet vetëm në disa hoste. Kjo është arsyeja pse Kubernetes 1.19 prezanton dy veçori të reja të vëllimit të testimit alfa që janë konceptualisht të ngjashme me vëllimet EmptyDir:
-
vëllime kalimtare për qëllime të përgjithshme;
-
Ndjekja e kapacitetit të ruajtjes së CSI.
Përparësitë e qasjes së re:
-
ruajtja mund të jetë lokale ose e lidhur nëpërmjet një rrjeti;
-
vëllimet mund të kenë një madhësi të caktuar që nuk mund të tejkalohet nga aplikacioni;
-
punon me çdo drejtues CSI që mbështet sigurimin e vëllimeve të vazhdueshme dhe (për të mbështetur gjurmimin e kapacitetit) zbaton thirrjen
GetCapacity; -
vëllimet mund të kenë disa të dhëna fillestare në varësi të drejtuesit dhe cilësimeve;
-
të gjitha operacionet standarde me një vëllim (krijimi i një fotografie, ndryshimi i madhësisë, etj.) mbështeten;
-
vëllimet mund të përdoren me çdo kontrollues aplikacioni që pranon një modul ose specifikim vëllimi;
-
Planifikuesi Kubernetes zgjedh vetë nyjet e përshtatshme, kështu që nuk ka më nevojë për të siguruar dhe konfiguruar shtesat e planifikuesit ose modifikimin e grepave në internet.
Mundësitë e aplikimit
Prandaj, vëllimet kalimtare për qëllime të përgjithshme janë të përshtatshme për rastet e mëposhtme të përdorimit:
Kujtesa e vazhdueshme si një zëvendësim për RAM-in për memcached
Publikimet më të fundit të memcached duke përdorur memorie të vazhdueshme (Intel Optane, etj., përafërsisht. përkthyes) në vend të RAM-it të rregullt. Kur vendosni memcached përmes një kontrolluesi aplikacioni, mund të përdorni vëllime kalimtare për qëllime të përgjithshme për të kërkuar që një vëllim i një madhësie të caktuar të ndahet nga PMEM duke përdorur drejtuesin CSI, për shembull. .
Magazinimi lokal LVM si një hapësirë pune
Aplikacionet që punojnë me të dhëna që janë më të mëdha se RAM mund të kërkojnë ruajtje lokale me një madhësi ose metrikë të performancës që vëllimet e rregullta Kubernetes EmptyDir nuk mund t'i ofrojnë. Për shembull, për këtë qëllim është shkruar .
Qasje vetëm për lexim për vëllimet e të dhënave
Shpërndarja e një vëllimi mund të rezultojë në krijimin e një vëllimi të plotë kur:
-
rikuperimi ;
-
krijim ;
-
punë .
Këto vëllime mund të montohen në modalitetin vetëm për lexim.
Si punon kjo
Vëllimet kalimtare me qëllim të përgjithshëm
Një tipar kryesor i vëllimeve kalimtare me qëllim të përgjithshëm është burimi i ri i vëllimit, EphemeralVolumeSource, që përmban të gjitha fushat për të krijuar një kërkesë vëllimi (historikisht quhet një kërkesë e vazhdueshme vëllimi, PVC). Kontrollues i ri në kube-controller-manager shikon bishtajat që krijojnë një burim të tillë vëllimi dhe më pas krijon një PVC për ato bishtaja. Për drejtuesin e CSI, kjo kërkesë duket e njëjtë me të tjerat, kështu që këtu nuk nevojitet mbështetje e veçantë.
Për sa kohë që ekzistojnë PVC të tilla, ato mund të përdoren si çdo kërkesë tjetër në vëllim. Në veçanti, ato mund të referohen si burim të dhënash kur kopjoni një vëllim ose krijoni një fotografi nga një vëllim. Objekti PVC përmban gjithashtu gjendjen aktuale të vëllimit.
Emrat e PVC-ve të krijuara automatikisht janë të paracaktuar: ato janë një kombinim i emrit të pod dhe emrit të vëllimit, të ndara me një vizë ndarëse. Emrat e paracaktuar e bëjnë më të lehtë ndërveprimin me PVC sepse nuk keni pse ta kërkoni nëse e dini emrin e pod dhe emrin e vëllimit. E keqja është se emri mund të jetë tashmë në përdorim, gjë që zbulohet nga Kubernetes dhe si rezultat pod bllokohet nga fillimi.
Për të siguruar që vëllimi të fshihet së bashku me podin, kontrolluesi i bën një kërkesë vëllimit nën zotëruesin. Kur pod fshihet, funksionon mekanizmi standard i mbledhjes së mbeturinave, i cili fshin kërkesën dhe volumin.
Kërkesat përputhen nga drejtuesi i ruajtjes përmes mekanizmit normal të klasës së ruajtjes. Edhe pse klasa me lidhje të menjëhershme dhe të vonshme (aka WaitForFirstConsumer) janë të mbështetura, për vëllime kalimtare ka kuptim të përdoret WaitForFirstConsumer, atëherë planifikuesi mund të marrë parasysh përdorimin e nyjeve dhe disponueshmërinë e ruajtjes kur zgjedh një nyje. Këtu shfaqet një veçori e re.
Ndjekja e kapacitetit të ruajtjes
Zakonisht planifikuesi nuk ka njohuri se ku drejtuesi CSI do të krijojë volumin. Gjithashtu nuk ka asnjë mënyrë që planifikuesi të kontaktojë drejtpërdrejt shoferin për të kërkuar këtë informacion. Prandaj, planifikuesi anketon nyjet derisa të gjejë një në të cilin vëllimet mund të aksesohen (lidhja e vonë) ose ia lë zgjedhjen e vendndodhjes tërësisht drejtuesit (lidhja e menjëhershme).
I ri CSIStorageCapacity, e cila është në fazën alfa, lejon që të dhënat e nevojshme të ruhen në etcd në mënyrë që të jenë të disponueshme për planifikuesin. Ndryshe nga mbështetja për vëllime kalimtare për qëllime të përgjithshme, kur vendosni drejtuesin, duhet të aktivizoni gjurmimin e kapacitetit të ruajtjes: external-provisioner duhet të publikojë informacionin e kapacitetit të marrë nga shoferi në mënyrë normale GetCapacity.
Nëse planifikuesi duhet të zgjedhë një nyje për një pod me një volum të palidhur që përdor lidhjen e vonuar dhe drejtuesi e ka aktivizuar këtë veçori gjatë vendosjes duke vendosur flamurin CSIDriver.storageCapacity, atëherë nyjet që nuk kanë kapacitet të mjaftueshëm ruajtjeje do të hidhen automatikisht. Kjo funksionon si për vëllimet e përkohshme ashtu edhe për ato të vazhdueshme, por jo për vëllimet kalimtare CSI sepse parametrat e tyre nuk mund të lexohen nga Kubernetes.
Si zakonisht, vëllimet e lidhura menjëherë krijohen përpara se të planifikohen podet dhe vendosja e tyre zgjidhet nga drejtuesi i ruajtjes, kështu që kur konfiguroni external-provisioner Si parazgjedhje, klasat e ruajtjes me lidhje të menjëhershme anashkalohen, pasi këto të dhëna nuk do të përdoren gjithsesi.
Meqenëse planifikuesi kubernetes detyrohet të punojë me informacione potencialisht të vjetruara, nuk ka asnjë garanci që kapaciteti do të jetë i disponueshëm në çdo rast kur të krijohet vëllimi, por shanset që ai të krijohet pa riprova megjithatë rriten.
NB Ju mund të merrni informacion më të detajuar, si dhe "të praktikoni në mënyrë të sigurtë në stendën e maceve", dhe në rast të një situate plotësisht të pakuptueshme, të merrni ndihmë të kualifikuar për mbështetje teknike në kurse intensive - do të mbahet në datat 28-30 shtator dhe për specialistët më të avancuar 14–16 tetor.
siguri
Kapaciteti CSIStorage
Objektet CSIStorageCapacity qëndrojnë në hapësirat e emrave; kur hapet çdo drejtues CSI në hapësirën e vet të emrave, rekomandohet të kufizohen të drejtat RBAC në CSIStorageCapacity në atë hapësirë pasi është e qartë se nga vijnë të dhënat. Kubernetes nuk e kontrollon gjithsesi për këtë, dhe zakonisht drejtuesit vendosen në të njëjtën hapësirë emrash, kështu që në fund të fundit drejtuesit pritet të punojnë dhe të mos publikojnë të dhëna të pasakta (dhe këtu dështoi karta ime, përafërsisht. përkthyes i bazuar në një shaka me mjekër)
Vëllimet kalimtare me qëllim të përgjithshëm
Nëse përdoruesit kanë të drejta për të krijuar një pod (direkt ose indirekt), ata gjithashtu do të jenë në gjendje të krijojnë vëllime kalimtare për qëllime të përgjithshme edhe nëse nuk kanë të drejta për të krijuar një kërkesë në vëllim. Kjo është për shkak se kontrollet e lejes së RBAC aplikohen në kontrolluesin që krijon PVC, jo te përdoruesi. Ky është ndryshimi kryesor për të shtuar , përpara se ta aktivizoni këtë veçori në grupe ku përdoruesit e pabesueshëm nuk duhet të kenë të drejta për të krijuar vëllime.
Shembull
Të ndara PMEM-CSI përmban të gjitha ndryshimet e nevojshme për të ekzekutuar një grup Kubernetes 1.19 brenda makinave virtuale QEMU me të gjitha veçoritë në fazën alfa. Kodi i shoferit nuk ka ndryshuar, vetëm vendosja ka ndryshuar.
Në një makinë të përshtatshme (Linux, një përdorues normal mund të përdorë , shiko detaje) këto komanda do të shfaqin grupin 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
Pasi gjithçka të funksionojë, dalja do të përmbajë udhëzime për përdorim:
The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in. Alternatively, use kubectl directly with the
following env variable:
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
...
To try out the pmem-csi driver ephemeral volumes:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Objektet CSIStorageCapacity nuk janë menduar të lexohen nga njerëzit, kështu që kërkohet një përpunim. Filtrat e shabllonit Golang do të tregojnë klasat e ruajtjes, ky shembull do të tregojë emrin, topologjinë dhe kapacitetin:
$ 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 vetëm ka përmbajtjen e mëposhtme:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels: <none>
Annotations: <none>
API Version: storage.k8s.io/v1alpha1
Capacity: 30716Mi
Kind: CSIStorageCapacity
Metadata:
Creation Timestamp: 2020-08-11T15:41:03Z
Generate Name: csisc-
Managed Fields:
...
Owner References:
API Version: apps/v1
Controller: true
Kind: StatefulSet
Name: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Resource Version: 2994
Self Link: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
Match Labels:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Storage Class Name: pmem-csi-sc-late-binding
Events: <none>
Le të përpiqemi të krijojmë një aplikacion demo me një vëllim të vetëm kalimtar për qëllime të përgjithshme. 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ç tregohet në udhëzimet e mësipërme, tani kemi një pod shtesë dhe PVC:
$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-csi-app-inline-volume 1/1 Running 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1 <none> <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-csi-app-inline-volume-my-csi-volume Bound pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
Pronari PVC - nën:
$ 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 i pritshëm i përditësuar 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 26620 Mi, programuesi nuk do të marrë parasysh pmem-csi-pmem-govm-worker1 në çdo rast.
Çka më tej?
Të dyja tiparet janë ende në zhvillim. Gjatë testimit alfa u hapën disa aplikacione. Lidhjet e propozimit të përmirësimit dokumentojnë punën që duhet bërë për të kaluar në fazën beta, si dhe cilat alternativa tashmë janë shqyrtuar dhe refuzuar:
Burimi: www.habr.com