🥇Vytváříme kubernetes platformu v Pinterestu

Během svého fungování vytvořilo 300 milionů uživatelů Pinterestu více než 200 miliard pinů na více než 4 miliardách nástěnek. Aby se postaral o tuto armádu uživatelů a rozsáhlou databázi obsahu, portál vyvinul tisíce služeb, počínaje mikroslužbami, které zvládne několik CPU, a konče obrovskými monolity, které běží na celém parku virtuálních strojů. A nyní nastal okamžik, kdy se společnost zaměřila na k8s. Co tedy „kostka“ zaujala „Pinterest“? O tom se dozvíte v našem překladu čerstvého článku z blogu Pinterest engineering.

Takže stovky milionů uživatelů a stovky miliard pinů. Abychom se postarali o tuto armádu uživatelů a rozsáhlou databázi obsahu, vyvinuli jsme tisíce služeb, počínaje mikroslužbami, které zvládne několik CPU, a konče obrovskými monolity, které běží na celém parku virtuálních strojů. Kromě toho máme různé frameworky, které také mohou vyžadovat prostředky CPU, paměti nebo přístup k I/O operacím.

Při podpoře tohoto zoo nástrojů čelí vývojový tým řadě problémů:

Inženýři nemají jednotný způsob, jak spustit pracovní prostředí. Stateless služby, Stateful služby a projekty ve fázi aktivního vývoje jsou založeny na zcela odlišných technologických steacích. To vedlo ke vzniku celého školícího kurzu pro inženýry a také vážně zkomplikuje práci našeho infrastrukturního týmu.
Vývojáři, kteří mají k dispozici vlastní park virtuálních strojů, vytvářejí obrovské zatížení pro interní administrátory. V důsledku toho tak jednoduché operace, jako je aktualizace OS nebo AMI, trvají týdny a měsíce. To vede k růstu zátěže v, na pohled, naprosto běžných situacích.
Obtížnosti s vytvářením globálních nástrojů pro správu infrastruktury nad již existujícími řešeními. Situaci komplikuje také to, že najít vlastníky virtuálních strojů není snadné. To znamená, že nevíme, zda můžeme bezpečně uvolnit tyto kapacity pro práci v jiných oblastech naší infrastruktury.

Orkestační systémy kontejnerů jsou způsob, jak sjednotit správu pracovního zatížení. Otevírají vám cestu k urychlení vývoje a usnadňují správu infrastruktury, protože všechny zdroje zapojené do projektu jsou spravovány jedním centralizovaným systémem.

Obrázek 1: Priority infrastruktury (spolehlivost, výkonnost vývojářů a efektivita).

Tým Cloud Management Platform ve firmě Pinterest se seznámil s K8s v roce 2017. Do první poloviny roku 2017 jsme zdokumentovali většinu našich výrobních kapacit, včetně API a všech našich webových serverů.Poté jsme provedli důkladné hodnocení různých systémů pro orkestraci kontejnerových řešení, vytváření klastrů a práci s nimi. Na konci roku 2017 jsme se rozhodli využít Kubernetes. Byl dostatečně flexibilní a široce podporován komunitou vývojářů.

V současné době jsme vytvořili vlastní nástroje pro počáteční načítání klastru na základě Kops a převedli jsme na Kubernetes existující komponenty infrastruktury – jako jsou síť, bezpečnost, metriky, vedení záznamů, správa identity a provoz. Také jsme implementovali systém modelování pracovních zatížení pro náš zdroj, jehož složitost je skryta před vývojáři. Nyní se soustředíme na zajištění stability klastru, jeho škálování a připojení nových klientů.

Kubernetes: cesta Pinterestu

Začátek práce s Kubernetes na úrovni Pinterestu jako platformy, která bude milována našimi inženýry, přinesl řadu obtíží.

Jako velká společnost jsme investovali značné prostředky do infrastrukturních nástrojů. Příkladem mohou být bezpečnostní nástroje, které zpracovávají certifikáty a distribuují klíče, komponenty pro řízení provozu, systémy pro objevování služeb, komponenty pro viditelnost a vysílání záznamů a metrik. To vše bylo shromážděno nikoliv náhodou: prošli jsme normální cestou pokusů a omylů, a proto jsme chtěli integrovat všechny tyto prvky do nové infrastruktury na Kubernetes, místo abychom znovu vynalézali starý bicykl na nové platformě. Tento přístup v zásadě usnadnil migraci, protože veškerá podpora aplikací již existovala a nebylo ji třeba vytvářet od nuly.

