🥇Vytvárame kubernetes-platformu na Pinterest

Za roky existencie Pinterestu 300 miliónov používateľov služby vytvorilo viac ako 200 miliárd pripnutí na viac ako 4 miliardy násteniek. Aby sme obslúžili túto armádu používateľov a rozsiahlu databázu obsahu, portál vyvinul tisíce služieb, počnúc mikroservismi, s ktorými si poradí niekoľko CPU, a končiac obrovskými monolitmi, ktoré bežia na celom parku virtuálnych strojov. A prišiel čas, kedy sa pohľad spoločnosti obrátil na k8s. Čím teda „kocka“ zaujala „Pinterest“? O tom sa dozviete z nášho prekladu čerstvého článku z blogu Pinterest engineering.

Takže státisíce miliónov používateľov a státisíce miliárd pripnutí. Aby sme obslúžili túto armádu používateľov a rozsiahlu databázu obsahu, vyvinuli sme tisíce služieb, počnúc mikroservismi, s ktorými si poradí niekoľko CPU, a končiac obrovskými monolitmi, ktoré bežia na celom parku virtuálnych strojov. Okrem toho máme rôzne frameworky, ktoré tiež môžu vyžadovať zdroje CPU, pamäte alebo prístup k operáciám vstupu a výstupu.

Pri podpore tohto zoologického parku nástrojov sa tím vývoja stretáva s viacerými problémami:

Inžinieri nemajú unified spôsob spúšťania pracovného prostredia. Stateless služby, Stateful služby a projekty v aktívnom vývoji sú založené na úplne rôznych technologických stackoch. To viedlo k vytvoreniu celého školenia pre inžinierov a vážne komplikuje prácu nášho infraštruktúrneho tímu.
Vývojári, ktorí majú k dispozícii vlastný park virtuálnych strojov, vytvárajú obrovské zaťaženie pre interných administrátorov. Napokon, také jednoduché operácie, ako je aktualizácia OS alebo AMI, sa ťahajú na týždne a mesiace. To vedie k rastu zaťaženia v, na prvý pohľad, úplne bežných situáciách.
Zložitosti pri vytváraní globálnych nástrojov na správu infraštruktúry na už existujúcich riešeniach. Situáciu komplikuje aj to, že nájsť vlastníkov virtuálnych strojov nie je jednoduché. To znamená, že nevieme, či môžeme bezpečne vydať tieto zdroje na prácu na iných úsekoch našej infraštruktúry.

Orkestrátorské systémy kontajnerov sú spôsob, ako zjednotiť správu pracovnej záťaže. Otvárajú vám cestu k zvýšeniu rýchlosti vývoja a zjednodušujú správu infraštruktúry, pretože všetky zdroje zapojené do projektu spravuje jeden centralizovaný systém.

Obrázok 1: Prioritné oblasti infraštruktúry (spoľahlivosť, výkon vývojárov a efektivita).

Tím Cloud Management Platformu v Pinterest sa s K8s zoznámil v roku 2017. Do prvej polovice roku 2017 sme zdokumentovali väčšinu našich výrobných kapacít, vrátane API a všetkých našich webových serverov. Následne sme vykonali dôkladné posúdenie rôznych systémov na orchestráciu kontajnerových riešení, budovanie klastrov a ich správu. Na konci roku 2017 sme sa rozhodli využiť Kubernetes. Bol dostatočne flexibilný a široko podporovaný v komunite vývojárov.

Doteraz sme vytvorili vlastné nástroje na zavádzanie klastra na základe Kops a previedli existujúce komponenty infraštruktúry na Kubernetes — ako sú sieť, bezpečnosť, metriky, správa denníkov, správa identity a prevádzka. Taktiež sme implementovali systém modelovania pracovných záťaží pre náš zdroj, ktorého zložitosti sú od vývojárov skryté. Teraz sa sústreďujeme na zabezpečenie stability klastra, jeho škálovanie a pripojenie nových klientov.

Kubernetes: cesta Pinterestu

Zavedenie Kubernetes na úrovni Pinterestu ako obľúbenej platformy medzi našimi inžiniermi viedlo k mnohým ťažkostiam.

Ako veľká spoločnosť sme investovali značné prostriedky do infraštruktúrnych nástrojov. Príkladom sú bezpečnostné nástroje, ktoré spracovávajú certifikáty a distribuujú kľúče, komponenty na kontrolu prevádzky, systémy na prejavovanie služieb, komponenty viditeľnosti a odosielania denníkov a metrík. Toto všetko nebolo zostavené len tak: prešli sme normálnou cestou pokusov a omylov a preto sme chceli integrovať všetku túto technológiu do novej infraštruktúry na Kubernetes namiesto toho, aby sme znova vynaliezali starý bicykel na novej platforme. Takýto prístup vo všeobecnosti zjednodušil migráciu, pretože všetka podpora aplikácií už existuje a nemusí sa vytvárať od nuly.

Na druhej strane, modelov predikcie záťaže v samotnom Kubernetes (napríklad nasadenia, úloh a Daemonsetov) nie je dostatok pre náš projekt. Tieto problémy použiteľnosti sú obrovskými prekážkami na ceste k prechodu na Kubernetes. Napríklad sme počuli, ako si vývojári služieb sťažujú na nedostatok alebo nesprávne nastavenie vstupu. Taktiež sme sa stretli so zlým používaním templaterov, keď sa vytvorili stovky kópií s rovnakou špecifikáciou a úlohou, čo viedlo k hrozivým problémom s ladením.

Bolo tiež veľmi ťažké udržiavať rôzne verzie v rovnakom klasteri. Predstavte si zložitosti zákazníckej podpory, ak musíte pracovať súčasne s mnohými verziami rovnakej doby vykonávania, so všetkými ich problémami, chybami a aktualizáciami.

Užívateľské zdroje a ovládače Pinterestu

Aby sme našim inžinierom uľahčili proces zavádzania Kubernetes a zjednodušili infraštruktúru a urýchlili jej chod, vyvinuli sme naše vlastné definície užívateľských zdrojov (CRD).

CRD poskytujú nasledujúce funkčné schopnosti:

Zlúčenie rôznych natívnych zdrojov Kubernetes, aby fungovali ako jediné zaťaženie. Napríklad zdroj PinterestService zahŕňa nasadenie, službu vstupu a konfiguračnú mapu. To umožňuje vývojárom nezamýšľať sa nad nastavením DNS.
Zavádzanie potrebnej podpory aplikácií. Používateľ by sa mal sústrediť iba na špecifikáciu kontajnera podľa svojej obchodnej logiky, zatiaľ čo ovládač CRD zavádza všetky potrebné init-kontajnery, premenné prostredia a špecifikácie podu. To zaisťuje zásadne iný úroveň pohodlia pre vývojárov.
Ovládače CRD tiež spravujú životný cyklus vlastných zdrojov a zvyšujú dostupnosť ladenia. To zahŕňa zladenie požadovaných a skutočných špecifikácií, aktualizáciu stavu CRD a vedenie protokolov udalostí a nie len to. Bez CRD by vývojári museli spravovať početnú sadu zdrojov, čo by len zvyšovalo pravdepodobnosť chyby.

Tu je príklad PinterestService a vnútorného zdroja, ktorý spravuje náš ovládač:

Ako je uvedené vyššie, na podporu používateľskej kontajnerovej aplikácie je potrebné integrovať do nej inicializačný kontajner a niekoľko rozšírení na zabezpečenie, viditeľnosť a prácu so sieťovým prenosom. Okrem toho sme vytvorili šablóny konfiguračných máp a implementovali podporu šablón PVC pre dávkové úlohy, ako aj sledovanie viacerých premenných prostredia na sledovanie identifikácie, spotreby zdrojov a zbieranie "odpadu".

Ťažko si predstaviť, že by vývojári chceli písať tieto konfiguračné súbory manuálne bez podpory CRD, nieto ešte ďalšiu podporu a ladenie konfigurácií.

Pracovný tok nasadenia aplikácií

Na obrázku vyššie je znázornené, ako nasadiť používateľský zdroj Pinterest v klastri Kubernetes:

Vývojári interagujú s naším klastra Kubernetes cez CLI a používateľské rozhranie.
Nástroje CLI / UI extrahujú YAML súbory konfiguračného pracovného toku a ďalšie vlastnosti zostavy (rovnaký identifikátor verzie) z Artifactory, po čom ich odosielajú do služieb na predloženie úloh. Tento krok zaručuje, že do klastra budú nasadené iba stabilné verzie.
JSS funguje ako brána pre rôzne platformy, vrátane Kubernetes. Tu sa vykonáva autentifikácia používateľa, priradenie kvót a čiastočná kontrola konfigurácie nášho CRD.
Po overení CRD na strane JSS sa informácie odosielajú na API platformy k8s.
Náš CRD kontrolér sleduje udalosti na všetkých používateľských zdrojoch. Transformuje CR na nativné zdroje k8s, pridáva potrebné moduly, nastavuje príslušné premenné prostredia a vykonáva ďalšie pomocné úlohy, čím zaručuje dostatočnú infraštruktúrnu podporu pre kontajnerové používateľské aplikácie.
Potom kontrolér CRD odosiela získané údaje do API Kubernetes na spracovanie plánovačom a na spustenie ich prevádzky.

Poznámka: Toto predbežné nasadenie pracovného toku bolo vytvorené pre prvých používateľov našej novej platformy k8s. Momentálne pracujeme na vylepšení tohto procesu, aby sme sa mohli plne integrovať s naším novým CI/CD. To znamená, že nemôžeme zdieľať všetko, čo súvisí s Kubernetes. S nadšením očakávame, že sa s vami podelíme o naše skúsenosti a pokroky tímu v tejto oblasti v našom ďalšom blogovom príspevku „Vytvorenie platformy CI/CD pre Pinterest“.

