Let wel. vertaal.: GitLab se aanvaarding van Kubernetes word beskou as een van die twee hooffaktore wat bydra tot die maatskappy se groei. Tot onlangs was die infrastruktuur van die GitLab.com-aanlyndiens egter op virtuele masjiene gebou, en slegs sowat 'n jaar gelede het sy migrasie na K8s begin, wat nog nie voltooi is nie. Ons bied graag 'n vertaling aan van 'n onlangse artikel deur 'n GitLab SRE-ingenieur oor hoe dit gebeur en watter gevolgtrekkings die ingenieurs wat by die projek betrokke is, maak.
Ons infrastruktuurafdeling migreer nou al vir ongeveer 'n jaar alle dienste wat op GitLab.com loop na Kubernetes. Gedurende hierdie tyd het ons uitdagings in die gesig gestaar nie net met die verskuiwing van dienste na Kubernetes nie, maar ook met die bestuur van hibriede ontplooiings tydens die oorgang. Die waardevolle lesse wat ons geleer het, sal in hierdie artikel bespreek word.
Sedert die begin van GitLab.com loop sy bedieners in die wolk in virtuele masjiene. Hierdie virtuele masjiene word deur Chef bestuur en geïnstalleer met ons . in die geval dat die toepassing opgedateer moet word, is om eenvoudig die bedienervloot op 'n gekoördineerde opeenvolgende wyse op te dateer deur die CI-pyplyn te gebruik. Hierdie metode, al is dit stadig en 'n bietjie - verseker dat GitLab.com dieselfde installasie- en konfigurasiemetodes as selfstandige gebruikers gebruik (selfbestuur) GitLab-installasies gebruik ons Linux-pakkette hiervoor.
Ons gebruik hierdie metode omdat dit van kritieke belang is om die pyn en vreugde te ervaar waardeur die gemiddelde lid van die gemeenskap gaan wanneer hulle hul kopieë van GitLab installeer en opstel. Hierdie benadering het vir 'n geruime tyd goed gewerk, maar toe die aantal projekte op GitLab 10 miljoen oorskry het, het ons besef dat dit nie meer aan ons skaal- en ontplooiingsbehoeftes voldoen nie.
Eerste stappe in die rigting van Kubernetes en wolk-inheemse GitLab
Die projek is in 2017 geskep om GitLab voor te berei vir ontplooiing in die wolk, en om gebruikers in staat te stel om GitLab op Kubernetes-klusters te installeer. Destyds het ons geweet dat die migreer van GitLab na Kubernetes die SaaS-platform se skaalbaarheid sou verhoog, implementerings vereenvoudig en rekenaardoeltreffendheid sou verbeter. Terselfdertyd was baie kenmerke van ons toepassing afhanklik van NFS-gemonteerde partisies, wat die oorgang van virtuele masjiene vertraag het.
Die fokus op wolk-inheems en Kubernetes het ons ingenieurs in staat gestel om te beplan vir 'n geleidelike oorgang, waartydens ons sommige van die toepassing se NAS-afhanklikhede laat vaar het terwyl ons voortgegaan het om nuwe kenmerke langs die pad te ontwikkel. Sedert ons ons migrasie in die somer van 2019 begin beplan het, is baie van hierdie beperkings verwyder en die proses om GitLab.com na Kubernetes te migreer is nou goed aan die gang!
Kenmerke van GitLab.com in Kubernetes
Vir GitLab.com gebruik ons 'n enkele plaaslike GKE-kluster wat alle toepassingsverkeer hanteer. Om die kompleksiteit van 'n (reeds moeilike) migrasie te verminder, fokus ons op dienste wat nie op plaaslike berging of NFS staatmaak nie. GitLab.com gebruik 'n oorwegend monolitiese Rails-kodebasis en ons stuur verkeer gebaseer op werklading-eienskappe na verskillende eindpunte wat in hul eie noduspoele geïsoleer is.
In die geval van die frontend, word hierdie tipes verdeel in versoeke aan die web, API, Git SSH/HTTPS en Register. In die geval van die backend, verdeel ons die take in die tou volgens verskillende eienskappe, afhangende van , wat ons in staat stel om diensvlakdoelwitte (SLO's) vir verskillende werkladings te stel.
Al hierdie GitLab.com-dienste is gekonfigureer met 'n ongewysigde GitLab Helm-kaart. Konfigurasie word in subkaarte gedoen wat selektief geaktiveer kan word namate ons dienste geleidelik na die groep migreer. Selfs met die besluit om nie sommige van ons statige dienste soos Redis, Postgres, GitLab Pages en Gitaly by die migrasie in te sluit nie, stel die gebruik van Kubernetes ons in staat om die aantal VM's wat tans deur Chef bestuur word, drasties te verminder.
Deursigtigheid en konfigurasiebestuur van Kubernetes
Alle instellings word deur GitLab self bestuur. Drie konfigurasieprojekte gebaseer op Terraform en Helm word hiervoor gebruik. Ons probeer GitLab self waar moontlik gebruik om GitLab te laat loop, maar vir operasionele take het ons 'n aparte GitLab-installasie. Dit is nodig om nie afhanklik te wees van die beskikbaarheid van GitLab.com wanneer ontplooiings en opdaterings van GitLab.com uitgevoer word nie.
Alhoewel ons pyplyne vir die Kubernetes-kluster op 'n aparte GitLab-installasie loop, het die kodebewaarplekke spieëls wat publiek beskikbaar is by die volgende adresse:
- - GitLab.com-konfigurasiebinding vir GitLab Helm-kaart;
- - bevat konfigurasies vir dienste wat nie direk met die GitLab-toepassing verband hou nie. Dit sluit in konfigurasies vir aanteken en groepmonitering, sowel as geïntegreerde gereedskap soos PlantUML;
- - Terraform-konfigurasie vir Kubernetes en verouderde VM-infrastruktuur. Hier konfigureer jy al die hulpbronne wat nodig is om die groep te laat loop, insluitend die groep self, noduspoele, diensrekeninge, IP-adresbespreking.
Wanneer veranderinge aangebring word, word die publieke aansig gewys. met 'n skakel na 'n gedetailleerde verskil wat SRE ontleed voordat veranderinge aan die groep gemaak word.
Vir SRE lei die skakel na 'n gedetailleerde verskil in die GitLab-installasie, wat gebruik word vir produksie en toegang tot wat beperk is. Dit laat werknemers en die gemeenskap sonder toegang tot die operasionele ontwerp (wat slegs oop is vir SRE's) toe om voorgestelde konfigurasieveranderinge te sien. Deur 'n publieke GitLab-instansie vir kode te kombineer met 'n private instansie vir CI-pyplyne, handhaaf ons 'n enkele werkvloei terwyl ons onafhanklikheid van GitLab.com verseker vir konfigurasie-opdaterings.
Wat ons tydens die migrasie geleer het
Tydens die skuif is ondervinding opgedoen wat ons toepas op nuwe migrasies en ontplooiings in Kubernetes.
1. Verhoogde koste as gevolg van verkeer tussen Beskikbaarheidsones
Daaglikse uitgangstatistieke (grepe per dag) vir die Git-bergingsvloot op GitLab.com
Google verdeel sy netwerk in streke. Dié word op hul beurt in beskikbaarheidsones (AZ) verdeel. Git-hosting word geassosieer met groot hoeveelhede data, daarom is dit vir ons belangrik om netwerkuitgang te beheer. In die geval van interne verkeer is uitgang slegs gratis as dit binne die grense van een beskikbaarheidsone bly. Ten tyde van hierdie skrywe gee ons ongeveer 100 TB se data op 'n tipiese werksdag weg (en dit is net vir Git-bewaarplekke). Dienste wat in dieselfde virtuele masjiene in ons ou VM-gebaseerde topologie was, loop nou in verskillende Kubernetes-peule. Dit beteken dat sommige van die verkeer wat voorheen plaaslik op die VM was, moontlik buite beskikbaarheidsones kan gaan.
Streek-GKE-klusters laat jou toe om oor verskeie beskikbaarheidsones te strek vir oortolligheid. Ons oorweeg die moontlikheid vir dienste wat groot hoeveelhede verkeer genereer. Dit sal die koste van uitgang verminder terwyl oortolligheid op die groepvlak gehandhaaf word.
2. Limiete, hulpbronversoeke en skaal
Die aantal replikas wat produksieverkeer na registry.gitlab.com hanteer. Verkeer spits om ~15:00 UTC.
Ons migrasieverhaal het in Augustus 2019 begin, toe ons die eerste diens, die GitLab Container Registry, na Kubernetes gemigreer het. Hierdie hoë-verkeer missie-kritieke diens was 'n goeie pas vir die eerste migrasie, want dit is 'n staatlose toepassing met min eksterne afhanklikhede. Die eerste probleem wat ons teëgekom het, was 'n groot aantal peule wat uitgestoot is weens 'n gebrek aan geheue op die nodusse. As gevolg hiervan moes ons versoeke en limiete verander.
Daar is gevind dat in die geval van 'n toepassing waarvan die geheueverbruik met verloop van tyd groei, lae waardes vir versoeke (reservering van geheue vir elke peul), tesame met 'n "vrygewige" harde beperking op gebruik, tot versadiging gelei het (versadiging) nodusse en 'n hoë vlak van verplasings. Om hierdie probleem te hanteer, was dit . Dit het die druk van die nodusse verwyder en 'n peullewensiklus verskaf wat nie te veel druk op die nodus geplaas het nie. Ons begin nou migrasies met ruim (en byna identiese) versoek- en limietwaardes, en pas dit aan soos nodig.
3. Metrieke en logs
Infrastruktuur-afdeling fokus op latency, foutkoers en versadiging met gevestigde (SLO) gekoppel aan .
Oor die afgelope jaar was een van die sleutelontwikkelings in die infrastruktuurafdeling verbeterings in die monitering en werk met SLO. SLO's het ons toegelaat om doelwitte vir individuele dienste te stel, wat ons tydens die migrasie fyn dopgehou het. Maar selfs met hierdie verbeterde waarneembaarheid, is dit nie altyd moontlik om probleme met behulp van statistieke en waarskuwings onmiddellik te sien nie. Deur byvoorbeeld op latensie en foutkoerse te fokus, dek ons nie alle gebruiksgevalle ten volle vir 'n diens wat gemigreer word nie.
Hierdie probleem is byna onmiddellik ontdek nadat sommige van die werkladings na die groepering verskuif is. Dit het homself veral akuut gemaak wanneer dit kom by die kontrolering van funksies, waarvan die aantal versoeke klein is, maar wat baie spesifieke konfigurasie-afhanklikhede het. Een van die sleutellesse uit die migrasie was die behoefte om in ag te neem wanneer nie net metrieke gemonitor word nie, maar ook logs en die "langstert" (dit gaan oor op die grafiek - ongeveer. vertaal.) foute. Nou vir elke migrasie sluit ons 'n gedetailleerde lys van versoeke na die logs in (log navrae) en ons beplan duidelike terugrolprosedures wat van een skof na 'n ander oorgedra kan word in geval van probleme.
Om dieselfde versoeke in parallel te bedien op die ou VM-infrastruktuur en die nuwe een gebaseer op Kubernetes was 'n unieke uitdaging. Anders as lig-en-skuif-migrasie (vinnige oordrag van toepassings "soos dit is" na 'n nuwe infrastruktuur; vir meer besonderhede, sien bv. - ongeveer. vertaal.), vereis parallelle werk op "ou" VM'e en Kubernetes dat moniteringsinstrumente versoenbaar is met beide omgewings en metrieke in een aansig kan kombineer. Dit is belangrik dat ons dieselfde kontroleskerms en lognavrae gebruik om konsekwente waarneembaarheid gedurende die oorgangstydperk te verkry.
4. Skakel verkeer na die nuwe groep oor
Vir GitLab.com word sommige van die bedieners onder toegewys . Canary Park bedien ons interne projekte en kan ook . Maar dit is hoofsaaklik ontwerp om veranderinge aan die infrastruktuur en toepassing te toets. Die eerste gemigreerde diens het begin deur 'n beperkte hoeveelheid interne verkeer te aanvaar, en ons gaan voort om hierdie metode te gebruik om te verseker dat daar aan die SLO voldoen word voordat alle verkeer na die kluster gestoot word.
In die geval van migrasie beteken dit dat versoeke na interne projekte eers na Kubernetes gestuur word, en dan skakel ons die res van die verkeer geleidelik oor na die groepering deur die gewig vir die backend deur HAProxy te verander. Tydens die oorgang van VM na Kubernetes het dit duidelik geword dat dit baie voordelig is om 'n maklike manier te hê om verkeer tussen die ou en nuwe infrastruktuur te herlei en, dienooreenkomstig, die ou infrastruktuur gereed te hou vir terugrol in die eerste paar dae na die migrasie.
5. Spaarkrag van peule en hul gebruik
Byna onmiddellik is die volgende probleem geïdentifiseer: peule vir die Registry-diens het vinnig begin, maar die bekendstelling van peule vir Sidekiq het tot . Sidekiq se langlopende peule het 'n probleem geword toe ons werkladings na Kubernetes begin migreer het vir werkers wat werk vinnig moet verwerk en vinnig moet skaal.
In hierdie geval was die les dat terwyl die Horizontal Pod Autoscaler (HPA) in Kubernetes verkeersgroei goed hanteer, dit belangrik is om werksladingeienskappe in ag te neem en ekstra peulkapasiteit toe te ken (veral wanneer die vraag ongelyk is). In ons geval was daar 'n skielike uitbarsting van take, wat gelei het tot vinnige skaal, wat gelei het tot versadiging van SVE-hulpbronne voordat ons die noduspoel kon skaal.
Dit is altyd aanloklik om soveel as moontlik uit 'n groepie te trek, maar ons het egter aanvanklik prestasiekwessies ondervind en begin nou met 'n ruim podbegroting en skaal dit later af, met SLO fyn dop. Die bekendstelling van peule vir die Sidekiq-diens is aansienlik versnel en neem nou gemiddeld ongeveer 40 sekondes. het beide GitLab.com en ons gebruikers van selfbestuurde installasies gewen wat die amptelike GitLab Helm Chart uitvoer.
Gevolgtrekking
Nadat ons elke diens migreer het, het ons ons verheug oor die voordele van die gebruik van Kubernetes in produksie: vinniger en veiliger toepassing-ontplooiing, skaal en doeltreffender hulpbrontoewysing. Boonop strek die voordele van migrasie verder as die GitLab.com-diens. Met elke verbetering op die amptelike Helm Chart, baat sy gebruikers ook.
Ek hoop jy het die storie van ons Kubernetes-migrasie-avontuur geniet. Ons gaan voort om alle nuwe dienste na die groepering te migreer. Bykomende inligting kan in die volgende publikasies gevind word:
- «»;
- «»;
- .
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com