Přehled řešení zotavení po havárii typu Aktivní-pasivní pro Službu Azure Kubernetes Service (AKS)
Když vytvoříte aplikaci ve službě Azure Kubernetes Service (AKS) a během vytváření prostředků zvolíte oblast Azure, jedná se o aplikaci s jednou oblastí. Když se oblast během havárie stane nedostupnou, vaše aplikace bude také nedostupná. Pokud vytvoříte stejné nasazení v sekundární oblasti Azure, bude vaše aplikace méně náchylná k havárii v jedné oblasti, která zaručuje kontinuitu podnikových procesů a veškerá replikace dat napříč oblastmi vám umožní obnovit poslední stav aplikace.
Tato příručka popisuje řešení zotavení po havárii aktivní-pasivní pro AKS. V rámci tohoto řešení nasadíme dva nezávislé a identické clustery AKS do dvou spárovaných oblastí Azure s pouze jedním clusterem, který aktivně obsluhuje provoz.
Poznámka:
Následující postup byl interně zkontrolován a prověřen ve spojení s našimi partnery Microsoftu.
Přehled řešení aktivní-pasivní
V tomto přístupu pro zotavení po havárii máme nasazené dva nezávislé clustery AKS ve dvou oblastech Azure. Provoz však aktivně obsluhuje pouze jeden z clusterů. Sekundární cluster (neaktivně obsluhuje provoz) obsahuje stejná konfigurační data a data aplikací jako primární cluster, ale nepřijímá žádný provoz, pokud ho nesměruje Správce provozu služby Azure Front Door.
Scénáře a konfigurace
Toto řešení je nejlepší implementovat při hostování aplikací závislých na prostředcích, jako jsou databáze, které aktivně obsluhují provoz v jedné oblasti. V situacích, kdy potřebujete hostovat bezstavové aplikace nasazené v obou oblastech, jako je horizontální škálování, doporučujeme zvážit aktivní-aktivní řešení, protože aktivní-pasivní zahrnuje přidanou latenci.
Komponenty
Řešení zotavení po havárii typu aktivní-pasivní využívá mnoho služeb Azure. Tato ukázková architektura zahrnuje následující komponenty:
Více clusterů a oblastí: Nasadíte několik clusterů AKS, z nichž každý je v samostatné oblasti Azure. Během normálních operací se síťový provoz směruje do primárního clusteru AKS nastaveného v konfiguraci služby Azure Front Door.
Nakonfigurované stanovení priority clusteru: Pro každý cluster nastavíte úroveň stanovení priority mezi 1–5 (s nejvyšší prioritou 1 a 5 nejnižší prioritou). Můžete nastavit více clusterů na stejnou úroveň priority a určit váhu pro každý cluster. Pokud primární cluster přestane být dostupný, provoz se automaticky směruje do další oblasti vybrané ve službě Azure Front Door. Veškerý provoz musí projít službou Azure Front Door, aby tento systém fungoval.
Azure Front Door: Vyrovnávání zatížení služby Azure Front Door a směruje provoz do instance služby Aplikace Azure Gateway v primární oblasti (cluster musí být označen s prioritou 1). V případě selhání oblasti služba přesměruje provoz do dalšího clusteru v seznamu priorit.
Další informace najdete v tématu Směrování provozu na základě priority.
Pár hvězdicových paprsků: Pro každou místní instanci AKS se nasadí pár hvězdicových paprsků. Zásady Azure Firewall Manageru spravují pravidla brány firewall napříč jednotlivými oblastmi.
Key Vault: Pro ukládání tajných kódů a klíčů zřídíte službu Azure Key Vault v každé oblasti.
Log Analytics: Místní instance Log Analytics ukládají metriky místních sítí a diagnostické protokoly. Sdílená instance ukládá metriky a diagnostické protokoly pro všechny instance AKS.
Container Registry: Image kontejneru pro úlohu se ukládají do spravovaného registru kontejneru. V tomto řešení se pro všechny instance Kubernetes v clusteru používá jedna instance služby Azure Container Registry . Geografická replikace služby Azure Container Registry umožňuje replikovat image do vybraných oblastí Azure a poskytuje nepřetržitý přístup k imagím, i když dojde k výpadku oblasti.
Proces převzetí služeb při selhání
Pokud se služba nebo součást služby stane nedostupnou v jedné oblasti, provoz by se měl směrovat do oblasti, ve které je tato služba dostupná. Architektura s více oblastmi zahrnuje mnoho různých bodů selhání. V této části se podíváme na potenciální body selhání.
Pody aplikací (regionální)
Objekt nasazení Kubernetes vytvoří více replik podu (ReplicaSet). Pokud není k dispozici, provoz se směruje mezi zbývajícími replikami. Sada replik Kubernetes se pokusí udržet zadaný počet replik v provozu. Pokud jedna instance přestane fungovat, měla by se znovu vytvořit nová instance. Sondy aktivity můžou zkontrolovat stav aplikace nebo procesu spuštěného v podu. Pokud pod nereaguje, sonda aktivity odebere pod, který vynutí repliku , aby vytvořila novou instanci.
Další informace najdete v tématu Kubernetes ReplicaSet.
Pody aplikací (globální)
Jakmile bude celá oblast nedostupná, pody v clusteru už nebudou k dispozici pro obsluhu požadavků. V tomto případě instance služby Azure Front Door směruje veškerý provoz do zbývajících oblastí stavu. Clustery a pody Kubernetes v těchto oblastech nadále obsluhují požadavky. Pokud chcete kompenzovat zvýšený provoz a požadavky na zbývající cluster, mějte na paměti následující pokyny:
- Ujistěte se, že jsou síťové a výpočetní prostředky správné velikosti, aby absorbovaly náhlé zvýšení provozu kvůli převzetí služeb při selhání oblasti. Pokud například používáte azure Container Network Interface (CNI), ujistěte se, že máte podsíť, která může podporovat všechny IP adresy podů se špičkou zatížení provozu.
- Pomocí horizontálního automatického škálování podů zvyšte počet replik podů, abyste kompenzovali zvýšenou regionální poptávku.
- Pomocí automatického škálování clusteru AKS zvyšte počet uzlů instance Kubernetes, abyste mohli kompenzovat zvýšenou regionální poptávku.
Fondy uzlů Kubernetes (regionální)
Občas může dojít k lokalizovaným selháním výpočetních prostředků, jako je nedostupnost napájení v jednom racku serverů Azure. Pokud chcete chránit uzly AKS před selháním v jedné oblasti, použijte Azure Zóny dostupnosti. Zóny dostupnosti zajišťují, aby uzly AKS v každé zóně dostupnosti byly fyzicky oddělené od uzlů definovaných v jiných zónách dostupnosti.
Fondy uzlů Kubernetes (globální)
V úplné regionální chybě Azure Front Door směruje provoz do zbývajících oblastí, které jsou v pořádku. Znovu nezapomeňte kompenzovat zvýšený provoz a požadavky na zbývající cluster.
Strategie testování převzetí služeb při selhání
I když v AKS nejsou v současné době k dispozici žádné mechanismy pro účely testování , azure Chaos Studio nabízí možnost vytvořit v clusteru experiment s chaosem.
Další kroky
Pokud zvažujete jiné řešení, přečtěte si následující články: