Sdílet prostřednictvím

Přehled vysoké dostupnosti a zotavení po havárii pro Službu Azure Kubernetes Service (AKS)

  • Článek

Při vytváření a správě aplikací v cloudu vždy hrozí riziko výpadků a havárií. Pokud chcete zajistit provozní kontinuitu (BC), musíte naplánovat vysokou dostupnost (HA) a zotavení po havárii (DR).

Vysoká dostupnost odkazuje na návrh a implementaci systému nebo služby, která je vysoce spolehlivá a dochází k minimálním výpadkům. Vysoká dostupnost je kombinací nástrojů, technologií a procesů, které zajišťují, aby systém nebo služba byly k dispozici pro provedení zamýšlené funkce. Vysoká dostupnost je důležitou součástí plánování zotavení po havárii. Zotavení po havárii je proces zotavení po havárii a obnovení obchodních operací do normálního stavu. Zotavení po havárii je podmnožina BC, což je proces údržby obchodních funkcí nebo jejich rychlé obnovení v případě velkého přerušení.

Tento článek se zabývá některými doporučenými postupy pro aplikace nasazené do AKS, ale nejedná se o vyčerpávající seznam možných řešení.

Přehled technologií

Cluster Kubernetes je rozdělený na dvě komponenty:

  • Řídicí rovina, která poskytuje základní služby Kubernetes a orchestraci aplikačních úloh a
  • Uzly, které spouští úlohy vaší aplikace.

Diagram řídicí roviny Kubernetes a komponent uzlů

Když vytvoříte cluster AKS, platforma Azure automaticky vytvoří a nakonfiguruje řídicí rovinu. AKS nabízí dvě cenové úrovně pro správu clusteru: úroveň Free a úroveň Standard. Další informace najdete v tématu Cenové úrovně Free a Standard pro správu clusteru AKS.

Řídicí rovina a její prostředky se nacházejí pouze v oblasti, ve které jste cluster vytvořili. AKS poskytuje řídicí rovinu s jedním tenantem s vyhrazeným serverem rozhraní API, plánovačem atd. Definujete počet a velikost uzlů a platforma Azure nakonfiguruje zabezpečenou komunikaci mezi řídicí rovinou a uzly. Interakce s řídicí rovinou probíhá prostřednictvím rozhraní API Kubernetes, jako kubectl je řídicí panel Kubernetes.

Ke spouštění aplikací a podpůrných služeb potřebujete uzel Kubernetes. Cluster AKS má alespoň jeden uzel, virtuální počítač Azure, na kterém běží komponenty uzlu Kubernetes a modul runtime kontejneru. Velikost virtuálního počítače Azure pro vaše uzly definuje procesory, paměť, velikost a dostupný typ úložiště (například vysoce výkonný disk SSD nebo běžný pevný disk). Naplánujte virtuální počítač a velikost úložiště, ať už vaše aplikace můžou vyžadovat velké množství procesoru a paměti nebo vysoce výkonného úložiště. V AKS je image virtuálního počítače pro uzly vašeho clusteru založená na Ubuntu Linuxu, Azure Linuxu nebo Windows Serveru 2022. Když vytvoříte cluster AKS nebo škálujete počet uzlů, platforma Azure automaticky vytvoří a nakonfiguruje požadovaný počet virtuálních počítačů.

Další informace o komponentách clusteru a úloh v AKS najdete v tématu Základní koncepty Kubernetes pro AKS.

Důležitá poznámka

Regionální a globální zdroje

Místní prostředky se zřizují jako součást razítka nasazení do jedné oblasti Azure. Tyto prostředky nesdílejí nic s prostředky v jiných oblastech a je možné je nezávisle odebrat nebo replikovat do jiných oblastí. Další informace najdete v tématu Místní zdroje informací.

Globální prostředky sdílejí životnost systému a můžou být globálně dostupné v kontextu nasazení ve více oblastech. Další informace najdete v tématu Globální zdroje informací.

Cíle obnovení

