Přehled pasivního studeného řešení 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 pasivní studené řešení 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 jediným clusterem, který aktivně obsluhuje provoz v případě potřeby aplikace.
Poznámka:
Následující postup byl interně zkontrolován a prověřen ve spojení s našimi partnery Microsoftu.
Přehled pasivního studeného řešení
V tomto přístupu máme nasazené dva nezávislé clustery AKS ve dvou oblastech Azure. V případě potřeby aplikace aktivujeme pasivní cluster pro příjem provozu. Pokud pasivní cluster přestane fungovat, musíme ručně aktivovat studený cluster, abychom převzali tok provozu. Tuto podmínku můžeme nastavit ručním vstupem pokaždé nebo určit určitou událost.
Scénáře a konfigurace
Toto řešení je nejlépe implementované jako úloha "použití podle potřeby", což je užitečné pro scénáře, které vyžadují, aby úlohy běžely v určitých denních časech nebo běžely na vyžádání. Mezi příklady případů použití pasivního přístupu patří:
- Výrobní společnost, která potřebuje pro velkou datovou sadu spustit složitou simulaci náročnou na prostředky. V tomto případě se pasivní cluster nachází v cloudové oblasti, která nabízí vysoce výkonné výpočetní a úložné služby. Pasivní cluster se používá pouze v případech, kdy je simulace aktivována uživatelem nebo plánem. Pokud cluster při aktivaci nefunguje, můžete ho použít jako zálohu a úloha na něm může běžet.
- Vládní agentura, která potřebuje udržovat zálohu svých důležitých systémů a dat v případě kybernetického útoku nebo přírodní katastrofy. V tomto případě se pasivní cluster nachází v zabezpečeném a izolovaném umístění, které není přístupné veřejnosti.
Komponenty
Řešení pasivního zotavení po havárii 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. Když je aplikace potřeba, aktivuje se pasivní cluster pro příjem síťového provozu.
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.
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.
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 pasivní cluster nefunguje správně kvůli problému v konkrétní oblasti Azure, můžete aktivovat studený cluster a přesměrovat veškerý provoz do oblasti tohoto clusteru. Tento proces můžete použít, zatímco pasivní cluster je deaktivován, dokud znovu nepracuje. Spuštění studeného clusteru může trvat několik minut, protože je vypnutý a potřebuje dokončit proces nastavení. Tento přístup není ideální pro aplikace citlivé na čas. V takovém případě doporučujeme zvážit převzetí služeb při selhání aktivní-aktivní.
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: