Unele aplicații trebuie, de asemenea, să stocheze date, dar sunt destul de confortabile cu faptul că datele nu vor fi salvate după o repornire.
De exemplu, serviciile de stocare în cache sunt limitate de RAM, dar pot, de asemenea, să mute date care sunt rareori utilizate în stocarea mai lentă decât RAM, cu un impact redus asupra performanței generale. Alte aplicații trebuie să fie conștiente de faptul că în fișiere pot fi introduse doar citire, cum ar fi setările sau cheile secrete.
Kubernetes are deja mai multe tipuri , dar funcționalitatea lor este limitată la ceea ce este implementat în K8-uri.
Efemer a permis extinderea lui Kubernetes cu drivere CSI pentru a oferi suport pentru volume locale ușoare. În acest fel este posibil să se utilizeze : setări, secrete, date de identificare, variabile și așa mai departe. Driverele CSI trebuie modificate pentru a suporta această caracteristică Kubernetes, deoarece se presupune că driverele standardizate obișnuite nu vor funcționa - dar se presupune că astfel de volume pot fi utilizate pe orice nod selectat pentru pod.
Aceasta poate fi o problemă pentru volumele care consumă resurse de gazdă semnificative sau pentru stocarea care este disponibilă numai pe unele gazde. De aceea, Kubernetes 1.19 introduce două noi funcții de testare alfa, care sunt similare conceptual cu volumele EmptyDir:
-
volume efemere de uz general;
-
Urmărirea capacității de stocare CSI.
Avantajele noii abordări:
-
stocarea poate fi locală sau conectată printr-o rețea;
-
volumele pot avea o dimensiune specificată care nu poate fi depășită de aplicație;
-
funcționează cu orice driver CSI care acceptă furnizarea de volume persistente și (pentru a sprijini urmărirea capacității) implementează apelul
GetCapacity; -
volumele pot avea unele date inițiale în funcție de driver și setări;
-
sunt acceptate toate operațiunile standard cu un volum (crearea unui instantaneu, redimensionare etc.);
-
volumele pot fi utilizate cu orice controler de aplicație care acceptă o specificație de modul sau volum;
-
Programatorul Kubernetes selectează singur nodurile potrivite, astfel încât nu mai este nevoie să furnizați și să configurați extensii de planificator sau să modificați webhook-urile.
Opțiuni de aplicare
Prin urmare, volumele efemere de uz general sunt potrivite pentru următoarele cazuri de utilizare:
Memorie persistentă ca înlocuitor pentru RAM pentru memcache
Ultimele versiuni ale memcached folosind memorie persistentă (Intel Optane etc., aproximativ traducător) în loc de RAM obișnuită. Când implementați memcached printr-un controler de aplicație, puteți utiliza volume efemere de uz general pentru a solicita ca un volum de o anumită dimensiune să fie alocat de la PMEM utilizând driverul CSI, de exemplu .
Stocare locală LVM ca spațiu de lucru
Aplicațiile care funcționează cu date mai mari decât RAM pot necesita stocare locală cu o dimensiune sau valori de performanță pe care volumele EmptyDir obișnuite de la Kubernetes nu le pot oferi. De exemplu, în acest scop a fost scris .
Acces numai în citire pentru volume de date
Alocarea unui volum poate duce la crearea unui volum complet atunci când:
-
restaurare ;
-
creare ;
-
lucru .
Aceste volume pot fi montate în modul numai citire.
Cum funcționează
Volume efemere de uz general
O caracteristică cheie a volumelor efemere de uz general este noua sursă de volum, EphemeralVolumeSource, care conține toate câmpurile pentru a crea o cerere de volum (denumită istoric cerere de volum persistentă, PVC). Controler nou în kube-controller-manager se uită la păstăile care creează o astfel de sursă de volum și apoi creează un PVC pentru acele păstăi. Pentru driverul CSI, această solicitare arată la fel cu celelalte, deci nu este nevoie de suport special aici.
Atâta timp cât există astfel de PVC-uri, ele pot fi folosite ca orice alte solicitări pe volum. În special, ele pot fi referite ca sursă de date atunci când se copiază un volum sau se creează un instantaneu dintr-un volum. Obiectul din PVC conține și starea curentă a volumului.
Numele PVC-urilor create automat sunt predefinite: sunt o combinație între numele podului și numele volumului, separate printr-o cratimă. Numele predefinite facilitează interacțiunea cu PVC-ul, deoarece nu trebuie să îl căutați dacă cunoașteți numele podului și numele volumului. Dezavantajul este că numele poate fi deja în uz, care este detectat de Kubernetes și, ca urmare, podul este blocat de la pornire.
Pentru a se asigura că volumul este șters împreună cu podul, controlerul face o cerere către volumul aflat sub proprietar. Când podul este șters, funcționează mecanismul standard de colectare a gunoiului, care șterge atât cererea, cât și volumul.
Cererile sunt potrivite de driverul de stocare prin mecanismul normal al clasei de stocare. Deși clase cu legare imediată și târzie (alias WaitForFirstConsumer) sunt suportate, pentru volumele efemere are sens să se folosească WaitForFirstConsumer, atunci planificatorul poate lua în considerare atât utilizarea nodului, cât și disponibilitatea stocării atunci când selectează un nod. O nouă caracteristică apare aici.
Urmărirea capacității de stocare
De obicei, programatorul nu cunoaște unde va crea volumul driverul CSI. De asemenea, nu există nicio modalitate ca programatorul să contacteze direct șoferul pentru a solicita aceste informații. Prin urmare, planificatorul sondajează nodurile până când găsește unul pe care volumele pot fi accesate (legare târzie) sau lasă alegerea locației în întregime la latitudinea driverului (legare imediată).
Nou CSIStorageCapacity, care se află în stadiul alfa, permite stocarea datelor necesare în etcd, astfel încât să fie disponibile pentru planificator. Spre deosebire de suportul pentru volume efemere de uz general, atunci când implementați driverul, trebuie să activați urmărirea capacității de stocare: external-provisioner ar trebui să publice informațiile de capacitate primite de la șofer prin normal GetCapacity.
Dacă programatorul trebuie să selecteze un nod pentru un pod cu un volum nelegat care folosește legarea tardivă, iar driverul a activat această caracteristică în timpul implementării setând marcajul CSIDriver.storageCapacity, atunci nodurile care nu au suficientă capacitate de stocare vor fi eliminate automat. Acest lucru funcționează atât pentru volume efemere de uz general, cât și pentru volume persistente, dar nu și pentru volumele efemere CSI, deoarece parametrii lor nu pot fi citiți de Kubernetes.
Ca de obicei, volumele conectate imediat sunt create înainte ca podurile să fie programate, iar plasarea lor este aleasă de driverul de stocare, deci atunci când se configurează external-provisioner În mod implicit, clasele de stocare cu legare imediată sunt omise, deoarece aceste date nu vor fi folosite oricum.
Deoarece programatorul kubernetes este forțat să lucreze cu informații potențial învechite, nu există nicio garanție că capacitatea va fi disponibilă în fiecare caz atunci când este creat volumul, dar șansele ca acesta să fie creat fără reîncercări sunt totuși crescute.
NB Puteți obține informații mai detaliate, precum și „exersa pe standul pentru pisici” în siguranță, iar în cazul unei situații complet de neînțeles, primiți asistență tehnică calificată la cursuri intensive - va avea loc în perioada 28-30 septembrie, iar pentru specialiștii mai avansați 14–16 octombrie.
Безопасность
CSISstorageCapacity
Obiectele CSIStorageCapacity se află în spații de nume; atunci când lansați fiecare driver CSI în propriul spațiu de nume, este recomandat să restricționați drepturile RBAC la CSIStorageCapacity în spațiul respectiv, deoarece este evident de unde provin datele. Kubernetes oricum nu verifică acest lucru și, de obicei, driverele sunt plasate în același spațiu de nume, așa că în cele din urmă se așteaptă ca driverele să funcționeze și să nu publice date incorecte (și aici a eșuat cardul meu, aproximativ traducător bazat pe o glumă cu barbă)
Volume efemere de uz general
Dacă utilizatorii au drepturi de a crea un pod (direct sau indirect), aceștia vor putea, de asemenea, să creeze volume efemere de uz general, chiar dacă nu au drepturi de a crea o solicitare pe volum. Acest lucru se datorează faptului că verificările de permisiuni RBAC sunt aplicate controlerului care creează PVC-ul, nu utilizatorului. Aceasta este modificarea principală de adăugat , înainte de a activa această caracteristică pe clustere în care utilizatorii neîncrezători nu ar trebui să aibă drepturi de a crea volume.
Exemplu
Separa PMEM-CSI conține toate modificările necesare pentru a rula un cluster Kubernetes 1.19 în interiorul mașinilor virtuale QEMU cu toate caracteristicile din stadiul alfa. Codul șoferului nu s-a schimbat, s-a schimbat doar implementarea.
Pe o mașină adecvată (Linux, un utilizator normal poate folosi , uite detalii) aceste comenzi vor deschide clusterul și vor instala driverul 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
După ce totul funcționează, rezultatul va conține instrucțiuni de utilizare:
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 -
Obiectele CSIStorageCapacity nu sunt menite să fie citite de oameni, așa că este necesară o anumită prelucrare. Filtrele șablonului Golang vor afișa clasele de stocare, acest exemplu va afișa numele, topologia și capacitatea:
$ 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
Un singur obiect are următorul conținut:
$ 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>
Să încercăm să creăm o aplicație demo cu un singur volum efemer de uz general. Conținutul fișierului 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
După crearea, așa cum se arată în instrucțiunile de mai sus, avem acum un pod suplimentar și 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
Proprietar PVC - sub:
$ 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
...
Informații actualizate așteptat pentru 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
Dacă o altă aplicație are nevoie de mai mult de 26620Mi, programatorul nu va ține cont pmem-csi-pmem-govm-worker1 în orice caz.
Ce urmeaza?
Ambele caracteristici sunt încă în dezvoltare. Mai multe aplicații au fost deschise în timpul testării alfa. Legăturile de propunere de îmbunătățire documentează munca care trebuie făcută pentru a trece la etapa beta, precum și alternativele care au fost deja luate în considerare și respinse:
Sursa: www.habr.com