Kostka na kostce, metaklastry, plástve, distribuce zdrojů

Rýže. 1. Kubernetes ekosystém na Alibaba Cloud

Od roku 2015 je Alibaba Cloud Container Service for Kubernetes (ACK) jednou z nejrychleji rostoucích cloudových služeb v Alibaba Cloud. Obsluhuje řadu klientů a podporuje také interní infrastrukturu Alibaby a další cloudové služby společnosti.

Stejně jako u podobných kontejnerových služeb od světových poskytovatelů cloudu jsou našimi hlavními prioritami spolehlivost a dostupnost. Proto byla vytvořena škálovatelná a globálně dostupná platforma pro desítky tisíc clusterů Kubernetes.

V tomto článku se podělíme o naše zkušenosti se správou velkého počtu clusterů Kubernetes v cloudové infrastruktuře a také o architektuře základní platformy.

Vstup

Kubernetes se stal de facto standardem pro různé úlohy v cloudu. Jak je znázorněno na Obr. 1 výše, stále více aplikací Alibaba Cloud nyní běží na clusterech Kubernetes: stavové a bezstavové aplikace, stejně jako správci aplikací. Správa Kubernetes byla vždy zajímavým a vážným tématem diskusí pro inženýry, kteří budují a udržují infrastrukturu. Pokud jde o poskytovatele cloudu, jako je Alibaba Cloud, do popředí se dostává otázka škálování. Jak spravovat clustery Kubernetes v tomto měřítku? Osvědčené postupy pro správu obrovských clusterů Kubernetes s 10 000 uzly jsme již probrali. Samozřejmě se jedná o zajímavý problém škálování. Existuje však další měřítko: množství samotné shluky.

Toto téma jsme diskutovali s mnoha uživateli ACK. Většina z nich se rozhodne provozovat desítky, ne-li stovky malých nebo středně velkých clusterů Kubernetes. Existují pro to dobré důvody: omezení potenciálního poškození, oddělení clusterů pro různé týmy, vytvoření virtuálních clusterů pro testování. Pokud má ACK za cíl sloužit globálnímu publiku s tímto modelem využití, musí spolehlivě a efektivně spravovat velký počet clusterů ve více než 20 regionech.

Rýže. 2. Problémy správy velkého množství clusterů Kubernetes

Jaké jsou hlavní výzvy řízení klastrů v tomto měřítku? Jak je znázorněno na obrázku, je třeba řešit čtyři problémy:

• Heterogenita

ACK by měl podporovat různé typy clusterů, včetně standardních, bezserverových, Edge, Windows a několika dalších. Různé clustery vyžadují různé možnosti, komponenty a modely hostování. Někteří zákazníci potřebují pomoc s přizpůsobením pro jejich konkrétní případy.

• Různé velikosti clusterů

Shluky se liší velikostí, od několika uzlů s několika lusky až po desítky tisíc uzlů s tisíci lusky. Požadavky na zdroje se také velmi liší. Nesprávná alokace zdrojů může ovlivnit výkon nebo dokonce způsobit selhání.

• Různé verze

Kubernetes se velmi rychle vyvíjí. Nové verze jsou vydávány každých několik měsíců. Zákazníci jsou vždy ochotni zkoušet nové funkce. Chtějí tedy umístit testovací zátěž na nové verze Kubernetes a produkční na ty stabilní. Aby ACK splnil tento požadavek, musí zákazníkům neustále dodávat nové verze Kubernetes při zachování stabilních verzí.

• Soulad se zabezpečením

Shluky jsou rozmístěny v různých regionech. Jako takové musí splňovat různé bezpečnostní požadavky a úřední předpisy. Například cluster v Evropě musí být v souladu s GDPR, zatímco finanční cloud v Číně musí mít další vrstvy ochrany. Tyto požadavky jsou povinné a je nepřijatelné je ignorovat, protože to představuje pro klienty cloudové platformy obrovská rizika.

Platforma ACK je navržena tak, aby vyřešila většinu výše uvedených problémů. V současnosti spolehlivě a stabilně spravuje více než 10 tisíc clusterů Kubernetes po celém světě. Podívejme se, jak toho bylo dosaženo, včetně několika klíčových principů designu/architektury.

Design

Kostka na kostce a plástev

Na rozdíl od centralizované hierarchie se architektura založená na buňkách obvykle používá k škálování platformy mimo jediné datové centrum nebo k rozšíření rozsahu obnovy po havárii.

Každý region v Alibaba Cloud se skládá z několika zón (AZ) a obvykle odpovídá konkrétnímu datovému centru. Ve velké oblasti (např. Huangzhou) jsou často tisíce klientských clusterů Kubernetes se systémem ACK.

ACK spravuje tyto clustery Kubernetes pomocí samotného Kubernetes, což znamená, že máme spuštěný metacluster Kubernetes pro správu klientských clusterů Kubernetes. Tato architektura se také nazývá „kube-on-kube“ (KoK). Architektura KoK zjednodušuje správu klientských clusterů, protože nasazení clusteru je jednoduché a deterministické. Ještě důležitější je, že můžeme znovu použít nativní funkce Kubernetes. Například správa serverů API prostřednictvím nasazení, používání operátoru etcd ke správě více etcds. Taková rekurze vždy přináší zvláštní potěšení.

