Hei Habr!
Vă reamintim că am mai lansat un altul extrem de interesant și util despre modelele Kubernetes. Totul a început cu „„Brendan Burns și, apropo, avem de lucru în acest segment . Astăzi vă invităm să citiți un articol de pe blogul MinIO care prezintă pe scurt tendințele și specificul tiparelor de stocare a datelor în Kubernetes.
Kubernetes a schimbat fundamental modelele tradiționale de dezvoltare și implementare a aplicațiilor. Acum, o echipă poate dezvolta, testa și implementa o aplicație în câteva zile — în mai multe medii, toate în cadrul clusterelor Kubernetes. O astfel de muncă cu generațiile anterioare de tehnologie dura de obicei săptămâni, dacă nu luni.
Această accelerare este posibilă prin abstracția oferită de Kubernetes - adică pentru că Kubernetes însuși interacționează cu detaliile de nivel scăzut ale mașinilor fizice sau virtuale, permițând utilizatorilor să declare procesorul dorit, cantitatea dorită de memorie și numărul de containere. instanțe, printre alți parametri. Cu o comunitate uriașă care sprijină Kubernetes și adoptarea acestuia în continuă expansiune, Kubernetes este lider printre toate platformele de orchestrare a containerelor cu o marjă largă.
Pe măsură ce utilizarea Kubernetes crește, crește și confuzia cu privire la modelele sale de stocare..
Cu toată lumea concurând pentru o bucată din plăcinta Kubernetes (adică stocarea de date), când vine vorba de stocarea datelor, semnalul este înecat în mult zgomot.
Kubernetes întruchipează un model modern pentru dezvoltarea, implementarea și managementul aplicațiilor. Acest model modern decuplează stocarea datelor de calcul. Pentru a înțelege pe deplin detașarea în contextul Kubernetes, trebuie, de asemenea, să înțelegeți ce sunt aplicațiile cu stare și fără stat și cum se încadrează stocarea datelor în acestea. Aici abordarea REST API utilizată de S3 are avantaje clare față de abordarea POSIX/CSI a altor soluții.
În acest articol, vom vorbi despre modelele de stocare a datelor în Kubernetes și vom aborda în mod specific dezbaterea dintre aplicațiile stateful și stateless pentru a înțelege mai bine care este diferența dintre ele și de ce este importantă. Restul textului va analiza aplicațiile și modelele lor de stocare a datelor în lumina celor mai bune practici pentru lucrul cu containere și Kubernetes.
Containere apatride
Containerele sunt prin natura lor ușoare și efemere. Ele pot fi oprite, îndepărtate sau implementate cu ușurință pe un alt nod - totul în câteva secunde. Într-un sistem de orchestrare a containerelor mari, astfel de operațiuni au loc tot timpul, iar utilizatorii nici măcar nu observă astfel de modificări. Totuși, mișcările sunt posibile numai dacă containerul nu are nicio dependență de nodul pe care se află. Se spune că astfel de containere funcționează Fara stare.
Containere cu stat
Dacă un container stochează date pe dispozitive atașate local (sau pe un dispozitiv bloc), atunci depozitul de date pe care se află va trebui să fie mutat într-un nou nod, împreună cu containerul însuși, în cazul unei defecțiuni. Acest lucru este important deoarece, altfel, aplicația care rulează în container nu va putea funcționa corect, deoarece trebuie să acceseze datele stocate pe mediile locale. Se spune că astfel de containere funcționează cu stare.
Din punct de vedere pur tehnic, containerele stateful pot fi mutate și în alte noduri. Acest lucru se realizează de obicei folosind sisteme de fișiere distribuite sau blocare de stocare în rețea atașată la toate nodurile care rulează containere. În acest fel, containerele accesează volume pentru stocarea persistentă a datelor, iar informațiile sunt stocate pe discuri situate în întreaga rețea. Voi numi această metodă „abordarea containerizată cu stare„, iar în restul articolului îl voi numi așa de dragul uniformității.
Într-o abordare tipică de container cu stare, toate podurile de aplicație sunt atașate la un singur sistem de fișiere distribuit - un fel de stocare partajată în care se află toate datele aplicației. Deși sunt posibile unele variații, aceasta este o abordare la nivel înalt.
Acum haideți să vedem de ce abordarea containerului cu state este un anti-model într-o lume centrată pe cloud.
Design de aplicații native în cloud
În mod tradițional, aplicațiile foloseau baze de date pentru stocarea structurată a informațiilor și discuri locale sau sisteme de fișiere distribuite în care toate datele nestructurate sau chiar semi-structurate erau aruncate. Pe măsură ce volumul de date nestructurate a crescut, dezvoltatorii și-au dat seama că POSIX era prea discutabil, avea o suprasolicitare semnificativă și, în cele din urmă, a împiedicat performanța aplicațiilor atunci când se trecea la o scară cu adevărat mare.
Acest lucru a contribuit în principal la apariția unui nou standard pentru stocarea datelor, adică stocarea bazată pe cloud, care funcționează în principal pe baza API-ului REST și eliberează aplicația de întreținerea împovărătoare a unei stocări locale de date. În acest caz, aplicația intră efectiv în modul apatrid (deoarece starea este în stocare la distanță). Aplicațiile moderne sunt construite de la zero, având în vedere acest factor. De regulă, orice aplicație modernă care prelucrează date de un fel sau altul (jurnale, metadate, blob-uri etc.) este construită după o paradigmă orientată spre cloud, în care starea este transferată într-un sistem software special dedicat stocării sale.
Abordarea containerului cu state forțează toată această paradigmă să revină exact acolo unde a început!
Folosind interfețele POSIX pentru a stoca date, aplicațiile funcționează ca și cum ar fi stateful și, din această cauză, se îndepărtează de cele mai importante principii ale designului centrat pe cloud, adică capacitatea de a varia dimensiunea firelor de lucru ale aplicației în funcție de intrarea. input.load, treceți la un nou nod de îndată ce nodul curent eșuează și așa mai departe.
Aruncând o privire mai atentă la această situație, constatăm că atunci când alegem un depozit de date, ne confruntăm din nou și din nou cu dilema API POSIX vs. REST, DAR cu agravarea suplimentară a problemelor POSIX din cauza naturii distribuite a mediilor Kubernetes. În special,
- POSIX este vorbăreț: Semantica POSIX necesită ca fiecare operație să fie asociată cu metadate și descriptori de fișiere care ajută la menținerea stării operației. Acest lucru are ca rezultat costuri semnificative care nu au valoare reală. API-urile de stocare a obiectelor, în special API-ul S3, scapă de aceste cerințe, permițând aplicației să se declanșeze și apoi să „uite” de apel. Răspunsul sistemului de stocare indică dacă acțiunea a avut succes sau nu. Dacă nu reușește, aplicația poate încerca din nou.
- Restricții de rețea: Într-un sistem distribuit, se presupune că pot exista multe aplicații care încearcă să scrie date pe același suport atașat. Prin urmare, nu numai că aplicațiile vor concura între ele pentru lățimea de bandă de transfer de date (pentru a trimite date către medii), dar sistemul de stocare însuși va concura pentru această lățime de bandă prin trimiterea de date pe discuri fizice. Datorită locuinței POSIX, numărul apelurilor în rețea crește de mai multe ori. Pe de altă parte, API-ul S3 oferă o distincție clară între apelurile de rețea dintre cele care provin de la client către server și cele care apar în interiorul serverului.
- Безопасность: Modelul de securitate POSIX este conceput pentru participarea umană activă: administratorii configurează niveluri de acces specifice pentru fiecare utilizator sau grup. Această paradigmă este dificil de adaptat la o lume centrată pe cloud. Aplicațiile moderne depind de modelele de securitate bazate pe API, unde drepturile de acces sunt definite ca un set de politici, sunt alocate conturi de serviciu, acreditări temporare etc.
- controlabilitatea: Containerele cu stat au o anumită suprasarcină de gestionare. Vorbim despre sincronizarea accesului paralel la date, asigurarea coerenței datelor, toate acestea necesită o analiză atentă a tiparelor de acces la date pe care să le folosiți. Software-ul suplimentar trebuie instalat, monitorizat și configurat, ca să nu mai vorbim de efortul suplimentar de dezvoltare.
Interfață de stocare a datelor containerului
În timp ce Interfața de stocare a containerelor (CSI) a fost de mare ajutor cu proliferarea stratului de volum Kubernetes, externalizându-l parțial către furnizori de stocare terți, a contribuit, de asemenea, din neatenție la convingerea că abordarea containerului cu state este metoda recomandată pentru stocarea datelor în Kubernetes.
CSI a fost dezvoltat ca standard pentru furnizarea de sisteme arbitrare de stocare a fișierelor și blocurilor pentru aplicațiile vechi atunci când rulează pe Kubernetes. Și, așa cum a arătat acest articol, singura situație în care o abordare a containerului cu state (și CSI în forma sa actuală) are sens este atunci când aplicația în sine este un sistem moștenit în care nu este posibil să adăugați suport pentru API-ul de stocare a obiectelor. .
Este important de inteles ca folosind CSI in forma sa actuala, adica montand volume atunci cand lucram cu aplicatii moderne, vom intampina aproximativ aceleasi probleme care au aparut in sistemele in care stocarea datelor este organizata in stil POSIX.
O abordare mai bună
În acest caz, este important de înțeles că majoritatea aplicațiilor nu sunt concepute în mod inerent special pentru lucru cu stat sau fără stat. Acest comportament depinde de arhitectura generală a sistemului și de alegerile specifice de proiectare făcute. Să vorbim puțin despre aplicațiile stateful.
În principiu, toate datele aplicației pot fi împărțite în mai multe tipuri mari:
- Date de jurnal
- Date de marcaj de timp
- Date despre tranzacții
- Metadate
- Imagini de containere
- Date blob (obiect binar mare).
Toate aceste tipuri de date sunt foarte bine acceptate pe platformele moderne de stocare și există mai multe platforme native din cloud, adaptate pentru a furniza date în fiecare dintre aceste formate specifice. De exemplu, datele și metadatele tranzacțiilor pot locui într-o bază de date modernă nativă în cloud, cum ar fi CockroachDB, YugaByte etc. Imaginile containerului sau datele blob pot fi stocate într-un registru docker bazat pe MinIO. Datele de marcare temporală pot fi stocate într-o bază de date cu serii temporale, cum ar fi InfluxDB etc. Nu vom intra în detaliu despre fiecare tip de date și aplicațiile sale asociate aici, dar ideea generală este de a evita stocarea persistentă a datelor care se bazează pe montarea discului local.
În plus, este adesea eficient să se furnizeze un strat temporar de cache care să servească drept depozit de fișiere temporare pentru aplicații, dar aplicațiile nu ar trebui să depindă de acest strat ca sursă a adevărului.
Stocare cu stat pentru aplicații
În timp ce în cele mai multe cazuri este util să păstrați aplicațiile apatride, acele aplicații care sunt concepute pentru a stoca date - cum ar fi baze de date, depozite de obiecte, depozite cheie-valoare - trebuie să aibă stare. Să vedem de ce aceste aplicații sunt implementate pe Kubernetes. Să luăm MinIO ca exemplu, dar principii similare se aplică oricărui alt sistem mare de stocare nativ în cloud.
Aplicațiile cloud-native sunt concepute pentru a profita din plin de flexibilitatea inerentă containerelor. Aceasta înseamnă că nu fac presupuneri cu privire la mediul în care vor fi desfășurați. De exemplu, MinIO folosește un mecanism intern de codare de ștergere pentru a oferi sistemului suficientă rezistență pentru a rămâne operațional chiar dacă jumătate dintre discuri eșuează. De asemenea, MinIO gestionează integritatea și securitatea datelor folosind hashing și criptare proprietare pe partea de server.
Pentru astfel de aplicații centrate pe cloud, volumele locale persistente (PV) sunt cele mai convenabile ca stocare de rezervă. PV local oferă capacitatea de a stoca date brute, în timp ce aplicațiile care rulează peste aceste PV colectează în mod independent informații pentru a scala datele și pentru a gestiona cerințele tot mai mari de date.
Această abordare este mult mai simplă și semnificativ mai scalabilă decât PV-urile bazate pe CSI, care introduc propriile straturi de gestionare a datelor și redundanță în sistem; Ideea este că aceste straturi de obicei intră în conflict cu aplicațiile concepute pentru a fi stateful.
O mișcare puternică către decuplarea datelor de calcule
În acest articol, am vorbit despre modul în care aplicațiile sunt reorientate pentru a funcționa fără a salva starea sau, cu alte cuvinte, stocarea datelor este decuplată de calcularea pe ele. În concluzie, să ne uităm la câteva exemple reale ale acestei tendințe.
, o platformă proeminentă de analiză a datelor, a fost în mod tradițional cu stare și implementată pe HDFS. Cu toate acestea, pe măsură ce Spark se mută într-o lume centrată pe cloud, platforma este din ce în ce mai folosită fără stat folosind `s3a`. Spark folosește s3a pentru a transfera starea către alte sisteme, în timp ce containerele Spark în sine funcționează complet fără stat. Alți jucători majori ai întreprinderilor în domeniul analizei de date mari, în special, , , Ei trec, de asemenea, să lucreze cu separarea stocării datelor și calculele pe acestea.
Modele similare pot fi văzute și pe alte platforme analitice mari, inclusiv Presto, Tensorflow to R, Jupyter. Prin descărcarea stării în sistemele de stocare în cloud la distanță, devine mult mai ușor să gestionați și să scalați aplicația dvs. În plus, facilitează portabilitatea aplicației într-o varietate de medii.
Sursa: www.habr.com