Úplný plán zotavení po havárii musí určovat obchodní požadavky pro každý proces, který aplikace implementuje:

  • Cíl bodu obnovení (RPO) je maximální přijatelná doba trvání ztráty dat. RPO se měří v jednotkách času, jako jsou minuty, hodiny nebo dny.
  • Cíl doby obnovení (RTO) je maximální přijatelná doba výpadku s výpadky definovanými vaší specifikací. Pokud je například přijatelná doba trvání výpadku v havárii osm hodin, je RTO osm hodin.

Zóny dostupnosti

Zóny dostupnosti můžete použít k rozložení dat mezi více zón ve stejné oblasti. V rámci oblasti jsou zóny dostupnosti dostatečně blízko, aby měly připojení s nízkou latencí k jiným zónám dostupnosti, ale jsou od sebe dostatečně vzdálené, aby se snížila pravděpodobnost, že místní výpadky nebo počasí ovlivní více než jedno. Další informace najdete v tématu Doporučení pro používání zón dostupnosti a oblastí.

Zónová odolnost

Clustery AKS jsou odolné vůči zónovým selháním. Pokud dojde k selhání zóny, cluster se bude dál spouštět ve zbývajících zónách. Řídicí rovina clusteru a uzly jsou rozložené mezi zóny a platforma Azure automaticky zpracovává distribuci uzlů. Další informace najdete v tématu Zónová odolnost AKS.

Vyrovnávání zatížení

Globální vyrovnávání zatížení

Globální služby vyrovnávání zatížení distribuují provoz mezi regionální back-endy, cloudy nebo hybridní místní služby. Tyto služby směrují provoz koncových uživatelů k nejbližšímu dostupnému back-endu. Reagují také na změny spolehlivosti nebo výkonu služby, aby maximalizovaly dostupnost a výkon. Následující služby Azure poskytují globální vyrovnávání zatížení:

Regionální vyrovnávání zatížení

Místní služby vyrovnávání zatížení distribuují provoz v rámci virtuálních sítí mezi virtuální počítače nebo zónově redundantní koncové body služby v rámci oblasti. Následující služby Azure poskytují regionální vyrovnávání zatížení:

Pozorovatelnost

Potřebujete shromažďovat data z aplikací a infrastruktury, abyste umožnili efektivní provoz a maximalizovali spolehlivost. Azure poskytuje nástroje, které vám pomůžou monitorovat a spravovat úlohy AKS. Další informace najdete v tématu Zdroje pozorovatelnosti.

Definice oboru

Dostupnost aplikace je důležitá při správě clusterů AKS. AKS ve výchozím nastavení poskytuje vysokou dostupnost pomocí více uzlů ve škálovací sadě virtuálních počítačů, ale tyto uzly nechrání systém před selháním oblasti. Pokud chcete maximalizovat dobu provozu, naplánujte si dopředu zachování kontinuity podnikových procesů a připravte se na zotavení po havárii s využitím následujících osvědčených postupů:

  • Naplánujte clustery AKS v několika oblastech.
  • Směrování provozu napříč několika clustery pomocí Azure Traffic Manageru
  • Pro registry imagí kontejneru použijte geografickou replikaci.
  • Naplánujte stav aplikace napříč několika clustery.
  • Replikace úložiště napříč několika oblastmi

Implementace modelu nasazení

Model nasazení Výhody Nevýhody
Aktivní-aktivní • Během převzetí služeb při selhání nedojde ke ztrátě nebo nekonzistence dat.
• Vysoká odolnost
• Lepší využití prostředků s vyšším výkonem		 • Složitá implementace a správa
• Vyšší náklady
• Vyžaduje nástroj pro vyrovnávání zatížení a formu směrování provozu.
Aktivní-pasivní • Jednodušší implementace a správa
• Nižší náklady
• Nevyžaduje nástroj pro vyrovnávání zatížení ani Traffic Manager.		 • Potenciál ztráty nebo nekonzistence dat během převzetí služeb při selhání
• Delší doba obnovení a výpadek
• Nedostatečné využití prostředků
Pasivní chlad • Nejnižší náklady
• Nevyžaduje synchronizaci, replikaci, nástroj pro vyrovnávání zatížení ani Traffic Manager.
• Vhodné pro úlohy s nízkou prioritou, nekritické úlohy		 • Vysoké riziko ztráty nebo nekonzistence dat během převzetí služeb při selhání
• Nejdelší doba obnovení a výpadky
• Vyžaduje ruční zásah k aktivaci clusteru a aktivaci zálohování.

