Mõned rakendused vajavad samuti andmete salvestamist, kuid nad on piisavalt leebed selle suhtes, et andmeid ei salvestata pärast taaskäivitamist.
Näiteks vahemälu teenused on piiratud mälumahtude poolest, kuid need võivad samuti liigutada andmeid, mida harva kasutatakse, aeglasemasse salvestusruumi, mis mõjutab üldist jõudlust minimaalselt. Teised rakendused peavad teadma, et failides võivad olla ainult lugemiseks mõeldud sisendid, nagu konfiguratsioonid või salajased võtmed.
Kuberneteses on juba mitu tüüpi , kuid nende funktsionaalsus on piiratud K8s-is rakendatuga.
Efemeersed on võimaldanud laiendada Kubernetesit CSI draiverite kaudu, et toetada kerged kohalikke mahuteid. Nii on võimalik rakendada : seaded, saladused, autentimisandmed, muutujad jne. CSI draiverid peavad olema kohandatud selle Kubernetes'i funktsiooni toetamiseks, kuna eeldatakse, et tavalised standarditud draiverid ei tööta - kuid eeldatakse, et selliseid mahtusid saab kasutada mis tahes sõlmest, mille pod valib.
See võib olla probleem mahutite puhul, mis tarbivad sõlmest märkimisväärselt ressursse, või salvestuse puhul, mis on saadaval ainult mõnel sõlmest. Seetõttu on Kubernetes 1.19-s tutvustatud kahte uut mahtude funktsiooni alfa-testimiseks, mis on kontseptuaalselt sarnased EmptyDir mahtudega:
üldotstarbelised efemeersed mahud;
CSI salvestusmahu jälgimine.
Uue lähenemise eelised:
salvestus võib olla kohalik või võrgu kaudu ühendatav;
mahtudel võib olla määratud suurus, mida rakendus ei tohi ületada;
toimib igasuguste CSI draiveritega, mis toetavad pidevate mahutite pakkumist ja (mahu jälgimise toetamiseks) rakendavad kutsungi
GetCapacity;mahtudel võivad olla algandmed, mis sõltuvad draiverist ja seadistustest;
kõik tüüpilised toimingud mahuga (olekufaili loomine, suuruse muutmine jne) on toetatud;
mahtusid saab kasutada igasuguste rakenduste juhtidega, mis aktsepteerivad mooduli või mahu spetsifikatsiooni;
Kubernetes'i ajakava valib sobivad sõlmed automaatselt, seega pole enam vajalik ajakava laienduste konfigureerimine ja webhooks'i muutmine.
Kasutusvõimalused
Seega sobivad üldotstarbelised efemeersed mahud järgmisteks kasutusvõimalusteks:
Püsiv mälu asendamiseks speichimälu jaoks memcachedis
Viimased versioonid memcachedist püsiva mälutootmise (nt Intel Optane jne, tõlkija märk.) asemel tavalise RAMiga. Kui memcachedi rakenduste juhiga üles seatakse, saab üldotstarbeliste efemeersete mahtudega nõuda antud suurusega mahu eraldamist PMEMist CSI draiveri kaudu, näiteks .
Kohalik LVM-i salvestusruum tööruumina
Andmed rakendustes, mille suurus ületab mälumahu suurust, võivad küsida kohalikku salvestusruumi, mille suurus või jõudlusmeetmed ei pruugi rahuldada tavaliste Kubernetes'i EmptyDir mahtude nõudeid. Näiteks selle eesmärgi nimel on kirjutatud .
Ainult lugemisõigus andmemahtude jaoks
Mahtude eraldamine võib viia täidetud mahu loomise juurde juhul, kui:
taastamine ;
loomine ;
töös .
Need mahud võivad olla monteeritud ainult lugemisrežiimis.
Kuidas see toimib
Üldotstarbelised efemeersed mahud
Üks peamisi omadusi üldotstarbeliste efemeersete mahtude puhul on uus mahu allikas, EphemeralVolumeSource, mis sisaldab kõiki välju, mis on vajalikud mahu (ajalooliselt tuntud kui püsiva mahu, PVC) taotluse tegemiseks. Uus kontrollija kube-controller-manager vaatab üle podid, mis loovad sellise mahu allika, ja seejärel loob nende podide jaoks PVC. CSI draiveri jaoks näeb see taotlus välja nagu teised, seega ei ole siin erilist tuge vaja.
Kuna PVC-d olemas on, saab neid kasutada nagu ükskõik muid mahtude päringuid. Eeskätt võivad need olla andmeallikaks mahust kopeerimisel või mahu hetkeseisu loomisel. PVC objekt sisaldab ka mahu praegust olekut.
Automaatsete PVC-de nimetused on ettenähtud: see on kombinatsioon podi nimest ja mahu nimest, eraldatuna sidekriipsuga. Nime ettenähtavus lihtsustab PVC-ga töötamist, kuna seda ei pea otsima, kui podi ja mahu nime tead. Puuduseks on see, et nimi võib olla juba kasutusel, mida Kubernetes tuvastab ja mille tõttu podi käivitamine takerdub.
Selleks, et olla kindel, et maht kustutatakse koos podiga, teeb kontroller podist päringu omaniku. Kui pod kustutatakse, käivitub tavaline prahi koristamise mehhanism, mis kustutab nii päringu kui ka mahu.
Päringutele vastab salvestusdraiver klassikalise salvestusklassi mehhanismi kaudu. Kuigi kohene ja hiline sidumine (need on WaitForFirstConsumer) on toetatud, on efemeersete mahupuhul mõttekam kasutada WaitForFirstConsumer, siis planeerija võib arvesse võtta nii sõlme kasutust kui ka salvestuse kättesaadavust sõlme valimisel. Siin tuleb mängu uus funktsioon.
Salvestuse mahutavuse jälgimine
Tavaliselt ei ole planeerijal teavet selle kohta, kus CSI draiver loob mahtusid. Planeerijal puudub ka otsene kontakt draiveriga, et küsida selle teabe saamiseks. Seetõttu küsib planeerija sõlmede kohta seni, kuni leiab selle, kus maht on kättesaadav (hilisem sidumine), või jätab koha valiku täielikult draiveri hooleks (otsekohene sidumine).
Uus CSIStorageCapacity, mis on alfa faasis, lubab vajalikku teavet salvestada etcd-s, et planeerija saaks sellele ligi. Erinevalt ajutiste üldmahtude toetamisest tuleb draiveri juurutamisel lubada salvestuse mahutavuse jälgimine: external-provisioner peab avaldama mahutavuse teabe, mis on saadud draiverilt tavalise GetCapacity.
Kui planeerijale tuleb valida sõlm podi jaoks, millel on sidumata maht, mis kasutab hilisemate sidumiste funktsiooni, ja draiver aktiveeris selle funktsiooni juurutamise käigus, määrates lipu CSIDriver.storageCapacity, siis eemaldatakse automaatselt sõlmed, millel ei ole piisavalt salvestusmahtu. See toimib nii ajutiste üldotstarbeliste kui ka püsivate mahtudega, kuid mitte ajutiste CSI mahtudega, kuna nende parameetreid ei saa Kubernetesel lugeda.
Nagu tavaliselt, luuakse koheselt siduvad mahud enne podide ajakava koostamist ning nende paigutuse valib salvestusdraiver, seega seadistamisel external-provisioner vahele jäetakse vaikimisi koheselt siduvad salvestusklassid, kuna neid andmeid ei saa ikkagi kasutada.
Kuna Kubernetes'i ajakava peab töötama potentsiaalselt aegunud teabe alusel, pole garantiid, et maht on igal juhul saadaval, kui maht luuakse, kuid sellegipoolest, tõenäosus, et see loob ilma korduskatseteta, suureneb.
N.B. Rohkem teavet saate, samuti ohutult «katsetada» seinte süsteemil, ning juhul, kui olukord jääb täielikult segaseks, saate kvalifitseeritud tehnilise abi intensiivsetel — toimub 28-30. septembril, ning edasijõudnud spetsialistide jaoks 14–16. oktoobril.
Turvalisus
CSIStorageCapacity
CSIStorageCapacity objektid asuvad nimede ruumides, iga CSI draiveri juurutamisel on soovitatav piirata RBAC õigusi CSIStorageCapacity's, kuna on ilmne, kust andmed pärinevad. Igal juhul Kubernetes ei kontrolli seda ja tavaliselt installitakse draiverid ühte nimesse ruumi, seega oodatakse lõpuks, et draiverid töötaksid ja ei avaldaks valeandmeid (ja siin mul läks kaart jooksma, tõlkija märkuses põhinev naljakas anekdoot)
Üldotstarbelised efemeersed mahud
Kui kasutajatel on õigused podi loomiseks (otse või kaudselt) – saavad nad luua ka ajutisi universaalseid mahtusid, isegi kui neil pole õigusi mahtude päringu loomise jaoks. Ja see kõik juhtub, sest RBAC õiguste kontrolli rakendatakse PVC loomise kontrollija suhtes, mitte kasutaja suhtes. See on peamine muudatus, mis tuleb lisada , enne kui see funktsioon klastrites aktiveeritakse, kui usaldamatutel kasutajatel ei tohiks olla õigusi mahtude loomiseks.
Näide
Erakordne PMEM-CSI sisaldab kõiki vajalikke muudatusi, et käivitada Kubernetes 1.19 klaster QEMU virtuaalmasinates koos kõigi alfa-etapis olevate funktsioonidega. Draiveri kood on jäänud muutumatuks, muudeti ainult juurutust.
Sobivatel masinatel (Linux, tavaline kasutaja võib kasutada , vaadake üksikasju) need käsud tõstavad üles klastri ja installivad PMEM-CSI draiveri:
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
Pärast seda, kui kõik töötab, sisaldab väljund juhiseid kasutamiseks:
Testiklastri on valmis. Logige sisse [...]/pmem-csi/_work/pmem-govm/ssh.0, käivitage
kubectl pärast sisselogimist. Alternatiivselt kasutage kubectl otse koos
järgiva keskkonnamuutujaga:
KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets loodud
secret/pmem-csi-node-secrets loodud
serviceaccount/pmem-csi-controller loodud
...
Proovige pmem-csi draiveri ajutisi mahuteid:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
CSIStorageCapacity objektid ei ole mõeldud inimeste lugemiseks, seega on vajalik mingi töötlemine. Golang'i malli filtrite abil kuvatakse ladustamisklassid, selles näites kuvatakse nimi, topoloogia ja maht:
$ 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
Eraldi objektil on järgmine sisu:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Name: csisc-sqdnt
Namespace: default
Labels:
Annotations:
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:
Proovime luua näidisrakendust koos ühe ajutise üldotstarbelise mahutiga. Faili sisu 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
Pärast loomist, nagu on näidatud ülaltoodud juhistes, saime me uue aluse ja 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
$ 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
PVC omanik — pod:
$ 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
...
Oodatakse uuendatud teavet 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
Kui teisel rakendusel peaks olema rohkem kui 26620Mi, ei arvestata seda planeerimisel pmem-csi-pmem-govm-worker1 iga hinnaga.
Mis edasi?
Mõlemad funktsioonid on endiselt töös. Alpha-testimise käigus on avatud mitmeid piletid. Parenduste ettepanekute kaudu tehtud töö dokumenteerimist hoitakse, et liikuda beta-faasi, samuti on analüüsitud ja tagasi lükatud alternatiive:
Allikas: habr.com