V rámci jedné oblasti je nasazeno několik metaklastrů Kubernetes v závislosti na počtu klientů. Tyto metashluky nazýváme buňky. K ochraně před selháním celé zóny podporuje ACK multiaktivní nasazení v jedné oblasti: metacluster distribuuje hlavní součásti clusteru klientů Kubernetes do více zón a spouští je současně, to znamená v multiaktivním režimu. Aby byla zajištěna spolehlivost a efektivita masteru, ACK optimalizuje umístění komponent a zajišťuje, že API server a etcd jsou blízko sebe.

Tento model umožňuje spravovat Kubernetes efektivně, flexibilně a spolehlivě.

Plánování zdrojů metaklastru

Jak jsme již zmínili, počet metaklastrů v jednotlivých regionech závisí na počtu klientů. Ale v jakém okamžiku přidat nový metacluster? Toto je typický problém plánování zdrojů. Zpravidla je obvyklé vytvořit nový, když stávající metaklastry vyčerpají všechny své zdroje.

Vezměme si například síťové zdroje. V architektuře KoK jsou komponenty Kubernetes z klientských clusterů nasazeny jako pody v metaclusteru. Používáme Terway (obr. 3) je vysoce výkonný plugin vyvinutý společností Alibaba Cloud pro správu kontejnerové sítě. Poskytuje bohatou sadu bezpečnostních zásad a umožňuje vám připojit se k virtuálním privátním cloudům (VPC) zákazníků prostřednictvím Alibaba Cloud Elastic Networking Interface (ENI). Abychom mohli efektivně distribuovat síťové zdroje mezi uzly, pody a služby v metaklastru, musíme pečlivě sledovat jejich využití v rámci metaklastru virtuálních privátních cloudů. Když síťové zdroje skončí, vytvoří se nová buňka.

Abychom určili optimální počet klientských clusterů v každém metaklastru, bereme také v úvahu naše náklady, požadavky na hustotu, kvótu zdrojů, požadavky na spolehlivost a statistiky. Rozhodnutí vytvořit nový metacluster je učiněno na základě všech těchto informací. Vezměte prosím na vědomí, že malé clustery se mohou v budoucnu značně rozšířit, takže spotřeba zdrojů se zvýší, i když počet clusterů zůstane nezměněn. Obvykle necháváme dostatek volného prostoru pro růst každého shluku.

Rýže. 3. Architektura sítě Terway

Škálování součástí průvodce napříč klientskými clustery

Komponenty průvodce mají různé potřeby zdrojů. Závisí na počtu uzlů a podů v clusteru, počtu nestandardních řadičů/operátorů interagujících s APIServerem.

V ACK se každý klientský cluster Kubernetes liší velikostí a požadavky na běh. Neexistuje žádná univerzální konfigurace pro umístění součástí průvodce. Pokud u velkého klienta omylem nastavíme nízký limit zdrojů, pak jeho cluster zátěž nezvládne. Pokud nastavíte konzervativně vysoký limit pro všechny clustery, dojde k plýtvání zdroji.

K nalezení jemného kompromisu mezi spolehlivostí a cenou používá ACK typový systém. Konkrétně definujeme tři typy shluků: malý, střední a velký. Každý typ má samostatný profil alokace zdrojů. Typ je určen na základě zatížení komponent průvodce, počtu uzlů a dalších faktorů. Typ clusteru se může v průběhu času měnit. ACK nepřetržitě monitoruje tyto faktory a může podle toho typovat nahoru/dolů. Jakmile se změní typ clusteru, alokace zdrojů se automaticky aktualizuje s minimálním zásahem uživatele.

Pracujeme na vylepšení tohoto systému pomocí jemnějšího škálování a přesnější aktualizace typu, aby tyto změny probíhaly plynuleji a měly větší ekonomický smysl.

Rýže. 4. Inteligentní vícestupňové přepínání typu

Evoluce klientských klastrů ve velkém měřítku

Předchozí části se zabývaly některými aspekty správy velkého počtu clusterů Kubernetes. Je tu však další problém, který je třeba vyřešit: evoluce klastrů.

Kubernetes je „Linux“ cloudového světa. Je průběžně aktualizován a stává se modulárnějším. Našim zákazníkům musíme neustále dodávat nové verze, opravovat zranitelnosti a aktualizovat stávající clustery a také spravovat velké množství souvisejících komponent (CSI, CNI, Device Plugin, Scheduler Plugin a mnoho dalších).

Vezměme si jako příklad správu komponent Kubernetes. Nejprve jsme vyvinuli centralizovaný systém pro registraci a správu všech těchto propojených komponent.

Rýže. 5. Flexibilní a zásuvné komponenty

Než budete pokračovat, musíte se ujistit, že aktualizace proběhla úspěšně. K tomu jsme vyvinuli systém pro kontrolu funkčnosti komponent. Kontrola se provádí před a po aktualizaci.

Rýže. 6. Předběžná kontrola komponent clusteru