Model nasazení s vysokou dostupností aktivní-aktivní

V modelu nasazení vysoké dostupnosti aktivní-aktivní máte dva nezávislé clustery AKS nasazené ve dvou různých oblastech Azure (obvykle spárované oblasti, jako je Kanada – střed a Kanada – východ nebo USA – východ 2 a USA – střed), které aktivně obsluhují provoz.

S touto ukázkovou architekturou:

  • Nasadíte dva clustery AKS v samostatných oblastech Azure.
  • Během normálních operací směruje síťový provoz mezi oběma oblastmi. Pokud se jedna oblast stane nedostupnou, provoz automaticky směruje do oblasti, která je nejblíže uživateli, který žádost vydal.
  • Pro každou místní instanci AKS je nasazený pár hvězdicových paprsků. Zásady Azure Firewall Manageru spravují pravidla brány firewall napříč oblastmi.
  • Služba Azure Key Vault je zřízená v každé oblasti pro ukládání tajných kódů a klíčů.
  • Vyrovnávání zatížení služby Azure Front Door a směruje provoz do místní instance brány Aplikace Azure lication, která se nachází před každým clusterem AKS.
  • Místní instance Log Analytics ukládají metriky regionálních sítí a diagnostické protokoly.
  • Image kontejneru pro úlohu se ukládají ve spravovaném registru kontejneru. Jedna služba Azure Container Registry se používá pro všechny instance Kubernetes v clusteru. Geografická replikace služby Azure Container Registry umožňuje replikaci imagí do vybraných oblastí Azure a poskytuje nepřetržitý přístup k imagím, i když dojde k výpadku oblasti.

Pokud chcete vytvořit model nasazení aktivní-aktivní v AKS, proveďte následující kroky:

  1. Vytvořte dvě identická nasazení ve dvou různých oblastech Azure.

  2. Vytvořte dvě instance webové aplikace.

  3. Vytvořte profil služby Azure Front Door s následujícími prostředky:

    • Koncový bod.
    • Dvě skupiny původu, z nichž každá má prioritu jednoho.
    • Trasa.

  4. Omezte síťový provoz na webové aplikace jenom z instance služby Azure Front Door. 5. Nakonfigurujte všechny ostatní back-endové služby Azure, jako jsou databáze, účty úložiště a zprostředkovatelé ověřování.

  5. Nasaďte kód do obou webových aplikací s průběžným nasazováním.

Další informace najdete v tématu Doporučené řešení s vysokou dostupností aktivní-aktivní pro AKS.

Model nasazení zotavení po havárii typu Aktivní-pasivní

V modelu nasazení zotavení po havárii aktivní-pasivní máte dva nezávislé clustery AKS nasazené ve dvou různých oblastech Azure (obvykle spárované oblasti, jako je Kanada – střed a Kanada – východ nebo USA – východ 2 a USA – střed), které aktivně obsluhují provoz. Provoz v daném okamžiku aktivně obsluhuje pouze jeden z clusterů. Druhý cluster obsahuje stejná konfigurační data a data aplikací jako aktivní cluster, ale nepřijímá provoz, pokud ho nesměruje traffic manager.

