{"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\/nl\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Onze conclusies na een jaar migratie van GitLab.com naar Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: de aanpassing van Kubernetes in GitLab wordt beschouwd als een van de twee belangrijkste factoren die bijdragen aan de groei van het bedrijf. Tot voor kort was de infrastructuur van de online service GitLab.com echter gebouwd op virtuele machines, en het migreren naar K8s begon slechts ongeveer een jaar geleden, een proces dat nog steeds gaande is. We zijn blij om een vertaling te presenteren van een recent artikel van een SRE-engineer van GitLab over hoe dit verloopt en welke lessen de ingenieurs, die bij dit project betrokken zijn, hieruit trekken.<\/i><\/p>\n

\"Onze
\n
\nAl bijna een jaar is onze infrastructuurafdeling bezig met de migratie van alle diensten die draaien op GitLab.com naar Kubernetes. In die tijd zijn we tegen problemen aangelopen, niet alleen met het verplaatsen van diensten naar Kubernetes, maar ook met het beheren van een hybride deployment tijdens de overgang. In dit artikel bespreken we de waardevolle lessen die we hebben geleerd.<\/a><\/noindex><\/p>\n

Vanaf het begin werkte GitLab.com op servers in de cloud op virtuele machines. Deze virtuele machines worden beheerd door Chef, en hun installatie gebeurt met behulp van onze offici\u00eble Linux-pakket<\/a><\/noindex>. De uitrolstrategie<\/a><\/noindex> voor het geval er een update van de applicatie nodig is, bestaat uit het eenvoudig bijgewerkt houden van de serverpark op een geco\u00f6rdineerde, geleidelijke manier door middel van een CI-pipeline. Deze methode - hoewel langzaam en een beetje saai<\/a><\/noindex> garandeert dat GitLab.com dezelfde installatie- en configuratiemethoden gebruikt als gebruikers van de zelf-gehoste (self-managed)<\/i> installaties van GitLab die onze Linux-pakketten gebruiken.<\/p>\n

We gebruiken deze methode omdat het cruciaal is om de vreugdes en zorgen die reguliere leden van de gemeenschap ervaren tijdens het installeren en configureren van hun eigen kopie\u00ebn van GitLab, zelf te ervaren. Deze aanpak heeft een tijdje goed gewerkt, maar toen het aantal projecten op GitLab meer dan 10 miljoen overschreed, realiseerden we ons dat deze methode niet langer voldeed aan onze schaal- en uitrolbehoeften.<\/p>\n

Eerste stappen naar Kubernetes en cloud-native GitLab<\/h2>\n

\nIn 2017 werd het project opgericht GitLab Charts<\/a><\/noindex> voor de voorbereiding van GitLab voor implementatie in de cloud, en om gebruikers in staat te stellen GitLab in Kubernetes-clusters te installeren. We wisten toen al dat het verplaatsen van GitLab naar Kubernetes de schaalbaarheid van het SaaS-platform zou vergroten, implementaties zou vereenvoudigen en de effici\u00ebntie van het gebruik van rekenbronnen zou verbeteren. Tegelijkertijd waren veel functies van onze applicatie afhankelijk van gemounte NFS-volume's, wat de overgang van virtuele machines vertraagde.<\/p>\n

De drang naar cloud native en Kubernetes stelde onze ingenieurs in staat om een geleidelijke overstap te plannen, waarbij we enkele afhankelijkheden van de applicatie van netwerklocy's hebben opgegeven, terwijl we tegelijkertijd nieuwe functies bleven ontwikkelen. Sinds we in de zomer van 2019 zijn begonnen met het plannen van de migratie, zijn veel van deze beperkingen weggenomen en de migratie van GitLab.com naar Kubernetes is nu in volle gang!<\/p>\n

Kenmerken van GitLab.com op Kubernetes<\/h2>\n

\nVoor GitLab.com gebruiken we een enkele regionale GKE-cluster die al het verkeer van de applicatie verwerkt. Om de complexiteit van de (al ingewikkelde) migratie te minimaliseren, richten we ons op diensten die niet afhankelijk zijn van lokale opslag of NFS. GitLab.com heeft voornamelijk een monolithische codebase op Rails, en we leiden het verkeer af afhankelijk van de kenmerken van de werkbelasting naar verschillende endpoints, die zijn ge\u00efsoleerd in hun eigen knooppool.<\/p>\n

Voor de frontend worden deze typen onderverdeeld in aanvragen naar web, API, Git SSH\/HTTPS en Registry. Voor de backend splitsen we jobs in de wachtrij op basis van verschillende kenmerken afhankelijk van vooraf gedefinieerde resourcegrenzen<\/a><\/noindex>, die ons in staat stellen om service level doelen (Service-Level Objectives, SLO's) voor verschillende workloads vast te stellen.<\/p>\n

Al deze GitLab.com-services zijn ingesteld met behulp van de ongewijzigde Helm-chart van GitLab. De configuratie wordt uitgevoerd in subcharts die selectief kunnen worden ingeschakeld naarmate we de diensten geleidelijk naar de cluster verplaatsen. Zelfs met het besluit om sommige van onze stateful-services, zoals Redis, Postgres, GitLab Pages en Gitaly, niet in de migratie op te nemen, stelt het gebruik van Kubernetes ons in staat om het aantal VM's dat momenteel door Chef wordt beheerd, drastisch te verminderen.<\/p>\n

Transparantie en configuratiebeheer in Kubernetes<\/h2>\n

\nAlle instellingen worden beheerd door GitLab zelf. Hiervoor worden drie configuratieprojecten gebruikt op basis van Terraform en Helm. We proberen waar mogelijk GitLab zelf te gebruiken voor het draaien van GitLab, maar voor operationele taken hebben we een aparte GitLab-installatie die functioneert. Dit is nodig om niet afhankelijk te zijn van de beschikbaarheid van GitLab.com tijdens deployments en updates van GitLab.com.<\/p>\n

Hoewel onze pipelines voor de Kubernetes-cluster draaien op een aparte installatie van GitLab, hebben de code repositories spiegels die publiekelijk toegankelijk zijn op de volgende adressen:<\/p>\n