Pro rychlou a spolehlivou aktualizaci těchto komponent pracuje systém průběžného nasazení s podporou částečného vylepšení (stupně šedi), pauz a dalších funkcí. Standardní řadiče Kubernetes nejsou pro tento případ použití příliš vhodné. Proto jsme pro správu komponent clusteru vyvinuli sadu specializovaných ovladačů, včetně pluginu a pomocného řídicího modulu (správa postranních vozíků).

Například řadič BroadcastJob je navržen tak, aby aktualizoval součásti na každém pracovním počítači nebo kontroloval uzly na každém počítači. Úloha Broadcast spustí modul na každém uzlu v clusteru, jako je DaemonSet. DaemonSet však vždy udržuje modul spuštěný po dlouhou dobu, zatímco BroadcastJob jej zhroutí. Řadič vysílání také spouští moduly na nově připojených uzlech a inicializuje uzly s nezbytnými součástmi. V červnu 2019 jsme otevřeli zdrojový kód automatizačního enginu OpenKruise, který sami v rámci společnosti používáme.

Rýže. 7. OpenKurise organizuje provádění úlohy Broadcast na všech uzlech

Abychom zákazníkům pomohli vybrat správné konfigurace clusteru, poskytujeme také sadu předdefinovaných profilů, včetně profilů Serverless, Edge, Windows a Bare Metal. Jak se krajina rozšiřuje a potřeby našich zákazníků rostou, přidáme další profily, abychom zjednodušili zdlouhavý proces nastavení.

Rýže. 8. Pokročilé a flexibilní klastrové profily pro různé scénáře

Globální pozorovatelnost napříč datovými centry

Jak je znázorněno níže na Obr. 9, cloudová služba Alibaba Cloud Container byla nasazena ve dvaceti regionech po celém světě. Vzhledem k tomuto rozsahu je jedním z klíčových cílů ACK snadné sledování stavu běžících clusterů, abychom v případě, že klientský cluster narazí na problém, mohli na vzniklou situaci rychle reagovat. Jinými slovy, musíte přijít s řešením, které vám umožní efektivně a bezpečně sbírat statistiky v reálném čase z klientských clusterů ve všech regionech – a vizuálně prezentovat výsledky.

Rýže. 9. Globální nasazení služby Alibaba Cloud Container ve dvaceti regionech

Jako mnoho monitorovacích systémů Kubernetes používáme Prometheus jako náš hlavní nástroj. Pro každý metaklastr shromažďují agenti Prometheus následující metriky:

• Metriky OS, jako jsou zdroje hostitele (CPU, paměť, disk atd.) a šířka pásma sítě.
• Metriky pro systém správy metaklastru a klientského clusteru, jako je kube-apiserver, kube-controller-manager a kube-scheduler.
• Metriky z kubernetes-state-metrics a cadvisor.
• metriky etcd, jako je doba zápisu na disk, velikost databáze, propustnost spojení mezi uzly atd.

Globální statistiky se shromažďují pomocí typického vícevrstvého agregačního modelu. Monitorovací data z každého metaklastru jsou nejprve agregována v každé oblasti a poté odeslána na centrální server, který ukazuje celkový obraz. Vše funguje přes mechanismus federace. Server Prometheus v každém datovém centru shromažďuje metriky z tohoto datového centra a centrální server Prometheus je zodpovědný za agregaci monitorovacích dat. AlertManager se napojí na centrální Prometheus a v případě potřeby zasílá upozornění přes DingTalk, email, SMS atd. Vizualizace - pomocí Grafany.

Na obrázku 10 lze monitorovací systém rozdělit do tří úrovní:

• Hraniční úroveň

Vrstva nejdále od středu. Prometheus Edge Server běží v každém metaklastru a shromažďuje metriky z meta a klientských clusterů v rámci stejné síťové domény.

• Kaskádová úroveň

Funkce kaskádové vrstvy Prometheus je shromažďovat monitorovací data z více regionů. Tyto servery fungují na úrovni větších geografických celků, jako je Čína, Asie, Evropa a Amerika. Jak klastry rostou, lze region rozdělit a poté se v každé nové velké oblasti objeví server Prometheus na kaskádové úrovni. S touto strategií můžete plynule škálovat podle potřeby.

• Centrální úroveň

Centrální server Prometheus se připojí ke všem kaskádovým serverům a provede finální agregaci dat. Kvůli spolehlivosti byly dvě centrální instance Prometheus vytvořeny v různých zónách a připojeny ke stejným kaskádovým serverům.

Rýže. 10. Globální víceúrovňová monitorovací architektura založená na federačním mechanismu Prometheus

Shrnutí

Cloudová řešení založená na Kubernetes nadále transformují naše odvětví. Kontejnerová služba Alibaba Cloud poskytuje bezpečný, spolehlivý a vysoce výkonný hosting – je to jeden z nejlepších cloudových hostingů Kubernetes. Tým Alibaba Cloud pevně věří v principy Open Source a open source komunity. Určitě budeme pokračovat ve sdílení našich znalostí v oblasti provozu a správy cloudových technologií.

Zdroj: www.habr.com