Cub-pe-cub, metaclustere, faguri, distribuție de resurse

Orez. 1. Ecosistemul Kubernetes pe Alibaba Cloud

Din 2015, Alibaba Cloud Container Service pentru Kubernetes (ACK) a fost unul dintre serviciile cloud cu cea mai rapidă creștere din Alibaba Cloud. Deservește numeroși clienți și sprijină, de asemenea, infrastructura internă a Alibaba și celelalte servicii cloud ale companiei.

Ca și în cazul serviciilor de containere similare de la furnizori de cloud de clasă mondială, prioritățile noastre principale sunt fiabilitatea și disponibilitatea. Prin urmare, a fost creată o platformă scalabilă și accesibilă la nivel global pentru zeci de mii de clustere Kubernetes.

În acest articol, vom împărtăși experiența noastră de gestionare a unui număr mare de clustere Kubernetes pe infrastructura cloud, precum și arhitectura platformei de bază.

Intrare

Kubernetes a devenit standardul de facto pentru o varietate de sarcini de lucru în cloud. După cum se arată în Fig. 1 de mai sus, din ce în ce mai multe aplicații Alibaba Cloud rulează acum pe clustere Kubernetes: aplicații cu stare și fără stat, precum și manageri de aplicații. Managementul Kubernetes a fost întotdeauna un subiect interesant și serios de discuție pentru inginerii care construiesc și întrețin infrastructura. Când vine vorba de furnizorii de cloud precum Alibaba Cloud, problema scalării vine în prim-plan. Cum să gestionezi clusterele Kubernetes la această scară? Am acoperit deja cele mai bune practici pentru gestionarea clusterelor uriașe Kubernetes cu 10 de noduri. Desigur, aceasta este o problemă de scalare interesantă. Dar există o altă scară: cantitatea clusterele în sine.

Am discutat acest subiect cu mulți utilizatori ACK. Majoritatea dintre ei aleg să ruleze zeci, dacă nu sute, de clustere Kubernetes mici sau mijlocii. Există motive întemeiate pentru aceasta: limitarea daunelor potențiale, separarea clusterelor pentru diferite echipe, crearea clusterelor virtuale pentru testare. Dacă ACK își propune să servească un public global cu acest model de utilizare, trebuie să gestioneze în mod fiabil și eficient un număr mare de clustere în peste 20 de regiuni.

Orez. 2. Probleme de gestionare a unui număr mare de clustere Kubernetes

Care sunt principalele provocări ale gestionării clusterelor la această scară? După cum se arată în figură, există patru probleme de rezolvat:

• Eterogenitate

ACK ar trebui să accepte diferite tipuri de clustere, inclusiv standard, serverless, Edge, Windows și multe altele. Diferitele clustere necesită opțiuni, componente și modele de găzduire diferite. Unii clienți au nevoie de asistență cu personalizarea pentru cazurile lor specifice.

• Diverse dimensiuni de cluster

Clusterele variază ca mărime: de la câteva noduri cu mai multe poduri până la zeci de mii de noduri cu mii de păstăi. Cerințele de resurse variază, de asemenea, foarte mult. Alocarea necorespunzătoare a resurselor poate afecta performanța sau chiar poate cauza eșec.

• Diferite versiuni

Kubernetes evoluează foarte repede. Noi versiuni sunt lansate la fiecare câteva luni. Clienții sunt întotdeauna dispuși să încerce funcții noi. Așa că vor să plaseze sarcina de testare pe noile versiuni de Kubernetes și sarcina de producție pe cele stabile. Pentru a îndeplini această cerință, ACK trebuie să livreze în permanență noi versiuni de Kubernetes clienților, menținând în același timp versiuni stabile.

• Conformitatea securității

Clusterele sunt distribuite în diferite regiuni. Ca atare, acestea trebuie să respecte diverse cerințe de siguranță și reglementări oficiale. De exemplu, un cluster din Europa trebuie să respecte GDPR, în timp ce un cloud financiar din China trebuie să aibă straturi suplimentare de protecție. Aceste cerințe sunt obligatorii și este inacceptabil să le ignorăm, deoarece acest lucru creează riscuri uriașe pentru clienții platformei cloud.

