🥇Volume efemere cu monitorizarea capacității de stocare: EmptyDir pe steroizi

Unele aplicații au nevoie, de asemenea, să stocheze date, dar acestea sunt destul de relaxate în privința faptului că datele nu vor fi salvate după repornire.

De exemplu, serviciile de cache sunt restricționate de memoria operativă, dar pot transfera, de asemenea, date care sunt rar utilizate către un stocare care funcționează mai lent decât memoria operativă, cu un impact mic asupra performanței generale. Alte aplicații trebuie să știe că fișierele pot conține unele date de intrare doar pentru citire, cum ar fi setările sau cheile secrete.

În Kubernetes există deja câteva tipuri de volume efemere,dar funcționalitatea lor este limitată la ceea ce este implementat în K8s.

Volumele efemere CSI au permis extinderea Kubernetes-ului cu drivere CSI pentru a oferi suport pentru volume locale ușoare. Astfel este posibil să se aplice structuri arbitrare: configurații, secrete, date de identificare, variabile etc. Driverele CSI trebuie să fie actualizate pentru a suporta această funcționalitate a Kubernetes-ului, deoarece se așteaptă că driverele standardizate obișnuite nu vor funcționa - dar se așteaptă ca aceste volume să poată fi utilizate pe orice nod ales pentru pod.

Aceasta poate deveni o problemă pentru volumele care consumă semnificativ resursele nodului sau pentru stocarea disponibilă doar pe anumite noduri. De aceea, în Kubernetes 1.19 sunt introduse două noi funcții de volume pentru testarea alfa, conceptualmente similare cu volumele EmptyDir:

volume efemere de uz general;
monitorizarea capacității stocării CSI.

Avantajele noii abordări:

stocarea poate fi locală sau conectată prin rețea;
volumele pot avea o dimensiune fixă, care nu poate fi depășită de aplicație;
funcționează cu orice drivere CSI care suportă furnizarea de volume persistente și (pentru a susține monitorizarea capacității) implementează apelul GetCapacity;;
volumele pot avea date inițiale care depind de driver și parametrii;
toate operațiunile standard cu volume (crearea de instantanee, redimensionarea etc.) sunt acceptate;
volumele pot fi utilizate cu orice controler de aplicații care acceptă specificația unui modul sau a unui volum;
Planificatorul Kubernetes alege nodurile potrivite, așa că nu mai trebuie să asigurați și să configurați extensiile planificatorului și să modificați webhooks.

Opțiuni de utilizare

Astfel, volumele efemere de tip general sunt potrivite pentru următoarele opțiuni de utilizare:

Memorie permanentă ca înlocuitor pentru memoria RAM pentru memcached.

Cele mai recente versiuni memcached au adăugat suport pentru utilizarea memoriei permanente (Intel Optane etc., nota traducătorului) în loc de memoria RAM obișnuită. Atunci când se desfășoară memcached prin intermediul unui controler de aplicații, se poate solicita un volum de dimensiune specificată din PMEM prin intermediul driverului CSI, de exemplu, PMEM-CSI..

Stocare locală LVM ca spațiu de lucru.

Aplicațiile care lucrează cu date al căror volum depășește memoria RAM pot solicita stocare locală cu dimensiuni sau metrici de performanță pe care volumele obișnuite EmptyDir din Kubernetes nu le pot oferi. De exemplu, pentru această destinație a fost scris TopoLVM..

Acces doar în citire pentru volumele cu date.

Alocarea unui volum poate duce la crearea unui volum complet în următoarele situații:

recuperare a unui instantaneu de volum.;
crearea unei copii a volumului.;
de umpluturi de date..

Aceste volume pot fi montate în modul doar pentru citire.

Cum funcționează

Volume efemere de tip general.

O caracteristică cheie a volumelor efemere de tip general este noua sursă de volum, EphemeralVolumeSource, care conține toate câmpurile necesare pentru a crea o cerere pentru volum (istoric, aceasta se numea cerere pentru volum permanent, PVC). Noua controler în kube-controller-manager analizează modulele care creează o astfel de sursă de volum și apoi creează PVC pentru aceste module. Pentru driverul CSI, această cerere arată ca toate celelalte, așa că nu este necesară o suport special aici.

