🥇 Naši sklepi po letu migracije GitLab.com na Kubernetes

Op. prev.: Adaptacija Kubernetes v GitLab se smatra jednim od dva glavna faktora koji doprinose rastu kompanije. Ipak, do nedavno, infrastruktura online usluge GitLab.com je bila izgrađena na virtuelnim mašinama, a migracija u K8s je započela pre oko godine, koja još uvek nije završena. Rado predstavljamo prevod nedavne članka SRE inženjera GitLab-a o tome kako to funkcioniše i koje zaključke donose inženjeri uključeni u projekat.

Već gotovo godinu dana naše infrastrukturno odeljenje se bavi migracijom svih usluga koje rade na GitLab.com u Kubernetes. Tokom tog perioda, suočili smo se s problemima koji se ne odnose samo na premještanje usluga u Kubernetes, već i na upravljanje hibridnim deployment-om tokom prelaska. O vrednim lekcima koje smo naučili, biće reči u ovom članku.

Od samog početka GitLab.com, njegovi serveri su radili u oblaku na virtuelnim mašinama. Tim virtuelnim mašinama upravlja Chef, a njihova instalacija se vrši pomoću našeg official Linux paketa. Strategija implementacije u slučaju da je potrebno ažurirati aplikaciju, sastoji se u jednostavnom ažuriranju servera naglašeno koordiniranim redosledom uz pomoć CI pipeline-a. Ova metoda — iako spora i pomalo dosadna garantuje da GitLab.com primenjuje iste metode instaliranja i konfiguracije koje koriste korisnici lokalnih (self-managed) instalacija GitLab-a, koje koriste naše Linux pakete.

Koristimo ovu metodu jer je izuzetno važno osetiti sve brige i radosti koje obični članovi zajednice doživljavaju dok instaliraju i konfigurišu svoje kopije GitLab-a. Ovaj pristup je dobro funkcionisao određeno vreme, međutim, kada je broj projekata na GitLab-u premašio 10 miliona, 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, projekat je stvoren GitLab Charts za pripravo GitLab za implementacijo v oblaku ter da bi uporabnikom omogočili namestitev GitLab v Kubernetes grozde. Takrat smo vedeli, da bo prenos GitLab v Kubernetes povečal možnosti skaliranja SaaS platforme, poenostavil implementacije in povečal učinkovitost rabe računalniških virov. Hkrati so mnoge funkcije naše aplikacije temeljile na nameščenih NFS particijah, kar je upočasnilo prehod z virtualnih strojev.

Pot do cloud native in Kubernetes je našim inženirjem omogočila, da so načrtovali postopni prehod, pri katerem smo se odrekli nekaterim odvisnostim aplikacije od omrežnih shranjevanj, hkrati pa še naprej razvijali nove funkcije. Odkar smo začeli načrtovati migracijo poleti 2019, so bila številna ta omejitev odpravljena, proces prenosa GitLab.com na Kubernetes pa sedaj poteka s polno paro!

Značilnosti delovanja GitLab.com v Kubernetesu

Za GitLab.com uporabljamo enotni regionalni GKE grozd, ki obdeluje ves promet aplikacije. Da bi zmanjšali kompleksnost (itak že zapletenega) prenosa, se osredotočamo na storitve, ki niso odvisne od lokalnega shranjevanja ali NFS. GitLab.com večinoma uporablja monolitno bazno kodo na Rails in promet usmerjamo glede na značilnosti delovne obremenitve na različne končne točke, izolirane v svoje lastne skupine vozlišč.

V primeru frontenda se ti tipi delijo na poizvedbe za web, API, Git SSH/HTTPS in Registry. V primeru backend-a razdelimo naloge v vrstah glede na različne značilnosti na podlagi vnaprej določenih mejnikov virov, ki nam omogočajo določitev ciljev ravni storitev (Service-Level Objectives, SLOs) za različne obremenitve.

Vse te storitve GitLab.com so nastavljene s pomočjo nemodificiranega Helm grafa GitLab. Konfiguracija se izvaja v subgrafih, ki jih lahko izbira vključujemo, ko postopoma prenašamo storitve v grozd. Tudi ob upoštevanju, da smo se odločili, da ne vključimo v migracijo nekaterih naših stateful storitev, kot so Redis, Postgres, GitLab Pages in Gitaly, uporaba Kubernetes omogoča drastično zmanjšanje števila VM-ov, ki jih trenutno upravlja Chef.

Pripravljenost in upravljanje konfiguracije Kubernetes

Vse nastavitve upravlja sam GitLab. Za to se uporabljajo trije konfiguracijski projekti na osnovi Terraform in Helm. Trudimo se, da na vse mogoče načine uporabimo sam GitLab za zagon GitLab-a, vendar imamo za operativne naloge ločeno namestitev GitLab. Ta je potrebna, da ne bi bili odvisni od razpoložljivosti GitLab.com pri izvajanju implementacij in posodobitev GitLab.com.