Platforma ACK este concepută pentru a rezolva majoritatea problemelor de mai sus. În prezent, gestionează în mod fiabil și stabil peste 10 mii de clustere Kubernetes din întreaga lume. Să vedem cum s-a realizat acest lucru, inclusiv prin mai multe principii cheie de design/arhitectură.

Desen

Cub-pe-cub și fagure

Spre deosebire de o ierarhie centralizată, arhitectura bazată pe celule este utilizată de obicei pentru a scala o platformă dincolo de un singur centru de date sau pentru a extinde domeniul de recuperare în caz de dezastru.

Fiecare regiune din Alibaba Cloud constă din mai multe zone (AZ) și de obicei corespunde unui anumit centru de date. Într-o regiune mare (de exemplu, Huangzhou), există adesea mii de clustere de clienți Kubernetes care rulează ACK.

ACK gestionează aceste clustere Kubernetes folosind Kubernetes însuși, ceea ce înseamnă că avem un metacluster Kubernetes care rulează pentru a gestiona clusterele Kubernetes client. Această arhitectură este numită și „kube-on-kube” (KoK). Arhitectura KoK simplifică gestionarea clusterelor de clienți, deoarece implementarea clusterelor este simplă și deterministă. Mai important, putem reutiliza funcțiile native Kubernetes. De exemplu, gestionarea serverelor API prin implementare, utilizarea operatorului etcd pentru a gestiona mai multe etcd-uri. O astfel de recursivitate aduce întotdeauna o plăcere deosebită.

Mai multe metaclustere Kubernetes sunt implementate într-o regiune, în funcție de numărul de clienți. Aceste metaclustere le numim celule. Pentru a proteja împotriva eșecului unei zone întregi, ACK acceptă implementări multi-active într-o singură regiune: metaclusterul distribuie componentele master ale clusterului client Kubernetes în mai multe zone și le rulează simultan, adică în modul multi-activ. Pentru a asigura fiabilitatea și eficiența masterului, ACK optimizează plasarea componentelor și se asigură că serverul API și etcd sunt aproape unul de celălalt.

Acest model vă permite să gestionați Kubernetes în mod eficient, flexibil și fiabil.

Planificarea resurselor metaclusterului

După cum am menționat deja, numărul de metaclustere din fiecare regiune depinde de numărul de clienți. Dar în ce moment să adăugați un nou metacluster? Aceasta este o problemă tipică de planificare a resurselor. De regulă, se obișnuiește să se creeze unul nou atunci când metaclusterele existente și-au epuizat toate resursele.

Să luăm resursele de rețea, de exemplu. În arhitectura KoK, componentele Kubernetes din clusterele de clienți sunt implementate ca pod-uri într-un metacluster. Folosim Terway (Fig. 3) este un plugin de înaltă performanță dezvoltat de Alibaba Cloud pentru gestionarea rețelei de containere. Oferă un set bogat de politici de securitate și vă permite să vă conectați la cloud-urile private virtuale (VPC) ale clienților prin interfața de rețea elastică Alibaba Cloud (ENI). Pentru a distribui eficient resursele de rețea între noduri, poduri și servicii dintr-un metacluster, trebuie să monitorizăm cu atenție utilizarea acestora în metaclusterul de cloud-uri private virtuale. Când resursele de rețea se termină, este creată o nouă celulă.

Pentru a determina numărul optim de clustere de clienți din fiecare metacluster, luăm în considerare și costurile noastre, cerințele de densitate, cota de resurse, cerințele de fiabilitate și statisticile. Decizia de a crea un nou metacluster este luată pe baza tuturor acestor informații. Vă rugăm să rețineți că clusterele mici se pot extinde foarte mult în viitor, astfel încât consumul de resurse crește chiar dacă numărul de clustere rămâne neschimbat. De obicei, lăsăm suficient spațiu liber pentru ca fiecare cluster să crească.

