Vítejte v sérii krátkých průvodců Kubernetes. Toto je pravidelný sloupek s nejzajímavějšími otázkami, které dostáváme online i na našich školeních. Odpovídá expert na Kubernetes.
Dnešním expertem je Daniele Polencic (). Daniele pracuje jako instruktor a vývojář softwaru ve společnosti .
Pokud chcete dostat odpověď na svou otázku v příštím příspěvku, nebo na .
Zmeškali jste předchozí příspěvky? .
Jak propojit Kubernetes clustery v různých datacentrech?
Stručně: , a také doporučuji přečíst si o a .
Poměrně často je infrastruktura replikována a distribuována do různých regionů, zejména ve řízených prostředích.
Pokud je jeden region nedostupný, provoz se přesměrovává do jiného, aby se zabránilo výpadkům.
Se systémem Kubernetes můžete použít podobnou strategii a rozdělovat pracovní zatížení do různých regionů.
Můžete mít jeden nebo více clusterů pro tým, region, prostředí nebo kombinaci těchto prvků.
Vaše clustery mohou být umístěny v různých cloudech a v místním prostředí.
Ale jak naplánovat infrastrukturu pro takové geografické rozložení?
Měli byste vytvořit jeden velký cluster pro několik cloudových prostředí prostřednictvím jediné sítě?
Nebo vytvořit mnoho malých clusterů a najít způsob, jak je řídit a synchronizovat?
Jeden řídící cluster
Vytvoření jednoho clusteru prostřednictvím jediné sítě není tak snadné.
Představte si, že máte havárii, ztrátu konektivity mezi segmenty clusteru.
Pokud máte jednoho master server, polovina zdrojů nebude moci přijímat nové příkazy, protože se nebyli schopni spojit s masterem.
A navíc máte staré směrovací tabulky (kube-proxy nelze načíst nové) a žádné další pody (kubelet nemůže požadovat aktualizace).
Co je ještě horší, pokud Kubernetes nevidí uzel, označuje ho jako ztracený a rozděluje chybějící pody mezi existující uzly.
Nakonec máte dvakrát více podů.
Pokud uděláte jednoho master serveru pro každý region, bude mít potíže s algoritmem dosahování shody v databázi etcd. (pozn. red. – Ve skutečnosti databáze etcd nemusí být nutně umístěna na master serverech. Může být spuštěna na samostatné skupině serverů v jednom regionu. I když tím vzniká jednopunktová chyba clusteru. Na druhou stranu je to rychlé.)
etcd používá , aby docílil shody hodnoty před jejím zápisem na disk.
To znamená, že většina instancí musí dosáhnout shody, než může být stav zapsán do etcd.
Pokud se zpoždění mezi instancemi etcd výrazně prodlouží, jako v případě tří instancí etcd v různých regionech, trvá dlouho, než se hodnota dohodne a zapíše na disk.
To se podepisuje i na kontrolerech Kubernetes.
Správci kontrolerů potřebují více času, aby se dozvěděli o změně a zapsali odpověď do databáze.
A protože kontrolerů je více než jeden, dochází k řetězové reakci a celý cluster začíná pracovat velmi pomalu..
etcd je tak citlivý na zpoždění, že .
Momentálně neexistují dobré příklady velké sítě pro jeden cluster.
Hlavně komunita vývojářů a skupina SIG-cluster se snaží pochopit, jak orchestraci clusterů provádět stejně jako Kubernetes orchestruje kontejnery.
Varianta 1: federace clusterů s kubefed.
Oficiální odpověď od SIG-cluster je, .
Poprvé se snažili spravovat kolekci clusterů jako jediný objekt pomocí nástroje kube federation.
Začátek byl dobrý, ale nakonec kube federation nezískal popularitu, protože nepodporoval všechny zdroje.
Podporoval sloučené dodávky a služby, ale například ne StatefulSets.
A také konfigurace federace byla předávána ve formě anotací a postrádala flexibilitu.
Představte si, jak lze popsat rozdělení replik pro každý cluster ve federaci pomocí jediných anotací.
Vznikl z toho absolutní nepořádek.
SIG-cluster odvedli skvělou práci po kubefed v1 a rozhodli se přistoupit k problému jiným způsobem.
Místo anotací se rozhodli vydat kontroler, který se instaluje na clustery. Ten lze konfigurovat pomocí vlastních definic zdrojů (Custom Resource Definition, CRD).
Pro každý zdroj, který bude součástí federace, máte uživatelsky definovanou CRD ze tří sekcí:
- standardní definice zdroje, například nasazení;
- oddíl
umístění, kde určujete, jak bude zdroj rozdělen ve federaci; - oddíl
přepsání, kde lze pro konkrétní zdroj přepsat váhu a parametry z umístění.
Zde je příklad sloučeného nasazení 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, nasazení je rozděleno mezi dva clustry: cluster1 a cluster2.
První cluster dodává tři repliky, zatímco druhý má nastavenou hodnotu 5.
Pokud potřebujete větší kontrolu nad počtem replik, kubefed2 poskytuje nový objekt ReplicaSchedulingPreference, kde jde repliky rozdělovat podle váhy:
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 hotové, aktivně se pracuje v oficiálním repozitáři projektu.
Sledujte kubefed2, ale pamatujte, že pro pracovní prostředí zatím není vhodný.
Zjistěte více o kubefed2 z v blogu o Kubernetes a z .
Varianta 2: sloučení clusterů ve stylu Booking.com
Vývojáři Booking.com se nezabývali kubefed v2, ale vytvořili Shipper — operátor pro dodávky na několika clusterech, v několika regionech a v několika cloudu.
něčím podobným jako kubefed2.
Oba nástroje umožňují nastavovat strategie nasazení na několika clusterech (jaké clustry se používají a kolik mají replik).
Ale úkol Shipper je snížit riziko chyb při dodání.
V Shipper lze definovat řadu kroků, které popisují rozdělení replik mezi předchozím a aktuálním nasazením a objem vstupního provozu.
Když posíláte zdroj do clusteru, řadič Shipper postupně zavádí tuto změnu do všech sloučených clusterů.
A navíc je Shipper velmi omezen.
Například, přijímá Helm grafy jako vstupní data. a nepodporuje vanilla zdroje.
Obecně platí, že Shipper funguje následujícími způsoby.
Místo standardního dodání je třeba vytvořit zdroj aplikace zahrnující Helm chart:
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 několika clusterů, ale jeho úzká vazba na Helm je spíše překážkou.
Co když se všichni přepneme z Helmu na nebo ?
Zjistěte více o Shipper a jeho filozofii v .
Pokud se chcete podívat na kód, .
Možnost 3: „magické“ spojení clusterů
Kubefed v2 a Shipper pracují s federací clusterů, poskytují clusterům nové zdroje prostřednictvím uživatelského definování zdrojů.
Ale co když nechcete přepisovat všechny dodávky, StatefulSets, DaemonSets atd. pro spojení?
Jak zapojit existující cluster do federace, aniž byste měnili YAML?
, který se zabývá pracovními zátěžemi plánování v clusterech.
Ale místo toho, abyste vymýšleli nový způsob interakce s clusterem a obalovali zdroje do uživatelských definic, multi-cluster-scheduler se integruje do standardního životního cyklu Kubernetes a zachycuje všechny volání, které vytvářejí pody.
Každý vytvářený pod je okamžitě nahrazen prázdnou náhradou.
multi-cluster-scheduler používá , aby zachytilo volání a vytvořilo nečinný pod náhradu.
Původní pod prochází dalším cyklem plánování, kde je po konzultaci s celou federací přijato rozhodnutí o umístění.
Nakonec je pod dodán do cílového clusteru.
V důsledku toho máte navíc pod, který nic nedělá, pouze zabírá místo.
Výhoda spočívá v tom, že jste nemuseli psát nové zdroje pro spojení dodávek.
Každý zdroj vytvářející pod je automaticky připraven pro spojení.
To je zajímavé, protože najednou máte dodávky rozložené po několika regionech, aniž byste si toho všimli. Nicméně, to je docela riskantní, protože vše se tu drží na magii.
Ale pokud se Shipper snaží převážně zmírnit důsledky dodávek, multi-cluster-scheduler plní obecnější úkoly a možná je lépe přizpůsoben pro balíčkové úlohy.
Nemá pokročilý mechanismus postupných dodávek.
O multi-cluster-scheduler se můžete dozvědět více na .
Pokud chcete číst o multi-cluster-scheduler v akci, Admiralty má — pracovními procesy, událostmi, CI a CD Kubernetes.
Další nástroje a řešení
Spojení několika clusterů a jejich správa je složitý úkol, univerzální řešení neexistuje.
Pokud chcete tento tematiku podrobněji prozkoumat, zde je několik zdrojů:
- — nástroj, který spojuje overlay sítě různých clusterů Kubernetes.
- Obchodní síť Target používá .
- Zkuste použít IPV6 a .
- Můžete použít service mesh, například .
- Cilium, plugin pro rozhraní sítě kontejnerů, nabízí , která umožňuje kombinovat několik clusterů.
To je pro dnešek vše.
Děkuji, že jste dočetli až do konce!
Pokud víte, jak efektivně spojit několik clusterů, .
Vaši metodu přidáme do odkazů.
Zvláštní poděkování Chrisu Nesbitt-Smithovi () a Vincentu de Smetovi () (inženýrovi spolehlivosti v ) za přečtení článku a sdílení užitečných informací o tom, jak federace funguje.
Zdroj: habr.com
