Bilješka. prev.: Usvajanje Kubernetesa u GitLabu smatra se jednim od dva glavna čimbenika koji doprinose rastu tvrtke. No, donedavno je infrastruktura GitLab.com online servisa bila izgrađena na virtualnim strojevima, a tek prije otprilike godinu dana započela je njegova migracija na K8s, koja još uvijek nije dovršena. Zadovoljstvo nam je predstaviti prijevod nedavnog članka GitLab SRE inženjera o tome kako se to događa i kakve zaključke donose inženjeri koji sudjeluju u projektu.
Već otprilike godinu dana naš odjel infrastrukture migrira sve usluge koje se izvode na GitLab.com na Kubernetes. Tijekom tog vremena naišli smo na izazove povezane ne samo s premještanjem usluga na Kubernetes, već i s upravljanjem hibridnom implementacijom tijekom prijelaza. O vrijednim lekcijama koje smo naučili raspravljat ćemo u ovom članku.
Od samog početka GitLab.com-a, njegovi poslužitelji radili su u oblaku na virtualnim strojevima. Tim virtualnim strojevima upravlja Chef, a instalirani su pomoću našeg . u slučaju da aplikaciju treba ažurirati, sastoji se od jednostavnog ažuriranja flote poslužitelja na koordiniran, sekvencijalan način pomoću CI cjevovoda. Ova metoda - iako sporo i malo - osigurava da GitLab.com koristi iste postupke instalacije i konfiguracije kao izvanmrežni korisnici (samoupravljanje) Instalacije GitLaba za to koriste naše Linux pakete.
Koristimo ovu metodu jer je izuzetno važno iskusiti sve tuge i radosti koje obični članovi zajednice doživljavaju kada instaliraju i konfiguriraju svoje kopije GitLaba. Ovaj je pristup dobro funkcionirao neko vrijeme, ali kada je broj projekata na GitLabu premašio 10 milijuna, shvatili smo da više ne zadovoljava naše potrebe za skaliranjem i implementacijom.
Prvi koraci prema Kubernetesu i GitLabu izvornom u oblaku
Projekt je nastao 2017. godine pripremiti GitLab za implementaciju u oblaku i omogućiti korisnicima da instaliraju GitLab na Kubernetes klastere. Tada smo znali da bi premještanje GitLaba u Kubernetes povećalo skalabilnost SaaS platforme, pojednostavilo implementacije i poboljšalo učinkovitost računalnih resursa. U isto vrijeme, mnoge funkcije naše aplikacije ovisile su o montiranim NFS particijama, što je usporavalo prijelaz s virtualnih strojeva.
Pomak prema izvornom oblaku i Kubernetesu omogućio je našim inženjerima planiranje postupnog prijelaza, tijekom kojeg smo napustili neke ovisnosti aplikacije o mrežnoj pohrani dok smo nastavili razvijati nove značajke. Otkako smo počeli planirati migraciju u ljeto 2019., mnoga od ovih ograničenja su riješena, a proces migracije GitLab.com na Kubernetes sada je uveliko u tijeku!
Značajke GitLab.com u Kubernetesu
Za GitLab.com koristimo jedan regionalni GKE klaster koji obrađuje sav promet aplikacija. Kako bismo smanjili složenost (ionako zahtjevne) migracije, usredotočeni smo na usluge koje se ne oslanjaju na lokalnu pohranu ili NFS. GitLab.com koristi pretežno monolitnu Rails kodnu bazu, a mi usmjeravamo promet na temelju karakteristika radnog opterećenja na različite krajnje točke koje su izolirane u vlastite skupove čvorova.
U slučaju sučelja, te se vrste dijele na zahtjeve za web, API, Git SSH/HTTPS i registar. U slučaju backenda, dijelimo poslove u redu čekanja prema različitim karakteristikama ovisno o , koji nam omogućuju da postavimo ciljeve razine usluge (SLO) za različita radna opterećenja.
Sve ove usluge GitLab.com konfigurirane su pomoću neizmijenjenog grafikona GitLab Helm. Konfiguracija se provodi u podgramima, koji se mogu selektivno omogućiti kako postupno migriramo usluge u klaster. Iako smo odlučili ne uključiti neke od naših usluga s praćenjem stanja u migraciju, kao što su Redis, Postgres, GitLab Pages i Gitaly, korištenje Kubernetesa omogućuje nam radikalno smanjenje broja VM-ova kojima Chef trenutno upravlja.
Vidljivost i upravljanje Kubernetes konfiguracijom
Svim postavkama upravlja sam GitLab. Za to se koriste tri konfiguracijska projekta temeljena na Terraformu i Helmu. Trudimo se koristiti sam GitLab kad god je to moguće za pokretanje GitLaba, ali za operativne zadatke imamo zasebnu instalaciju GitLaba. Ovo je potrebno kako biste bili sigurni da ne ovisite o dostupnosti GitLab.com prilikom izvođenja GitLab.com implementacija i ažuriranja.
Iako se naši cjevovodi za Kubernetes klaster izvode na zasebnoj GitLab instalaciji, postoje zrcala repozitorija koda koji su javno dostupni na sljedećim adresama:
- — GitLab.com konfiguracijski okvir za GitLab Helm grafikon;
- - Sadrži konfiguracije za usluge koje nisu izravno povezane s GitLab aplikacijom. To uključuje konfiguracije za bilježenje i praćenje klastera, kao i integrirane alate poput PlantUML;
- — Terraform konfiguracija za Kubernetes i naslijeđenu VM infrastrukturu. Ovdje konfigurirate sve resurse potrebne za pokretanje klastera, uključujući sam klaster, skupove čvorova, račune usluga i rezervacije IP adresa.
Javni prikaz se prikazuje kada se naprave promjene. s vezom na detaljnu razliku koju SRE analizira prije unošenja promjena u klaster.
Za SRE, poveznica vodi do detaljne razlike u GitLab instalaciji, koja se koristi za proizvodnju i kojoj je pristup ograničen. To omogućuje zaposlenicima i zajednici, bez pristupa operativnom projektu (koji je otvoren samo za SRE), da vide predložene promjene konfiguracije. Kombinacijom javne GitLab instance za kod s privatnom instancom za CI cjevovode, održavamo jedan radni tijek dok osiguravamo neovisnost o GitLab.com za konfiguracijska ažuriranja.
Što smo saznali tijekom migracije
Tijekom preseljenja stečeno je iskustvo koje primjenjujemo na nove migracije i implementacije u Kubernetesu.
1. Povećani troškovi zbog prometa između zona dostupnosti
Dnevna izlazna statistika (bajtova po danu) za flotu Git repozitorija na GitLab.com
Google svoju mrežu dijeli na regije. One su pak podijeljene u zone pristupačnosti (AZ). Git hosting povezan je s velikim količinama podataka, stoga nam je važno kontrolirati izlaz iz mreže. Za interni promet izlaz je besplatan samo ako ostane unutar iste zone dostupnosti. Od pisanja ovog teksta, opslužujemo približno 100 TB podataka u tipičnom radnom danu (i to samo za Git repozitorije). Usluge koje su se nalazile na istim virtualnim strojevima u našoj staroj topologiji temeljenoj na VM-u sada se izvode u različitim Kubernetes podovima. To znači da bi dio prometa koji je prethodno bio lokalan za VM potencijalno mogao putovati izvan zona dostupnosti.
Regionalni GKE klasteri omogućuju vam da obuhvatite više zona dostupnosti radi redundantnosti. Razmatramo tu mogućnost za usluge koje generiraju velike količine prometa. To će smanjiti izlazne troškove uz zadržavanje redundancije na razini klastera.
2. Ograničenja, zahtjevi za resursima i skaliranje
Broj replika koje obrađuju proizvodni promet na registry.gitlab.com. Promet je najveći u ~15:00 UTC.
Naša priča o migraciji započela je u kolovozu 2019., kada smo migrirali našu prvu uslugu, GitLab Container Registry, na Kubernetes. Ova kritična usluga s velikim prometom bila je dobar izbor za prvu migraciju jer je to aplikacija bez statusa s nekoliko vanjskih ovisnosti. Prvi problem s kojim smo se susreli bio je velik broj izbačenih podova zbog nedostatka memorije na čvorovima. Zbog toga smo morali promijeniti zahtjeve i limite.
Otkriveno je da su u slučaju aplikacije u kojoj se potrošnja memorije povećava tijekom vremena, niske vrijednosti za zahtjeve (rezerviranje memorije za svaku mahunu) zajedno s "velikodušnim" čvrstim ograničenjem upotrebe dovele do zasićenja (zasićenje) čvorova i visoku razinu deložacija. Nositi se s ovim problemom, bilo je . Ovo je smanjilo pritisak na čvorove i osiguralo da mahune imaju životni ciklus koji ne stavlja preveliki pritisak na čvor. Sada započinjemo migracije s velikodušnim (i gotovo identičnim) zahtjevima i graničnim vrijednostima, prilagođavajući ih prema potrebi.
3. Metrike i dnevnici
Odjel za infrastrukturu fokusiran je na kašnjenje, stope pogrešaka i zasićenost instaliranim (SLO) povezan s .
Tijekom prošle godine, jedan od ključnih događaja u odjelu infrastrukture bila su poboljšanja u praćenju i radu s ČVN-ima. ČVN-i su nam omogućili da postavimo ciljeve za pojedinačne usluge koje smo pomno pratili tijekom migracije. Ali čak i uz ovu poboljšanu vidljivost, nije uvijek moguće odmah uočiti probleme pomoću metrike i upozorenja. Na primjer, usredotočujući se na kašnjenje i stope pogrešaka, ne pokrivamo u potpunosti sve slučajeve upotrebe za uslugu koja prolazi kroz migraciju.
Ovaj je problem otkriven gotovo odmah nakon migracije nekih radnih opterećenja u klaster. To je postalo posebno akutno kada smo morali provjeriti funkcije za koje je broj zahtjeva bio mali, ali koje su imale vrlo specifične konfiguracijske ovisnosti. Jedna od ključnih lekcija iz migracije bila je potreba da se uzmu u obzir ne samo metrike prilikom praćenja, već i zapisnici i "dugi rep" (radi se o na karti - cca. prev.) pogreške. Sada za svaku migraciju uključujemo detaljan popis upita dnevnika (upiti dnevnika) i planirati jasne postupke povratka koji se mogu prenijeti iz jedne smjene u drugu ako se pojave problemi.
Usluživanje istih zahtjeva paralelno na staroj VM infrastrukturi i novoj infrastrukturi temeljenoj na Kubernetesu predstavljalo je jedinstven izazov. Za razliku od lift-and-shift migracije (brzi prijenos aplikacija "kakve jesu" na novu infrastrukturu; više detalja možete pročitati, npr. - cca. prev.), paralelni rad na "starim" VM-ovima i Kubernetesu zahtijeva da alati za praćenje budu kompatibilni s oba okruženja i da mogu kombinirati metrike u jedan prikaz. Važno je da koristimo iste nadzorne ploče i upite dnevnika kako bismo postigli dosljednu vidljivost tijekom prijelaznog razdoblja.
4. Prebacivanje prometa na novi klaster
Za GitLab.com, dio poslužitelja posvećen je . Canary Park služi našim internim projektima i također može . Ali prvenstveno je osmišljen za testiranje promjena napravljenih na infrastrukturi i aplikaciji. Prva migrirana usluga započela je prihvaćanjem ograničene količine internog prometa, a mi nastavljamo koristiti ovu metodu kako bismo osigurali ispunjenje SLO prije slanja cjelokupnog prometa u klaster.
U slučaju migracije, to znači da se zahtjevi za interne projekte prvo šalju u Kubernetes, a zatim postupno prebacujemo ostatak prometa na klaster mijenjajući težinu za backend kroz HAProxy. Tijekom migracije s VM-a na Kubernetes postalo je jasno da je vrlo korisno imati jednostavan način preusmjeravanja prometa između stare i nove infrastrukture i, sukladno tome, održavati staru infrastrukturu spremnom za vraćanje na staro stanje u prvih nekoliko dana nakon migracije.
5. Rezervni kapaciteti mahuna i njihovo korištenje
Skoro odmah je identificiran sljedeći problem: podovi za uslugu Registry pokrenuti su brzo, ali pokretanje podova za Sidekiq trajalo je do . Dugo vrijeme pokretanja za Sidekiq podove postalo je problem kada smo započeli migraciju radnih opterećenja na Kubernetes za radnike koji su trebali brzo obraditi poslove i brzo se skalirati.
U ovom slučaju, lekcija je bila da dok Kubernetesov Horizontal Pod Autoscaler (HPA) dobro podnosi rast prometa, važno je uzeti u obzir karakteristike radnih opterećenja i dodijeliti rezervni kapacitet podovima (posebno kada je potražnja neravnomjerno raspoređena). U našem slučaju, došlo je do iznenadnog porasta poslova, što je dovelo do brzog skaliranja, što je dovelo do zasićenja CPU resursa prije nego što smo imali vremena skalirati skup čvorova.
Uvijek postoji iskušenje da se iz klastera iscijedi što je više moguće, međutim, nakon što smo u početku naišli na probleme s izvedbom, sada počinjemo s izdašnim proračunom za podove i kasnije ga smanjujemo, pažljivo pazeći na SLO-ove. Lansiranje kapsula za uslugu Sidekiq znatno je ubrzano i sada u prosjeku traje oko 40 sekundi. osvojio je i GitLab.com i naše korisnike samoupravljanih instalacija koje rade sa službenom ljestvicom GitLab Helm.
Zaključak
Nakon migracije svake usluge, radovali smo se prednostima korištenja Kubernetesa u proizvodnji: bržem i sigurnijem postavljanju aplikacija, skaliranju i učinkovitijoj raspodjeli resursa. Štoviše, prednosti migracije nadilaze GitLab.com uslugu. Svako poboljšanje službene karte Helm koristi korisnicima.
Nadam se da ste uživali u priči o našim avanturama migracije na Kubernetes. Nastavljamo s migracijom svih novih usluga u klaster. Dodatne informacije možete pronaći u sljedećim publikacijama:
- «»;
- «»;
- .
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com