Notu. transl.: Kubernetes-adopto ĉe GitLab estas konsiderata unu el la du ĉefaj faktoroj kontribuantaj al la kresko de la kompanio. Tamen, ĝis antaŭ nelonge, la infrastrukturo de la interreta servo GitLab.com estis konstruita sur virtualaj maŝinoj, kaj nur antaŭ ĉirkaŭ unu jaro komenciĝis ĝia migrado al K8s, kiu ankoraŭ ne estas finita. Ni ĝojas prezenti tradukon de lastatempa artikolo de GitLab SRE-inĝeniero pri kiel tio okazas kaj kiajn konkludojn faras la inĝenieroj partoprenantaj en la projekto.
Jam de ĉirkaŭ unu jaro, nia infrastruktura divido migras ĉiujn servojn kurantajn sur GitLab.com al Kubernetes. Dum ĉi tiu tempo, ni renkontis defiojn rilatajn ne nur al translokado de servoj al Kubernetes, sed ankaŭ al administrado de la hibrida deplojo dum la transiro. La valoraj lecionoj, kiujn ni lernis, estos diskutitaj en ĉi tiu artikolo.
De la komenco mem de GitLab.com, ĝiaj serviloj funkciis en la nubo sur virtualaj maŝinoj. Ĉi tiuj virtualaj maŝinoj estas administritaj de Chef kaj instalitaj per nia . se la aplikaĵo devas esti ĝisdatigita, konsistas el simple ĝisdatigi la servilfloton en kunordigita, sinsekva maniero uzante CI-dukton. Ĉi tiu metodo - kvankam malrapida kaj iomete - certigas, ke GitLab.com uzas la samajn instaladojn kaj agordajn praktikojn kiel eksterretaj uzantoj (mem-administrata) GitLab-instalaĵoj uzante niajn Linuksajn pakaĵojn por tio.
Ni uzas ĉi tiun metodon ĉar estas ege grave sperti ĉiujn malĝojojn kaj ĝojojn, kiujn ordinaraj membroj de la komunumo spertas kiam ili instalas kaj agordas siajn kopiojn de GitLab. Ĉi tiu aliro funkciis bone dum iom da tempo, sed kiam la nombro da projektoj en GitLab superis 10 milionojn, ni rimarkis, ke ĝi ne plu kontentigis niajn bezonojn por skalo kaj disvastigo.
Unuaj paŝoj al Kubernetes kaj nubo-denaska GitLab
La projekto estis kreita en 2017 por prepari GitLab por nuba deplojo, kaj ebligi uzantojn instali GitLab sur Kubernetes-aretoj. Ni sciis tiam, ke movi GitLab al Kubernetes pliigos la skaleblon de la platformo SaaS, simpligus deplojojn kaj plibonigus la efikecon de komputikaj rimedoj. Samtempe, multaj el la funkcioj de nia aplikaĵo dependis de muntitaj NFS-diskoj, kiuj malrapidigis la transiron de virtualaj maŝinoj.
La puŝo al nubo-indiĝeno kaj Kubernetes permesis al niaj inĝenieroj plani laŭpaŝan transiron, dum kiu ni forlasis iujn el la dependecoj de la aplikaĵo pri retstokado dum daŭre disvolvi novajn funkciojn. Ekde kiam ni komencis plani la migradon en la somero de 2019, multaj el ĉi tiuj limigoj estis solvitaj, kaj la procezo de migrado de GitLab.com al Kubernetes nun estas bone marŝata!
Trajtoj de GitLab.com en Kubernetes
Por GitLab.com, ni uzas ununuran regionan GKE-areton, kiu pritraktas la tutan aplikan trafikon. Por minimumigi la kompleksecon de la (jam malfacila) migrado, ni koncentriĝas pri servoj, kiuj ne dependas de loka stokado aŭ NFS. GitLab.com uzas ĉefe monolitan kodbazon de Rails, kaj ni direktas trafikon bazitan sur laborŝarĝaj trajtoj al malsamaj finpunktoj, kiuj estas izolitaj en siajn proprajn nodajn naĝejojn.
En la kazo de la fasado, ĉi tiuj tipoj estas dividitaj en petojn al retejo, API, Git SSH/HTTPS kaj Registro. En la kazo de la backend, ni disigas laborpostenojn en la vosto laŭ diversaj karakterizaĵoj depende de , kiuj ebligas al ni agordi Servonivelajn Celojn (SLO) por diversaj laborŝarĝoj.
Ĉiuj ĉi tiuj GitLab.com-servoj estas agorditaj per nemodifita GitLab Helm-diagramo. Agordo estas farita en subdiagramoj, kiuj povas esti selekteme ebligitaj dum ni iom post iom migras servojn al la areto. Kvankam ni decidis ne inkluzivi kelkajn el niaj ŝtataj servoj en la migrado, kiel Redis, Postgres, GitLab Pages kaj Gitaly, uzi Kubernetes permesas al ni radikale redukti la nombron da VM-oj kiujn Chef nuntempe administras.
Kubernetes-Agordo Videbleco kaj Administrado
Ĉiuj agordoj estas administritaj de GitLab mem. Por tio, tri agordaj projektoj bazitaj sur Terraform kaj Helm estas uzataj. Ni provas, kiam ajn eblas, uzi GitLab mem por ruli GitLab, sed por funkciaj taskoj ni havas apartan GitLab-instalaĵon. Ĉi tio necesas por certigi, ke vi ne dependas de la havebleco de GitLab.com kiam vi faras GitLab.com-deplojojn kaj ĝisdatigojn.
Kvankam niaj duktoj por la Kubernetes-areo funkcias per aparta GitLab-instalaĵo, ekzistas speguloj de la kodaj deponejoj kiuj estas publike haveblaj ĉe la sekvaj adresoj:
- — GitLab.com agorda kadro por la GitLab Helm-diagramo;
- - Enhavas agordojn por servoj, kiuj ne rekte rilatas al la aplikaĵo GitLab. Ĉi tiuj inkluzivas agordojn por registrado kaj monitorado de aretoj, same kiel integrajn ilojn kiel PlantUML;
- — Terraform-agordo por Kubernetes kaj hereda VM-infrastrukturo. Ĉi tie vi agordas ĉiujn rimedojn necesajn por ruli la areton, inkluzive de la areto mem, nodaj naĝejoj, servaj kontoj kaj IP-adresrezervoj.
Publika vido montriĝas kiam ŝanĝoj estas faritaj. kun ligo al la detala diferenco kiun SRE analizas antaŭ fari ŝanĝojn al la areto.
Por SRE, la ligo kondukas al detala diferenco en la GitLab-instalaĵo, kiu estas uzata por produktado kaj aliro al kiu estas limigita. Ĉi tio permesas al dungitoj kaj la komunumo, sen aliro al la funkcia projekto (kiu estas malfermita nur al SREoj), vidi proponitajn agordajn ŝanĝojn. Kombinante publikan ekzemplon de GitLab por kodo kun privata petskribo por CI-duktoj, ni konservas ununuran laborfluon dum certigante sendependecon de GitLab.com por agordaj ĝisdatigoj.
Kion ni eksciis dum la migrado
Dum la movo, oni akiris sperton, kiun ni aplikas al novaj migradoj kaj deplojoj en Kubernetes.
1. Pliigitaj kostoj pro trafiko inter haveblecaj zonoj
Ĉiutagaj eliraj statistikoj (bajtoj tage) por la deponejo de Git ĉe GitLab.com
Guglo dividas sian reton en regionojn. Tiuj, siavice, estas dividitaj en alireblajn zonojn (AZ). Git-gastigado estas asociita kun grandaj kvantoj da datumoj, do gravas por ni kontroli la retan eliron. Por interna trafiko, eliro estas libera nur se ĝi restas ene de la sama havebleczono. De ĉi tiu skribado, ni servas proksimume 100 TB da datumoj en tipa labortago (kaj tio estas nur por Git-deponejoj). Servoj kiuj loĝis en la samaj virtualaj maŝinoj en nia malnova VM-bazita topologio nun funkcias en malsamaj Kubernetes-podoj. Ĉi tio signifas, ke iu trafiko, kiu antaŭe estis loka al la VM, povus eble vojaĝi ekster havebleczonoj.
Regionaj GKE-aretoj permesas vin ampleksi plurajn Disponeczonojn por redundo. Ni pripensas la eblecon por servoj kiuj generas grandajn volumojn de trafiko. Ĉi tio reduktos elirkostojn konservante grapol-nivelan redundon.
2. Limoj, rimedopetoj kaj skalo
La nombro da kopioj prilaboranta produktan trafikon ĉe registry.gitlab.com. Trafiko kulminas je ~15:00 UTC.
Nia migra rakonto komenciĝis en aŭgusto 2019, kiam ni migris nian unuan servon, la GitLab Container Registry, al Kubernetes. Ĉi tiu misi-kritika, alta trafika servo estis bona elekto por la unua migrado ĉar ĝi estas sennacia aplikaĵo kun malmultaj eksteraj dependecoj. La unua problemo, kiun ni renkontis, estis granda nombro da elpelitaj balgoj pro manko de memoro sur la nodoj. Pro tio, ni devis ŝanĝi petojn kaj limojn.
Oni trovis, ke en la kazo de aplikaĵo, kie la konsumo de memoro pliiĝas laŭlonge de la tempo, malaltaj valoroj por petoj (rezervante memoron por ĉiu pod) kune kun "malavara" malmola limo de uzado kondukis al saturiĝo. (saturiĝo) nodoj kaj alta nivelo de eldomigoj. Por trakti ĉi tiun problemon, ĝi estis . Ĉi tio forigis la premon de la nodoj kaj certigis, ke la podoj havas vivociklon, kiu ne tro premas la nodon. Nun ni komencas migradojn kun malavaraj (kaj preskaŭ identaj) petaj kaj limvaloroj, alĝustigante ilin laŭbezone.
3. Metriko kaj ŝtipoj
La infrastruktura divido fokusiĝas pri latencia, eraroprocentoj kaj saturiĝo kun instalita (SLO) ligita al .
Dum la pasinta jaro, unu el la ŝlosilaj eventoj en la infrastruktura divido estis plibonigoj en monitorado kaj laborado kun SLOoj. SLO-oj permesis al ni fiksi celojn por individuaj servoj, kiujn ni atente kontrolis dum la migrado. Sed eĉ kun ĉi tiu plibonigita observeblo, ne ĉiam eblas tuj vidi problemojn uzante metrikojn kaj atentigojn. Ekzemple, fokusante pri latenteco kaj erarprocentoj, ni ne plene kovras ĉiujn uzkazojn por servo spertanta migradon.
Ĉi tiu problemo estis malkovrita preskaŭ tuj post migrado de iuj laborŝarĝoj al la areto. Ĝi fariĝis precipe akra kiam ni devis kontroli funkciojn por kiuj la nombro da petoj estis malgranda, sed kiuj havis tre specifajn agordajn dependecojn. Unu el la ĉefaj lecionoj de la migrado estis la bezono konsideri ne nur metrikojn dum monitorado, sed ankaŭ ŝtipojn kaj la "longan voston" (ĉi tio temas pri sur la diagramo - ĉ. traduk.) eraroj. Nun por ĉiu migrado ni inkluzivas detalan liston de protokolaj demandoj (protokoloj) kaj planu klarajn retroigajn procedurojn, kiuj povas esti translokigitaj de unu deĵoro al la sekva se aperos problemoj.
Servado de la samaj petoj paralele sur la malnova VM-infrastrukturo kaj la nova Kubernetes-bazita infrastrukturo prezentis unikan defion. Male al lift-kaj-ŝanĝa migrado (rapida translokigo de aplikaĵoj "kiel estas" al nova infrastrukturo; pli da detaloj legeblas, ekzemple, - ĉ. traduk.), paralela laboro pri "malnovaj" VMs kaj Kubernetes postulas, ke monitoraj iloj estu kongruaj kun ambaŭ medioj kaj povi kombini metrikojn en unu vido. Gravas, ke ni uzu la samajn panelojn kaj protokolojn por atingi konsekvencan observeblecon dum la transira periodo.
4. Ŝanĝi trafikon al nova areto
Por GitLab.com, parto de la serviloj estas dediĉita al . Canary Park servas niajn internajn projektojn kaj povas ankaŭ . Sed ĝi estas ĉefe desegnita por testi ŝanĝojn faritajn al la infrastrukturo kaj aplikaĵo. La unua migrita servo komenciĝis akceptante limigitan kvanton da interna trafiko, kaj ni daŭre uzas ĉi tiun metodon por certigi ke SLOoj estas plenumitaj antaŭ sendi la tutan trafikon al la areto.
En la kazo de migrado, ĉi tio signifas, ke petoj al internaj projektoj unue estas senditaj al Kubernetes, kaj poste ni iom post iom ŝanĝas la reston de la trafiko al la areto ŝanĝante la pezon por la backend per HAProxy. Dum la migrado de VM al Kubernetes, evidentiĝis, ke estas tre utile havi facilan manieron redirekti trafikon inter la malnova kaj nova infrastrukturo kaj, sekve, teni la malnovan infrastrukturon preta por retroigo en la unuaj tagoj post la migrado.
5. Rezervaj kapabloj de podoj kaj ilia uzo
Preskaŭ tuj la sekva problemo estis identigita: podoj por la Registroservo komenciĝis rapide, sed lanĉi podojn por Sidekiq daŭris ĝis . La longa daŭra tempo por Sidekiq-podoj fariĝis problemo kiam ni komencis migri laborŝarĝojn al Kubernetes por laboristoj, kiuj devis prilabori laborojn rapide kaj rapide skali.
En ĉi tiu kazo, la leciono estis, ke dum Horizontal Pod Autoscaler (HPA) en Kubernetes faras bonan laboron por trakti trafikan kreskon, estas grave konsideri la karakterizaĵojn de la laborŝarĝoj kaj asigni rezervan kapaciton al la podoj (precipe kiam postulo estas. malegale distribuita). En nia kazo, estis subita kresko de laborpostenoj, kondukante al rapida skalo, kiu kondukis al saturiĝo de CPU-resursoj antaŭ ol ni havis tempon por grimpi la nodan naĝejon.
Ĉiam estas tento elpremi kiel eble plej multe el areto, tamen, komence renkontinte rendimentajn problemojn, ni nun komencas kun malavara podbuĝeto kaj reduktas ĝin poste, atentante SLO-ojn. La lanĉo de podoj por la servo Sidekiq estis signife akcelita kaj nun daŭras proksimume 40 sekundojn averaĝe. gajnis kaj GitLab.com kaj niajn uzantojn de memadministrataj instalaĵoj laborantaj kun la oficiala GitLab Helm-diagramo.
konkludo
Post migrado de ĉiu servo, ni ĝojis pri la avantaĝoj de uzado de Kubernetes en produktado: pli rapida kaj pli sekura aplikaĵa disfaldo, skalo kaj pli efika asigno de rimedoj. Krome, la avantaĝoj de migrado iras preter la servo GitLab.com. Ĉiu plibonigo de la oficiala Helm-diagramo profitigas ĝiajn uzantojn.
Mi esperas, ke vi ĝuis la rakonton pri niaj migraj aventuroj de Kubernetes. Ni daŭre migras ĉiujn novajn servojn al la areto. Pliaj informoj troveblas en la sekvaj publikaĵoj:
- «»;
- «»;
- .
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com