Čeprav naši pipeline-i za Kubernetes klaster delujejo na ločeni namestitvi GitLab, imajo repozitoriji kode zrcaljenja, javno dostopna na naslednjih naslovih:

k8s-workloads/gitlab-com — konfiguracijska obveznica GitLab.com za Helm chart GitLab;
k8s-workloads/gitlab-helmfiles — vsebuje konfiguracije za storitve, ki niso neposredno povezane z aplikacijo GitLab. Sem spadajo konfiguracije za beleženje in spremljanje klasterja, kot tudi za integrirane instrumente, kot je PlantUML;
Gitlab-com-infrastructure — konfiguracija Terraform za Kubernetes in staro (legacy) VM infrastrukturo. Tukaj se konfigurirajo vsi viri, potrebni za zagon klasterja, vključno s samim klasterjem, bazeni vozlišč, računi storitev, rezervacijo IP naslovov.

Ko so spremembe uvedene, se prikaže javna kratek povzetek s povezavo na podroben diff, ki ga SRE analizira pred uvedbo sprememb v klaster.

Za SRE povezava vodi na podroben diff v namestitvi GitLab, ki se uporablja za obratovanje in dostop do katerega je omejen. To omogoča zaposlenim in skupnosti brez dostopa do operativnega projekta (ta je odprt samo za SRE), da si ogledajo predlagane spremembe v konfiguraciji. S kombiniranjem javne instance GitLab-a za kodo z zasebno instance za CI pipeline, ohranjamo enoten delovni postopek, hkrati pa zagotavljamo neodvisnost od GitLab.com pri posodobitvah konfiguracije.

Kaj smo ugotovili med migracijo

Med selitvijo se je nakopičila izkušnja, ki jo uporabljamo za nove migracije in implementacije v Kubernetes.

1. Povečanje stroškov zaradi prometa med območji dostopnosti

Dnevna egress statistika (bajti na dan) za park Git shranjevanj na GitLab.com

Google razdvaja svoju mrežu na regione. Ovi se zatim deli na zone dostupnosti (AZ). Git hosting je povezan s velikim količinama podataka, stoga je važno kontrolisati mrežni egress. U slučaju internog saobraćaja, egress je besplatan samo ako ostaje unutar jedne zone dostupnosti. U trenutku pisanja ovog članka, svakodnevno prenosimo oko 100 TB podataka (i to je samo za Git repozitorije). Servisi koji su u našoj staroj topologiji zasnovanoj na VM-ima radili na istim virtuelnim mašinama, sada funkcionišu u različitim podovima Kubernetes-a. To znači da deo saobraćaja, koji je ranije bio lokalni za VM, može potencijalno izlaziti izvan zona dostupnosti.

Regionalni GKE klasteri omogućavaju pokrivanje više zona dostupnosti za rezervaciju. Razmatramo mogućnost podeliti regionalni GKE klaster na jednonozne klastere za servise koji generišu velike količine saobraćaja. To će smanjiti troškove egress-a uz očuvanje rezervacije na nivou klastera.

2. Limiti, zahtevi resursa i skaliranje

Broj replika koji obrađuju production saobraćaj na registry.gitlab.com. Saobraćaj dostiže svoj vrhunac u ~15:00 UTC.

Naša priča o migraciji počela je u avgustu 2019. godine, kada smo prvi servis — GitLab Container Registry — prebacili u Kubernetes. Ovaj kritično važan servis s visokom trafikom bio je savršen za prvu migraciju, jer predstavlja stateless aplikaciju s malim brojem spoljašnjih zavisnosti. Prvi problem s kojim smo se suočili bilo je veliko broj izbačenih podova zbog nedostatka memorije na čvorovima. Zbog toga smo morali promeniti zahteve i limite.

Otkriveno je da u slučaju aplikacije koja tokom vremena povećava potrošnju memorije, niske vrednosti zahteva (rezervišući memoriju za svaki pod) zajedno s "dadežnim" strogim limitom na korišćenje dovode do zasićenja (saturation) čvorova i visokom nivou izbačenosti. Da bismo rešili ovaj problem, odlučeno je povećati zahteve i smanjiti limite. To je zmanjšalo pritisk na vozli in zagotovilo življenjski cikel pod-ov, ki ni postavljal prevelikega pritiska na vozlišče. Zdaj začnemo migracije z velikodušnimi (in skoraj enakimi) vrednostmi zahtevkov in omejitev, ki jih po potrebi prilagajamo.

3. Merila in dnevniški zapisi

Infrastrukturna enota se osredotoča na zakasnitve, odstotek napak in saturacijo z določenimi cilji nivoja storitve (SLO), vezanimi na skupno dostopnost našega sistema.