Atâta timp cât aceste PVC-uri există, se pot utiliza ca orice alte cereri de volum. În special, ele pot fi referite ca sursă de date atunci când se copiază un volum sau se creează un instantaneu din volum. Obiectul PVC conține, de asemenea, starea curentă a volumului.

Numele PVC-urilor create automat sunt predefinite: este o combinație între numele podului și numele volumului, separate printr-o cratimă. Predefinirea numelui facilitează interacțiunea cu PVC-ul, deoarece nu trebuie căutat, dacă se știe numele podului și numele volumului. Dezavantajul este că numele ar putea fi deja folosit, ceea ce este detectat de Kubernetes și, ca urmare, lansarea podului este blocată.

Pentru a te asigura că volumul este șters împreună cu podul, controlerul face din pod proprietarul cererii pentru volum. Când podul este șters, se activează mecanismul standard de curățare, care șterge atât cererea, cât și volumul.

Cererile sunt asociate cu driver-ul de stocare printr-un mecanism standard de clasă de stocare. Deși clasele cu asociere imediată și întârziată (denumite și WaitForFirstConsumer) sunt acceptate, pentru volume efemere are sens să folosești WaitForFirstConsumer, astfel încât planificatorul să poată lua în considerare atât utilizarea nodului, cât și disponibilitatea stocării la alegerea nodului. Aici apare o nouă funcție.

Monitorizarea capacității de stocare

De obicei, planificatorul nu are informații despre unde driver-ul CSI va crea volumul. De asemenea, planificatorul nu are capacitatea de a se conecta direct la driver pentru a solicita aceste informații. Prin urmare, planificatorul interoghează nodurile până când găsește unul pe care volumele pot fi disponibile (asociere întârziată), sau lasă complet alegerea locului în seama driver-ului (asociere imediată).

Un nou API CSIStorageCapacity, aflat în stadiul alpha, permite stocarea datelor necesare în etcd, astfel încât acestea să fie accesibile planificatorului. Spre deosebire de suportul pentru volume efemere de uz general, la implementarea driver-ului trebuie activată monitorizarea capacității de stocare: external-provisioner trebuie să publice informații despre capacitate, obținute de la driver printr-o GetCapacity;.

Dacă planificatorului trebuie să aleagă un nod pentru un pod cu volum neasociat, folosind asocierea întârziată, iar driver-ul a activat această funcție la implementare, stabilind flag-ul CSIDriver.storageCapacity, nodurile care nu au suficientă capacitate de stocare vor fi eliminate automat. Aceasta funcționează atât pentru volumele efemere de uz general, cât și pentru volumele permanente, dar nu pentru volumele CSI efemere, deoarece parametrii lor nu pot fi citiți de Kubernetes.

Ca de obicei, volumele cu legături imediate sunt create înainte de planificarea podurilor, iar amplasarea acestora este aleasă de driverul de stocare, așa că la configurare external-provisioner din default se sar peste clasele de stocare cu legături imediate, deoarece aceste date nu vor fi folosite oricum.

Deoarece planificatorul Kubernetes este obligat să lucreze cu informații care ar putea fi depășite, nu există garanții că capacitatea va fi disponibilă în orice moment când volumul va fi creat, însă, totuși, șansele ca el să fie creat fără încercări repetate cresc.

N.B. Informații mai detaliate puteți obține, precum și să „exersați” în siguranță pe un stand de teste, iar în cazul unei situații complet neclare, să obțineți ajutor calificat din partea suportului tehnic la seminarii - Kubernetes Baza se va desfășura între 28-30 septembrie, iar pentru specialiștii mai avansați Kubernetes Mega 14–16 octombrie.

Securitate

CSIStorageCapacity

Obiectele CSIStorageCapacity se află în namespace-uri, la desfășurarea fiecărui driver CSI în propriul său namespace este recomandat să se limiteze drepturile RBAC pentru CSIStorageCapacity în acel spațiu, deoarece este evident de unde provin datele. Oricum, Kubernetes nu verifică asta, iar de obicei, driverii sunt instalați într-un singur namespace, așa că, în cele din urmă, se așteaptă ca driverii să funcționeze și să nu publice date incorecte (și aici mi-a ieșit harta, nota traductorului pe baza unei glume cunoscute)

Volume efemere de tip general.

Dacă utilizatorii au drepturi de a crea un pod (direct sau indirect) - ei vor putea, de asemenea, să creeze volume efemere de utilizare generală chiar și dacă nu au drepturi de a crea o cerere pentru volum. Asta se datorează faptului că verificările drepturilor RBAC se aplică controlerului care creează PVC, nu utilizatorului. Aceasta este modificarea principală care trebuie adăugată la contul, înainte de a activa această funcție în clustere, dacă utilizatorii nesiguri nu ar trebui să aibă drepturi de a crea volume.

Exemplu

Separat discuție în PMEM-CSI conține toate modificările necesare pentru a lansa un cluster Kubernetes 1.19 în interiorul mașinilor virtuale QEMU cu toate funcțiile aflate în stadiul alpha. Codul driverului nu a fost modificat, doar desfășurarea.

Pe o mașină adecvată (Linux, utilizator obișnuit poate folosi Docker, consultați aici detaliile) aceste comenzi vor ridica 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 a funcționat, output-ul va conține instrucțiuni pentru utilizare:

Clusterul de test este pregătit. Conectați-vă cu [...]\/pmem-csi\/\_work\/pmem-govm\/ssh.0, rulați
kubectl odată ce v-ați conectat. Alternativ, utilizați kubectl direct cu următoarea variabilă de mediu:
   KUBECONFIG=[...]\/pmem-csi\/\_work\/pmem-govm\/kube.config

secret\/pmem-csi-registry-secrets creat
secret\/pmem-csi-node-secrets creat
serviceaccount\/pmem-csi-controller creat
...
Pentru a testa volumul efemer al driverului pmem-csi:
   cat deploy\/kubernetes-1.19\/pmem-app-ephemeral.yaml |
   [...]\/pmem-csi\/\_work\/pmem-govm\/ssh.0 kubectl create -f -

Obiectele CSIStorageCapacity nu sunt destinate citirii de către oameni, așa că este necesară o anumită procesare. Prin utilizarea filtrelor de șablon pe Golang vor fi afișate clasele de stocare, în acest exemplu vor fi afișate 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 obiect separat are următorul conținut:

$ kubectl describe csistoragecapacities\/csisc-6cw8j
Nume:         csisc-sqdnt
Namespace:    default
Etichete:      
Anotări:      
Versiune API:  storage.k8s.io\/v1alpha1
Capacitate:     30716Mi
Tip:         CSIStorageCapacity
Metadata:
  Timpul de creare:  2020-08-11T15:41:03Z
  Nume generat:       csisc-
  Câmpuri gestionate:
    ...
  Referințe proprietar:
    Versiune API:     apps\/v1
    Controler:      true
    Tip:            StatefulSet
    Nume:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Versiune resursă:  2994
  Link de sine:         \/apis\/storage.k8s.io\/v1alpha1\/namespaces\/default\/csistoragecapacities\/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Topologia nodului:
  Etichete de potrivire:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Numele clasei de stocare:           pmem-csi-sc-late-binding
Evenimente:

Haideți să încercăm să creăm o aplicație demo cu un volum efemer 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 este arătat în instrucțiunile de mai sus, am obținut un pod suplimentar și un PVC:

$ kubectl get pods\/my-csi-app-inline-volume -o wide
NUME                       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

Proprietarul PVC este podul:

$ 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țiile 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 va necesita mai mult de 26620Mi, programatorul nu va lua în considerare pmem-csi-pmem-govm-worker1 în niciun scenariu.

Ce urmează?

Ambele funcții sunt încă în dezvoltare. Au fost deschise mai multe cereri în timpul testării alpha. Documentația este realizată pe baza propunerilor de îmbunătățire, ceea ce trebuie făcut pentru a trece la stadiul beta, precum și ce alternative au fost deja analizate și respinse:

Sursa: habr.com