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 (). Daniel pracuje jako instruktor a vývojář softwaru v .
Pokud chcete odpověď na svou otázku v dalším příspěvku, nebo .
Zmeškali jste předchozí příspěvky? .
Jak propojit clustery Kubernetes v různých datových centrech?
Stručně: , a také vám doporučuji přečíst si o и .
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á dohodnout 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.
etcd je tak citlivý na latenci, že .
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.
Možnost 1: federovat clustery s kubefed
Oficiální odpověď od SIG-cluster - .
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í.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Jak vidíte, nabídka je rozdělena do dvou skupin: cluster1 и cluster2.
První cluster dodává tři repliky a druhý má hodnotu 5.
Pokud potřebujete větší kontrolu nad počtem replik, kubefed2 poskytuje nový objekt ReplicaSchedulingPreference, kde lze replikám vážit:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Struktura CRD a API ještě nejsou zcela připraveny a probíhají aktivní práce v oficiálním úložišti projektu.
Dávejte pozor na kubefed2, ale mějte na paměti, že ještě není dost dobrý pro produkční prostředí.
Další informace o kubefed2 od na blogu Kubernetes a .
Možnost 2: Seskupování ve stylu Booking.com
Vývojáři Booking.com se nezabývali kubefed v2, ale přišli s Shipperem, operátorem pro doručování na více clusterech, více regionech a více cloudech.
trochu podobný kufeped2.
Oba nástroje umožňují přizpůsobit strategii nasazení více clusterů (které clustery se používají a kolik mají replik).
Ale Úkolem odesílatele je snížit riziko chyb při přepravě.
V aplikaci Odesílatel můžete definovat řadu kroků, které popisují rozdělení replik mezi předchozí a aktuální nasazení a množství příchozího provozu.
Když vložíte prostředek do clusteru, řadič Shipper tuto změnu postupně nasadí do všech federovaných clusterů.
Přepravce je také velmi omezený.
Například, jako vstup bere Helmovy mapy a nepodporuje vanilkové zdroje.
Obecně platí, že Odesílatel funguje následovně.
Namísto standardní distribuce musíte vytvořit prostředek aplikace, který obsahuje Helmův diagram:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper je dobrá volba pro správu více clusterů, ale jeho blízký vztah s Helm jen překáží.
Co když všichni přejdeme z Helmu na nebo ?
Zjistěte více o Shipperovi a jeho filozofii na .
Pokud se chcete ponořit do kódu, .
Možnost 3: „magické“ sloučení klastrů
Kubefed v2 a Shipper pracují s federací klastrů poskytováním nových prostředků klastrům prostřednictvím vlastní definice prostředků.
Ale co když nechcete přepsat všechny zásoby, StatefulSets, DaemonSets atd., které mají být sloučeny?
Jak zahrnout existující cluster do federace bez změny YAML?
, která se zabývá plánováním zátěže na clusterech.
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.
multi-cluster-scheduler použití k zachycení hovoru a vytvoření nečinného fiktivního modulu.
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 .
Pokud si chcete přečíst o multi-cluster-plánovači v akci, Admiralita má - 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:
- je nástroj, který propojuje překryvné sítě různých clusterů Kubernetes.
- Obchodní řetězec Target využívá .
- Zkuste použít IPV6 a .
- Můžete použít například servisní síť .
- Cilium, plugin pro síťové rozhraní kontejnerů, nabízí , 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ů, .
Vaši metodu přidáme do odkazů.
Zvláštní poděkování patří Chrisi Nesbitt-Smithovi () a Vincent de Sme () (inženýrovi spolehlivosti v ) za přečtení článku a sdílení užitečných informací o fungování federace.
Zdroj: www.habr.com