Huomautus. käännös: Kubernetesin käyttöönottoa GitLabissa pidetään yhtenä kahdesta päätekijästä, jotka vaikuttavat yrityksen kasvuun. GitLab.com-verkkopalvelun infrastruktuuri rakennettiin kuitenkin viime aikoihin asti virtuaalikoneiden varaan, ja vasta noin vuosi sitten alkoi siirtyminen K8:aan, joka ei ole vieläkään valmis. Meillä on ilo esitellä käännös GitLabin SRE-insinöörin tuoreesta artikkelista siitä, miten tämä tapahtuu ja mitä johtopäätöksiä projektiin osallistuvat insinöörit tekevät.
Infrastruktuuriosastomme on nyt noin vuoden ajan siirtänyt kaikkia GitLab.comissa käynnissä olevia palveluita Kubernetesiin. Tänä aikana kohtasimme haasteita, jotka liittyivät paitsi palveluiden siirtämiseen Kubernetesiin, myös hybridikäyttöönoton hallintaan siirtymän aikana. Opittuja arvokkaita opetuksia käsitellään tässä artikkelissa.
GitLab.comin alusta lähtien sen palvelimet toimivat pilvessä virtuaalikoneen. Näitä virtuaalikoneita hallinnoi Chef ja ne asennetaan meidän avullamme . jos sovellus on päivitettävä, se koostuu yksinkertaisesti palvelinkaluston päivittämisestä koordinoidusti, peräkkäisellä tavalla CI-liukuhihnan avulla. Tämä menetelmä - vaikkakin hidas ja vähän - varmistaa, että GitLab.com käyttää samoja asennus- ja määrityskäytäntöjä kuin offline-käyttäjät (itse hallittu) GitLab-asennukset Linux-pakettejamme käyttäen.
Käytämme tätä menetelmää, koska on erittäin tärkeää kokea kaikki surut ja ilot, joita tavalliset yhteisön jäsenet kokevat asentaessaan ja määritessään GitLabin kopioita. Tämä lähestymistapa toimi hyvin jonkin aikaa, mutta kun GitLabin projektien määrä ylitti 10 miljoonaa, huomasimme, että se ei enää vastannut skaalauksen ja käyttöönoton tarpeitamme.
Ensimmäiset askeleet Kubernetesiin ja pilvipohjaiseen GitLabiin
Projekti syntyi vuonna 2017 valmistella GitLab pilvikäyttöön ja antaa käyttäjille mahdollisuus asentaa GitLab Kubernetes-klustereihin. Tiesimme silloin, että GitLabin siirtäminen Kubernetesiin lisää SaaS-alustan skaalautuvuutta, yksinkertaistaa käyttöönottoja ja parantaa laskentaresurssien tehokkuutta. Samaan aikaan monet sovelluksemme toiminnot riippuivat asennetuista NFS-osioista, mikä hidasti siirtymistä virtuaalikoneen.
Pyrkimys kohti pilvipohjaista natiivia ja Kubernetesia antoi insinööreillemme mahdollisuuden suunnitella asteittaista siirtymää, jonka aikana hylkäsimme osan sovelluksen riippuvuuksista verkkotallennustilasta ja jatkoimme uusien ominaisuuksien kehittämistä. Siitä lähtien, kun aloimme suunnitella siirtoa kesällä 2019, monet näistä rajoituksista on ratkaistu, ja GitLab.comin siirtäminen Kubernetesiin on nyt hyvässä vauhdissa!
GitLab.comin ominaisuudet Kubernetesissa
GitLab.comissa käytämme yhtä alueellista GKE-klusteria, joka käsittelee kaiken sovellusliikenteen. Minimoidaksemme (jo jo hankalan) siirron monimutkaisuuden keskitymme palveluihin, jotka eivät ole riippuvaisia paikallisesta tallennustilasta tai NFS:stä. GitLab.com käyttää pääasiassa monoliittista Rails-koodikantaa, ja reititämme liikenteen työkuorman ominaisuuksien perusteella eri päätepisteisiin, jotka on eristetty omiin solmuryhmiinsä.
Käyttöliittymän tapauksessa nämä tyypit on jaettu verkko-, API-, Git SSH/HTTPS- ja rekisteripyyntöihin. Taustajärjestelmän tapauksessa jaamme jonossa olevat työt erilaisten ominaisuuksien mukaan riippuen , joiden avulla voimme asettaa palvelutason tavoitteet (SLO:t) erilaisille työkuormille.
Kaikki nämä GitLab.com-palvelut on määritetty käyttämällä muokkaamatonta GitLab Helm -kaaviota. Konfigurointi suoritetaan alakaavioissa, jotka voidaan ottaa käyttöön valikoivasti siirtäessämme palveluita asteittain klusteriin. Vaikka päätimme olla sisällyttämättä siirtoon joitakin tilallisia palvelujamme, kuten Redisiä, Postgresia, GitLab Pages ja Gitaly, Kubernetesin avulla voimme radikaalisti vähentää Chefin tällä hetkellä hallinnoimien virtuaalikoneiden määrää.
Kubernetes-määritysten näkyvyys ja hallinta
GitLab itse hallinnoi kaikkia asetuksia. Tätä varten käytetään kolmea Terraformiin ja Helmiin perustuvaa konfigurointiprojektia. Pyrimme käyttämään itse GitLabia aina kun mahdollista GitLabin ajamiseen, mutta operatiivisiin tehtäviin meillä on erillinen GitLab-asennus. Tämä on tarpeen sen varmistamiseksi, että et ole riippuvainen GitLab.comin saatavuudesta suorittaessasi GitLab.comin käyttöönottoja ja päivityksiä.
Vaikka Kubernetes-klusterin putkistomme toimivat erillisessä GitLab-asennuksessa, koodivarastoista on peilejä, jotka ovat julkisesti saatavilla seuraavista osoitteista:
- — GitLab.com-määrityskehys GitLab Helm -kaaviolle;
- - Sisältää konfiguraatioita palveluille, jotka eivät liity suoraan GitLab-sovellukseen. Näitä ovat lokiin kirjaamisen ja klusterin valvonnan konfiguraatiot sekä integroidut työkalut, kuten PlantUML;
- — Terraform-kokoonpano Kubernetesille ja vanhalle VM-infrastruktuurille. Täällä määrität kaikki klusterin suorittamiseen tarvittavat resurssit, mukaan lukien itse klusteri, solmuvarastot, palvelutilit ja IP-osoitevaraukset.
Julkinen näkymä näytetään, kun muutoksia tehdään. jossa on linkki yksityiskohtaiseen erotukseen, jonka SRE analysoi ennen muutosten tekemistä klusteriin.
SRE:ssä linkki johtaa yksityiskohtaiseen eroon GitLab-asennuksessa, jota käytetään tuotantoon ja johon pääsy on rajoitettu. Tämä antaa työntekijöille ja yhteisölle mahdollisuuden tarkastella ehdotettuja kokoonpanomuutoksia ilman käyttöoikeutta operatiiviseen projektiin (joka on avoin vain SRE:ille). Yhdistämällä julkisen GitLab-esiintymän koodia varten yksityiseen ilmentymään CI-putkia varten, ylläpidämme yhtä työnkulkua ja varmistamme samalla riippumattomuuden GitLab.comista määrityspäivityksiä varten.
Mitä saimme selville muuttoliikkeen aikana
Muuton aikana saatiin kokemusta, jota sovellamme Kubernetesin uusiin migraatioihin ja käyttöönottoihin.
1. Lisääntyneet kustannukset saatavuuden vyöhykkeiden välisestä liikenteestä
Päivittäiset poistumistilastot (tavuja päivässä) Git-tietovarastolle GitLab.comissa
Google jakaa verkkonsa alueisiin. Ne puolestaan on jaettu saavutettavuusvyöhykkeisiin (AZ). Git-isännöinti liittyy suuriin tietomääriin, joten meille on tärkeää hallita verkon ulosmenoa. Sisäisen liikenteen osalta ulospääsy on ilmaista vain, jos se pysyy samalla käytettävyysalueella. Tätä kirjoittaessamme palvelemme noin 100 TB dataa tyypillisenä työpäivänä (ja tämä koskee vain Git-tietovarastoja). Palvelut, jotka sijaitsivat samoissa virtuaalikoneen vanhassa VM-pohjaisessa topologiassamme, toimivat nyt eri Kubernetes-tyypeissä. Tämä tarkoittaa, että osa liikenteestä, joka oli aiemmin paikallista VM:lle, voi mahdollisesti kulkea käytettävyysalueiden ulkopuolella.
Alueellisten GKE-klusterien avulla voit kattaa useita saatavuusvyöhykkeitä redundanssia varten. Harkitsemme mahdollisuutta suuria liikennemääriä tuottaville palveluille. Tämä vähentää poistumiskustannuksia säilyttäen samalla klusteritason redundanssin.
2. Rajat, resurssipyynnöt ja skaalaus
Sivuston registry.gitlab.com tuotantoliikennettä käsittelevien replikoiden määrä. Liikenne ruuhka on ~15 UTC.
Siirtymistarinamme alkoi elokuussa 2019, kun siirsimme ensimmäisen palvelumme, GitLab Container Registryn, Kubernetesiin. Tämä tehtäväkriittinen, paljon liikennettä palveleva palvelu oli hyvä valinta ensimmäiseen siirtoon, koska se on valtioton sovellus, jolla on vähän ulkoisia riippuvuuksia. Ensimmäinen ongelma, jonka kohtasimme, oli suuri määrä häätöjä, koska solmuissa ei ollut muistia. Tämän vuoksi jouduimme muuttamaan pyyntöjä ja rajoja.
Havaittiin, että sovelluksessa, jossa muistin kulutus kasvaa ajan myötä, alhaiset pyyntöjen arvot (muistin varaaminen jokaiselle podille) yhdistettynä "anteliaan" kovaan käyttörajoitukseen johtivat kyllästymiseen. (kylläisyys) solmut ja korkea häätöjen määrä. Tämän ongelman ratkaisemiseksi se oli . Tämä poisti solmujen paineen ja varmisti, että tyynyillä oli elinkaaren aika, joka ei aiheuttanut liikaa painetta solmulle. Nyt aloitamme migraatiot runsailla (ja lähes identtisillä) pyyntö- ja raja-arvoilla, mukauttaen niitä tarpeen mukaan.
3. Mittarit ja lokit
Infrastruktuuridivisioona keskittyy latenssiin, virhetasoihin ja kyllästymiseen asennettujen kanssa (SLO) linkitetty .
Kuluneen vuoden aikana yksi infrastruktuuri-divisioonan tärkeimmistä tapahtumista on ollut SLO:iden seurannan ja yhteistyön parantaminen. SLO:iden avulla pystyimme asettamaan tavoitteita yksittäisille palveluille, joita seurasimme tarkasti siirron aikana. Mutta vaikka tämä paranneltu havaittavuus, ei aina ole mahdollista nähdä välittömästi ongelmia käyttämällä mittareita ja hälytyksiä. Esimerkiksi keskittymällä latenssiin ja virhetasoihin emme kata täysin kaikkia siirtymävaiheessa olevan palvelun käyttötapauksia.
Tämä ongelma havaittiin melkein välittömästi sen jälkeen, kun jotkin työkuormat oli siirretty klusteriin. Siitä tuli erityisen akuutti, kun piti tarkistaa toimintoja, joiden pyyntöjen määrä oli pieni, mutta joilla oli hyvin erityisiä konfiguraatioriippuvuuksia. Yksi siirtymisen keskeisistä opetuksista oli tarve ottaa monitoroinnissa huomioon paitsi mittarit myös lokit ja "pitkä häntä" (tämä on noin kartalla - n. käännös.) virheitä. Nyt jokaista siirtoa varten sisällytämme yksityiskohtaisen luettelon lokikyselyistä (lokikyselyt) ja suunnittele selkeät palautusmenettelyt, jotka voidaan siirtää vuorosta toiseen, jos ongelmia ilmenee.
Samojen pyyntöjen palveleminen rinnakkain vanhassa VM-infrastruktuurissa ja uudessa Kubernetes-pohjaisessa infrastruktuurissa oli ainutlaatuinen haaste. Toisin kuin nosto ja siirto -siirto (sovellusten nopea siirto "sellaisenaan" uuteen infrastruktuuriin; lisätietoja voi lukea esim. - noin käännös.), "vanhojen" virtuaalikoneiden ja Kubernetesin rinnakkaistyö edellyttää, että valvontatyökalut ovat yhteensopivia molempien ympäristöjen kanssa ja pystyvät yhdistämään mittareita yhdeksi näkymään. On tärkeää, että käytämme samoja kojetauluja ja lokikyselyitä, jotta saavutetaan johdonmukainen havainnointi siirtymäkauden aikana.
4. Liikenteen vaihtaminen uuteen klusteriin
GitLab.comissa osa palvelimista on omistettu . Canary Park palvelee sisäisiä projektejamme ja voi myös . Mutta se on ensisijaisesti suunniteltu testaamaan infrastruktuuriin ja sovellukseen tehtyjä muutoksia. Ensimmäinen siirretty palvelu aloitti hyväksymällä rajoitetun määrän sisäistä liikennettä, ja käytämme edelleen tätä menetelmää varmistaaksemme, että SLO:t täyttyvät ennen kaiken liikenteen lähettämistä klusteriin.
Siirron tapauksessa tämä tarkoittaa, että pyynnöt sisäisiin projekteihin lähetetään ensin Kubernetesille, jonka jälkeen siirrämme vähitellen muun liikenteen klusteriin muuttamalla taustajärjestelmän painoa HAProxyn kautta. Siirtyessä VM:stä Kubernetesiin kävi selväksi, että oli erittäin hyödyllistä saada liikennettä helposti uudelleen ohjattua vanhan ja uuden infrastruktuurin välillä ja sen mukaisesti pitää vanha infrastruktuuri valmiina palautusta varten ensimmäisten päivien aikana siirron jälkeen.
5. Varaa palot ja niiden käyttö
Melkein välittömästi havaittiin seuraava ongelma: Rekisteripalvelun podit käynnistyivät nopeasti, mutta Sidekiqin podien lanseeraus kesti . Sidekiq-podien pitkästä käynnistysajasta tuli ongelma, kun aloimme siirtää työkuormia Kubernetesiin työntekijöille, joiden piti käsitellä työt nopeasti ja skaalautua nopeasti.
Tässä tapauksessa opetus oli, että vaikka Kubernetesin Horizontal Pod Autoscaler (HPA) käsittelee liikenteen kasvua hyvin, on tärkeää ottaa huomioon työkuormien ominaisuudet ja varata ylimääräistä kapasiteettia podille (varsinkin kun kysyntä jakautuu epätasaisesti). Meidän tapauksessamme työpaikkojen määrä lisääntyi äkillisesti, mikä johti nopeaan skaalautumiseen, mikä johti suorittimen resurssien kyllästymiseen ennen kuin ehtimme skaalata solmupoolia.
Aina on houkutus puristaa klusterista mahdollisimman paljon irti, mutta alun perin havaittuamme suorituskykyongelmia aloitamme nyt runsaalla pod-budjetilla ja pienennämme sitä myöhemmin pitäen tiiviisti silmällä SLO:ita. Sidekiq-palvelun podien lanseeraus on kiihtynyt merkittävästi ja kestää nyt keskimäärin noin 40 sekuntia. voitti sekä GitLab.comin että virallisen GitLab Helm -kaavion kanssa toimivien itsehallittujen asennusten käyttäjämme.
Johtopäätös
Kunkin palvelun siirron jälkeen iloitsimme Kubernetesin tuotannon eduista: nopeammasta ja turvallisemmasta sovellusten käyttöönotosta, skaalauksesta ja tehokkaammasta resurssien allokoinnista. Lisäksi siirtymisen edut ulottuvat GitLab.com-palvelun ulkopuolelle. Jokainen virallisen Helm-kaavion parannus hyödyttää sen käyttäjiä.
Toivottavasti pidit tarinasta Kubernetes-muuttoseikkailuistamme. Jatkamme kaikkien uusien palveluiden siirtämistä klusteriin. Lisätietoja löytyy seuraavista julkaisuista:
- «";
- «";
- .
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com