Az évek során a Pinterest 300 millió felhasználója több mint 200 milliárd tűt hozott létre több mint 4 milliárd táblán. Ennek a felhasználói seregnek és a hatalmas tartalombázisnak a kiszolgálására a portál több ezer szolgáltatást fejlesztett ki, a néhány CPU-val kezelhető mikroszolgáltatásoktól a virtuális gépek teljes flottáján futó óriási monolitokig. És akkor eljött a pillanat, amikor a cég szeme a k8s-ra esett. Miért nézett ki jól a „kocka” a Pinteresten? Erről megtudhatja egy nemrégiben megjelent cikkünk fordításából .
Tehát több száz millió felhasználó és több száz milliárd pin. A felhasználók seregének és a hatalmas tartalombázisnak a kiszolgálására több ezer szolgáltatást fejlesztettünk ki, a néhány CPU-val kezelhető mikroszolgáltatásoktól a virtuális gépek teljes flottáján futó óriási monolitokig. Ezen kívül számos keretrendszerünk van, amelyek szintén igényelhetnek CPU-, memória- vagy I/O-hozzáférést.
Az eszközpark karbantartása során a fejlesztőcsapat számos kihívással néz szembe:
- A mérnökök számára nincs egységes módszer a termelési környezet működtetésére. Az állapot nélküli szolgáltatások, a Stateful szolgáltatások és az aktív fejlesztés alatt álló projektek teljesen más technológiai halmazokra épülnek. Ez egy teljes képzési tanfolyam létrehozásához vezetett a mérnökök számára, és komolyan megnehezíti infrastrukturális csapatunk munkáját.
- A saját virtuális gépparkkal rendelkező fejlesztők óriási terhet rónak a belső rendszergazdákra. Ennek eredményeként az olyan egyszerű műveletek, mint az operációs rendszer vagy az AMI frissítése heteket és hónapokat vesznek igénybe. Ez megnövekedett munkaterheléshez vezet a látszólag abszolút mindennapos helyzetekben.
- Nehézségek a globális infrastruktúra-menedzsment eszközök létrehozásában a meglévő megoldásokon felül. A helyzetet tovább bonyolítja, hogy nem egyszerű megtalálni a virtuális gépek tulajdonosait. Vagyis nem tudjuk, hogy ez a kapacitás biztonságosan kitermelhető-e az infrastruktúra más részein való működéshez.
A konténerhangosítási rendszerek a munkaterhelés-kezelés egységesítésének egyik módja. Kinyitják a kaput a nagyobb fejlesztési sebesség előtt és egyszerűsítik az infrastruktúra kezelését, mivel a projektben részt vevő összes erőforrást egyetlen központosított rendszer kezeli.
1. ábra: Az infrastruktúra prioritásai (megbízhatóság, fejlesztői termelékenység és hatékonyság).
A Pinterest Cloud Management Platform csapata 8-ben fedezte fel a K2017s-okat. 2017 első felére dokumentáltuk termelési képességeink nagy részét, beleértve az API-t és az összes webszerverünket. Ezt követően a konténermegoldások összehangolására, a klaszterek építésére és a velük való munkavégzésre vonatkozóan elvégeztük a különféle rendszerek alapos felmérését. 2017 vége felé a Kubernetes használata mellett döntöttünk. Meglehetősen rugalmas volt, és a fejlesztői közösség széles körben támogatott.
A mai napig elkészítettük saját fürtindítási eszközeinket, amelyek Kops-on alapulnak, és a meglévő infrastruktúra-összetevőket, például a hálózatot, a biztonságot, a mérőszámokat, a naplózást, az identitáskezelést és a forgalmat áttelepítettük a Kubernetesre. Erőforrásunkhoz munkaterhelés-modellező rendszert is bevezettünk, melynek összetettsége rejtve van a fejlesztők elől. Most a klaszter stabilitásának biztosítására, méretezésére és új ügyfelek csatlakoztatására összpontosítunk.
Kubernetes: The Pinterest Way
A Kubernetes használatának megkezdése a Pinterest szintjén, mint olyan platform, amelyet mérnökeink imádni fognak, rengeteg kihívással járt.
Nagyvállalatként sokat fektettünk be az infrastrukturális eszközökbe. Ilyenek például a tanúsítványfeldolgozást és kulcselosztást kezelő biztonsági eszközök, a forgalomirányítási összetevők, a szolgáltatásfelderítő rendszerek, a láthatósági összetevők, valamint a napló- és mérőszámok küldési összetevői. Mindezt okkal gyűjtöttük össze: végigmentünk a próba és hiba szokásos útján, és ezért szerettük volna mindezt a berendezést a Kubernetes új infrastruktúrájába integrálni, ahelyett, hogy a régi kereket egy új platformon újra feltaláltuk volna. Ez a megközelítés összességében leegyszerűsítette az áttelepítést, mivel az összes alkalmazástámogatás már létezik, és nem kell a semmiből létrehozni.
Másrészt a Kubernetes terhelés-előrejelzési modelljei (például telepítések, feladatok és démonkészletek) nem elegendőek a projektünkhöz. Ezek a használhatósági problémák óriási akadályok a Kubernetesre való átállás előtt. Hallottuk például, hogy a szolgáltatásfejlesztők panaszkodnak hiányzó vagy helytelen bejelentkezési beállítások miatt. A sablonmotorok helytelen használatával is találkoztunk, amikor több száz példány készült ugyanazzal a specifikációval és feladattal, ami rémálomszerű hibakeresési problémákat eredményezett.
Nagyon nehéz volt ugyanabban a klaszterben különböző verziókat karbantartani. Képzelje el az ügyfélszolgálat bonyolultságát, ha egyidejűleg ugyanazon futási környezet több verziójában kell dolgoznia, minden problémájával, hibájával és frissítésével együtt.
Pinterest felhasználói tulajdonságai és vezérlői
Annak érdekében, hogy mérnökeink könnyebben megvalósíthassák a Kubernetes alkalmazást, valamint egyszerűsítsük és felgyorsítsuk infrastruktúránkat, kifejlesztettük saját egyéni erőforrás-definícióinkat (CRD).
A CRD-k a következő funkciókat biztosítják:
- A különböző natív Kubernetes-erőforrások kombinálása, hogy azok egyetlen munkaterhelésként működjenek. Például a PinterestService erőforrás tartalmaz egy központi telepítést, egy bejelentkezési szolgáltatást és egy konfigurációs térképet. Ez lehetővé teszi a fejlesztőknek, hogy ne aggódjanak a DNS beállítása miatt.
- Végezze el a szükséges alkalmazástámogatást. A felhasználónak csak a konténer specifikációra kell koncentrálnia az üzleti logikájának megfelelően, míg a CRD vezérlő megvalósítja az összes szükséges init konténert, környezeti változót és pod specifikációt. Ez alapvetően más szintű kényelmet biztosít a fejlesztők számára.
- A CRD-vezérlők a natív erőforrások életciklusát is kezelik, és javítják a hibakeresés elérhetőségét. Ez magában foglalja a kívánt és a tényleges specifikációk egyeztetését, a CRD állapotának frissítését és az eseménynaplók karbantartását és még sok mást. CRD nélkül a fejlesztők több erőforrás kezelésére kényszerülnének, ami csak növelné a hiba valószínűségét.
Íme egy példa egy PinterestService-re és egy belső erőforrásra, amelyet a vezérlőnk kezel:
Mint fentebb látható, az egyéni tároló támogatásához integrálnunk kell egy indítótárolót és több kiegészítőt a biztonság, a láthatóság és a hálózati forgalom biztosítása érdekében. Ezenkívül konfigurációs térképsablonokat hoztunk létre, és bevezettük a PVC-sablonok támogatását a kötegelt feladatokhoz, valamint több környezeti változó nyomon követését az identitás, az erőforrás-felhasználás és a szemétgyűjtés nyomon követésére.
Nehéz elképzelni, hogy a fejlesztők CRD támogatás nélkül kézzel szeretnék megírni ezeket a konfigurációs fájlokat, nem beszélve a konfigurációk további karbantartásáról és hibakereséséről.
Alkalmazástelepítési munkafolyamat
A fenti kép bemutatja, hogyan telepíthet egyéni Pinterest-erőforrást egy Kubernetes-fürtre:
- A fejlesztők a CLI-n és a felhasználói felületen keresztül lépnek kapcsolatba Kubernetes-fürtünkkel.
- A CLI/UI-eszközök lekérik a munkafolyamat-konfigurációs YAML-fájlokat és más összeállítási tulajdonságokat (azonos verzióazonosító) az Artifactory-ból, majd elküldik azokat a Job Submission Service-nek. Ez a lépés biztosítja, hogy csak éles verziók kerüljenek a fürtbe.
- A JSS egy átjáró különféle platformokhoz, köztük a Kuberneteshez. Itt a felhasználó hitelesítése, kvóták kiadása és a CRD konfigurációjának részleges ellenőrzése történik.
- A CRD JSS oldalon történő ellenőrzése után az információ elküldésre kerül a k8s platform API-nak.
- CRD-vezérlőnk minden felhasználói erőforráson figyeli az eseményeket. A CR-eket natív k8s erőforrásokká alakítja, hozzáadja a szükséges modulokat, beállítja a megfelelő környezeti változókat, és egyéb támogatási munkákat végez annak biztosítása érdekében, hogy a konténeres felhasználói alkalmazások megfelelő infrastruktúra-támogatást kapjanak.
- A CRD-vezérlő ezután átadja a kapott adatokat a Kubernetes API-nak, hogy az ütemező feldolgozhassa és üzembe helyezhesse.
Megjegyzés: A telepítésnek ez a kiadás előtti munkafolyamata az új k8s platform első felhasználói számára készült. Jelenleg ennek a folyamatnak a finomításán dolgozunk, hogy teljes mértékben integrálódjunk új CI/CD-nkkel. Ez azt jelenti, hogy nem mondhatunk el mindent, ami a Kubernetes-szel kapcsolatos. Várjuk, hogy megosszuk tapasztalatainkat és a csapat ebben az irányban elért előrehaladását a következő blogbejegyzésünkben, „A CI/CD platform építése a Pinterest számára”.
A speciális erőforrások típusai
A Pinterest speciális igényei alapján a következő CRD-ket fejlesztettük ki, hogy megfeleljenek a különböző munkafolyamatoknak:
- A PinterestService állapot nélküli szolgáltatások, amelyek régóta futnak. Számos alaprendszerünk ilyen szolgáltatásokon alapul.
- A PinterestJobSet teljes ciklusú kötegelt munkákat modellez. A Pinteresten általánosan elterjedt forgatókönyv az, hogy több feladat futtatja párhuzamosan ugyanazt a tárolót, függetlenül a többi hasonló folyamattól.
- A PinterestCronJob-ot széles körben használják kis időszakos terhelésekkel együtt. Ez egy csomagolóanyag a natív cron-munkához a biztonságért, a forgalomért, a naplókért és a metrikákért felelős Pinterest-támogatási mechanizmusokkal.
- A PinterestDaemon infrastruktúra démonokat tartalmaz. Ez a család folyamatosan növekszik, ahogy egyre több támogatást adunk klasztereinkhez.
- A PinterestTrainingJob kiterjed a Tensorflow és a Pytorch folyamatokra, és ugyanolyan szintű futásidejű támogatást biztosít, mint az összes többi CRD. Mivel a Pinterest aktívan használja a Tensorflow-t és más gépi tanulási rendszereket, okunk volt arra, hogy külön CRD-t építsünk köréjük.
Dolgozunk a PinterestStatefulSet-en is, amelyet hamarosan adaptálunk adattárházakhoz és más állapotjelző rendszerekhez.
Futásidejű támogatás
Amikor egy alkalmazáscsomag fut a Kubernetes rendszeren, automatikusan kap egy tanúsítványt, amely azonosítja magát. Ez a tanúsítvány a titkos tárhely elérésére vagy más szolgáltatásokkal való kommunikációra szolgál mTLS-en keresztül. Eközben a Container Init Configurator és a Daemon letölti az összes szükséges függőséget a konténeres alkalmazás futtatása előtt. Amikor minden készen áll, a forgalmi oldalkocsi és a démon regisztrálja a modul IP-címét a Zookeeper-nél, hogy az ügyfelek felfedezhessék azt. Mindez működni fog, mert a hálózati modult az alkalmazás elindítása előtt konfigurálták.
A fentiek tipikus példák a munkaterhelések futásidejű támogatására. Más típusú munkaterhelések némileg eltérő támogatást igényelhetnek, de mindegyik pod-szintű oldalkocsik, csomópont-szintű vagy virtuálisgép-szintű démonok formájában jelenik meg. Biztosítjuk, hogy mindez a felügyeleti infrastruktúrán belül kerüljön telepítésre, és az alkalmazások között konzisztens legyen, ami végső soron jelentősen csökkenti a műszaki munka és az ügyfélszolgálat terheit.
Tesztelés és minőségbiztosítás
A meglévő Kubernetes tesztinfrastruktúrára egy végponttól végpontig terjedő tesztfolyamatot építettünk. Ezek a tesztek minden klaszterünkre vonatkoznak. A folyamat számos felülvizsgálaton ment keresztül, mielőtt a termékklaszter részévé vált.
A tesztelő rendszereken kívül vannak olyan felügyeleti és riasztási rendszereink, amelyek folyamatosan figyelik a rendszerelemek állapotát, az erőforrás-felhasználást és egyéb fontos mutatókat, csak akkor értesítenek bennünket, ha emberi beavatkozásra van szükség.
Alternatívák
Megvizsgáltunk néhány alternatívát az egyéni erőforrásokhoz, például a mutációs hozzáférés-vezérlőket és a sablonrendszereket. Azonban mindegyik jelentős működési kihívásokkal jár, ezért a CRD útvonalat választottuk.
Az oldalkocsik, környezeti változók és egyéb futásidejű támogatások bevezetésére mutációs beléptetővezérlőt használtak. Különféle problémákkal szembesült azonban, például az erőforrás-kötéssel és az életciklus-kezeléssel, amelyeknél ilyen problémák nem merülnek fel a CRD-ben.
Megjegyzés: A sablonrendszereket, például a Helm diagramokat is széles körben használják hasonló konfigurációjú alkalmazások futtatására. Munkaalkalmazásaink azonban túl sokrétűek ahhoz, hogy sablonokkal kezeljük őket. A folyamatos telepítés során is túl sok hiba lesz a sablonok használatakor.
Közelgő munka
Jelenleg vegyes terheléssel foglalkozunk az összes klaszterünkben. A különböző típusú és méretű folyamatok támogatása érdekében a következő területeken dolgozunk:
- A fürtök gyűjteménye nagy alkalmazásokat oszt el különböző fürtök között a méretezhetőség és a stabilitás érdekében.
- A fürt stabilitásának, méretezhetőségének és láthatóságának biztosítása az alkalmazáskapcsolatok és SLA-k létrehozásához.
- Az erőforrások és kvóták kezelése úgy, hogy az alkalmazások ne ütközzenek egymással, és a fürt méretét részünkről szabályozzuk.
- Új CI/CD platform az alkalmazások támogatásához és telepítéséhez Kubernetesen.
Forrás: will.com