Orez. 3. Arhitectura rețelei Terway

Scalarea componentelor expertului în clustere de clienți

Componentele expertului au nevoi diferite de resurse. Acestea depind de numărul de noduri și pod-uri din cluster, de numărul de controlere/operatori non-standard care interacționează cu APIServer.

În ACK, fiecare cluster de clienți Kubernetes diferă în ceea ce privește dimensiunea și cerințele de rulare. Nu există o configurație universală pentru plasarea componentelor expertului. Dacă setăm din greșeală o limită scăzută de resurse pentru un client mare, atunci clusterul său nu va putea face față încărcării. Dacă setați o limită relativ ridicată pentru toate clusterele, resursele vor fi irosite.

Pentru a găsi un compromis subtil între fiabilitate și cost, ACK folosește un sistem de tip. Și anume, definim trei tipuri de clustere: mici, medii și mari. Fiecare tip are un profil separat de alocare a resurselor. Tipul este determinat pe baza încărcării componentelor expertului, a numărului de noduri și a altor factori. Tipul de cluster se poate schimba în timp. ACK monitorizează continuu acești factori și poate scrie în sus/jos în consecință. Odată ce tipul de cluster este schimbat, alocarea resurselor este actualizată automat cu intervenția minimă a utilizatorului.

Lucrăm pentru a îmbunătăți acest sistem cu o scalare mai fină și o actualizare mai precisă a tipului, astfel încât aceste modificări să aibă loc mai ușor și să aibă mai mult sens economic.

Orez. 4. Comutare inteligentă în mai multe etape

Evoluția clusterelor de clienți la scară

Secțiunile anterioare au acoperit câteva aspecte ale gestionării unui număr mare de clustere Kubernetes. Cu toate acestea, există o altă problemă care trebuie rezolvată: evoluția clusterelor.

Kubernetes este „Linuxul” lumii cloud. Este actualizat continuu și devine mai modular. Trebuie să livrăm în mod constant noi versiuni clienților noștri, să reparăm vulnerabilitățile și să actualizăm clusterele existente, precum și să gestionăm un număr mare de componente aferente (CSI, CNI, Device Plugin, Scheduler Plugin și multe altele).

Să luăm ca exemplu managementul componentelor Kubernetes. Pentru început, am dezvoltat un sistem centralizat pentru înregistrarea și gestionarea tuturor acestor componente conectate.

Orez. 5. Componente flexibile și conectabile

Înainte de a continua, trebuie să vă asigurați că actualizarea a avut succes. Pentru a face acest lucru, am dezvoltat un sistem de verificare a funcționalității componentelor. Verificarea se efectuează înainte și după actualizare.

Orez. 6. Verificarea preliminară a componentelor clusterului

Pentru a actualiza rapid și fiabil aceste componente, un sistem de implementare continuă funcționează cu suport pentru avansare parțială (scale de gri), pauze și alte funcții. Controlerele standard Kubernetes nu sunt potrivite pentru acest caz de utilizare. Prin urmare, pentru a gestiona componentele clusterului, am dezvoltat un set de controlere specializate, inclusiv un plugin și un modul de control auxiliar (management sidecar).

De exemplu, controlerul BroadcastJob este proiectat să actualizeze componente de pe fiecare mașină de lucru sau să verifice nodurile de pe fiecare mașină. Jobul Broadcast rulează un pod pe fiecare nod din cluster, ca un DaemonSet. Cu toate acestea, DaemonSet menține întotdeauna podul să funcționeze mult timp, în timp ce BroadcastJob îl colapsează. Controlerul Broadcast lansează, de asemenea, pod-uri pe nodurile nou conectate și inițializează nodurile cu componentele necesare. În iunie 2019, am deschis codul sursă al motorului de automatizare OpenKruise, pe care noi înșine îl folosim în cadrul companiei.

Orez. 7. OpenKurise organizează execuția sarcinii Broadcast pe toate nodurile

