A Pinterest évei alatt 300 millió felhasználó több mint 200 milliárd pin-t hozott létre több mint 4 milliárd táblán. Ennek a hatalmas felhasználói bázisnak és kiterjedt tartalmi adatbázisnak a kiszolgálása érdekében a portál több ezer szolgáltatást fejlesztett ki, kezdve a néhány CPU-val működő mikroszolgáltatásokkal, egészen a hatalmas monolitokig, amelyek egy teljes virtuális gépparkon futnak. És eljött az a pillanat, amikor a cég a k8s-re irányította a figyelmét. Miért ragadta meg a „kockát” a Pinterest? Erről egy friss cikkünk fordításából értesülhet. .
Szóval, számos millió felhasználó és számos milliárd pin. Annak érdekében, hogy kiszolgáljuk ezt a hatalmas felhasználói bázist és kiterjedt tartalmi adatbázist, több ezer szolgáltatást fejlesztettünk ki, kezdve a néhány CPU-val működő mikroszolgáltatásokkal, egészen a hatalmas monolitokig, amelyek egy teljes virtuális gépparkon futnak. Emellett különböző keretrendszereink is vannak, amelyek szintén igényelhetnek CPU-erőforrást, memóriát vagy hozzáférést a bemeneti/kimeneti műveletekhez.
A fejlesztőcsapat a különféle eszközök támogatása során számos problémával találkozik:
- Az mérnököknek nincs egységes módja a munkakörnyezet futtatásának. A stateless szolgáltatások, stateful szolgáltatások és az aktívan fejlesztés alatt álló projektek teljesen eltérő technológiai stackekre épülnek. Ez oda vezetett, hogy egész tréningkurzusokat kellett létrehozni az mérnökök számára, és komolyan megnehezíti az infrastruktúra csapatunk munkáját.
- A fejlesztők, akik saját virtuális gépparkot használnak, hatalmas terhelést ró az belső adminisztrátorokra. Ennek eredményeként olyan egyszerű műveletek, mint az operációs rendszer vagy AMI frissítése hetekig, hónapokig elhúzódnak. Ez ártalmas terhelést eredményez, még olyan, látszólag hétköznapi helyzetekben is.
- A globális infrastruktúra kezelési eszközök létrehozásának nehézségei a már meglévő megoldások felett. A helyzetet bonyolítja, hogy nehéz megtalálni a virtuális gépek tulajdonosait. Vagyis nem tudjuk, hogy biztonságosan ki lehet-e vonni ezeket a teljesítményeket más részeink működtetésére.
A konténeres orchesztrációs rendszerek egységesítik a munkaterhelés kezelését. Lehetővé teszik a fejlesztési sebesség növelését és megkönnyítik az infrastruktúra kezelését, mivel a projekt során részt vevő összes forrást egy központosított rendszer irányítja.
1. ábra: Infrastruktúra prioritások (megbízhatóság, fejlesztői teljesítmény és hatékonyság).
A Pinterest Cloud Management Platform csapata 2017-ben ismerkedett meg a K8s-el. 2017 első felére dokumentáltuk a termelési kapacitásaink nagy részét, beleértve az API-t és az összes webszerverünket. Ezt követően alaposan értékeltük a különböző konténeres orchestration rendszereket, klaszterépítési megoldásokat és azok működését. 2017 végére úgy döntöttünk, hogy használni fogjuk a Kubernetes-t. Elég rugalmas volt és széles körben támogatott a fejlesztői közösség által.
Jelenleg saját klaszter-inicializáló eszközeinket alakítottuk ki Kops alapján, és átállítottuk a meglévő infrastruktúra komponenseit a Kubernetes-re — mint például a hálózat, biztonság, metrikák, naplózás, azonosítási kezelés és forgalom. Ezen kívül létrehoztunk egy munkaterhelés modellező rendszert az erőforrásunkhoz, amelynek összetettsége rejtve marad a fejlesztők előtt. Most a klaszter stabilitásának biztosítására, annak méretezésére és új ügyfelek csatlakoztatására összpontosítunk.
Kubernetes: Pinterest útja
A Kubernetes Pinterest általi bevezetése, mint olyan platform, amelyet mérnökeink kedvelni fognak, számos nehézséghez vezetett.
Mint nagyvállalat, jelentős összegeket fektettünk az infrastruktúra eszközökbe. Például a biztonsági eszközök, amelyek kezelik a tanúsítványokat és a kulcsok elosztását, forgalom-ellenőrző elemek, szolgáltatás-felfedező rendszerek, láthatósági és naplózási komponensek és metrikák. Mindezek nem véletlenszerűen kerültek összeállításra: végigjártuk a próba és hiba normális útját, ezért szerettük volna integrálni ezt az egészet az új Kubernetes-alapú infrastruktúrába, ahelyett, hogy újra feltalálnánk a régi biciklit egy új platformon. Ez a megközelítés összességében megkönnyítette a migrációt, mivel minden alkalmazástámogatás már létezett, nem kellett azt nulláról létrehozni.
Másrészt a Kubernetesben a terhelés-előrejelző modellek (például a telepítések, feladatok és Daemon készletek) nem elegendőek a projektünk számára. Ezek a használhatósági problémák hatalmas akadályok az átállás során. Például hallottuk, hogy a szolgáltatásfejlesztők panaszkodnak a belépési lehetőségek hiányára vagy helytelen konfigurálására. Emellett találkoztunk a sablonkezelők helytelen használatával, amikor több száz azonos specifikációval és feladattal készült másolat jött létre, ami szörnyű hibakeresési problémákhoz vezetett.
A különböző verziók támogatása is nagyon nehézkes volt ugyanabban a klaszterben. Képzelje el a kliensek támogatásának bonyolultságát, ha egyszerre több verzióval kell dolgoznia ugyanazon futtatási környezetről, az összes problémájával, hibájával és frissítésével.
Pinterest egyéni erőforrásai és vezérlői
A Kubernetes bevezetésének megkönnyítése érdekében, valamint az infrastruktúra egyszerűsítése és sebességének növelése céljából kifejlesztettük a saját egyéni erőforrásdefinícióinkat (CRD).
A CRD a következő funkciókat biztosítja:
- Különböző natív Kubernetes erőforrások egyesítése, hogy együttes terhelésként működjenek. Például a PinterestService erőforrás magában foglalja a telepítést, a belépési szolgáltatást és a konfigurációs térképet. Ez lehetővé teszi a fejlesztők számára, hogy ne kelljen a DNS beállításaival foglalkozniuk.
- A szükséges alkalmazástámogatás bevezetése. A felhasználónak csak a konténer specifikációjára kell összpontosítania az üzleti logikája szerint, míg a CRD vezérlő bevezeti az összes szükséges init-konténert, környezeti változót és pod specifikációt. Ez lényegesen más szintű kényelmet biztosít a fejlesztők számára.
- A CRD vezérlők a saját erőforrásaik életciklusát is kezelik, és növelik a hibakeresési elérhetőséget. Ez magában foglalja a kívánt és valós specifikációk egyeztetését, a CRD állapotának frissítését, és eseménynaplók vezetését, és még sok mást. A CRD nélkül a fejlesztőknek számos erőforrást kellett volna kezelniük, ami csak növelte volna a hibák lehetőségét.
Íme egy példa a PinterestService-re és a belső erőforrásra, amelyet a vezérlőnk kezel:
Ahogy fentebb látható, a felhasználói konténer támogatásához integrálnunk kell egy inicializáló konténert és néhány bővítményt, hogy biztosítsuk a biztonságot, a láthatóságot és a hálózati forgalom kezelését. Ezen kívül létrehoztunk konfigurációs térkép sablonokat és megvalósítottuk a PVC sablonok támogatását a csomagolt feladatokhoz, valamint nyomon követjük a környezeti változókat az azonosítás, erőforrás-fogyasztás és a „szemét” gyűjtés nyomon követése érdekében.
Nehezen képzelhető el, hogy a fejlesztők kézi úton írják meg ezeket a konfigurációs fájlokat CRD támogatás nélkül, nem beszélve a konfigurációk további támogatásáról és hibakereséséről.
Alkalmazások telepítési munkafolyamata
A fenti ábra azt mutatja, hogyan lehet telepíteni a Pinterest felhasználói erőforrást a Kubernetes klaszterbe:
- A fejlesztők CLI-n és a felhasználói felületen keresztül lépnek kapcsolatba a Kubernetes klaszterünkkel.
- A CLI / UI eszközök YAML konfigurációs fájlokat és egyéb build tulajdonságokat (ugyanaz a verzióazonosító) húznak ki az Artifactory-ból, majd ezeket elküldik a Munkafolyamat Beküldési Szolgáltatásnak. Ez a lépés biztosítja, hogy csak működő verziók kerüljenek be a klaszterbe.
- A JSS különböző platformok átjárója, beleértve a Kubernetest. Itt történik a felhasználó hitelesítése, a kvóták kiadása és a CRD konfiguráció részleges ellenőrzése.
- A JSS oldalon történő CRD ellenőrzés után az információ az k8s platform API-jára kerül elküldésre.
- CRD-vezérlőnk nyomon követi az összes felhasználói erőforrás eseményeit. Átalakítja a CR-t natív k8s erőforrásokká, hozzáadja a szükséges modulokat, beállítja a megfelelő környezeti változókat, és elvégzi a többi támogató munkát, így biztosítva a konténeres felhasználói alkalmazások számára a kellő infrastruktúra támogatást.
- Ezután a CRD-vezérlő továbbítja az összegyűjtött adatokat a Kubernetes API-nak, hogy azokat a scheduler feldolgozhassa és működésbe léphessen.
Megjegyzés: ez a telepítési munkafolyamat előzetes verzióját az új k8s-platform korai felhasználói számára hoztuk létre. Jelenleg a folyamat finomításán dolgozunk, hogy teljes mértékben integrálódjunk az új CI/CD rendszerünkkel. Ez azt jelenti, hogy nem tudunk mindent elmondani a Kuberneteshez kapcsolódóan. Alig várjuk, hogy megosszuk tapasztalatainkat és beszámoljunk a csapat előrehaladásáról ebben az irányban a következő blogbejegyzésünkben, „CI/CD platform építése a Pinterest számára”.
Speciális erőforrások típusai
A Pinterest konkrét igényeinek figyelembevételével az alábbi CRD-ket fejlesztettük ki, amelyek különböző munkafolyamatokhoz illeszkednek:
- A PinterestService régóta működő stateless szolgáltatások. Számos alapvető rendszerünk ezen szolgáltatások összességén alapul.
- A PinterestJobSet egy teljes körű batch feladatcsomagot modellez. A Pinterest-en gyakori forgatókönyv, hogy több feladat párhuzamosan indítja ugyanazokat a konténereket, függetlenül más hasonló folyamatoktól.
- A PinterestCronJob széles körben alkalmazható kisebb, rendszeres terhelések esetén. Ez egy burkolószerkezet, amely natív cron működéshez készült, a Pinterest által kezelt biztonsági, forgalmi, naplózási és metrikai mechanizmusokkal.
- A PinterestDaemon infrastruktúra Daemon-okat tartalmaz. Ez a család folyamatosan bővül, mivel egyre több támogatást adunk a klasztereinkhez.
- A PinterestTrainingJob a Tensorflow és Pytorch folyamatokat célozza meg, biztosítva a munkavégzés közbeni azonos szintű támogatást, mint minden más CRD. Mivel a Pinterest aktívan használja a Tensorflow-t és más gépi tanulási rendszereket, indokolt volt egy külön CRD-t építeni köréjük.
Továbbá dolgozunk a PinterestStatefulSet-en, amely hamarosan adat tárolási és más stateful rendszerekhez igazodik.
Futtatókörnyezet támogatása
Amikor egy alkalmazásmodul elindul Kubernetesben, automatikusan megkapja a tanúsítványt, amely lehetővé teszi számára, hogy azonosítsa magát. Ezt a tanúsítványt használják a titkos tárolóhoz való hozzáféréshez vagy a többi szolgáltatással való kommunikációhoz mTLS-en keresztül. Eközben a konténer-kezdeményezési konfigurátor és a Daemon betölti az összes szükséges függőséget a konténeralkalmazás indítása előtt. Amikor minden készen áll, a sidecar forgalma és a Daemon regisztrálja a modul IP-címét a Zookeeperünkben, hogy az ügyfelek felfedezhessék. Mindez működni fog, mivel a hálózati modul már a alkalmazás elindítása előtt be volt állítva.
Fenti példák a tipikus munkaterhek támogatására vonatkoznak futás közben. Más típusú munkaterhekhez talán kissé eltérő támogatás szükséges, de mindegyik pod szintű sidecar-ként, nodális, vagy virtuális gépek Daemon-jaiként jelenik meg. Gondoskodunk arról, hogy mindez a menedzsment infrastruktúra keretein belül legyen telepítve és összehangolva az alkalmazások között, ami végül jelentősen csökkenti a technikai munka és az ügyféltámogatás terheit.
Tesztelés és QA
Összegyűjtöttük az end-to-end tesztelési folyamatot a már meglévő Kubernetes tesztinfrastruktúra felett. Ezek a tesztek minden klaszterre kiterjednek. A folyamatunk számos átalakításon ment keresztül, mielőtt a termék klaszterének részévé vált.
A tesztelési rendszerek mellett monitoring és értesítési rendszereink is vannak, amelyek folyamatosan figyelemmel kísérik a rendszer komponenseinek állapotát, a resource-felhasználást és más fontos mutatókat, csak akkor értesítve minket, ha emberi beavatkozásra van szükség.
Alternatívák
Megfontoltuk néhány alternatívát a testreszabott erőforrások számára, mint például a mutációs vezérlőket és a sablonrendszereket. Azonban mindezek komoly működési nehézségekkel jártak, ezért a CRD módszerét választottuk.
A mutációs hozzáférési ellenőrzőt a sidecarok, környezeti változók és egyéb futási támogatások bevezetésére használták. Mindazonáltal számos problémával küzdött, például az erőforrások összekapcsolása és életciklusuk kezelése terén, míg a CRD esetében ilyen problémák nem merülnek fel.
Megjegyzés: A sablonrendszerek, mint a Helm-diagramok, szintén széles körben használatosak hasonló konfigurációjú alkalmazások indítására. Azonban a mi munkánk során az alkalmazások túl változatosak ahhoz, hogy sablonokkal kezelhessük őket. Emellett a folyamatos telepítés során, sablonok használatakor, túl sok hiba lépne fel.
Közelgő munka
Jelenleg vegyes terheléssel foglalkozunk minden klaszterünkben. Az ilyen típusú és méretű folyamatok támogatása érdekében a következő irányokban dolgozunk:
- A klaszterek összessége nagy alkalmazásokat oszt el különböző klaszterek között a skálázhatóság és a stabilitás biztosítása érdekében.
- A klaszter stabilitásának, skálázhatóságának és láthatóságának biztosítása az alkalmazás és SLA kapcsolatának létrehozása érdekében.
- Erőforrások és kvóták kezelése, hogy az alkalmazások ne ütközzenek egymással, és a klaszter méretét kezünk alatt tartsuk.
- Új CI/CD platform az alkalmazások Kubernetesben történő támogatásához és telepítéséhez.
Forrás: habr.com