Na druhou stranu, modelů pro předpovídání zátěže v samotném Kubernetes (například nasazení, úlohy a Daemon sety) není dostatek pro náš projekt. Tyto problémy s použitelností představují obrovské překážky na cestě k přechodu na Kubernetes. Například jsme slyšeli, jak si vývojáři služeb stěžují na nedostatek nebo nesprávné nastavení vstupu. Také jsme se setkali s nesprávným použitím templaterů, kdy se vytvářelo stovky kopií se stejnými specifikacemi a úlohami, což vedlo k hrozným problémům s laděním.

Bylo také velmi obtížné udržovat různé verze ve stejném clusteru. Představte si složitost zákaznické podpory, když musíte pracovat najednou s mnoha verzemi jednoho a téhož běhového prostředí, se všemi jejich problémy, chybami a aktualizacemi.

Uživatelské zdroje a controllery Pinterestu

Abychom našim inženýrům usnadnili proces zavádění Kubernetes a zjednodušili infrastrukturu a urychlili její chod, vyvinuli jsme naše vlastní definice uživatelských zdrojů (CRD).

CRD poskytují následující funkční možnosti:

Sloučení různých nativních zdrojů Kubernetes, aby pracovaly jako jednotná zátěž. Například zdroj PinterestService zahrnuje nasazení, vstupní službu a konfigurační mapu. To umožňuje vývojářům nezabývat se nastavením DNS.
Zavedení potřebné podpory aplikací. Uživatelský musí soustředit pouze na specifikaci kontejneru podle své obchodní logiky, zatímco controller CRD zavádí všechny potřebné init kontejnery, proměnné prostředí a specifikace pod. To zajišťuje zcela jinou úroveň pohodlí pro vývojáře.
Controllery CRD také spravují životní cyklus vlastních zdrojů a zvyšují dostupnost ladění. To zahrnuje sladění požadovaných a skutečných specifikací, aktualizaci stavu CRD a vedení logů událostí a nejen to. Bez CRD by byli vývojáři nuceni spravovat nespočetný množství zdrojů, což by pouze zvyšovalo pravděpodobnost chyby.

Zde je příklad PinterestService a vnitřního zdroje, který spravuje náš controller:

Jak bylo uvedeno výše, pro podporu uživatelského kontejneru je nutné integraci do něj zahrnout kontejner inicializace a několik doplňků pro zajištění bezpečnosti, viditelnosti a zpracování síťového provozu. Kromě toho jsme vytvořili šablony konfigurace map a implementovali podporu PVC šablon pro dávková zadání, stejně jako sledování mnoha proměnných prostředí pro sledování identifikace, využití prostředků a shromažďování "odpadků".

Těžko si představit, že by vývojáři chtěli tyto konfigurační soubory psát ručně bez podpory CRD, aniž bychom zmiňovali další údržbu a ladění konfigurací.

Workflow nasazení aplikací

Na výše uvedeném obrázku je znázorněno, jak nasadit vlastní zdroj Pinterest v Kubernetes clusteru:

Vývojáři komunikují s naším Kubernetes clusterem prostřednictvím CLI a uživatelského rozhraní.
Nástroje CLI / UI extrahují YAML konfigurační soubory pracovního procesu a další vlastnosti sestavení (stejný identifikátor verze) z Artifactory, po čemž je odesílají do Služby podávání úloh. Tento krok zajišťuje, že do clusteru budou nasazeny pouze funkční verze.
JSS funguje jako brána pro různé platformy, včetně Kubernetes. Zde probíhá autentizace uživatele, vydávání kvót a částečná kontrola konfigurace našeho CRD.
Po kontrole CRD na straně JSS jsou informace odeslány na API platformy k8s.
Náš CRD kontroler sleduje události na všech uživatelských zdrojích. Převádí CR na nativní k8s zdroje, přidává potřebné moduly, nastavuje odpovídající proměnné prostředí a vykonává další podpůrné úkoly, čímž zajišťuje dostatečnou infrastrukturovou podporu pro kontejnerové uživatelské aplikace.
Poté kontroler CRD předává získané údaje do API Kubernetes, aby byly zpracovány plánovačem a uvedeny do provozu.

Poznámka: Tato předběžná pracovní verze nasazení byla vytvořena pro první uživatele nové platformy k8s. Momentálně pracujeme na vylepšení tohoto procesu, abychom se plně integrovali s naším novým CI/CD. To znamená, že nemůžeme sdílet všechny informace související s Kubernetes. Těšíme se na možnost sdílet naše zkušenosti a informovat o pokroku týmu v této oblasti v našem dalším blogovém příspěvku „Budování CI/CD platformy pro Pinterest“.

Typy speciálních zdrojů

