Jegyzet. ford.: A GitLabnál a Kubernetes bevezetése a vállalat növekedéséhez hozzájáruló két fő tényező egyike. A GitLab.com online szolgáltatás infrastruktúrája azonban egészen a közelmúltig virtuális gépekre épült, és csak körülbelül egy éve kezdődött el a K8-asokra való migrációja, amely még mindig nem fejeződött be. Örömmel mutatjuk be a GitLab SRE mérnökének friss cikkének fordítását arról, hogy ez hogyan történik, és milyen következtetéseket vonnak le a projektben résztvevő mérnökök.
Körülbelül egy éve az infrastrukturális részlegünk a GitLab.com-on futó összes szolgáltatást áttelepíti a Kubernetesre. Ez idő alatt nemcsak a szolgáltatások Kubernetesbe való áthelyezésével, hanem az átállás során a hibrid telepítés kezelésével is szembesültünk kihívásokkal. Az általunk tanult értékes leckékről ebben a cikkben lesz szó.
A GitLab.com kezdetétől fogva a szerverei felhőben futottak virtuális gépeken. Ezeket a virtuális gépeket a Chef kezeli, és a mi használatával telepítjük . abban az esetben, ha az alkalmazást frissíteni kell, egyszerűen a szerverflotta koordinált, szekvenciális frissítéséből áll egy CI-folyamat segítségével. Ez a módszer - bár lassú és egy kicsit - biztosítja, hogy a GitLab.com ugyanazt a telepítési és konfigurációs gyakorlatot használja, mint az offline felhasználók (saját kezelésű) GitLab telepítések ehhez a Linux csomagjainkkal.
Azért használjuk ezt a módszert, mert rendkívül fontos, hogy átéljük mindazokat a bánatokat és örömöket, amelyeket a közösség hétköznapi tagjai tapasztalnak, amikor telepítik és konfigurálják a GitLab példányait. Ez a megközelítés egy ideig jól működött, de amikor a GitLabon a projektek száma meghaladta a 10 milliót, rájöttünk, hogy már nem felel meg a méretezéssel és telepítéssel kapcsolatos igényeinknek.
Első lépések a Kubernetes és a felhőalapú GitLab felé
A projekt 2017-ben jött létre felkészíteni a GitLabot a felhőbe történő telepítésre, és lehetővé tenni a felhasználók számára a GitLab telepítését Kubernetes-fürtökön. Akkor tudtuk, hogy a GitLab áthelyezése a Kubernetesre növeli a SaaS platform skálázhatóságát, leegyszerűsíti a telepítéseket és javítja a számítási erőforrások hatékonyságát. Ugyanakkor alkalmazásunk számos funkciója a csatlakoztatott NFS-partícióktól függött, ami lelassította a virtuális gépekről való átállást.
A felhőalapú natív és a Kubernetes felé történő elmozdulás lehetővé tette mérnökeink számára, hogy egy fokozatos átállást tervezzenek, amelynek során felhagytunk az alkalmazás hálózati tárhelytől való egyes függőségeivel, miközben folytattuk az új funkciók fejlesztését. Azóta, hogy 2019 nyarán elkezdtük az áttelepítés tervezését, a korlátozások közül sok megoldódott, és a GitLab.com Kubernetesre történő migrálása már javában zajlik!
A GitLab.com szolgáltatásai a Kubernetesben
A GitLab.com esetében egyetlen regionális GKE-fürtöt használunk, amely az összes alkalmazásforgalmat kezeli. A (már trükkös) áttelepítés bonyolultságának minimalizálása érdekében azokra a szolgáltatásokra összpontosítunk, amelyek nem támaszkodnak a helyi tárolásra vagy az NFS-re. A GitLab.com túlnyomórészt monolitikus Rails kódbázist használ, és a forgalmat a munkaterhelés jellemzői alapján irányítjuk különböző végpontokhoz, amelyek a saját csomópontkészleteikbe vannak elkülönítve.
A frontend esetében ezek a típusok webre, API-ra, Git SSH/HTTPS-re és Registry-re irányuló kérésekre vannak felosztva. A backend esetében a sorban lévő jobokat különböző jellemzők szerint osztjuk fel, attól függően , amelyek lehetővé teszik, hogy szolgáltatásszintű célkitűzéseket (SLO-k) állítsunk be a különböző munkaterhelésekhez.
Mindezek a GitLab.com-szolgáltatások egy módosítatlan GitLab Helm diagram segítségével vannak konfigurálva. A konfigurálás aldiagramokon történik, amelyek szelektíven engedélyezhetők, ahogy fokozatosan migráljuk a szolgáltatásokat a fürtbe. Annak ellenére, hogy úgy döntöttünk, hogy egyes állapotalapú szolgáltatásainkat nem vonjuk be az áttelepítésbe, mint például a Redis, a Postgres, a GitLab Pages és a Gitaly, a Kubernetes használatával radikálisan csökkenthetjük a Chef által jelenleg kezelt virtuális gépek számát.
A Kubernetes konfigurációs láthatósága és kezelése
Minden beállítást maga a GitLab kezel. Ehhez három Terraform és Helm alapú konfigurációs projektet használnak. Lehetőség szerint magát a GitLabot igyekszünk használni a GitLab futtatásához, de az üzemeltetési feladatokhoz külön GitLab telepítésünk van. Erre azért van szükség, hogy Ön ne függjön a GitLab.com elérhetőségétől a GitLab.com telepítései és frissítései során.
Bár a Kubernetes-fürthöz készült csővezetékeink külön GitLab-telepítésen futnak, a kódtárolóknak vannak tükrei, amelyek nyilvánosan elérhetők a következő címeken:
- — GitLab.com konfigurációs keretrendszer a GitLab Helm diagramhoz;
- - Olyan szolgáltatások konfigurációit tartalmazza, amelyek nem kapcsolódnak közvetlenül a GitLab alkalmazáshoz. Ide tartoznak a naplózási és fürtfigyelési konfigurációk, valamint az olyan integrált eszközök, mint a PlantUML;
- — Terraform konfiguráció a Kuberneteshez és a régi virtuálisgép-infrastruktúrához. Itt konfigurálhatja a fürt futtatásához szükséges összes erőforrást, beleértve magát a fürtöt, a csomópontkészleteket, a szolgáltatásfiókokat és az IP-címfoglalásokat.
Nyilvános nézet jelenik meg, amikor módosításokat hajtanak végre. egy hivatkozással a részletes különbségre, amelyet az SRE elemzi a fürt módosítása előtt.
Az SRE esetében a hivatkozás a GitLab telepítésének részletes különbségéhez vezet, amelyet a termeléshez használnak, és amelyhez korlátozott a hozzáférés. Ez lehetővé teszi az alkalmazottak és a közösség számára, hogy az operatív projekthez (amely csak az SRE-k számára nyitva áll) hozzáférjenek a javasolt konfigurációs módosításokhoz. A kód nyilvános GitLab-példányának és a CI-folyamatok privát példányának kombinálásával egyetlen munkafolyamatot tartunk fenn, miközben biztosítjuk a GitLab.com-tól való függetlenséget a konfigurációs frissítésekhez.
Amit a vándorlás során megtudtunk
A költözés során olyan tapasztalatokat szereztünk, amelyeket alkalmazunk a Kubernetes új migrációira és telepítéseire.
1. Megnövekedett költségek a rendelkezésre állási zónák közötti forgalom miatt
Napi kilépési statisztika (bájt/nap) a Git-adattár flottájához a GitLab.com-on
A Google régiókra osztja hálózatát. Ezek viszont akadálymentesítési zónákra (AZ) vannak felosztva. A Git hosting nagy mennyiségű adathoz kapcsolódik, ezért fontos számunkra, hogy ellenőrizzük a hálózati kilépést. Belső forgalom esetén a kilépés csak akkor ingyenes, ha ugyanazon a rendelkezésre állási zónán belül marad. Az írás pillanatában körülbelül 100 TB adatot szolgálunk ki egy átlagos munkanapon (és ez csak a Git-tárolókra vonatkozik). A régi virtuálisgép-alapú topológiánkban ugyanazon virtuális gépeken található szolgáltatások most különböző Kubernetes podokban futnak. Ez azt jelenti, hogy a virtuális géphez korábban helyi forgalom egy része potenciálisan a rendelkezésre állási zónákon kívülre kerülhet.
A regionális GKE-fürtök lehetővé teszik több rendelkezésre állási zóna átfedését a redundancia érdekében. Mérlegeljük a lehetőséget olyan szolgáltatásokhoz, amelyek nagy forgalmat generálnak. Ez csökkenti a kilépési költségeket, miközben fenntartja a fürtszintű redundanciát.
2. Korlátok, erőforrásigények és méretezés
Az éles forgalmat feldolgozó replikák száma a registry.gitlab.com webhelyen. A forgalom 15:00 UTC-kor tetőzik.
Migrációs történetünk 2019 augusztusában kezdődött, amikor első szolgáltatásunkat, a GitLab Container Registry-t áttelepítettük a Kubernetesre. Ez a küldetéskritikus, nagy forgalmú szolgáltatás jó választás volt az első migrációhoz, mert ez egy állapot nélküli alkalmazás, kevés külső függőséggel. Az első probléma, amellyel találkoztunk, a csomópontok memóriahiánya miatt kiürített podok nagy száma volt. Emiatt módosítanunk kellett a kéréseken és a limiteken.
Felfedezték, hogy egy olyan alkalmazás esetében, ahol a memóriafogyasztás növekszik az idő múlásával, a kérések alacsony értékei (memória lefoglalása minden podhoz), valamint a „nagyvonalú” szigorú használati korlát telítettséghez vezet. (telítettség) csomópontok és magas szintű kilakoltatás. Ennek a problémának a megoldására az volt . Ez csökkentette a nyomást a csomópontokon, és biztosította a hüvelyek olyan életciklusát, amely nem gyakorol túl nagy nyomást a csomópontra. Most nagyvonalú (és szinte azonos) igény- és határértékekkel kezdjük a migrációt, szükség szerint módosítva azokat.
3. Mérések és naplók
Az infrastruktúra részleg a várakozási időre, a hibaarányra és a telepített telítettségre összpontosít (SLO) linkelve .
Az elmúlt év során az infrastruktúra divízió egyik kulcsfontosságú eseménye az SLO-k megfigyelésének és együttműködésének fejlesztése volt. Az SLO-k lehetővé tették számunkra, hogy célokat tűzzünk ki az egyes szolgáltatásokhoz, amelyeket az áttelepítés során szorosan figyelemmel kísértünk. De még a jobb megfigyelhetőség mellett sem mindig lehet azonnal észrevenni a problémákat a mérőszámok és riasztások használatával. Például a várakozási időre és a hibaarányra összpontosítva nem fedjük le teljes mértékben az áttelepítés alatt álló szolgáltatás minden használati esetét.
Ezt a problémát szinte azonnal észlelték, miután néhány munkaterhelést áttelepítettek a fürtre. Ez különösen akkor vált kiélezetté, amikor olyan funkciókat kellett ellenőriznünk, amelyekhez kicsi volt a kérések száma, de nagyon specifikus konfigurációfüggők voltak. A migráció egyik legfontosabb tanulsága az volt, hogy a figyelés során nemcsak a mérőszámokat kell figyelembe venni, hanem a naplókat és a „hosszú farkat” is. (ez kb a diagramon - kb. fordítás.) hibákat. Most minden áttelepítéshez mellékeljük a naplólekérdezések részletes listáját (napló lekérdezések) és világos visszaállítási eljárásokat tervezzenek, amelyek problémák esetén egyik műszakról a másikra átvihetők.
Egyedülálló kihívást jelentett ugyanazon kérések párhuzamos kiszolgálása a régi virtuálisgép-infrastruktúrán és az új Kubernetes-alapú infrastruktúrán. Ellentétben a lift-and-shift migrációval (az alkalmazások „ahogy vannak” gyors átvitele új infrastruktúrába; további részletek olvashatók pl. - kb. fordítás.), a „régi” virtuális gépeken és a Kubernetesen végzett párhuzamos munka megköveteli, hogy a megfigyelési eszközök kompatibilisek legyenek mindkét környezettel, és képesek legyenek a mutatókat egyetlen nézetben kombinálni. Fontos, hogy ugyanazokat az irányítópultokat és naplólekérdezéseket használjuk, hogy egységes megfigyelhetőséget érjünk el az átmeneti időszakban.
4. Forgalom átállítása új fürtre
A GitLab.com esetében a szerverek egy része erre van dedikálva . A Canary Park kiszolgálja belső projektjeinket, és azt is . De elsősorban az infrastruktúrán és az alkalmazáson végrehajtott változtatások tesztelésére tervezték. Az első áttelepített szolgáltatás korlátozott mennyiségű belső forgalom elfogadásával kezdődött, és továbbra is ezt a módszert használjuk annak biztosítására, hogy az SLO-k teljesüljenek, mielőtt az összes forgalmat a fürthöz küldené.
Áttelepítés esetén ez azt jelenti, hogy a belső projektek kérései először a Kubernetesnek kerülnek elküldésre, majd fokozatosan a fürtre kapcsoljuk a forgalom többi részét úgy, hogy a HAProxy-n keresztül módosítjuk a háttér súlyát. A virtuális gépről a Kubernetesre való migráció során világossá vált, hogy nagyon előnyös volt, ha a régi és az új infrastruktúra között egyszerűen át lehet irányítani a forgalmat, és ennek megfelelően a régi infrastruktúrát készen kell tartani a visszaállításra az migrációt követő első napokban.
5. A hüvelyek tartalékkapacitásai és felhasználásuk
Szinte azonnal a következő problémát azonosították: a Registry szolgáltatás podjai gyorsan elindultak, de a Sidekiq pod-ok elindítása több időt vett igénybe. . A Sidekiq pod-ok hosszadalmas indítási ideje problémát jelentett, amikor megkezdtük a munkaterhelések áttelepítését a Kubernetesre azon dolgozók számára, akiknek gyorsan kellett feldolgozniuk a feladatokat és gyorsan méretezniük kellett.
Ebben az esetben a tanulság az volt, hogy míg a Kubernetes Horizontal Pod Autoscaler (HPA) jól kezeli a forgalomnövekedést, fontos figyelembe venni a terhelések jellemzőit, és szabad kapacitást allokálni a podokra (főleg, ha a kereslet egyenetlenül oszlik el). A mi esetünkben hirtelen megugrott a munkák száma, ami gyors skálázódáshoz vezetett, ami a CPU-erőforrások telítéséhez vezetett, még mielőtt időnk lett volna a csomópontkészlet méretezésére.
Mindig van kísértés, hogy a lehető legtöbbet kisajtoljuk egy fürtből, azonban mivel kezdetben teljesítményproblémákba ütköztünk, most egy bőkezű pod-költségvetésbe kezdünk, majd később csökkentjük, szorosan figyelve az SLO-kat. A Sidekiq szolgáltatás podjainak elindítása jelentősen felgyorsult, és átlagosan körülbelül 40 másodpercet vesz igénybe. megnyerte a GitLab.com webhelyet és a hivatalos GitLab Helm diagrammal dolgozó saját kezelésű telepítések felhasználóit.
Következtetés
Az egyes szolgáltatások migrálása után örültünk a Kubernetes éles környezetben való használatának előnyeinek: gyorsabb és biztonságosabb alkalmazástelepítés, méretezés és hatékonyabb erőforrás-allokáció. Ezenkívül a migráció előnyei túlmutatnak a GitLab.com szolgáltatáson. A hivatalos Helm diagram minden fejlesztése a felhasználók számára előnyös.
Remélem, tetszett a Kubernetes vándorlási kalandjaink története. Folytatjuk az összes új szolgáltatás áttelepítését a fürtbe. További információk a következő kiadványokban találhatók:
- «";
- «";
- .
PS a fordítótól
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com