S touto ukázkovou architekturou:

  • Nasadíte dva clustery AKS v samostatných oblastech Azure.
  • Během normálních operací směruje síťový provoz do primárního clusteru AKS, který jste nastavili v konfiguraci služby Azure Front Door.
    • Prioritu je potřeba nastavit mezi 1 až 5 a 1 je nejvyšší a 5 nejnižší.
    • Můžete nastavit více clusterů na stejnou úroveň priority a určit váhu jednotlivých clusterů.
  • Pokud primární cluster přestane být dostupný (dojde k havárii), provoz se automaticky směruje do další oblasti vybrané ve službě Azure Front Door.
    • Veškerý provoz musí projít traffic managerem služby Azure Front Door, aby tento systém fungoval.
  • Azure Front Door směruje provoz do brány Aplikace Azure v primární oblasti (cluster musí být označen s prioritou 1). Pokud tato oblast selže, služba přesměruje provoz do dalšího clusteru v seznamu priorit.
    • Pravidla pocházejí z Azure Front Dooru.
  • 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říč oblastmi.
  • Služba Azure Key Vault je zřízená v každé oblasti pro ukládání tajných kódů a klíčů.
  • Místní instance Log Analytics ukládají metriky regionálních sítí a diagnostické protokoly.
  • Image kontejneru pro úlohu se ukládají ve spravovaném registru kontejneru. Jedna služba Azure Container Registry se používá pro všechny instance Kubernetes v clusteru. Geografická replikace služby Azure Container Registry umožňuje replikaci imagí do vybraných oblastí Azure a poskytuje nepřetržitý přístup k imagím, i když dojde k výpadku oblasti.

Pokud chcete vytvořit model nasazení typu aktivní-pasivní v AKS, proveďte následující kroky:

  1. Vytvořte dvě identická nasazení ve dvou různých oblastech Azure.

  2. Nakonfigurujte pravidla automatického škálování pro sekundární aplikaci, aby se škáluje na stejnou instanci jako primární, když se primární oblast stane neaktivní. I když je neaktivní, není potřeba vertikálně navýšit kapacitu. To pomáhá snížit náklady.

  3. Vytvořte dvě instance webové aplikace s jednou v každém clusteru.

  4. Vytvořte profil služby Azure Front Door s následujícími prostředky:

    • Koncový bod.
    • Skupina původu s prioritou jedné pro primární oblast.
    • Druhá skupina původu s prioritou dvou pro sekundární oblast.
    • Trasa.

  5. Omezte síťový provoz do webových aplikací pouze z instance služby Azure Front Door.

  6. Nakonfigurujte všechny ostatní back-endové služby Azure, jako jsou databáze, účty úložiště a zprostředkovatelé ověřování.

  7. Nasaďte kód do obou webových aplikací s průběžným nasazováním.

Další informace najdete v tématu Doporučené řešení zotavení po havárii typu aktivní-pasivní pro AKS.

Model nasazení pasivního studeného převzetí služeb při selhání

Model nasazení pasivního studeného převzetí služeb při selhání je nakonfigurovaný stejným způsobem jako model nasazení zotavení po havárii aktivní-pasivní, s výjimkou clusterů zůstává neaktivní, dokud je uživatel neaktivuje v případě havárie. Tento přístup považujeme za zastaralý , protože zahrnuje podobnou konfiguraci jako aktivní-pasivní, ale s přidanou složitostí ručního zásahu pro aktivaci clusteru a aktivaci zálohování.

S touto ukázkovou architekturou:

  • Pro lepší odolnost vytvoříte dva clustery AKS, nejlépe v různých oblastech nebo zónách.
  • Když potřebujete převzít služby při selhání, aktivujete nasazení, aby převzalo tok provozu.
  • V případě výpadku primárního pasivního clusteru je potřeba ručně aktivovat studený cluster, aby převzal tok provozu.
  • Tuto podmínku je potřeba nastavit buď ručním vstupem pokaždé, nebo určitou událostí, jak jste určili.
  • Služba Azure Key Vault je zřízená v každé oblasti pro ukládání tajných kódů a klíčů.
  • Místní instance Log Analytics ukládají metriky regionálních sítí a diagnostické protokoly pro každý cluster.

