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.

Tento průvodce popisuje aktivně-pasivní řešení zotavení po havárii 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 není směrován Azure Front Door Traffic Managerem.

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: Azure Front Door vyrovnává zatížení a směruje provoz do instance služby Azure Application Gateway v primárním regionu (cluster musí být označen 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.

Dvojice hub-and-spoke: Pro každou regionální instanci AKS je nasazena jedna dvojice hub-and-spoke. 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 probereme možná místa selhání.

Pody aplikací (regionální)

Objekt Deployment v Kubernetes vytváří více replik pody prostřednictvím objektu ReplicaSet. Pokud jedna z replik není k dispozici, provoz je přesměrován mezi zbývající repliky. Kubernetes ReplicaSet se snaží udržet zadaný počet replik v chodu. Pokud jedna instance přestane fungovat, měla by se znovu vytvořit nová instance. Sondy životaschopnosti mohou kontrolovat stav aplikace nebo procesu spuštěného v podu. Pokud pod nereaguje, sonda živosti pod odstraní, což přinutí ReplicaSet vytvořit novou instanci.

Další informace najdete v tématu Kubernetes ReplicaSet.

Pody aplikací (globální)

Když se celý region stane nedostupným, pody v clusteru již nebudou dostupné pro zpracování požadavků. V tomto případě instance služby Azure Front Door směruje veškerý provoz do zbývajících zdravých oblastí. 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 síťové a výpočetní prostředky jsou správně dimenzované, aby zvládly jakýkoli náhlý nárůst provozu v důsledku převzetí služeb při selhání v jiné 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í automatického horizontálního škálování podů zvyšte počet replik podů, abyste kompenzovali zvýšenou poptávku v regionu.
  • Pomocí automatického škálování clusteru AKS zvyšte počet uzlů instance Kubernetes, abyste mohli kompenzovat zvýšenou regionální poptávku.

Skupiny 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 v tomto řešení typu aktivní-pasivní 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é zóně dostupnosti.

Pooly uzlů Kubernetes (globální)

V případě úplného výpadku oblasti Azure Front Door směruje provoz do zbývajících zdravých oblastí. Opět nezapomeňte zohlednit zvýšený provoz a požadavky směřující na zbývající cluster.

Strategie testování přepnutí při selhání

Přestože v AKS aktuálně neexistují žádné mechanismy, které by mohly pro účely testování snížit celou oblast nasazení, můžete pomocí pracovních prostorů Azure Chaos Studio simulovat výpadek zóny dostupnosti pro fondy uzlů clusteru.

Další kroky

Pokud zvažujete jiné řešení, přečtěte si následující články:

  • Poslední aktualizace v