Na základě konkrétních potřeb Pinterestu jsme vyvinuli následující CRD, které vyhovují různým pracovním tokům:

PinterestService jsou dlouhodobě fungující stateless služby. Mnohé z našich hlavních systémů jsou postaveny na souboru těchto služeb.
PinterestJobSet modeluje balíčky úloh plného cyklu. V Pinterestu existuje běžný scénář, kdy několik úloh spouští stejné kontejnery paralelně, nezávisle na jiných obdobných procesech.
PinterestCronJob se široce používá ve spojení s malými periodickými zátěžemi. Je to wrapper pro nativní funkci cron s mechanismy podpory Pinterest, které zajišťují bezpečnost, provoz, logy a metriky.
PinterestDaemon zahrnuje infraštrukturní Daemony. Tato rodina se stále rozrůstá, protože přidáváme stále více podpory pro naše clustery.
PinterestTrainingJob se vztahuje na procesy Tensorflow a Pytorch, zajišťující stejnou úroveň podpory během provozu, jako všechny ostatní CRD. Vzhledem k tomu, že Pinterest aktivně využívá Tensorflow a další systémy strojového učení, mělo smysl vytvořit kolem nich samostatné CRD.

Také pracujeme na PinterestStatefulSet, který bude brzy přizpůsoben pro úložné systémy a další stateful systémy.

Podpora běhového prostředí

Když je modul aplikace spuštěn v Kubernetes, automaticky získává certifikát pro vlastní identifikaci. Tento certifikát se používá pro přístup k tajnému úložišti nebo pro komunikaci s jinými službami pomocí mTLS. Mezitím konfigurační inicializační procesory a Daemon načtou všechny nezbytné závislosti před spuštěním kontejnerové aplikace. Jakmile je všechno připraveno, sidecar pro provoz a Daemon zaregistrují IP adresu modulu v našem Zookeeperu, aby jej klienti mohli objevit. To vše bude fungovat, protože síťový modul byl nakonfigurován ještě před spuštěním aplikace.

Výše uvedené jsou typické příklady podpory pracovních zátěží během běhu. Pro jiné typy pracovních zátěží může být zapotřebí poněkud odlišná podpora, ale všechny jsou prezentovány ve formě pod úrovňových sidecarů, uzlových nebo Daemonů na úrovni virtuálních strojů. Dohlížíme na to, aby to bylo nasazeno v rámci řídící infrastruktury a sladěno mezi aplikacemi, což významně snižuje pracovní zátěž v oblasti technických prací a zákaznické podpory.

Testování a QA

Sestavili jsme end-to-end testovací pipeline nad již existující testovací infrastrukturou Kubernetes. Tyto testy se vztahují na všechny naše clustery. Náš pipeline prošel mnoha přestavbami, než se stal součástí produktového clusteru.

Kromě testovacích systémů máme systémy monitorování a upozorňování, které neustále sledují stav komponentů systému, spotřebu zdrojů a další důležité ukazatele, upozorňující nás pouze v případě potřeby lidského zásahu.

Alternativy

Zvažovali jsme některé alternativy vlastních zdrojů, jako jsou mutační kontrolery přístupu a systémy šablon. Nicméně všechny byly provázány se závažnými obtížemi v provozu, takže jsme si vybrali cestu CRD.

Mutační kontroler přístupu byl použit pro zavedení sidecarů, proměnných prostředí a další podpory během běhu. Nicméně se potýkal s různými problémy, například s propojením zdrojů a správou jejich životního cyklu, zatímco v CRD se takové problémy nevyskytují.

Poznámka: Systémy šablon, jako jsou diagramy Helm, jsou také široce používány pro nasazení aplikací se podobnými konfiguracemi. Naše pracovní aplikace jsou však příliš rozmanité na to, abychom je mohli spravovat pomocí šablon. Během kontinuálního nasazení s použitím šablon také vzniká příliš mnoho chyb.

Nadcházející práce

V současnosti se vyrovnáváme se smíšeným zatížením na všech našich clusterech. Abychom podpořili takovéto procesy různých typů a velikostí, pracujeme v následujících oblastech:

Soubor clusterů rozmístí velké aplikace mezi různé clustry za účelem zajištění škálovatelnosti a stability.
Zajištění stability, škálovatelnosti a viditelnosti clustru pro vytvoření spojení mezi aplikací a jejím SLA.
Správa zdrojů a kvót, aby mezi sebou aplikace nekolidovaly, a aby byl měřítko clustru řízeno z naší strany.
Nová platforma CI/CD pro podporu a nasazení aplikací v Kubernetes.

Zdroj: habr.com