{"id":94977,"date":"2020-09-24T07:43:00","date_gmt":"2020-09-24T05:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes"},"modified":"2020-09-24T07:43:00","modified_gmt":"2020-09-24T05:43:00","slug":"nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Vores konklusioner efter et \u00e5r med migration af GitLab.com til Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bem. overs.<\/b>: tilpasningen af Kubernetes i GitLab betragtes som en af de to vigtigste faktorer, der bidrager til virksomhedens v\u00e6kst. Indtil for nylig var infrastrukturen for online-tjenesten GitLab.com bygget p\u00e5 virtuelle maskiner, og f\u00f8rst for omkring et \u00e5r siden begyndte migreringen til K8s, som stadig ikke er afsluttet. Vi er glade for at pr\u00e6sentere overs\u00e6ttelsen af en nylig artikel af SRE-ingeni\u00f8ren fra GitLab om, hvordan dette forl\u00f8ber, og hvilke konklusioner ingeni\u00f8rerne, der deltager i projektet, drager.<\/i><\/p>\n

\"Vores
\n
\nI over et \u00e5r har vores infrastrukturafdeling arbejdet p\u00e5 at migrere alle tjenester, der k\u00f8rer p\u00e5 GitLab.com, til Kubernetes. I l\u00f8bet af denne tid er vi st\u00f8dt p\u00e5 problemer, der ikke kun relaterer sig til flytning af tjenester til Kubernetes, men ogs\u00e5 til at administrere hybriddeployment under overgangen. Denne artikel vil handle om de v\u00e6rdifulde lektioner, vi har l\u00e6rt.<\/a><\/noindex><\/p>\n

Fra starten har GitLab.coms servere k\u00f8rt i skyen p\u00e5 virtuelle maskiner. Disse virtuelle maskiner administreres af Chef, og deres installation sker via vores officielle Linux-pakke<\/a><\/noindex>. Udrulningsstrategi<\/a><\/noindex> i tilf\u00e6lde af at en opdatering af applikationen er n\u00f8dvendig, best\u00e5r i simpelthen at opdatere serverparken i en koordineret sekventiel r\u00e6kkef\u00f8lge ved hj\u00e6lp af en CI-pipeline. Denne metode - omend langsom og lidt kedelig<\/a><\/noindex> \u2014 sikrer, at GitLab.com bruger de samme installa- tions- og konfigurationsmetoder som brugerne af de selvadministrerede (self-managed)<\/i> installationer af GitLab, der anvender vores Linux-pakker.<\/p>\n

Vi bruger denne metode, fordi det er yderst vigtigt at opleve alle de sorger og gl\u00e6der, som de almindelige medlemmer af f\u00e6llesskabet f\u00f8ler, n\u00e5r de installerer og konfigurerer deres egen GitLab. Denne tilgang har fungeret godt i et stykke tid, men da antallet af projekter p\u00e5 GitLab oversteg 10 millioner, inds\u00e5 vi, at den ikke l\u00e6ngere opfylder vores behov for skalering og udrulning.<\/p>\n

De f\u00f8rste skridt mod Kubernetes og cloud-native GitLab<\/h2>\n

\nI 2017 blev projektet GitLab Charts<\/a><\/noindex> til at forberede GitLab til implementering i skyen samt at give brugerne mulighed for at installere GitLab i Kubernetes-klynger. Dengang vidste vi, at flytningen af GitLab til Kubernetes ville \u00f8ge skaleringsmulighederne for vores SaaS-platform, forenkle implementeringen og forbedre udnyttelsen af beregningressourcer. Samtidig var mange funktioner i vores applikation afh\u00e6ngige af monterede NFS-partitioner, hvilket h\u00e6mmede overgangen fra virtuelle maskiner.<\/p>\n

Str\u00e6ben efter cloud-native og Kubernetes har gjort det muligt for vores ingeni\u00f8rer at planl\u00e6gge en gradvis overgang, hvor vi har afvist nogle applikationsafh\u00e6ngigheder til netv\u00e6rkslagring, mens vi fortsat har udviklet nye funktioner. Siden vi begyndte at planl\u00e6gge migrationen sommeren 2019, er mange af disse begr\u00e6nsninger blevet elimineret, og processen med at overf\u00f8re GitLab.com til Kubernetes er nu i fuld gang!<\/p>\n

Funktionerne i GitLab.com i Kubernetes<\/h2>\n

\nFor GitLab.com bruger vi et samlet regionalt GKE-klynge, der h\u00e5ndterer al applikationstrafik. For at minimere kompleksiteten (som allerede er ret indviklet) ved migreringen fokuserer vi p\u00e5 tjenester, der ikke er afh\u00e6ngige af lokal lagring eller NFS. GitLab.com bruger prim\u00e6rt en monolitisk kodebase p\u00e5 Rails, og vi dirigerer trafik afh\u00e6ngigt af arbejdsbelastningens egenskaber til forskellige endpoints, der er isolerede i deres egne nodepuljer.<\/p>\n

I frontenden opdeles disse typer i anmodninger til web, API, Git SSH\/HTTPS og Registry. I backend opdeler vi job i k\u00f8erne baseret p\u00e5 forskellige karakteristika afh\u00e6ngig af forudbestemte gr\u00e6nser for ressourcer<\/a><\/noindex>, som g\u00f8r det muligt for os at s\u00e6tte servicem\u00e5l (Service-Level Objectives, SLOs) for forskellige belastninger.<\/p>\n

Alle disse tjenester p\u00e5 GitLab.com er konfigureret ved hj\u00e6lp af den u\u00e6ndrede Helm-chart for GitLab. Konfigurationen udf\u00f8res i subcharts, der selektivt kan aktiveres, efterh\u00e5nden som vi gradvist flytter tjenester til klyngen. Selvom det er besluttet ikke at inkludere nogle af vores stateful-tjenester, s\u00e5som Redis, Postgres, GitLab Pages og Gitaly, i migrationen, tillader brugen af Kubernetes os at reducere antallet af VM'er, som Chef for tiden administrerer, radikalt.<\/p>\n

Transparens og konfigurationsstyring i Kubernetes<\/h2>\n

\nAlle indstillinger styres af selve GitLab. Til dette anvendes tre konfigurationsprojekter baseret p\u00e5 Terraform og Helm. Vi pr\u00f8ver at bruge GitLab til at k\u00f8re GitLab, hvor det er muligt, men til driftsopgaver har vi en separat GitLab-installation. Denne er n\u00f8dvendig for at undg\u00e5 afh\u00e6ngighed af tilg\u00e6ngeligheden af GitLab.com under deployment og opdatering af GitLab.com.<\/p>\n

Selvom vores pipelines til Kubernetes-klyngen k\u00f8rer p\u00e5 en separat installation af GitLab, har kode-repositorierne spejle, der er offentligt tilg\u00e6ngelige p\u00e5 f\u00f8lgende adresser:<\/p>\n