{"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\/no\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"V\u00e5re konklusjoner etter et \u00e5r med migrering av GitLab.com til Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obs. overs.<\/b>: tilpassingen av Kubernetes i GitLab anses for \u00e5 v\u00e6re en av to hovedfaktorer som bidrar til selskapets vekst. Likevel, frem til nylig var infrastrukturen for nettjenesten GitLab.com bygget p\u00e5 virtuelle maskiner, og migreringen til K8s begynte f\u00f8rst for omtrent ett \u00e5r siden og er fortsatt ikke fullf\u00f8rt. Vi er glade for \u00e5 presentere oversettelsen av en nylig artikkel fra SRE-ingeni\u00f8ren i GitLab om hvordan dette foreg\u00e5r og hvilke konklusjoner ingeni\u00f8rene som deltar i prosjektet gj\u00f8r.<\/i><\/p>\n

\"V\u00e5re
\n
\nI over a year, our infrastructure department has been migrating all services running on GitLab.com to Kubernetes. During this time, we faced challenges not only with moving services to Kubernetes but also with managing a hybrid deployment during the transition. This article will discuss the valuable lessons we learned.<\/a><\/noindex><\/p>\n

Fra starten av har serverne p\u00e5 GitLab.com jobbet i skyen p\u00e5 virtuelle maskiner. Disse virtuelle maskinene administreres av Chef, og installasjonen skjer ved hjelp av v\u00e5r offisielle Linux-pakken<\/a><\/noindex>. Utrullingsstrategi<\/a><\/noindex> i tilfelle oppdateringer av applikasjonen, best\u00e5r i \u00e5 oppdatere serverparken p\u00e5 en koordinert, sekvensiell m\u00e5te ved hjelp av CI-pipeline. Denne metoden \u2014 selv om den er litt treigere og kanskje kjedelig<\/a><\/noindex> \u2014 garanterer at GitLab.com bruker de samme installasjons- og konfigureringsmetodene som brukerne av selvadministrerte (self-managed)<\/i> GitLab-installasjoner bruker v\u00e5re Linux-pakker for dette.<\/p>\n

Vi bruker denne metoden fordi det er ekstremt viktig \u00e5 oppleve alle gledene og utfordringene som vanlige medlemmer av fellesskapet opplever n\u00e5r de installerer og konfigurerer sine versjoner av GitLab. Denne tiln\u00e6rmingen har fungert godt en stund, men da antallet prosjekter p\u00e5 GitLab passerte 10 millioner, inns\u00e5 vi at den ikke lenger tilfredsstilte v\u00e5re behov for skalering og utrulling.<\/p>\n

F\u00f8rste skritt mot Kubernetes og cloud-native GitLab<\/h2>\n

\nI 2017 ble prosjektet GitLab Charts<\/a><\/noindex> for preparing GitLab for deployment in the cloud, as well as to give users the ability to install GitLab in Kubernetes clusters. At that time, we knew that migrating GitLab to Kubernetes would enhance the scalability of our SaaS platform, simplify deployments, and improve the efficiency of resource utilization. At the same time, many features of our application relied on mounted NFS partitions, which slowed the transition from virtual machines.<\/p>\n

The push towards cloud native and Kubernetes enabled our engineers to plan a gradual transition, during which we eliminated some of the application's dependencies on network storage, all while continuing to develop new features. Since we began planning the migration in the summer of 2019, many of these constraints have been removed, and the process of moving GitLab.com to Kubernetes is now in full swing!<\/p>\n

Features of GitLab.com operating in Kubernetes<\/h2>\n

\nFor GitLab.com, we use a single regional GKE cluster that processes all application traffic. To minimize the complexity of the already convoluted migration, we focus on services that do not rely on local storage or NFS. GitLab.com predominantly uses a monolithic Rails codebase, and we route traffic based on workload characteristics to various endpoints isolated in their own node pools.<\/p>\n

In the case of the frontend, these types are divided into web requests, API, Git SSH\/HTTPS, and Registry. For the backend, we break down jobs in the queue based on various characteristics depending on predetermined resource boundaries<\/a><\/noindex>, allowing us to set Service-Level Objectives (SLOs) for different loads.<\/p>\n

All these services on GitLab.com are configured using the unmodified GitLab Helm chart. Configuration is done in subcharts, which can be selectively included as we gradually move services into the cluster. Even considering the decision not to include some of our stateful services, such as Redis, Postgres, GitLab Pages, and Gitaly, using Kubernetes allows for a radical reduction in the number of VMs currently managed by Chef.<\/p>\n

Transparency and configuration management of Kubernetes<\/h2>\n

\nAll configurations are managed by GitLab itself. We use three configuration projects based on Terraform and Helm for this. We try to use GitLab itself for deploying GitLab wherever possible, but for operational tasks, we have a separate GitLab installation. This is needed to avoid dependency on the availability of GitLab.com during deployments and updates of GitLab.com.<\/p>\n

Selv om v\u00e5re pipelines for Kubernetes-klyngen kj\u00f8rer p\u00e5 en separat GitLab-installasjon, finnes det speil av kode-repoene, offentlig tilgjengelig p\u00e5 f\u00f8lgende adresser:<\/p>\n