V priebehu rokov vytvorilo 300 miliónov používateľov Pinterestu viac ako 200 miliárd pinov na viac ako 4 miliardách tabúľ. Aby mohol slúžiť tejto armáde používateľov a rozsiahlej obsahovej základni, portál vyvinul tisíce služieb, od mikroslužieb, ktoré dokáže spracovať niekoľko CPU, až po obrovské monolity, ktoré bežia na celej flotile virtuálnych strojov. A potom prišiel moment, keď pohľad spoločnosti padol na k8s. Prečo „kocka“ vyzerala dobre na Pintereste? Dozviete sa o tom z nášho prekladu nedávneho článku z .
Takže stovky miliónov používateľov a stovky miliárd pinov. Aby sme slúžili tejto armáde používateľov a rozsiahlej obsahovej základni, vyvinuli sme tisíce služieb, od mikroslužieb, ktoré môže spracovať niekoľko CPU, až po obrovské monolity, ktoré bežia na celých flotilách virtuálnych strojov. Okrem toho máme rôzne rámce, ktoré môžu tiež vyžadovať prístup k CPU, pamäti alebo I/O.
Pri udržiavaní tejto zoo nástrojov čelí vývojový tím niekoľkým výzvam:
- Pre inžinierov neexistuje jednotný spôsob, ako prevádzkovať produkčné prostredie. Bezstavové služby, Stavové služby a projekty, ktoré sa aktívne vyvíjajú, sú založené na úplne odlišných technológiách. To viedlo k vytvoreniu celého školiaceho kurzu pre inžinierov a tiež vážne komplikuje prácu nášho infraštruktúrneho tímu.
- Vývojári s vlastnou flotilou virtuálnych strojov vytvárajú obrovskú záťaž pre interných správcov. Výsledkom je, že také jednoduché operácie, ako je aktualizácia OS alebo AMI, trvajú týždne a mesiace. To vedie k zvýšenému pracovnému zaťaženiu v zdanlivo absolútne každodenných situáciách.
- Ťažkosti pri vytváraní nástrojov globálnej správy infraštruktúry nad rámec existujúcich riešení. Situáciu ešte viac komplikuje fakt, že nájsť majiteľov virtuálnych strojov nie je jednoduché. To znamená, že nevieme, či je možné túto kapacitu bezpečne vyťažiť na prevádzku v iných častiach našej infraštruktúry.
Systémy orchestrácie kontajnerov predstavujú spôsob, ako zjednotiť riadenie pracovného zaťaženia. Otvárajú dvere vyššej rýchlosti vývoja a zjednodušujú správu infraštruktúry, pretože všetky zdroje zahrnuté v projekte sú riadené jedným centralizovaným systémom.
Obrázok 1: Priority infraštruktúry (spoľahlivosť, produktivita vývojárov a efektivita).
Tím Cloud Management Platform na Pintereste objavil K8 v roku 2017. Do prvej polovice roku 2017 sme zdokumentovali väčšinu našich produkčných možností vrátane API a všetkých našich webových serverov. Potom sme vykonali dôkladné posúdenie rôznych systémov na organizovanie kontajnerových riešení, vytváranie klastrov a prácu s nimi. Ku koncu roka 2017 sme sa rozhodli používať Kubernetes. Bolo to dosť flexibilné a široko podporované v komunite vývojárov.
K dnešnému dňu sme vytvorili naše vlastné klastrové bootovacie nástroje založené na Kops a migrovali existujúce komponenty infraštruktúry, ako sú siete, bezpečnosť, metriky, protokolovanie, správa identity a návštevnosť na Kubernetes. Pre náš zdroj sme implementovali aj systém modelovania pracovného zaťaženia, ktorého zložitosť je vývojárom skrytá. Teraz sa zameriavame na zabezpečenie stability klastra, jeho škálovanie a pripájanie nových klientov.
Kubernetes: The Pinterest Way
Začiatok s Kubernetes v rozsahu Pinterestu ako platformy, ktorú by naši inžinieri milovali, priniesol veľa výziev.
Ako veľká spoločnosť sme veľa investovali do nástrojov infraštruktúry. Príklady zahŕňajú bezpečnostné nástroje, ktoré spracúvajú certifikáty a distribúciu kľúčov, komponenty riadenia prevádzky, systémy zisťovania služieb, komponenty viditeľnosti a komponenty odosielania protokolov a metrík. Toto všetko bolo zhromaždené z nejakého dôvodu: prešli sme bežnou cestou pokusov a omylov, a preto sme chceli integrovať všetko toto vybavenie do novej infraštruktúry na Kubernetes namiesto toho, aby sme znovu vynašli staré koleso na novej platforme. Tento prístup celkovo zjednodušil migráciu, pretože všetka podpora aplikácií už existuje a nie je potrebné ju vytvárať od začiatku.
Na druhej strane, modely prognózovania zaťaženia v samotnom Kubernetes (ako sú nasadenia, úlohy a sady démonov) pre náš projekt nestačia. Tieto problémy s použiteľnosťou sú obrovskými prekážkami prechodu na Kubernetes. Počuli sme napríklad, že vývojári služieb sa sťažovali na chýbajúce alebo nesprávne nastavenia prihlasovania. Stretli sme sa aj s nesprávnym používaním šablón šablón, kedy boli vytvorené stovky kópií s rovnakou špecifikáciou a úlohou, čo malo za následok problémy s ladením nočnej mory.
Bolo tiež veľmi ťažké udržiavať rôzne verzie v rovnakom klastri. Predstavte si zložitosť zákazníckej podpory, ak potrebujete pracovať súčasne vo viacerých verziách toho istého runtime prostredia so všetkými ich problémami, chybami a aktualizáciami.
Používateľské vlastnosti a ovládače Pinterestu
Aby sme našim inžinierom uľahčili implementáciu Kubernetes a zjednodušili a zrýchlili našu infraštruktúru, vyvinuli sme vlastné definície zdrojov (CRD).
CRD poskytujú nasledujúce funkcie:
- Kombinovanie rôznych natívnych zdrojov Kubernetes tak, aby fungovali ako jediné pracovné zaťaženie. Napríklad zdroj PinterestService zahŕňa nasadenie, prihlasovaciu službu a konfiguračnú mapu. To umožňuje vývojárom nestarať sa o nastavovanie DNS.
- Implementujte potrebnú podporu aplikácií. Používateľ sa musí zamerať iba na špecifikáciu kontajnera podľa svojej obchodnej logiky, zatiaľ čo kontrolér CRD implementuje všetky potrebné init kontajnery, premenné prostredia a špecifikácie pod. To poskytuje zásadne inú úroveň komfortu pre vývojárov.
- Radiče CRD tiež riadia životný cyklus natívnych zdrojov a zlepšujú dostupnosť ladenia. To zahŕňa zosúladenie požadovaných a skutočných špecifikácií, aktualizáciu stavu CRD a udržiavanie denníkov udalostí a ďalšie. Bez CRD by boli vývojári nútení spravovať viacero zdrojov, čo by len zvýšilo pravdepodobnosť chyby.
Tu je príklad služby PinterestService a interného zdroja, ktorý spravuje náš kontrolór:
Ako môžete vidieť vyššie, na podporu vlastného kontajnera potrebujeme integrovať init kontajner a niekoľko doplnkov, ktoré zabezpečia bezpečnosť, viditeľnosť a sieťovú prevádzku. Okrem toho sme vytvorili šablóny konfiguračných máp a implementovali podporu pre PVC šablóny pre dávkové úlohy, ako aj sledovanie viacerých premenných prostredia na sledovanie identity, spotreby zdrojov a zberu odpadu.
Je ťažké si predstaviť, že by vývojári chceli tieto konfiguračné súbory písať ručne bez podpory CRD, nehovoriac o ďalšej údržbe a ladení konfigurácií.
Pracovný postup nasadenia aplikácie
Obrázok vyššie ukazuje, ako nasadiť vlastný zdroj Pinterestu do klastra Kubernetes:
- Vývojári interagujú s naším klastrom Kubernetes prostredníctvom rozhrania CLI a používateľského rozhrania.
- Nástroje CLI/UI získavajú konfiguračné súbory YAML pracovného toku a ďalšie vlastnosti zostavy (rovnaké ID verzie) z Artifactory a potom ich odosielajú do služby Job Submission Service. Tento krok zabezpečí, že do klastra budú doručené iba produkčné verzie.
- JSS je bránou pre rôzne platformy vrátane Kubernetes. Tu sa overí používateľ, vydajú sa kvóty a čiastočne sa skontroluje konfigurácia nášho CRD.
- Po kontrole CRD na strane JSS sa informácie odošlú do API platformy k8s.
- Náš regulátor CRD monitoruje udalosti na všetkých používateľských zdrojoch. Konvertuje CR na natívne zdroje k8s, pridáva potrebné moduly, nastavuje vhodné premenné prostredia a vykonáva ďalšie podporné práce, aby sa zaistilo, že kontajnerizované používateľské aplikácie budú mať dostatočnú podporu infraštruktúry.
- CRD radič následne odovzdá prijaté dáta do Kubernetes API, aby ich mohol spracovať plánovač a dať do produkcie.
Poznámka: Tento pracovný postup nasadenia pred vydaním bol vytvorený pre prvých používateľov novej platformy k8s. V súčasnosti sme v procese zdokonaľovania tohto procesu, aby sme ho mohli plne integrovať s naším novým CI/CD. To znamená, že vám nemôžeme povedať všetko, čo súvisí s Kubernetes. Tešíme sa na zdieľanie našich skúseností a pokroku tímu v tomto smere v našom ďalšom blogovom príspevku „Building a CI/CD platform for Pinterest.“
Druhy špeciálnych zdrojov
Na základe špecifických potrieb Pinterestu sme vyvinuli nasledujúce CRD, aby vyhovovali rôznym pracovným postupom:
- PinterestService sú bezstavové služby, ktoré fungujú už dlho. Mnohé z našich základných systémov sú založené na súbore takýchto služieb.
- PinterestJobSet modeluje dávkové úlohy s plným cyklom. Bežným scenárom na Pintereste je, že viaceré úlohy spúšťajú rovnaké kontajnery paralelne bez ohľadu na iné podobné procesy.
- PinterestCronJob je široko používaný v spojení s malými periodickými záťažami. Toto je obal pre natívnu prácu cronu s podpornými mechanizmami Pinterestu, ktoré sú zodpovedné za bezpečnosť, návštevnosť, protokoly a metriky.
- PinterestDaemon zahŕňa démonov infraštruktúry. Táto rodina sa neustále rozrastá, pretože našim klastrom pridávame ďalšiu podporu.
- PinterestTrainingJob sa rozširuje na procesy Tensorflow a Pytorch a poskytuje rovnakú úroveň podpory behu ako všetky ostatné CRD. Keďže Pinterest aktívne používa Tensorflow a ďalšie systémy strojového učenia, mali sme dôvod postaviť okolo nich samostatné CRD.
Pracujeme aj na PinterestStatefulSet, ktorý bude čoskoro prispôsobený pre dátové sklady a ďalšie stavové systémy.
Runtime podpora
Keď aplikačný modul beží na Kubernetes, automaticky dostane certifikát na svoju identifikáciu. Tento certifikát sa používa na prístup k tajnému úložisku alebo na komunikáciu s inými službami prostredníctvom mTLS. Medzitým si Container Init Configurator a Daemon stiahnu všetky potrebné závislosti pred spustením kontajnerizovanej aplikácie. Keď je všetko pripravené, postranný vozík a Daemon zaregistrujú IP adresu modulu u nášho Zookeepera, aby ho klienti mohli objaviť. To všetko bude fungovať, pretože sieťový modul bol nakonfigurovaný pred spustením aplikácie.
Vyššie uvedené sú typické príklady podpory runtime pre pracovné zaťaženia. Iné typy pracovných zaťažení môžu vyžadovať mierne odlišnú podporu, ale všetky prichádzajú vo forme postranných vozíkov na úrovni modulov, démonov na úrovni uzlov alebo virtuálnych strojov. Zabezpečujeme, aby toto všetko bolo nasadené v rámci manažérskej infraštruktúry a bolo konzistentné naprieč aplikáciami, čo v konečnom dôsledku výrazne znižuje záťaž z hľadiska technickej práce a zákazníckej podpory.
Testovanie a kontrola kvality
Na vrchole existujúcej testovacej infraštruktúry Kubernetes sme vybudovali komplexný testovací kanál. Tieto testy platia pre všetky naše klastre. Náš kanál prešiel mnohými revíziami, kým sa stal súčasťou produktového klastra.
Okrem testovacích systémov disponujeme monitorovacími a výstražnými systémami, ktoré neustále monitorujú stav systémových komponentov, spotrebu zdrojov a ďalšie dôležité ukazovatele, pričom nás upozornia len vtedy, keď je potrebný ľudský zásah.
alternatívy
Pozreli sme sa na niektoré alternatívy k vlastným zdrojom, ako sú ovládače prístupu k mutáciám a systémy šablón. Všetky však prinášajú značné prevádzkové výzvy, preto sme zvolili cestu CRD.
Na zavedenie postranných vozíkov, premenných prostredia a ďalšej podpory behu bol použitý mutačný prístupový kontrolér. Čelila však rôznym problémom, ako je viazanie zdrojov a riadenie životného cyklu, kde takéto problémy v CRD nevznikajú.
Poznámka: Šablónové systémy, ako sú Helmove diagramy, sú tiež široko používané na spúšťanie aplikácií s podobnými konfiguráciami. Naše pracovné aplikácie sú však príliš rôznorodé na to, aby sa dali spravovať pomocou šablón. Aj počas nepretržitého nasadzovania bude pri používaní šablón príliš veľa chýb.
Nadchádzajúca práca
V súčasnosti sa stretávame so zmiešanou záťažou vo všetkých našich klastroch. Na podporu takýchto procesov rôznych typov a veľkostí pracujeme v nasledujúcich oblastiach:
- Kolekcia klastrov distribuuje veľké aplikácie do rôznych klastrov pre škálovateľnosť a stabilitu.
- Zabezpečenie stability klastra, škálovateľnosti a viditeľnosti pri vytváraní konektivity aplikácií a SLA.
- Riadenie zdrojov a kvót tak, aby aplikácie medzi sebou nekolidovali, a rozsah klastra je kontrolovaný z našej strany.
- Nová platforma CI/CD na podporu a nasadenie aplikácií na Kubernetes.
Zdroj: hab.com