Napomena za prijevod.: adaptacija Kubernetes u GitLabu smatra se jednim od dva glavna faktora koji pridonose rastu tvrtke. Međutim, do nedavno je infrastruktura online servisa GitLab.com bila izgrađena na virtualnim mašinama, a migracija u K8s, koja još uvijek nije završena, započela je prije otprilike godine. Uživajte u prijevodu nedavne članka SRE inženjera GitLaba o tome kako sve to izgleda i koje zaključke donose inženjeri uključeni u projekt.
Naš infrastrukturni tim već oko godinu dana provodi migraciju svih servisa koji rade na GitLab.com u Kubernetes. Tijekom tog vremena suočili smo se s problemima povezanim ne samo s premještanjem servisa u Kubernetes, već i s upravljanjem hibridnim deploymentom tijekom prijelaza. O vrijednim lekcijama koje smo naučili govorit ćemo u ovom članku.
Od samog početka GitLab.com njegovi su serveri radili u oblaku na virtualnim mašinama. Ove virtualne mašine upravlja Chef, a njihova instalacija se vrši pomoću našeg . za slučaj da je potrebno ažurirati aplikaciju, sastoji se u jednostavnom ažuriranju parka servera koordiniranim uzastopnim redom pomoću CI pipelinea. Ova metoda — iako spora i pomalo — jamči da GitLab.com primjenjuje iste metode instalacije i konfiguracije kao i korisnici samostalnih (self-managed) instalacija GitLaba, koristeći za to naše Linux pakete.
Koristimo ovu metodu jer je izuzetno važno iskusiti sve brige i radosti koje prolaze obični članovi zajednice kada instaliraju i postavljaju svoje kopije GitLaba. Ovaj pristup dobro je funkcionirao tijekom određenog vremena, no kada je broj projekata na GitLabu prešao 10 milijuna, shvatili smo da više ne zadovoljava naše potrebe za skaliranjem i implementacijom.
Prvi koraci ka Kubernetes i cloud-native GitLab
U 2017. godini pokrenut je projekt za pripremu GitLaba za implementaciju u oblaku, kao i za pružanje korisnicima mogućnosti instalacije GitLaba u Kubernetes klastere. Tada smo znali da će premještanje GitLaba u Kubernetes povećati mogućnosti skaliranja SaaS platforme, pojednostaviti implementacije i povećati efikasnost korištenja računalnih resursa. U isto vrijeme, mnoge funkcije naše aplikacije su ovisile o montiranim NFS particijama, što je usporavalo prelazak sa virtualnih mašina.
Težnja ka cloud native i Kubernetes omogućila je našim inženjerima da planiraju postepeni prelazak, tijekom kojeg smo se odrekli nekih zavisnosti aplikacije od umreženih skladišta, istovremeno nastavljajući s razvojem novih funkcija. Otkako smo započeli s planiranjem migracije ljeta 2019., mnoga od tih ograničenja su otklonjena, a proces prelaska GitLab.com na Kubernetes sada teče punom brzinom!
Karakteristike rada GitLab.com u Kubernetesu
Za GitLab.com koristimo jedinstveni regionalni GKE klaster koji obrađuje sav promet aplikacije. Kako bismo minimizirali složenost (ionako komplicirane) migracije, fokusiramo se na usluge koje ne ovise o lokalnom skladištu ili NFS-u. GitLab.com većinom koristi monolitnu kodnu bazu na Railsu, a promet usmjeravamo u zavisnosti od karakteristika radnog opterećenja na različite endpointove, izolirane u svoje vlastite čvorove.
Što se tiče frontenda, ti tipovi se dijele na zahtjeve za web, API, Git SSH/HTTPS i Registry. U slučaju backenda, razbijamo poslove u redovima prema različitim karakteristikama ovisno o , što nam omogućava postavljanje ciljanih metrika razine usluge (Service-Level Objectives, SLOs) za različita opterećenja.
Sve te usluge GitLab.com su konfigurirane pomoću nemodificiranog Helm chart-a GitLab. Konfiguracija se provodi u subchartovima koji se mogu selektivno uključivati kako postepeno premještamo usluge u klaster. Čak i uz ulaganje da se ne uključe u migraciju neki od naših stateful usluga, kao što su Redis, Postgres, GitLab Pages i Gitaly, korištenje Kubernetes omogućava radikalno smanjenje broja VM-ova kojima trenutno upravlja Chef.
Transparentnost i upravljanje konfiguracijom Kubernetes
Sve postavke upravlja sam GitLab. Za to se koriste tri konfiguracijska projekta temeljena na Terraformu i Helmu. Pokušavamo svugdje, gdje je to moguće, koristiti sam GitLab za pokretanje GitLab-a, ali za operativne zadatke imamo zasebnu instalaciju GitLab-a. To je potrebno kako bismo bili neovisni o dostupnosti GitLab.com prilikom izvođenja implementacija i ažuriranja GitLab.com.
Iako naši paketi za Kubernetes klaster rade na zasebnoj instalaciji GitLab-a, repozitoriji koda imaju zrcala, javno dostupna na sljedećim adresama:
- — konfiguracijska obavijest za GitLab.com za Helm grafikon;
- — sadrži konfiguracije za usluge koje nisu izravno povezane s aplikacijom GitLab. To uključuje konfiguracije za vođenje evidencije i praćenje klastera, kao i za integrirane alate poput PlantUML;
- — Terraform konfiguracija za Kubernetes i staru (legacy) VM infrastrukturu. Ovdje se postavljaju svi resursi potrebni za pokretanje klastera, uključujući sam klaster, grupe čvorova, račune servisa, rezervaciju IP adresa.
Prilikom izmjena prikazuje se javno s linkom na detaljan diff, koji SRE analizira prije nego što izvrši promjene u klasteru.
Za SRE, link vodi na detaljan diff u instalaciji GitLab-a, koja se koristi za operacije i pristup kojoj je ograničen. To omogućava zaposlenicima i zajednici bez pristupa operativnom projektu (koji je otvoren samo za SRE) da pregledaju predložene promjene u konfiguraciji. Kombinirajući javni primjerak GitLab-a za kod s privatnim primjerkom za CI pakete, održavamo jedinstven radni tok, dok istovremeno jamčimo neovisnost od GitLab.com tijekom ažuriranja konfiguracije.
Što smo saznali tijekom migracije
Tijekom preseljenja stečeno je iskustvo koje primjenjujemo na nove migracije i implementacije u Kubernetesu.
1. Povećanje troškova zbog prometa između zona dostupnosti
Dnevna egress statistika (bajtovi po danu) za park Git repozitorija na GitLab.com
Google dijeli svoju mrežu na regije. One su dalje podijeljene na zone dostupnosti (AZ). Git hosting povezan je s velikim količinama podataka, stoga nam je važno kontrolirati mrežni egress. U slučaju unutarnjeg prometa, egress je besplatan samo ako ostaje unutar granica jedne zone dostupnosti. U trenutku pisanja ovog članka šaljemo otprilike 100 TB podataka tijekom običnog radnog dana (i to je samo za Git repozitorije). Usluge koje su u našoj staroj topologiji, temeljnoj na VM-ima, bile na istim virtualnim strojevima, sada rade u različitim podovima Kubernetes-a. To znači da dio prometa koji je prije bio lokalni za VM može potencijalno izlaziti izvan zona dostupnosti.
Regionalni GKE klasteri omogućuju pokrivanje više zona dostupnosti za rezerviranje. Razmatramo mogućnost za usluge koje generiraju velike količine prometa. To će smanjiti troškove egress uz održavanje rezervacije na razini klastera.
2. Limitacije, requesti resursa i skaliranje
Broj replika koje obrađuju produkcijski promet na registry.gitlab.com. Promet doseže svoj vrhunac oko 15:00 UTC.
Naša priča o migraciji započela je u kolovozu 2019. kada smo prvi put premjestili uslugu — GitLab rezerva kontejnera (GitLab Container Registry) — u Kubernetes. Ova kritična usluga s visokim prometom bila je idealna za prvu migraciju, jer predstavlja stateless aplikaciju s malim brojem vanjskih ovisnosti. Prvi problem na koji smo naišli bila je velika količina izbačenih podova zbog nedostatka memorije na čvorovima. Zbog toga smo morali mijenjati requeste i limitacije.
Otkriveno je da u slučaju aplikacije čija se potrošnja memorije povećava tijekom vremena, niske vrijednosti za requeste (rezerviranje memorije za svaki pod) u kombinaciji s "generoznim" hard limitom korištenja dovode do zasićenja (saturation) čvorova i visoke razine izbacivanja. Da bismo se nosili s ovim problemom, odlučeno je To je smanjilo pritisak na čvorove i osiguralo životni ciklus podova, koji nije vršio prevelik pritisak na čvor. Sada započinjemo migracije s velikim (i gotovo jednakim) vrijednostima zahtjeva i limita, prilagođavajući ih po potrebi.
3. Metrički pokazatelji i logovi
Infrastrukturna jedinica fokusira se na kašnjenja, postotak grešaka i saturaciju prema postavljenim (SLO), vezanim za .
Tijekom protekle godine, jedan od ključnih događaja u infrastrukturnoj jedinici bila su poboljšanja u praćenju i radu s SLO. SLO su nam omogućili postavljanje ciljeva za pojedine usluge koje smo pomno pratili tijekom migracije. No, čak ni s tako poboljšanom vidljivošću, nije uvijek lako odmah uočiti probleme koristeći metrike i alarme. Na primjer, fokusirajući se na kašnjenja i postotak grešaka, ne pokrivamo potpuno sve scenarije korištenja usluge koja se migrira.
Ovaj problem je otkriven gotovo odmah nakon premještanja dijela radnih opterećenja u klaster. Posebno se oglasio kada je trebalo provjeriti funkcije za koje je broj zahtjeva mali, ali koje imaju vrlo specifične konfiguracijske ovisnosti. Jedna od ključnih lekcija nakon migracije bio je potreba za uzimanjem u obzir prilikom praćenja ne samo metrika, već i logova i ‘dugog repa’ (govorimo o na grafu — napomena prev.) grešaka. Sada za svaku migraciju uključujemo detaljan popis zahtjeva za logovima (log queries) i planiramo jasne postupke povratka, koje se u slučaju problema mogu prenositi s jedne smjene na drugu.
Paralelna obrada istih zahtjeva na staroj VM infrastrukturi i novoj, temeljenoj na Kubernetesu, predstavljala je jedinstveni izazov. Za razliku od migracije tipa lift-and-shift (brzi prijenos aplikacija 'kako jesu' u novu infrastrukturu; više informacija može se pročitati, na primjer, — napomena prev.), paralelni rad na «starim» VM i Kubernetes zahtijeva da alati za nadgledanje budu kompatibilni s oba okruženja i da mogu kombinirati metrike u jedan oblik. Važno je da koristimo iste nadzorne ploče i upite za logove kako bismo postigli dosljednu preglednost tijekom prijelaznog razdoblja.
4. Preusmjeravanje prometa na novu klaster
Za GitLab.com dio servera je rezerviran za . Kanarinski park opslužuje naše interne projekte, a također može . No, prvenstveno je namijenjen provjeri promjena unesenih u infrastrukturu i aplikaciju. Prva premještena usluga započela je s primanjem ograničenog volumena unutarnjeg prometa, a mi i dalje koristimo ovu metodu kako bismo osigurali poštivanje SLO-a prije nego što preusmjerimo sav promet u klaster.
U slučaju migracije to znači da se najprije u Kubernetes preusmjeravaju upiti k unutarnjim projektima, a zatim postupno preusmjeravamo ostatak prometa na klaster mijenjajući težinu za backend putem HAProxy. Tijekom prijelaza s VM na Kubernetes postalo je jasno da je vrlo korisno imati jednostavan način preusmjeravanja prometa između stare i nove infrastrukture, te održavati staru infrastrukturu spremnom za povratak tijekom prvih nekoliko dana nakon migracije.
5. Rezervni kapaciteti podova i njihovo korištenje
Gotovo odmah je identificiran sljedeći problem: podovi za uslugu Registry su se brzo pokretali, međutim pokretanje podova za Sidekiq trajalo je do . Dugotrajno pokretanje podova za Sidekiq postalo je problem kada smo krenuli s migracijom radnih opterećenja za radnike u Kubernetesu, kojima je potrebno brzo obraditi poslove i brzo se skalirati.
U ovom slučaju lekcija je bila da, iako Horizontal Pod Autoscaler (HPA) u Kubernetesu dobro upravlja rastom prometa, važno je uzeti u obzir karakteristike radnih opterećenja i osigurati rezervne kapacitete podova (posebno u uvjetima neujednačene potražnje). U našem slučaju zabilježen je nagli porast poslova, što je zahtijevalo brzo skaliranje, što je dovelo do zasićenja CPU resursa prije nego što smo uspjeli povećati bazen čvorova.
Uvijek postoji iskušenje da se iz klastera izvuče što više, međutim, suočeni s problemima s performansama, sada započinjemo s velikim budžetom za pod i kasnije ga smanjujemo, pomno prateći SLO. Pokretanje podova za Sidekiq uslugu značajno je ubrzano i sada u prosjeku traje oko 40 sekundi. koristi i GitLab.com, kao i naši korisnici samostalnih instalacija koji koriste službeni Helm dijagram GitLaba.
Zaključak
Nakon premještanja svake usluge, uživali smo u prednostima korištenja Kubernetes-a u produkciji: bržem i sigurnijem implementiranju aplikacija, skaliranju i učinkovitijoj raspodjeli resursa. Osim toga, prednosti migracije nadmašuju samu uslugu GitLab.com. Svaka poboljšanja službenog Helm dijagrama koriste i njegovi korisnici.
Nadam se da vam se svidjela priča o našim avanturama s migracijom na Kubernetes. Nastavljamo premještati sve nove usluge u klaster. Dodatne informacije možete pronaći u sljedećim publikacijama:
- «»;
- «»;
- .
P.S. od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
Finnish
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish