Nota traducătorului.: acest material provine dintr-un proiect educațional — răspuns la o întrebare populară în proiectarea infrastructurii bazate pe Kubernetes. Sperăm că descrierile suficient de detaliate ale avantajelor și dezavantajelor fiecărei opțiuni vor ajuta la alegerea optimă și pentru proiectul dumneavoastră.
TL;DR: aceeași suită de sarcini de lucru poate fi rulată pe mai multe clustere mari (fiecare cluster având un număr mare de sarcini de lucru) sau pe multe clustere mici (cu un număr mic de sarcini în fiecare cluster).
Mai jos este un tabel în care sunt evaluate avantajele și dezavantajele fiecărei abordări:
Atunci când se folosește Kubernetes ca platformă pentru operarea aplicațiilor, apar adesea câteva întrebări fundamentale legate de nuanțele configurării clusterelor:
- Câte clustere să folosiți?
- Cât de mari să fie acestea?
- Ce ar trebui să conțină fiecare cluster?
În acest articol, voi încerca să răspund la toate aceste întrebări, analizând avantajele și dezavantajele fiecărei abordări.
Formularea problemei
Ca dezvoltator de software, este foarte probabil să dezvoltați și să operați în paralel mai multe aplicații.
În plus, mai multe instanțe ale acestor aplicații sunt probabil rulate în medii diferite — de exemplu, acestea pot fi dev, test și prod.
Ca rezultat, se formează o adevărată matrice de aplicații și medii:
Aplicații și medii
În exemplul de mai sus, sunt prezentate 3 aplicații și 3 medii, ceea ce oferă în total 9 variante posibile.
Fiecare instanță a aplicației reprezintă o unitate de deployment autonomă, cu care se poate lucra independent de altele.
Rețineți că instanța aplicației poate consta din mai multe componentelor, cum ar fi front-end, back-end, bază de date etc. În cazul aplicațiilor microservicii, instanța va include toate microserviciile.
Ca rezultat, utilizatorii Kubernetes au câteva întrebări:
- Ar trebui să plasați toate instanțele aplicației într-un singur cluster?
- Ar trebui să creați un cluster separat pentru fiecare instanță a aplicației?
- Sau, poate, ar trebui să utilizați o combinație a abordărilor menționate mai sus?
Toate aceste variante sunt pe deplin viabile, deoarece Kubernetes este un sistem flexibil care nu limitează utilizatorul în opțiuni.
Iată câteva dintre posibilitățile disponibile:
- un singur cluster mare comun;
- multe clustere mici specializate;
- un cluster pentru fiecare aplicație;
- un cluster pentru fiecare mediu.
După cum se arată mai jos, primele două abordări sunt la extremitățile opuse ale scalei opțiunilor:
De la câteva clustere mari (stânga) la multe mici (dreapta)
În general, se consideră că un cluster este „mai mare” decât altul dacă are un număr mai mare de noduri și pod-uri. De exemplu, un cluster cu 10 noduri și 100 pod-uri este mai mare decât un cluster cu 1 nod și 10 pod-uri.
Ei bine, să începem!
1. Un mare cluster comun
Prima opțiune - a plasa toate sarcinile de lucru într-un singur cluster:
Un mare cluster
În cadrul acestei abordări, clusterul este utilizat ca o platformă infrastructurală generală — tot ce ai nevoie, pur și simplu, desfășori în clusterul existent Kubernetes.
Kubernetes permite separarea logică a părților clusterului, astfel încât pentru fiecare instanță de aplicație să poți folosi propriul spațiu de nume.
Să analizăm avantajele și dezavantajele acestei abordări.
+ Utilizarea eficientă a resurselor
În cazul unui singur cluster, este necesară doar o copie a tuturor resurselor necesare pentru a rula și gestiona clusterul Kubernetes.
De exemplu, aceasta este valabilă pentru nodurile master. În general, pentru fiecare cluster Kubernetes există 3 noduri master, așa că pentru un singur cluster numărul acestora va rămâne același (spre comparație, 10 clustere vor necesită 30 noduri master).
Această subtilitate se aplică și altor servicii care funcționează la nivelul întregului cluster, cum ar fi echilibratoarele de sarcină, controlerele Ingress, sistemele de autentificare, înregistrare și monitorizare.
În cadrul unui singur cluster, toate aceste servicii pot fi folosite simultan pentru toate sarcinile de lucru (nu trebuie să creezi copii ale acestora, cum se întâmplă în cazul mai multor clustere).
+ Economie
Ca urmare a celor de mai sus, numărul mai mic de clustere se dovedește, de obicei, a fi mai ieftin, deoarece costurile cu resursele redundante sunt absente.
Acest lucru este cu atât mai adevărat pentru nodurile master, care pot costa sume considerabile indiferent de modul de implementare (on-premises sau în cloud).
Unele servicii gestionate Kubernetes, cum ar fi sau , furnizează un strat de gestionare gratuit. În acest caz, problema costurilor nu este atât de acută.
Există, de asemenea, servicii gestionate care percep o taxă fixă pentru fiecare cluster Kubernetes (de exemplu, ).
+ Administrare eficientă
Gestionarea unui singur cluster este mai simplă decât gestionarea mai multor.
Administrarea poate include următoarele sarcini:
- actualizarea versiunii Kubernetes;
- configurarea pipeline-ului CI/CD;
- instalarea pluginului CNI;
- configurarea sistemului de autentificare a utilizatorilor;
- instalarea unui controller de acces;
și multe altele…
În cazul unui singur cluster, toate acestea trebuie făcute o singură dată.
Pentru multiple clustere, operațiile trebuie repetate de mai multe ori, ceea ce probabil va necesita automatizarea proceselor și instrumentelor pentru a asigura sistematizarea și uniformitatea procesului.
Acum, câteva cuvinte despre dezavantaje.
− Punct unic de eșec
În cazul unei defecțiuni a singurului cluster, toate tot sarcinile de lucru se vor opri imediat!
Există multe scenarii în care ceva poate merge prost:
- actualizarea Kubernetes duce la efecte secundare neașteptate;
- componenta comună a clusterului (de exemplu, pluginul CNI) începe să funcționeze diferit față de așteptări;
- una dintre componentele clusterului este configurată greșit;
- defecțiune în infrastructura subiacente.
Un astfel de incident poate provoca daune severe tuturor sarcinilor de lucru găzduite în clusterul comun.
− Lipsește izolarea strictă
Funcționarea într-un cluster comun înseamnă că aplicațiile împărtășesc resurse hardware, capabilități de rețea și sistem de operare pe nodurile clusterului.
Într-un sens, două containere cu două aplicații diferite care rulează pe același nod sunt asemănătoare cu două procese care rulează pe aceeași mașină sub un singur nucleu de sistem de operare.
Containerele Linux oferă o formă de izolare, dar aceasta nu este la fel de puternică precum cea asigurată de, să spunem, mașinile virtuale. În esență, un proces dintr-un container este același proces care rulează în sistemul de operare gazdă.
Aceasta poate deveni o problemă din perspectiva securității: o astfel de organizare teoretic permite aplicațiilor nesolidare să interacționeze între ele (intenționat sau accidental).
În plus, toate sarcinile de lucru din clusterul Kubernetes folosesc împreună unele servicii comune de cluster, cum ar fi — acest lucru permite aplicațiilor să găsească servicii ale altor aplicații din cluster.
Toate punctele menționate anterior pot avea semnificații diferite în funcție de cerințele de securitate ale aplicațiilor.
Kubernetes oferă diverse instrumente pentru prevenirea problemelor de securitate, cum ar fi și . Cu toate acestea, pentru configurarea lor corectă este necesară o anumită experiență, în plus, ele nu pot închide toate vulnerabilitățile de securitate.
Este important să ne amintim întotdeauna că Kubernetes a fost conceput inițial pentru partajare, nu pentru izolare și securitate.
− Lipsa unei multi-tenancy stricte
Având în vedere abundența resurselor comune din clusterul Kubernetes, există multe modalități prin care aplicațiile diferite pot "pătrunde una în teritoriul alteia".
De exemplu, o aplicație poate monopoliza o resursă comună (precum CPU sau memorie) și poate privi alte aplicații care rulează pe același nod de acces.
Kubernetes oferă diverse mecanisme de control al acestui comportament, cum ar fi (consultați, de asemenea, articolul „” — n. trad.), și . Cu toate acestea, la fel ca în cazul securității, configurarea lor este destul de complexă și nu pot preveni toate efectele secundare neprevăzute.
− Un număr mare de utilizatori
În cazul unui singur cluster, acesta trebuie să fie accesibil multor persoane. Cu cât numărul lor este mai mare, cu atât riscul ca aceștia să "strice" ceva este mai mare.
În interiorul clusterului, se poate controla cine și ce poate face prin (consultați articolul „” — n. trad.). Totuși, acest lucru nu va împiedica utilizatorii să "strice" ceva în cadrul zonei lor de responsabilitate.
− Clusterele nu pot crește la nesfârșit
Un cluster care este folosit pentru toate sarcinile de lucru va fi, probabil, destul de mare (în numărul de noduri și pod-uri).
Dar aici apare o altă problemă: clusterele din Kubernetes nu pot crește la nesfârșit.
Există o limită teoretică asupra dimensiunii clusterului. În Kubernetes, aceasta este de aproximativ .
Cu toate acestea, în viața reală, problemele pot începe mult mai devreme — de exemplu, doar la .
Problema este că clusterele mari exercită o presiune mare asupra stratului de control Kubernetes. Cu alte cuvinte, pentru a menține un cluster în stare de funcționare și a utiliza eficient resursele, este necesară o configurație atentă.
Această problemă este discutată în articolul corespunzător din blogul original intitulat „».
Dar să examinăm abordarea opusă: multe clustere mici.
2. Multe clustere mici, specializate
Prin această abordare, utilizați un cluster separat pentru fiecare element desfășurat:
Multe clustere mici
În scopurile acestui articol, prin element desfășurat se înțelege o instanță a aplicației — de exemplu, versiunea dev a unei aplicații separate.
În această strategie, Kubernetes este utilizat ca un mediu de execuție extrem de specializat pentru instanțe separate ale aplicației.
Să analizăm avantajele și dezavantajele acestei abordări.
+ Rază de explozie limitată
În cazul unei „defecțiuni” a clusterului, consecințele negative sunt limitate doar la sarcinile de lucru care au fost desfășurate în acest cluster. Toate celelalte sarcini de lucru rămân intacte.
+ Izolare
Sarcinile de lucru găzduite în clustere individuale nu au resurse comune, cum ar fi CPU, memorie, sistem de operare, rețea sau alte servicii.
Prin urmare, obținem o izolare strictă între aplicații necorelate, ceea ce poate beneficia siguranța acestora.
+ Număr mic de utilizatori
Având în vedere că fiecare cluster conține doar un set restrâns de sarcini de lucru, este redus numărul utilizatorilor care au acces la el.
Cu cât mai puțini oameni au acces la cluster, cu atât riscul ca ceva să „se strice” este mai mic.
Să vedem dezavantajele.
− Utilizare ineficientă a resurselor
Așa cum s-a menționat anterior, fiecare cluster Kubernetes necesită un anumit set de resurse de control: noduri master, componente ale stratului de control, soluții pentru monitorizare și înregistrare.
În cazul unui număr mare de clustere mici, trebuie alocate o proporție mai mare de resurse pentru gestionare.
− Costuri ridicate
Utilizarea ineficientă a resurselor atrage automat costuri mari.
De exemplu, utilizarea a 30 de noduri master în loc de trei, cu aceeași capacitate de calcul, va avea un impact inevitabil asupra costurilor.
− Dificultăți de administrare
Administrarea unui număr mare de clustere Kubernetes este mult mai complicată decât lucrul cu unul singur.
De exemplu, va trebui să configurați autentificarea și autorizarea pentru fiecare cluster. Actualizarea versiunii Kubernetes va trebui, de asemenea, realizată de mai multe ori.
Probabil va trebui să aplicați automatizarea pentru a îmbunătăți eficiența tuturor acestor sarcini.
Acum să discutăm despre scenarii mai puțin extreme.
3. Un cluster pentru fiecare aplicație
În cadrul acestui principiu, creați un cluster separat pentru toate instanțele unei aplicații specifice:
Cluster pentru aplicație
Această abordare poate fi văzută ca o generalizare a principiului „cluster separat pentru echipă”, deoarece, de obicei, o echipă de ingineri se ocupă de dezvoltarea uneia sau mai multor aplicații.
Să analizăm avantajele și dezavantajele acestei abordări.
+ Clusterul poate fi personalizat pentru aplicație
Dacă aplicația are cerințe speciale, acestea pot fi implementate în cluster fără a afecta celelalte clustere.
Aceste cerințe pot include lucrători cu GPU, anumite pluginuri CNI, mesh pentru servicii sau orice alt serviciu.
Fiecare cluster poate fi configurat pentru aplicația care funcționează în el, astfel încât să conțină doar ceea ce este necesar.
− Medii diferite într-un cluster
Dezavantajul acestei abordări este că instanțele aplicațiilor din medii diferite coexista într-un singur cluster.
De exemplu, versiunea prod a aplicației funcționează în același cluster cu versiunea dev. Acest lucru înseamnă, de asemenea, că dezvoltatorii își desfășoară activitatea în același cluster în care rulează versiunea de producție a aplicației.
Dacă, din cauza acțiunilor dezvoltatorilor sau a erorilor versiunii dev, apare o defecțiune în cluster, versiunea prod poate fi afectată, ceea ce constituie un dezavantaj major al acestei abordări.
Și, în final, ultimul scenariu din lista noastră.
4. Un cluster pentru fiecare mediu
Acest scenariu prevede alocarea unui cluster separat pentru fiecare mediu:
Un cluster pentru mediu
De exemplu, puteți avea clustere dev, test și prod, în care veți rula toate instanțele aplicației destinate unui mediu specific.
Iată avantajele și dezavantajele acestei abordări.
+ Izolarea mediului prod
În cadrul acestei abordări, toate mediile sunt izolate una de cealaltă. Totuși, în practică, acest lucru este deosebit de important pentru mediul de producție.
Versiunile de producție ale aplicației nu mai depind acum de ceea ce se întâmplă în alte clustere și medii.
Astfel, dacă o problemă apare brusc în clusterul de dezvoltare, versiunile de producție ale aplicațiilor vor continua să funcționeze ca și cum nimic nu s-ar fi întâmplat.
+ Clusterul poate fi ajustat pentru mediu
Fiecare cluster poate fi adaptat la mediul său. De exemplu, se pot:
- instala instrumente pentru dezvoltare și depanare în clusterul de dezvoltare;
- instala cadre și instrumente de testare în cluster; test;
- folosi echipamente și canale de rețea mai puternice în cluster; prod.
Aceasta permite creșterea eficienței atât în dezvoltarea, cât și în exploatarea aplicațiilor.
+ Limitarea accesului la clusterul de producție
Necesitatea de a lucra direct cu clusterul de producție apare rar, așa că se poate limita semnificativ numărul de persoane care au acces la acesta.
Se poate merge chiar mai departe și se poate lipsi complet oamenii de acces la acest cluster, iar toate desfășurările se pot realiza cu ajutorul unui instrument automatizat de CI/CD. O astfel de abordare va reduce la minimum riscul erorilor umane exact acolo unde este cel mai relevant.
Acum, câteva cuvinte despre dezavantaje.
− Absența izolației între aplicații
Principalul dezavantaj al abordării este lipsa izolației hardware și de resurse între aplicații.
Aplicațiile necorelate împărtășesc resursele clusterului: nucleul sistemului, procesorul, memoria și unele alte servicii.
Așa cum s-a menționat anterior, acest lucru poate fi potențial periculos.
− Imposibilitatea de a localiza dependențele aplicațiilor
Dacă o aplicație are cerințe speciale, acestea trebuie satisfăcute în toate clusterele.
De exemplu, dacă aplicației îi este necesar un GPU, atunci fiecare cluster trebuie să conțină cel puțin un worker cu GPU (chiar dacă este folosit doar de această aplicație).
În consecință, riscăm să obținem costuri mai mari și o utilizare ineficientă a resurselor.
Concluzie
Cu un anumit set de aplicații, acestea pot fi plasate în mai multe clustere mari sau în multe mici.
Articolul analizează beneficiile și dezavantajele diferitelor abordări, de la un singur cluster global până la mai multe mici și specializate:
- o mare cluster comun;
- multe clustere mici specializate;
- un cluster pentru fiecare aplicație;
- un cluster pentru fiecare mediu.
Deci, ce abordare ar trebui aleasă?
Ca de obicei, răspunsul depinde de scenariul de utilizare: trebuie să cântăriți avantajele și dezavantajele diferitelor abordări și să alegeți cea mai optimă variantă.
Cu toate acestea, alegerea nu se limitează la exemplele de mai sus — se poate folosi orice combinație dintre ele!
De exemplu, se pot organiza câte două clustere pentru fiecare echipă: un cluster pentru dezvoltare (în care vor fi medii dev și test) și un cluster pentru producție (unde va fi mediu de producție).
Bazându-vă pe informațiile din acest articol, veți putea optimiza avantajele și dezavantajele în funcție de scenariul specific. Succes!
P.S.
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
