Notă. transl.: Adoptarea Kubernetes la GitLab este considerată unul dintre cei doi factori principali care contribuie la creșterea companiei. Cu toate acestea, până de curând, infrastructura serviciului online GitLab.com a fost construită pe mașini virtuale, iar în urmă cu aproximativ un an a început migrarea sa la K8, care încă nu este finalizată. Suntem încântați să vă prezentăm o traducere a unui articol recent al unui inginer GitLab SRE despre cum se întâmplă acest lucru și ce concluzii trag inginerii care participă la proiect.
De aproximativ un an, divizia noastră de infrastructură migrează toate serviciile care rulează pe GitLab.com către Kubernetes. În acest timp, am întâmpinat provocări legate nu numai de mutarea serviciilor către Kubernetes, ci și de gestionarea implementării hibride în timpul tranziției. Lecțiile valoroase pe care le-am învățat vor fi discutate în acest articol.
De la începutul GitLab.com, serverele sale rulau în cloud pe mașini virtuale. Aceste mașini virtuale sunt gestionate de Chef și instalate folosind sistemul nostru . în cazul în care aplicația trebuie actualizată, constă în simpla actualizare a flotei de servere într-o manieră coordonată, secvenţială, folosind o conductă CI. Această metodă - deși lentă și puțin - se asigură că GitLab.com utilizează aceleași practici de instalare și configurare ca și utilizatorii offline (autogestionat) Instalări GitLab folosind pachetele noastre Linux pentru aceasta.
Folosim această metodă deoarece este extrem de important să experimentăm toate necazurile și bucuriile pe care le experimentează membrii obișnuiți ai comunității atunci când instalează și configurează copiile GitLab. Această abordare a funcționat bine de ceva timp, dar când numărul de proiecte de pe GitLab a depășit 10 milioane, ne-am dat seama că nu ne mai satisface nevoile de scalare și implementare.
Primii pași către Kubernetes și GitLab nativ în cloud
Proiectul a fost creat în 2017 pentru a pregăti GitLab pentru implementarea în cloud și pentru a permite utilizatorilor să instaleze GitLab pe clustere Kubernetes. Știam atunci că mutarea GitLab la Kubernetes va crește scalabilitatea platformei SaaS, va simplifica implementările și va îmbunătăți eficiența resurselor de calcul. În același timp, multe dintre funcțiile aplicației noastre depindeau de partiții NFS montate, ceea ce a încetinit tranziția de la mașinile virtuale.
Împingerea către cloud native și Kubernetes le-a permis inginerilor noștri să planifice o tranziție treptată, în timpul căreia am abandonat unele dintre dependențele aplicației de stocarea în rețea, continuând să dezvoltăm noi funcții. De când am început să planificăm migrarea în vara lui 2019, multe dintre aceste limitări au fost rezolvate, iar procesul de migrare a GitLab.com la Kubernetes este acum în desfășurare!
Caracteristicile GitLab.com în Kubernetes
Pentru GitLab.com, folosim un singur cluster regional GKE care se ocupă de tot traficul aplicațiilor. Pentru a minimiza complexitatea migrării (deja complicate), ne concentrăm pe serviciile care nu se bazează pe stocarea locală sau pe NFS. GitLab.com folosește o bază de cod Rails predominant monolitică și direcționăm traficul pe baza caracteristicilor încărcăturii de lucru către diferite puncte finale care sunt izolate în propriile lor pool-uri de noduri.
În cazul frontend-ului, aceste tipuri sunt împărțite în solicitări către web, API, Git SSH/HTTPS și Registry. În cazul backend-ului, împărțim joburile din coadă după diverse caracteristici în funcție de , care ne permit să setăm obiective la nivel de serviciu (SLO) pentru diferite sarcini de lucru.
Toate aceste servicii GitLab.com sunt configurate folosind o diagramă GitLab Helm nemodificată. Configurarea se realizează în subdiagrame, care pot fi activate selectiv pe măsură ce migrăm treptat serviciile către cluster. Chiar dacă am decis să nu includem unele dintre serviciile noastre stateful în migrare, cum ar fi Redis, Postgres, GitLab Pages și Gitaly, utilizarea Kubernetes ne permite să reducem radical numărul de VM-uri pe care Chef le gestionează în prezent.
Vizibilitatea și managementul configurației Kubernetes
Toate setările sunt gestionate chiar de GitLab. Pentru aceasta, sunt folosite trei proiecte de configurare bazate pe Terraform și Helm. Încercăm, ori de câte ori este posibil, să folosim GitLab în sine pentru a rula GitLab, dar pentru sarcinile operaționale avem o instalare separată GitLab. Acest lucru este necesar pentru a vă asigura că nu sunteți dependent de disponibilitatea GitLab.com atunci când efectuați implementări și actualizări GitLab.com.
Deși conductele noastre pentru clusterul Kubernetes rulează pe o instalare GitLab separată, există oglinzi ale depozitelor de cod care sunt disponibile public la următoarele adrese:
- — Cadrul de configurare GitLab.com pentru diagrama GitLab Helm;
- - Conține configurații pentru servicii care nu sunt asociate direct cu aplicația GitLab. Acestea includ configurații pentru înregistrare și monitorizare cluster, precum și instrumente integrate precum PlantUML;
- — Configurație Terraform pentru Kubernetes și infrastructura VM moștenită. Aici configurați toate resursele necesare pentru a rula clusterul, inclusiv clusterul în sine, pool-urile de noduri, conturile de serviciu și rezervările de adrese IP.
Vizualizarea publică este afișată când se fac modificări. cu un link către diferența detaliată pe care SRE o analizează înainte de a face modificări în cluster.
Pentru SRE, linkul duce la o diferență detaliată în instalarea GitLab, care este utilizată pentru producție și accesul la care este limitat. Acest lucru permite angajaților și comunității, fără acces la proiectul operațional (care este deschis doar SRE), să vadă modificările de configurare propuse. Combinând o instanță publică GitLab pentru cod cu o instanță privată pentru conducte CI, menținem un singur flux de lucru, asigurând în același timp independența față de GitLab.com pentru actualizările de configurare.
Ce am aflat în timpul migrației
În timpul mutării, s-a acumulat experiența pe care o aplicăm noilor migrări și implementări în Kubernetes.
1. Costuri crescute din cauza traficului dintre zonele de disponibilitate
Statistici zilnice de ieșire (octeți pe zi) pentru flota de depozite Git pe GitLab.com
Google își împarte rețeaua în regiuni. Acestea, la rândul lor, sunt împărțite în zone de accesibilitate (AZ). Găzduirea Git este asociată cu cantități mari de date, așa că este important pentru noi să controlăm ieșirea din rețea. Pentru traficul intern, ieșirea este gratuită numai dacă rămâne în aceeași zonă de disponibilitate. În momentul scrierii acestui articol, servim aproximativ 100 TB de date într-o zi de lucru obișnuită (și asta este doar pentru depozitele Git). Serviciile care se aflau în aceleași mașini virtuale din vechea noastră topologie bazată pe VM rulează acum în diferite poduri Kubernetes. Aceasta înseamnă că un anumit trafic care anterior era local pentru VM ar putea călători în afara zonelor de disponibilitate.
Clusterele regionale GKE vă permit să acoperiți mai multe zone de disponibilitate pentru redundanță. Luăm în considerare posibilitatea pentru serviciile care generează volume mari de trafic. Acest lucru va reduce costurile de ieșire, menținând în același timp redundanța la nivel de cluster.
2. Limite, cereri de resurse și scalare
Numărul de replici care procesează traficul de producție pe registry.gitlab.com. Traficul atinge vârfuri la ~15:00 UTC.
Povestea noastră de migrare a început în august 2019, când am migrat primul nostru serviciu, GitLab Container Registry, la Kubernetes. Acest serviciu critic, cu trafic ridicat, a fost o alegere bună pentru prima migrare, deoarece este o aplicație fără stat, cu puține dependențe externe. Prima problemă pe care am întâlnit-o a fost un număr mare de pod-uri evacuate din cauza lipsei de memorie pe noduri. Din această cauză, a trebuit să schimbăm solicitările și limitele.
S-a constatat că în cazul unei aplicații în care consumul de memorie crește în timp, valorile scăzute pentru solicitări (rezervarea memoriei pentru fiecare pod) cuplate cu o limită rigidă „generoasă” de utilizare au dus la saturare. (saturare) noduri și un nivel ridicat de evacuări. Pentru a face față acestei probleme, a fost . Acest lucru a eliminat presiunea de pe noduri și a asigurat că podurile au un ciclu de viață care nu a pus prea multă presiune asupra nodului. Acum începem migrațiile cu cereri și valori limită generoase (și aproape identice), ajustându-le după cum este necesar.
3. Metrici și jurnalele
Divizia de infrastructură se concentrează pe latență, rate de eroare și saturație cu instalat (SLO) legat de .
În ultimul an, unul dintre evenimentele cheie din divizia de infrastructură a fost îmbunătățirea monitorizării și a lucrului cu SLO. SLO-urile ne-au permis să stabilim obiective pentru serviciile individuale pe care le-am monitorizat îndeaproape în timpul migrării. Dar chiar și cu această observabilitate îmbunătățită, nu este întotdeauna posibil să vedeți imediat problemele folosind valorile și alertele. De exemplu, concentrându-ne pe ratele de latență și de eroare, nu acoperim în totalitate toate cazurile de utilizare pentru un serviciu aflat în curs de migrare.
Această problemă a fost descoperită aproape imediat după migrarea unor sarcini de lucru în cluster. A devenit deosebit de acută când a trebuit să verificăm funcții pentru care numărul de solicitări era mic, dar care aveau dependențe de configurare foarte specifice. Una dintre lecțiile cheie din migrare a fost necesitatea de a lua în considerare nu numai valorile la monitorizare, ci și jurnalele și „coada lungă” (este vorba despre pe grafic - aprox. traducere) erori. Acum, pentru fiecare migrare, includem o listă detaliată de interogări de jurnal (interogări de jurnal) și planificați proceduri clare de retragere care pot fi transferate de la o tură la alta dacă apar probleme.
Servirea acelorași solicitări în paralel pe vechea infrastructură VM și noua infrastructură bazată pe Kubernetes a reprezentat o provocare unică. Spre deosebire de migrarea lift-and-shift (transfer rapid al aplicațiilor „ca atare” la o nouă infrastructură; mai multe detalii pot fi citite, de exemplu, - aprox. traducere), munca paralelă pe mașinile virtuale „vechi” și Kubernetes necesită ca instrumentele de monitorizare să fie compatibile cu ambele medii și să poată combina valorile într-o singură vizualizare. Este important să folosim aceleași tablouri de bord și aceleași interogări de jurnal pentru a obține o observabilitate consecventă în timpul perioadei de tranziție.
4. Comutarea traficului la un cluster nou
Pentru GitLab.com, o parte din servere este dedicată . Canary Park deservește proiectele noastre interne și poate, de asemenea . Dar este conceput în primul rând pentru a testa modificările aduse infrastructurii și aplicației. Primul serviciu migrat a început prin a accepta o cantitate limitată de trafic intern și continuăm să folosim această metodă pentru a ne asigura că SLO-urile sunt îndeplinite înainte de a trimite tot traficul către cluster.
În cazul migrării, aceasta înseamnă că solicitările către proiectele interne sunt trimise mai întâi către Kubernetes, iar apoi trecem treptat restul traficului către cluster, schimbând greutatea pentru backend prin HAProxy. În timpul migrării de la VM la Kubernetes, a devenit clar că a fost foarte benefic să existe o modalitate ușoară de a redirecționa traficul între vechea și cea nouă infrastructură și, în consecință, să menținem vechea infrastructură pregătită pentru rollback în primele zile după migrare.
5. Capacități de rezervă ale păstăilor și utilizarea lor
Aproape imediat a fost identificată următoarea problemă: podurile pentru serviciul Registry au început rapid, dar lansarea podurilor pentru Sidekiq a durat până la . Timpul lung de rulare pentru pod-urile Sidekiq a devenit o problemă atunci când am început migrarea sarcinilor de lucru către Kubernetes pentru lucrătorii care trebuiau să proceseze rapid lucrările și să se scaleze rapid.
În acest caz, lecția a fost că, în timp ce Horizontal Pod Autoscaler (HPA) în Kubernetes face o treabă bună în gestionarea creșterii traficului, este important să se țină cont de caracteristicile sarcinilor de lucru și să se aloce capacității de rezervă pod-urilor (mai ales atunci când cererea este distribuite neuniform). În cazul nostru, a existat o creștere bruscă a locurilor de muncă, ceea ce a dus la o scalare rapidă, ceea ce a dus la saturarea resurselor CPU înainte de a avea timp să scalam pool-ul de noduri.
Există întotdeauna tentația de a strânge cât mai mult posibil dintr-un cluster, totuși, după ce am întâmpinat inițial probleme de performanță, acum începem cu un buget generos pentru pod și îl reducem mai târziu, urmărind cu atenție SLO-urile. Lansarea podurilor pentru serviciul Sidekiq a fost accelerată semnificativ și durează acum aproximativ 40 de secunde în medie. a câștigat atât GitLab.com, cât și utilizatorii noștri de instalații autogestionate care lucrează cu diagrama oficială GitLab Helm.
Concluzie
După migrarea fiecărui serviciu, ne-am bucurat de beneficiile utilizării Kubernetes în producție: implementare mai rapidă și mai sigură a aplicațiilor, scalare și alocare mai eficientă a resurselor. Mai mult decât atât, avantajele migrării depășesc serviciul GitLab.com. Fiecare îmbunătățire a diagramei oficiale Helm aduce beneficii utilizatorilor săi.
Sper că v-a plăcut povestea aventurilor noastre de migrare Kubernetes. Continuăm să migrăm toate serviciile noi către cluster. Informații suplimentare pot fi găsite în următoarele publicații:
- «»;
- «»;
- .
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com