Typy špeciálnych zdrojov

Na základe konkrétnych potrieb Pinterestu sme vyvinuli nasledujúce CRD, ktoré sú vhodné pre rôzne pracovné procesy:

PinterestService sú už dlhodobo fungujúce stateless služby. Mnohé naše základné systémy sú založené na súbore takýchto služieb.
PinterestJobSet modeluje dávkové úlohy celého cyklu. V Pintereste existuje bežný scenár, v ktorom niekoľko úloh spúšťa rovnaké kontajnery paralelne, pričom nezávisle od iných podobných procesov.
PinterestCronJob sa široko používa v kombinácii s malými periodickými záťažami. Je to obal pre natívne fungovanie cron s mechanizmami podpory Pinterestu, ktoré zabezpečujú bezpečnosť, prenos, protokoly a metriky.
PinterestDaemon obsahuje zásuvné moduly infraštruktúry. Táto rodina sa naďalej rozrastá, keďže pridávame čoraz viac podpory pre naše klastre.
PinterestTrainingJob sa rozširuje na procesy Tensorflow a Pytorch, zabezpečujúc rovnakú úroveň podpory počas prevádzky 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 vybudovať okolo nich samostatnú CRD.

Pracujeme aj na PinterestStatefulSet, ktorý čoskoro bude prispôsobený na databázové úložiská a iné stateful systémy.

Podpora vykonávacieho prostredia

Keď sa aplikačný modul spustí v Kubernetes, automaticky získa 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 cez mTLS. Medzitým inicializátor kontajnerov a Daemon načítajú všetky potrebné závislosti pred spustením kontajnerovej aplikácie. Keď je všetko pripravené, sidecar dopravy a Daemon zaregistrujú IP adresu modulu v našom Zookeeperi, aby ho mohli klienti objaviť. To všetko funguje, pretože sieťový modul bol nastavený ešte pred spustením aplikácie.

Vyššie uvedené sú typické príklady podpory pracovných záťaží počas prevádzky. Pre iné typy pracovných záťaží môže byť potrebná trochu iná podpora, ale všetky sú predstavené vo forme sidecar na úrovni pod, uzlových alebo Daemonov na úrovni virtuálnych strojov. Dbáme na to, aby sme to všetko nasadili v rámci manažérskej infraštruktúry a zosúladili medzi aplikáciami, čo v konečnom dôsledku významne znižuje záťaž v oblasti technickej práce a podpory zákazníkov.

Testovanie a QA

Zostavili sme end-to-end testovací pipeline na už existujúcej testovacej infraštruktúre Kubernetes. Tieto testy sa rozširujú na všetky naše klastre. Náš pipeline prežil mnohé úpravy, než sa stal súčasťou produktového klastra.

Okrem systémov testovania máme systémy monitorovania a upozornenia, ktoré neustále sledujú stav komponentov systému, spotrebu recursos a ďalšie dôležité ukazovatele, informujúc nás iba v prípade potreby ľudskej intervencie.

Alternatívy

Zvážili sme niektoré alternatívy prispôsobených zdrojov, ako sú mutačné controllery prístupu a systémy šablón. Avšak všetky tieto možnosti prinášajú vážne ťažkosti v prevádzke, takže sme sa rozhodli pre cestu CRD.

Mutačný controller prístupu sa používal na zavedenie sidecarov, premenných prostredia a ďalšej podpory počas prevádzky. Napriek tomu sa stretával s rôznymi problémami, ako je viazanie zdrojov a správa ich životného cyklu, pričom CRD tieto problémy nemá.

Poznámka: Systémy šablón, ako sú diagramy Helm, sú tiež široko používané na spúšťanie aplikácií so s podobnými konfiguráciami. Naše pracovné aplikácie sú však príliš rozmanité na to, aby sa dali spravovať pomocou šablón. Pri kontinuálnom nasadení s využitím šablón by sa takisto vyskytlo príliš veľa chýb.

Nadchádzajúca práca

Momentálne sa zaoberáme zmiešanou záťažou na všetkých našich klastroch. Aby sme podporovali podobné procesy rôzneho typu a veľkosti, pracujeme v nasledujúcich smeroch:

Súbor klastrov rozdeľuje veľké aplikácie medzi rôzne klastre na zabezpečenie škálovateľnosti a stability.
Zabezpečenie stability, škálovateľnosti a viditeľnosti klastra na vytvorenie spojenia aplikácie a jej SLA.
Riadenie zdrojov a kvót, aby aplikácie medzi sebou nekolidovali, a aby bol rozsah klastra kontrolovaný z našej strany.
Nová platforma CI/CD na podporu a nasadenie aplikácií v Kubernetes.

Zdroj: habr.com