V průběhu let vytvořilo 300 milionů uživatelů Pinterestu více než 200 miliard pinů na více než 4 miliardách nástěnek. Aby portál sloužil této armádě uživatelů a rozsáhlé obsahové základně, vyvinul tisíce služeb, od mikroslužeb, které může obsluhovat několik CPU, až po obří monolity, které běží na celé flotile virtuálních strojů. A pak přišel okamžik, kdy zrak společnosti padl na k8s. Proč „kostka“ vypadala dobře na Pinterestu? Dozvíte se o tom z našeho překladu nedávného článku z .
Tedy stovky milionů uživatelů a stovky miliard pinů. Abychom sloužili této armádě uživatelů a rozsáhlé obsahové základně, vyvinuli jsme tisíce služeb, od mikroslužeb, které může obsluhovat několik CPU, až po obří monolity, které běží na celých flotilách virtuálních strojů. Kromě toho máme různé rámce, které mohou také vyžadovat přístup k CPU, paměti nebo I/O.
Při údržbě této zoo nástrojů čelí vývojový tým řadě výzev:
- Pro inženýry neexistuje jednotný způsob, jak provozovat produkční prostředí. Bezstavové služby, stavové služby a projekty ve fázi aktivního vývoje jsou založeny na zcela odlišných technologických svazcích. To vedlo k vytvoření celého školícího kurzu pro inženýry a také vážně komplikuje práci našeho infrastrukturního týmu.
- Vývojáři s vlastní flotilou virtuálních strojů vytvářejí obrovskou zátěž pro interní administrátory. Výsledkem je, že tak jednoduché operace, jako je aktualizace OS nebo AMI, trvají týdny a měsíce. To vede ke zvýšené zátěži ve zdánlivě naprosto každodenních situacích.
- Potíže s vytvářením nástrojů pro správu globální infrastruktury nad stávajícími řešeními. Situaci navíc komplikuje fakt, že najít majitele virtuálních strojů není jednoduché. To znamená, že nevíme, zda lze tuto kapacitu bezpečně vytěžit pro provoz v jiných částech naší infrastruktury.
Systémy orchestrace kontejnerů představují způsob, jak sjednotit správu pracovní zátěže. Otevírají dveře vyšší rychlosti vývoje a zjednodušují správu infrastruktury, protože všechny zdroje zapojené do projektu jsou řízeny jedním centralizovaným systémem.
Obrázek 1: Priority infrastruktury (spolehlivost, produktivita vývojářů a efektivita).
Tým Cloud Management Platform na Pinterestu objevil K8s v roce 2017. Do první poloviny roku 2017 jsme zdokumentovali většinu našich produkčních schopností, včetně API a všech našich webových serverů. Poté jsme provedli důkladné posouzení různých systémů pro orchestraci řešení kontejnerů, vytváření clusterů a práci s nimi. Ke konci roku 2017 jsme se rozhodli používat Kubernetes. Bylo to docela flexibilní a široce podporované ve vývojářské komunitě.
K dnešnímu dni jsme vytvořili naše vlastní nástroje pro spouštění clusteru založené na Kops a migrovali jsme existující součásti infrastruktury, jako jsou sítě, zabezpečení, metriky, protokolování, správa identit a provoz na Kubernetes. Pro náš zdroj jsme také implementovali systém modelování zátěže, jehož složitost je vývojářům skryta. Nyní se zaměřujeme na zajištění stability clusteru, jeho škálování a připojení nových klientů.
Kubernetes: The Pinterest Way
Začít s Kubernetes v měřítku Pinterestu jako platformy, kterou by naši inženýři milovali, přineslo spoustu výzev.
Jako velká společnost jsme hodně investovali do infrastrukturních nástrojů. Příklady zahrnují nástroje zabezpečení, které se zabývají zpracováním certifikátů a distribucí klíčů, komponenty řízení provozu, systémy zjišťování služeb, komponenty viditelnosti a komponenty odesílání protokolů a metrik. To vše bylo shromážděno z nějakého důvodu: prošli jsme běžnou cestou pokusů a omylů, a proto jsme chtěli integrovat všechna tato zařízení do nové infrastruktury na Kubernetes místo toho, abychom znovu vynalezli staré kolo na nové platformě. Tento přístup celkově zjednodušil migraci, protože veškerá podpora aplikací již existuje a není třeba ji vytvářet od začátku.
Na druhou stranu samotné modely prognózování zatížení v Kubernetes (jako jsou nasazení, úlohy a sady démonů) pro náš projekt nestačí. Tyto problémy s použitelností jsou obrovskými překážkami pro přechod na Kubernetes. Slyšeli jsme například, že si vývojáři služeb stěžují na chybějící nebo nesprávné nastavení přihlášení. Setkali jsme se také s nesprávným použitím šablonových enginů, kdy byly vytvořeny stovky kopií se stejnou specifikací a úkolem, což mělo za následek problémy s laděním noční můry.
Bylo také velmi obtížné udržovat různé verze ve stejném clusteru. Představte si složitost zákaznické podpory, pokud potřebujete pracovat současně ve více verzích stejného runtime prostředí se všemi jejich problémy, chybami a aktualizacemi.
Uživatelské vlastnosti a ovladače Pinterestu
Abychom našim inženýrům usnadnili implementaci Kubernetes a zjednodušili a zrychlili naši infrastrukturu, vyvinuli jsme vlastní definice zdrojů (CRD).
CRD poskytují následující funkce:
- Kombinace různých nativních zdrojů Kubernetes tak, aby fungovaly jako jediná pracovní zátěž. Například prostředek PinterestService zahrnuje nasazení, přihlašovací službu a konfigurační mapu. Díky tomu se vývojáři nemusí starat o nastavení DNS.
- Implementujte potřebnou podporu aplikací. Uživatel se musí zaměřit pouze na specifikaci kontejneru podle své obchodní logiky, zatímco řadič CRD implementuje všechny potřebné init kontejnery, proměnné prostředí a specifikace podů. To poskytuje vývojářům zásadně jinou úroveň pohodlí.
- Řadiče CRD také spravují životní cyklus nativních zdrojů a zlepšují dostupnost ladění. To zahrnuje sladění požadovaných a skutečných specifikací, aktualizaci stavu CRD a údržbu protokolů událostí a další. Bez CRD by byli vývojáři nuceni spravovat více zdrojů, což by jen zvýšilo pravděpodobnost chyby.
Zde je příklad služby PinterestService a interního zdroje, který spravuje náš správce:
Jak můžete vidět výše, pro podporu vlastního kontejneru potřebujeme integrovat init kontejner a několik doplňků, které zajistí zabezpečení, viditelnost a síťový provoz. Kromě toho jsme vytvořili šablony konfiguračních map a implementovali podporu pro PVC šablony pro dávkové úlohy, stejně jako sledování více proměnných prostředí pro sledování identity, spotřeby zdrojů a shromažďování odpadu.
Je těžké si představit, že by vývojáři chtěli tyto konfigurační soubory psát ručně bez podpory CRD, natož pak konfigurace dále udržovat a ladit.
Pracovní postup nasazení aplikace
Obrázek výše ukazuje, jak nasadit vlastní prostředek Pinterestu do clusteru Kubernetes:
- Vývojáři komunikují s naším clusterem Kubernetes prostřednictvím rozhraní CLI a uživatelského rozhraní.
- Nástroje CLI/UI načítají soubory YAML konfigurace pracovního postupu a další vlastnosti sestavení (stejné ID verze) z Artifactory a poté je odešlou službě Job Submission Service. Tento krok zajišťuje, že do clusteru budou dodány pouze produkční verze.
- JSS je brána pro různé platformy, včetně Kubernetes. Zde se uživatel autentizuje, vydávají kvóty a částečně se kontroluje konfigurace našeho CRD.
- Po kontrole CRD na straně JSS se informace odešlou do API platformy k8s.
- Náš řadič CRD monitoruje události na všech uživatelských zdrojích. Převádí CR na nativní zdroje k8s, přidává potřebné moduly, nastavuje vhodné proměnné prostředí a provádí další podpůrné práce, aby zajistily, že kontejnerované uživatelské aplikace budou mít dostatečnou podporu infrastruktury.
- Řadič CRD pak přijatá data předá do Kubernetes API, aby je mohl zpracovat plánovač a uvést do výroby.
Poznámka: Tento předběžný pracovní postup nasazení byl vytvořen pro první uživatele nové platformy k8s. V současné době pracujeme na zdokonalování tohoto procesu, aby se plně integroval s naším novým CI/CD. To znamená, že vám nemůžeme říct vše, co souvisí s Kubernetes. Těšíme se, že se o naše zkušenosti a pokrok týmu v tomto směru podělíme v našem dalším příspěvku na blogu „Building a CI/CD platform for Pinterest.“
Druhy speciálních zdrojů
Na základě specifických potřeb Pinterestu jsme vyvinuli následující CRD, aby vyhovovaly různým pracovním postupům:
- PinterestService jsou bezstavové služby, které běží již dlouhou dobu. Mnoho našich základních systémů je založeno na sadě takových služeb.
- PinterestJobSet modeluje dávkové úlohy s plným cyklem. Běžným scénářem na Pinterestu je, že několik úloh spouští stejné kontejnery paralelně bez ohledu na jiné podobné procesy.
- PinterestCronJob je široce používán ve spojení s malými periodickými zátěžemi. Toto je obal pro nativní práci cronu s podpůrnými mechanismy Pinterestu, které jsou zodpovědné za zabezpečení, provoz, protokoly a metriky.
- PinterestDaemon zahrnuje démony infrastruktury. Tato rodina se stále rozrůstá, protože našim klastrům přidáváme další podporu.
- PinterestTrainingJob se rozšiřuje na procesy Tensorflow a Pytorch a poskytuje stejnou úroveň podpory za běhu jako všechny ostatní CRD. Vzhledem k tomu, že Pinterest aktivně používá Tensorflow a další systémy strojového učení, měli jsme důvod kolem nich vybudovat samostatné CRD.
Pracujeme také na PinterestStatefulSet, který bude brzy přizpůsoben pro datové sklady a další stavové systémy.
Runtime podpora
Když aplikační modul běží na Kubernetes, automaticky obdrží certifikát, který se identifikuje. Tento certifikát se používá pro přístup k tajnému úložišti nebo pro komunikaci s jinými službami prostřednictvím mTLS. Mezitím si Container Init Configurator a Daemon stáhnou všechny potřebné závislosti před spuštěním kontejnerizované aplikace. Když je vše připraveno, dopravní postranní vozík a Daemon zaregistrují IP adresu modulu u našeho Zookeepera, aby jej klienti mohli objevit. To vše bude fungovat, protože síťový modul byl nakonfigurován před spuštěním aplikace.
Výše uvedené jsou typické příklady runtime podpory pro pracovní zátěže. Jiné typy úloh mohou vyžadovat mírně odlišnou podporu, ale všechny přicházejí ve formě postranních vozíků na úrovni uzlů, démonů na úrovni uzlů nebo virtuálních strojů. Zajišťujeme, aby toto vše bylo nasazeno v rámci infrastruktury pro správu a bylo konzistentní napříč aplikacemi, což v konečném důsledku výrazně snižuje zátěž z hlediska technické práce a zákaznické podpory.
Testování a QA
Na stávající testovací infrastruktuře Kubernetes jsme vybudovali end-to-end testovací kanál. Tyto testy platí pro všechny naše clustery. Náš kanál prošel mnoha revizemi, než se stal součástí produktového clusteru.
Kromě testovacích systémů máme monitorovací a výstražné systémy, které neustále sledují stav systémových komponent, spotřebu zdrojů a další důležité ukazatele a upozorňují nás pouze na nutný zásah člověka.
Alternativy
Podívali jsme se na některé alternativy k vlastním zdrojům, jako jsou řadiče přístupu k mutacím a systémy šablon. Všechny však přicházejí s významnými provozními problémy, proto jsme zvolili cestu CRD.
K zavedení postranních vozíků, proměnných prostředí a další podpory běhového prostředí byl použit řadič mutačního přístupu. Potýkalo se však s různými problémy, jako je vázání zdrojů a řízení životního cyklu, kde takové problémy v CRD nevznikají.
Poznámka: Systémy šablon, jako jsou Helmovy diagramy, jsou také široce používány ke spouštění aplikací s podobnými konfiguracemi. Naše pracovní aplikace jsou však příliš rozmanité na to, aby je bylo možné spravovat pomocí šablon. Také během nepřetržitého nasazení bude při používání šablon příliš mnoho chyb.
Nadcházející práce
V současné době se potýkáme se smíšenou zátěží napříč všemi našimi klastry. Pro podporu takových procesů různých typů a velikostí pracujeme v následujících oblastech:
- Kolekce clusterů distribuuje velké aplikace napříč různými clustery pro škálovatelnost a stabilitu.
- Zajištění stability, škálovatelnosti a viditelnosti clusteru pro vytváření konektivity aplikací a SLA.
- Správa zdrojů a kvót tak, aby aplikace vzájemně nekolidovaly, a rozsah clusteru je řízen z naší strany.
- Nová platforma CI/CD pro podporu a nasazení aplikací na Kubernetes.
Zdroj: www.habr.com