Pentru a ajuta clienții să selecteze configurațiile de cluster potrivite, oferim și un set de profiluri predefinite, inclusiv profile Serverless, Edge, Windows și Bare Metal. Pe măsură ce peisajul se extinde și nevoile clienților noștri cresc, vom adăuga mai multe profiluri pentru a simplifica procesul obositor de configurare.

Orez. 8. Profiluri de cluster avansate și flexibile pentru diverse scenarii

Observabilitate globală în centrele de date

După cum se arată în fig. 9, serviciul cloud Alibaba Cloud Container a fost implementat în douăzeci de regiuni din întreaga lume. Având în vedere această amploare, unul dintre obiectivele cheie ale ACK este de a monitoriza cu ușurință starea clusterelor care rulează, astfel încât, dacă un cluster client întâmpină o problemă, să putem răspunde rapid la situație. Cu alte cuvinte, trebuie să veniți cu o soluție care să vă permită să colectați eficient și sigur statistici în timp real de la clusterele de clienți din toate regiunile - și să prezentați vizual rezultatele.

Orez. 9. Implementarea globală a serviciului Alibaba Cloud Container în douăzeci de regiuni

La fel ca multe sisteme de monitorizare Kubernetes, folosim Prometheus ca instrument principal. Pentru fiecare metacluster, agenții Prometheus colectează următoarele valori:

• Măsuri ale sistemului de operare, cum ar fi resursele gazdă (CPU, memorie, disc etc.) și lățimea de bandă a rețelei.
• Metrici pentru metacluster și sistemul de management al clusterelor client, cum ar fi kube-apiserver, kube-controller-manager și kube-scheduler.
• Metrici de la kubernetes-state-metrics și cadvisor.
• metrici etcd, cum ar fi timpul de scriere pe disc, dimensiunea bazei de date, debitul de legături între noduri etc.

Statisticile globale sunt colectate folosind un model tipic de agregare multistrat. Datele de monitorizare din fiecare metacluster sunt mai întâi agregate în fiecare regiune și apoi trimise la un server central care arată imaginea de ansamblu. Totul funcționează prin mecanismul de federație. Un server Prometheus din fiecare centru de date colectează valori de la acel centru de date, iar serverul central Prometheus este responsabil pentru agregarea datelor de monitorizare. AlertManager se conectează la centralul Prometheus și trimite alerte după cum este necesar prin DingTalk, e-mail, SMS, etc. Vizualizare - Folosind Grafana.

În Figura 10, sistemul de monitorizare poate fi împărțit în trei niveluri:

• Nivelul limită

Stratul cel mai îndepărtat de centru. Prometheus Edge Server rulează în fiecare metacluster, colectând valori de la meta clustere și clustere de clienți din același domeniu de rețea.

• Nivel în cascadă

Funcția stratului în cascadă Prometheus este de a colecta date de monitorizare din mai multe regiuni. Aceste servere funcționează la nivelul unităților geografice mai mari precum China, Asia, Europa și America. Pe măsură ce clusterele cresc, regiunea poate fi împărțită, iar apoi un server Prometheus la nivel de cascadă va apărea în fiecare regiune mare nouă. Cu această strategie, puteți scala fără probleme după cum este necesar.

• Nivel central

Serverul central Prometheus se conectează la toate serverele în cascadă și realizează agregarea finală a datelor. Pentru fiabilitate, două instanțe centrale Prometheus au fost ridicate în zone diferite, conectate la aceleași servere în cascadă.

Orez. 10. Arhitectură globală de monitorizare pe mai multe niveluri bazată pe mecanismul de federație Prometheus

Rezumat

Soluțiile cloud bazate pe Kubernetes continuă să ne transforme industria. Serviciul de containere Alibaba Cloud oferă găzduire sigură, fiabilă și de înaltă performanță - este una dintre cele mai bune găzduire cloud Kubernetes. Echipa Alibaba Cloud crede cu tărie în principiile Open Source și în comunitatea open source. Cu siguranță vom continua să împărtășim cunoștințele noastre în domeniul operațiunii și gestionării tehnologiilor cloud.

Sursa: www.habr.com