V preteklem letu je bil eden ključnih dogodkov v infrastrukturni enoti izboljšanje spremljanja in dela z SLO. SLO so nam omogočili postaviti cilje za posamezne storitve, za katere smo skrbno spremljali med migracijo. A tudi z izboljšanim nadzorom ni vedno mogoče takoj opaziti težav, ob uporabi meril in opozoril. Na primer, osredotočeni na zakasnitve in odstotek napak, ne pokrivamo popolnoma vseh scenarijev uporabe storitve, ki prehaja migracijo.

Ta težava je bila ugotovljena skoraj takoj po prenosu dela delovnih obremenitev v grozd. Še posebej se je izkazala, ko je bilo treba preveriti funkcije, število zahtevkov za katere je majhno, vendar imajo zelo specifične konfiguracijske odvisnosti. Ena ključnih lekcij po zaključku migracije je bila potreba, da pri spremljanju upoštevamo ne le merila, temveč tudi dnevnike in 'dolgi rep' (govorimo o takšnem njihovem razporedu na grafu — op. prev.) napak. Zdaj za vsako migracijo vključujemo podroben seznam zahtevkov za dnevnike (log queries) in načrtujemo jasne postopke za vračilo, ki jih ob morebitnih težavah lahko prenesemo iz ene izmena na drugo.

Paralelno obravnavanje istih zahtevkov na stari VM-infrastrukturi in novi, ki temelji na Kubernetesu, je predstavljalo edinstven izziv. Nasprotno od migracije tipa lift-and-shift (hitro prenesene aplikacije 'takšne, kot so' v novo infrastrukturo; več lahko preberete, na primer, ovde — op. prev.), sočasno delovanje na "starih" VM in Kubernetes zahteva, da so orodja za spremljanje združljiva z obema okoljema in znajo združiti metrike v enoten pogled. Pomembno je, da uporabljamo iste nadzorne plošče in poizvedbe za dnevnike, da dosežemo usklajeno opazovanje med prehodnim obdobjem.

4. Preusmeritev prometa na nov klaster

Za GitLab.com je del strežnikov namenjen kanarijski (canary) fazi. Kanarijski park podpira naše interne projekte, hkrati pa lahko vključuje uporabnike. Toda predvsem je namenjen preverjanju sprememb v infrastrukturi in aplikaciji. Prva prenesena storitev je začela z obravnavo omejene količine internega prometa, in ta pristop še naprej uporabljamo za zagotavljanje SLO pred preusmeritvijo celotnega prometa v klaster.

Pri migraciji to pomeni, da najprej v Kubernetes preusmerimo zahteve za interne projekte, nato pa postopoma preusmerjamo preostali promet v klaster z spremembo teže za backend prek HAProxy. Med prehodom z VM na Kubernetes se je izkazalo, da je zelo koristno imeti enostaven način za preusmerjanje prometa med staro in novo infrastrukturo ter ohranjati staro infrastrukturo pripravljeno za povratek v prvih nekaj dneh po migraciji.

5. Rezervne zmogljivosti pod-ov in njihova uporaba

Takoj se je pojavila naslednja težava: pod-i za storitev Registry so se hitro zagnali, vendar je zagon pod-ov za Sidekiq vzel do dveh minut. Dolgotrajno zagon pod-ov za Sidekiq je postal težava, ko smo začeli migracijo v Kubernetes delovnih obremenitev za delavce, ki morajo hitro obdelovati naloge in se hitro prilagajati.

V tem primeru je bila lekcija, da čeprav Horizontal Pod Autoscaler (HPA) v Kubernetes dobro obvladuje rast prometa, je pomembno upoštevati značilnosti delovnih obremenitev in dodeliti rezervne zmogljivosti pod-ov (še posebej v razmerah neenakomerne porazdelitve povpraševanja). V našem primeru smo opazili nenaden porast nalog, kar je povzročilo hitro prilagajanje, kar je privedlo do izčrpanosti virov CPU, preden smo uspeli prilagoditi skupino vozlišč.

Vedno obstaja skušnjava, da iz klustra izvlečemo čim več, vendar pa s problemi z zmogljivostjo, s katerimi smo se soočili že na začetku, zdaj začnemo s širokim proračunom za pod in ga kasneje zmanjšujemo, natančno spremljajoč SLO. Zagon podov za storitev Sidekiq se je znatno pospešil in zdaj povprečno traja okoli 40 sekund. Od skrajševanja časa zagona podov so tako GitLab.com kot naši uporabniki samostojnih inštalacij, ki delujejo z uradnim Helm chartom GitLab, pridobili.

Zaključek

Po selitvi vsake storitve smo uživali v prednostih uporabe Kubernetes v proizvodnji: hitrejše in varnejše uvajanje aplikacij, skaliranje in bolj učinkovita dodelitev virov. Prednosti migracije presegajo storitev GitLab.com. Vsako izboljšavo uradnega Helm charta pridobijo tudi njegovi uporabniki.

Upam, da vam je bila zgodba o naših dogodivščinah z migracijo v Kubernetes všeč. Nadaljujemo s selitvijo novih storitev v kluster. Dodatne informacije lahko najdete v naslednjih objavah: