Există mai multe moduri de a configura stocarea datelor pentru aplicațiile care rulează pe un cluster Kubernetes. Unele dintre ele sunt deja depășite, altele au apărut destul de recent. În acest articol, vom analiza conceptul a trei opțiuni pentru conectarea sistemelor de stocare, inclusiv cea mai recentă - conectarea prin interfața de stocare container.
Metoda 1: specificați PV în manifestul pod
Un manifest tipic care descrie un pod dintr-un cluster Kubernetes:
Părțile manifestului care descriu ce volum este conectat și unde sunt evidențiate color.
În secțiunea volumMonturi indicați punctele de montare (mountPath) - în ce director din interiorul containerului va fi montat volumul permanent, precum și numele volumului.
În secțiunea x listează toate volumele care sunt utilizate în pod. Specificați numele fiecărui volum, precum și tipul (în cazul nostru: awsElasticBlockStore) și parametrii de conexiune. Cei parametri sunt listați în manifest depind de tipul de volum.
Același volum poate fi montat simultan în mai multe containere pentru pod. În acest fel, diferite procese de aplicare pot accesa aceleași date.
Această metodă de conectare a fost inventată chiar de la început, când Kubernetes era abia la început, iar astăzi metoda este depășită.
Există mai multe probleme când îl utilizați:
- toate volumele trebuie create manual; Kubernetes nu poate crea nimic pentru noi;
- parametrii de acces pentru fiecare volum sunt unici și trebuie specificați în manifestele tuturor podurilor care utilizează volumul;
- pentru a schimba sistemul de stocare (de exemplu, trece de la AWS la Google Cloud), trebuie să modificați setările și tipul de volume montate în toate manifestele.
Toate acestea sunt foarte incomod, așa că, în realitate, această metodă este folosită pentru a conecta doar câteva tipuri speciale de volume: configMap, secret, emptyDir, hostPath:
-
configMap și secret sunt volume de servicii care vă permit să creați un volum cu fișiere din manifestele Kubernetes în container.
-
emptyDir este un volum temporar, creat doar pentru durata de viață a podului. Convenabil de utilizat pentru testarea sau stocarea datelor temporare. Când un pod este șters, volumul emptyDir este, de asemenea, șters și toate datele sunt pierdute.
-
hostPath - vă permite să montați orice director pe discul local al serverului pe care rulează aplicația în interiorul containerului cu aplicația, inclusiv /etc/kubernetes. Aceasta este o caracteristică nesigură, așa că politicile de securitate interzic de obicei utilizarea acestui tip de volum. În caz contrar, aplicația unui atacator va putea să monteze directorul HTC Kubernetes în interiorul containerului său și să fure toate certificatele de cluster. De obicei, volumele hostPath pot fi utilizate numai de aplicațiile de sistem care rulează în spațiul de nume kube-system.
sunt date în documentație.
Metoda 2. Conectarea la focare SC/PVC/PV
O metodă alternativă de conectare este conceptul de clasă de stocare, PersistentVolumeClaim, PersistentVolume.
Clasa de depozitare stochează parametrii de conectare la sistemul de stocare a datelor.
PersistentVolumeClaim descrie cerințele pentru ceea ce are nevoie aplicația.
Volumul persistent stochează parametrii de acces și starea volumului.
Esența ideii: în manifestul pod indică un volum de tip PersistentVolumeClaim și indică numele acestei entități în parametrul claimName.
Manifestul PersistentVolumeClaim descrie cerințele pentru volumul de date pe care le solicită aplicația. Inclusiv:
- dimensiunea discului;
- metoda de acces: ReadWriteOnce sau ReadWriteMany;
- link la clasa de stocare - în care sistem de stocare a datelor dorim să creăm volumul.
Manifestul clasei de stocare stochează tipul și parametrii conexiunii la sistemul de stocare. Cubetul are nevoie de ele pentru a monta volumul pe nodul său.
Manifestele PersistentVolume indică clasa de stocare și parametrii de acces pentru un anumit volum (ID volum, cale etc.).
Când creează un PVC, Kubernetes analizează ce dimensiune volum și ce clasă de stocare este necesară și selectează un PersistentVolume gratuit.
Dacă astfel de PV nu sunt disponibile, Kubernetes poate lansa un program special - Provisioner (numele acestuia este indicat în clasa Stocare). Acest program se conectează la sistemul de stocare, creează un volum de dimensiunea necesară, primește un identificator și creează un manifest PersistentVolume în clusterul Kubernetes, care este asociat cu PersistentVolumeClaim.
Tot acest set de abstracții vă permite să eliminați informații despre sistemul de stocare cu care lucrează aplicația de la nivelul manifestului aplicației până la nivelul de administrare.
Toți parametrii pentru conectarea la sistemul de stocare a datelor se află în clasa Storage, de care sunt responsabili administratorii clusterului. Tot ce trebuie să faceți când treceți de la AWS la Google Cloud este să schimbați numele clasei de stocare în PVC în manifestele aplicației. Volumul de persistență pentru stocarea datelor va fi creat automat în cluster folosind programul Provisioner.
Metoda 3: Interfața de depozitare a containerelor
Tot codul care interacționează cu diverse sisteme de stocare face parte din nucleul Kubernetes. Lansarea remedierii erorilor sau a noilor funcționalități este legată de noile versiuni; codul trebuie schimbat pentru toate versiunile Kubernetes acceptate. Toate acestea sunt greu de întreținut și de a adăuga noi funcționalități.
Pentru a rezolva problema, dezvoltatorii de la Cloud Foundry, Kubernetes, Mesos și Docker au creat Container Storage Interface (CSI) - o interfață simplă unificată care descrie interacțiunea sistemului de management al containerului și un driver special (CSI Driver) care funcționează cu un anumit sistem de stocare. Tot codul pentru interacțiunea cu sistemele de stocare a fost mutat din nucleul Kubernetes într-un sistem separat.
.
De obicei, CSI Driver constă din două componente: Node Plugin și Controller plugin.
Node Plugin rulează pe fiecare nod și este responsabil pentru montarea volumelor și efectuarea operațiunilor asupra acestora. Pluginul Controller interacționează cu sistemul de stocare: creează sau șterge volume, atribuie drepturi de acces etc.
Deocamdată, vechile drivere rămân în kernel-ul Kubernetes, dar nu mai sunt recomandate a fi folosite și toată lumea este sfătuită să instaleze Driver-ul CSI special pentru sistemul cu care vor lucra.
Inovația îi poate speria pe cei care sunt deja obișnuiți să configureze stocarea datelor prin clasa de stocare, dar de fapt nu s-a întâmplat nimic groaznic. Pentru programatori, nimic nu se schimbă cu adevărat - au lucrat doar cu numele Clasă de stocare și vor continua să facă acest lucru. Pentru administratori, a fost adăugată instalarea diagramei de conducere și structura setărilor s-a schimbat. Dacă anterior setările erau introduse direct în clasa de stocare, acum trebuie setate mai întâi în diagrama de conducere, apoi în clasa de stocare. Dacă te uiți la asta, nu s-a întâmplat nimic rău.
Să luăm un exemplu pentru a vedea beneficiile pe care le puteți obține trecând la conectarea sistemelor de stocare Ceph folosind driverul CSI.
Când lucrați cu Ceph, pluginul CSI oferă mai multe opțiuni pentru lucrul cu sistemele de stocare decât driverele încorporate.
- Crearea dinamică a discurilor. De obicei, discurile RBD sunt utilizate numai în modul RWO, dar CSI pentru Ceph le permite să fie utilizate în modul RWX. Mai multe pod-uri de pe noduri diferite pot monta același disc RDB pe nodurile lor și pot lucra cu ele în paralel. Pentru a fi corect, nu totul este atât de luminos - acest disc poate fi conectat doar ca dispozitiv bloc, ceea ce înseamnă că va trebui să adaptați aplicația pentru a lucra cu ea în modul de acces multiplu.
- Crearea de instantanee. Într-un cluster Kubernetes, puteți crea un manifest cu cerința de a crea un instantaneu. Pluginul CSI îl va vedea și va face un instantaneu de pe disc. Pe baza acestuia, puteți face fie o copie de rezervă, fie o copie a PersistentVolume.
- Creșterea dimensiunii discului pe stocare și PersistentVolume în clusterul Kubernetes.
- Cote. Driverele CephFS încorporate în Kubernetes nu acceptă cote, dar pluginurile CSI noi cu cel mai recent Ceph Nautilus pot activa cote pe partițiile CephFS.
- Metrici. Pluginul CSI poate oferi lui Prometheus o varietate de metrici despre volumele conectate, ce comunicări au loc etc.
- Conștient de topologie. Vă permite să specificați în manifeste modul în care clusterul este distribuit geografic și să evitați conectarea unui sistem de stocare situat în Amsterdam la podurile care rulează în Londra.
Cum se conectează Ceph la un cluster Kubernetes prin CSI, vezi . De asemenea, vă puteți abona la , care se va lansa pe 15 octombrie.
Autorul articolului: Sergey Bondarev, arhitect practicant la Southbridge, Certified Kubernetes Administrator, unul dintre dezvoltatorii kubespray.
Puțin Post Scriptum nu pentru publicitate, ci pentru beneficii...
PS Sergey Bondarev conduce două cursuri intensive: actualizat 28-30 septembrie și avansat 14–16 octombrie.
Sursa: www.habr.com