Pokud chcete vytvořit model nasazení pasivního studeného převzetí služeb při selhání v AKS, proveďte následující kroky:

  1. Vytvořte dvě identická nasazení v různých zónách a oblastech.
  2. Nakonfigurujte pravidla automatického škálování pro sekundární aplikaci, aby se škáluje na stejnou instanci jako primární, když se primární oblast stane neaktivní. I když je neaktivní, není potřeba vertikálně navýšit kapacitu, což pomáhá snížit náklady.
  3. Vytvořte dvě instance webové aplikace s jednou v každém clusteru.
  4. Nakonfigurujte všechny ostatní back-endové služby Azure, jako jsou databáze, účty úložiště a zprostředkovatelé ověřování.
  5. Nastavte podmínku, kdy se má aktivovat studený cluster. Pokud potřebujete, můžete použít nástroj pro vyrovnávání zatížení.

Další informace najdete v tématu Doporučené řešení pasivního a studeného převzetí služeb při selhání pro AKS.

Kvóty a omezení služeb

AKS nastavuje výchozí limity a kvóty pro prostředky a funkce, včetně omezení využití pro určité skladové položky virtuálních počítačů.

Prostředek Omezení
Maximální počet clusterů na předplatné globálně 5 000
Maximální počet clusterů na předplatné na oblast 1 100
Maximální počet uzlů na cluster se škálovacími sadami virtuálních počítačů a skladovou jednotkou Standard Load Balancer 5 000 napříč všemi fondy uzlů
Poznámka: Pokud nemůžete vertikálně navýšit kapacitu až na 5 000 uzlů na cluster, projděte si osvědčené postupy pro velké clustery.
Maximální počet uzlů na fond uzlů (fondy uzlů škálovacích sad virtuálních počítačů) 1000
Maximální počet fondů uzlů na cluster 100
Maximální počet podů na uzel: s modulem plug-insítě Kubenet 1 Maximum: 250
Výchozí nastavení Azure CLI: 110
Výchozí šablona Azure Resource Manageru: 110
Výchozí nasazení webu Azure Portal: 30
Maximální počet podů na uzel: s využitím rozhraní Azure Container Networking (Azure CNI)2 Maximum: 250
Maximální doporučená hodnota pro kontejnery Windows Serveru: 110
Výchozí hodnota: 30
Doplněk AKS Open Service Mesh (OSM) Verze clusteru Kubernetes: Podporované verze AKS
Řadiče OSM na cluster: 1
Pody na ovladač OSM: 1600
Účty služby Kubernetes spravované osmem: 160
Maximální počet služeb Kubernetes s vyrovnáváním zatížení na cluster s skladovou položku Standard Load Balancer 300
Maximální počet uzlů na cluster se skupinami dostupnosti virtuálních počítačů a skladovou jednotkou Load Balanceru úrovně Basic 100

1 Další jsou na vyžádání povoleny.
2 Kontejnery Windows Serveru musí používat síťový modul plug-in Azure CNI. Kontejnery Windows Serveru nepodporuje Kubenet.

Úroveň řídicí roviny Kubernetes Limit
Úroveň Standard Automaticky škáluje server rozhraní API Kubernetes na základě zatížení. Větší limity komponent řídicí roviny a instance serveru/etcd rozhraní API.
Úroveň Free Omezené prostředky s limitem 50 ztlumených požadavků a 100 volání jen pro čtení. Doporučený limit uzlu 10 uzlů na cluster Nejvhodnější pro experimentování, učení a jednoduché testování. Nedoporučuje se pro produkční/kritické úlohy.

Další informace najdete v tématu Kvóty a omezení služby AKS.

Backup

Azure Backup podporuje zálohování prostředků clusteru AKS a trvalých svazků připojených ke clusteru pomocí rozšíření zálohování. Trezor služby Backup komunikuje s clusterem AKS prostřednictvím rozšíření za účelem provádění operací zálohování a obnovení.

Další informace najdete v následujících článcích: