ProHoster > Blog > podávání > Jak propojit clustery Kubernetes v různých datových centrech
Jak propojit clustery Kubernetes v různých datových centrech
Vítejte v Kubernetes Quick Start Series. Toto je pravidelná rubrika s nejzajímavějšími dotazy, které dostáváme online a na našich školeních. Odpovídá expert Kubernetes.
Dnešním odborníkem je Daniel Polenchik (Daniele Polencic). Daniel pracuje jako instruktor a vývojář softwaru v Learnk8s.
Poměrně často je infrastruktura replikována a distribuována v různých regionech, zejména v kontrolovaných prostředích.
Pokud je jeden region nedostupný, provoz je přesměrován do jiného, aby nedošlo k přerušení.
S Kubernetes můžete použít podobnou strategii a rozdělit úlohy do různých regionů.
Můžete mít jeden nebo více clusterů na tým, region, prostředí nebo jejich kombinaci.
Vaše clustery mohou být hostovány ve více cloudech a on-premise.
Jak ale naplánovat infrastrukturu pro takové geografické rozšíření?
Potřebujete vytvořit jeden velký cluster pro několik cloudových prostředí v jedné síti?
Nebo mít mnoho malých clusterů a najít způsob, jak je ovládat a synchronizovat?
Jeden vedoucí klastr
Vytvoření jednoho clusteru přes jedinou síť není tak snadné.
Představte si, že máte nehodu, spojení mezi segmenty clusteru je ztraceno.
Pokud máte jeden hlavní server, polovina prostředků nebude moci přijímat nové příkazy, protože nebudou moci kontaktovat hlavní server.
A zároveň máte staré směrovací tabulky (kube-proxy nelze stáhnout nové) a žádné další moduly (kubelet nemůže žádat o aktualizace).
Ještě horší je, že pokud Kubernetes nevidí uzel, označí jej jako osiřelý a rozdělí chybějící pody do stávajících uzlů.
Výsledkem je, že máte dvakrát tolik lusků.
Pokud vytvoříte jeden hlavní server na region, nastanou problémy s konsensuálním algoritmem v databázi etcd. (Cca. vyd. - Databáze etcd ve skutečnosti nemusí být umístěna na hlavních serverech. Může být spuštěn na samostatné skupině serverů ve stejné oblasti. Avšak poté, co obdržel současně bod selhání clusteru. Ale rychle.)
atdd používá raftový algoritmusdohodnout se na hodnotě před zápisem na disk.
To znamená, že většina instancí musí dosáhnout konsensu, než může být stav zapsán do etcd.
Pokud latence mezi instancemi etcd prudce naroste, jako je tomu u tří instancí etcd v různých regionech, trvá dlouho, než se dohodnete na hodnotě a zapíšete ji na disk.
To se odráží i v ovladačích Kubernetes.
Správce řadiče potřebuje více času, aby se dozvěděl o změně a zapsal odpověď do databáze.
A protože ovladač není jeden, ale několik, dojde k řetězové reakci a celý shluk začne pracovat velmi pomalu.
V současné době neexistují žádné dobré příklady velké sítě pro jeden cluster.
V podstatě se vývojářská komunita a skupina SIG-cluster snaží přijít na to, jak organizovat clustery stejným způsobem, jakým Kubernetes organizuje kontejnery.
Poprvé jsme se pokusili spravovat kolekci clusterů jako jeden objekt pomocí nástroje kube federation.
Začátek byl dobrý, ale nakonec se kube federace nestala populární, protože nepodporovala všechny zdroje.
Podporoval federované dodávky a služby, ale ne například StatefulSets.
Také konfigurace federace byla předána ve formě anotací a nebyla flexibilní.
Představte si, jak můžete popsat rozdělení replik pro každý cluster ve federaci pomocí jediné anotace.
Ukázalo se, že je to úplný průšvih.
SIG-cluster odvedl skvělou práci po kubefed v1 a rozhodl se přistoupit k problému z jiného úhlu.
Místo anotací se rozhodli vydat řadič, který se instaluje na clustery. Může být konfigurován pomocí vlastních definic zdrojů (Custom Resource Definition, CRD).
Pro každý prostředek, který bude federován, máte vlastní definici CRD ve třech částech:
standardní definice prostředků, jako je nasazení;
část placement, kde definujete, jak bude prostředek distribuován ve federaci;
část override, kde u konkrétního zdroje můžete přepsat váhu a parametry z umístění.
Zde je příklad sdruženého doručení se sekcemi umístění a přepsání.
Ale namísto vymýšlení nového způsobu interakce s clusterem a zalamování zdrojů do vlastních definic se do standardního životního cyklu Kubernetes vloží multi-cluster-scheduler a zachytí všechna volání, která vytvářejí pody.
Každý vytvořený lusk je okamžitě nahrazen figurínou.
Původní modul prochází dalším plánovacím cyklem, kde po dotazování celé federace dojde k rozhodnutí o hostování.
Nakonec je modul doručen do cílového clusteru.
Ve výsledku máte extra pod, který nic nedělá, jen zabírá místo.
Výhodou je, že pro kombinování zásob nemusíte psát nové zdroje.
Každý prostředek, který vytvoří pod, je automaticky připraven ke federování.
To je zajímavé, protože najednou máte zásoby rozmístěné po několika regionech a vy jste si toho nevšimli. To je však dost riskantní, protože zde vše spočívá na kouzlu.
Ale zatímco se Shipper snaží hlavně zmírnit dopady zásilek, multi-cluster-scheduler je obecnější a možná se lépe hodí pro dávkové úlohy.
Nemá pokročilý mechanismus postupného dodávání.
Více o multi-cluster-plánovači naleznete na oficiální stránka úložiště.
Pokud si chcete přečíst o multi-cluster-plánovači v akci, Admiralita má zajímavý případ použití s Argo - pracovní postupy, události, CI a CD Kubernetes.
Další nástroje a řešení
Propojení a správa více clusterů je složitý úkol a neexistuje žádné univerzální řešení.
Pokud se chcete o tomto tématu dozvědět více, zde jsou některé zdroje:
Submariner od Ranchera je nástroj, který propojuje překryvné sítě různých clusterů Kubernetes.
Cilium, plugin pro síťové rozhraní kontejnerů, nabízí funkce cluster mesh, který umožňuje kombinovat několik clusterů
To je pro dnešek vše
Děkujeme za přečtení až do konce!
Pokud víte, jak efektivněji propojit více clusterů, Řekni nám.
Vaši metodu přidáme do odkazů.
Zvláštní poděkování patří Chrisi Nesbitt-Smithovi (Chris Nesbitt-Smith) a Vincent de Sme (Vincent De Smet) (inženýrovi spolehlivosti v swatmobile.io) za přečtení článku a sdílení užitečných informací o fungování federace.