Tato architektura podrobně popisuje, jak spustit více instancí clusteru Azure Kubernetes Service (AKS) napříč několika oblastmi v konfiguraci aktivní/aktivní a vysoce dostupné.
Tato architektura vychází ze základní architektury AKS, což je doporučený výchozí bod microsoftu pro infrastrukturu AKS. Základní funkce AKS podrobně popisuje funkce infrastruktury, jako jsou ID úloh Microsoft Entra, omezení příchozího a výchozího přenosu dat, limity prostředků a další zabezpečené konfigurace infrastruktury AKS. Tyto podrobnosti infrastruktury nejsou v tomto dokumentu popsané. Než budete pokračovat v obsahu s více oblastmi, doporučujeme seznámit se se směrným plánem AKS.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Komponenty
V této architektuře AKS s více oblastmi se používá mnoho komponent a služeb Azure. Tady jsou uvedeny pouze komponenty s jedinečností této architektury s více clustery. Zbývající informace najdete v architektuře standardních hodnot AKS.
- Regionální clustery AKS: Nasadí se 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 mezi všemi oblastmi. Pokud se jedna oblast stane nedostupnou, provoz se přesměruje do oblasti, která je nejblíže uživateli, který žádost vydal.
- Místní hvězdicové sítě: Pro každou místní instanci AKS se nasadí pár sítí s paprskovou hvězdicovou hvězdicovou sítí. Zásady Azure Firewall Manageru slouží ke správě zásad brány firewall ve všech oblastech.
- Místní trezor klíčů: Služba Azure Key Vault se zřizuje v každé oblasti. Trezory klíčů se používají k ukládání citlivých hodnot a klíčů specifických pro cluster AKS a podpůrné služby, které jsou v dané oblasti.
- Více pracovních prostorů protokolů: Pracovní prostory služby Regional Log Analytics se používají k ukládání metrik a diagnostických protokolů místních sítí. Sdílená instance Log Analytics se navíc používá k ukládání metrik a diagnostických protokolů pro všechny instance AKS.
- Globální profil služby Azure Front Door: Azure Front Door se používá k vyrovnávání zatížení a směrování provozu do místní instance brány Aplikace Azure lication, která se nachází před každým clusterem AKS. Azure Front Door umožňuje globální směrování vrstvy 7, z nichž obě jsou pro tuto architekturu vyžadovány.
- Globální registr kontejneru: Image kontejnerů pro úlohu se ukládají do spravovaného registru kontejneru. V této architektuře se pro všechny instance Kubernetes v clusteru používá jedna služba Azure Container Registry. Geografická replikace služby Azure Container Registry umožňuje replikovat image do vybraných oblastí Azure a poskytovat nepřetržitý přístup k imagím, i když dojde k výpadku oblasti.
Vzory návrhu
Tato architektura používá dva vzory návrhu cloudu:
- Geodes (geografické uzly), kde libovolná oblast může obsluhovat jakoukoli žádost.
- Razítka nasazení, kde je nasazeno více nezávislých kopií aplikace nebo součásti aplikace z jednoho zdroje, například ze šablony nasazení.
Důležité informace o vzorech geode
Při výběru oblastí pro nasazení jednotlivých clusterů AKS zvažte oblasti blízko příjemce úloh nebo vašim zákazníkům. Zvažte také využití replikace mezi oblastmi. Replikace mezi oblastmi asynchronně replikuje stejné aplikace a data napříč ostatními oblastmi Azure pro ochranu zotavení po havárii. Jak se cluster škáluje nad rámec dvou oblastí, pokračujte v plánování replikace mezi oblastmi pro každou dvojici clusterů AKS.
V rámci každé oblasti jsou uzly ve fondech uzlů AKS rozdělené do několika zón dostupnosti, aby se zabránilo problémům způsobeným selháním zón. Zóny dostupnosti jsou podporovány v omezené sadě oblastí, které ovlivňují umístění regionálního clusteru. Další informace o AKS a zónách dostupnosti, včetně seznamu podporovaných oblastí, najdete v tématu Zóny dostupnosti AKS.
Důležité informace o razítku nasazení
Při správě řešení AKS s více oblastmi nasadíte několik clusterů AKS napříč několika oblastmi. Každý z těchto clusterů se považuje za razítko. Pokud dojde k selhání oblasti nebo pokud potřebujete pro clustery přidat další kapacitu nebo oblastní přítomnost, možná budete muset vytvořit novou instanci kolku. Při výběru procesu vytváření a správy razítek nasazení je důležité zvážit následující věci:
- Vyberte příslušnou technologii pro definice kolek, která umožňuje generalizovanou konfiguraci. Například můžete použít Bicep k definování infrastruktury jako kódu.
- Zadejte hodnoty specifické pro instanci pomocí vstupního mechanismu nasazení, jako jsou proměnné nebo soubory parametrů.
- Vyberte nástroje pro nasazení, které umožňují flexibilní, opakovatelné a idempotentní nasazení.
- V konfiguraci aktivního/aktivního razítka zvažte, jak se provoz vyrovnává napříč každým razítkem. Tato architektura používá Azure Front Door pro globální vyrovnávání zatížení.
- Při přidání a odebrání kolek z kolekce zvažte kapacitu a náklady.
- Zvažte, jak získat přehled o kolekci razítek a monitorovat je jako jednu jednotku.
Každá z těchto položek je podrobně popsána s konkrétními pokyny v následujících částech.
Správa vozového parku
Toto řešení představuje topologii s více clustery a více oblastmi bez zahrnutí pokročilého orchestrátoru, který bude považovat všechny clustery za součást sjednoceného vozového parku. Když se počet clusterů zvýší, zvažte registraci členů do Azure Kubernetes Fleet Manageru , aby se zlepšila správa zúčastněných clusterů ve velkém měřítku. Zde uvedená architektura infrastruktury se v podstatě nemění s registrací do Fleet Manageru, ale každodenní operace a podobné aktivity jsou přínosem řídicí roviny, která může současně cílit na více clusterů.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Nasazení clusteru a spuštění
Při nasazování několika clusterů Kubernetes ve vysoce dostupných a geograficky distribuovaných konfiguracích je důležité vzít v úvahu součet jednotlivých clusterů Kubernetes jako párované jednotky. Můžete chtít vyvíjet strategie řízené kódem pro automatizované nasazení a konfiguraci, abyste zajistili, že každá instance Kubernetes bude co nejidentická. Zvažte strategie horizontálního navýšení nebo snížení kapacity, včetně přidání nebo odebrání dalších clusterů Kubernetes. Váš návrh a plán nasazení a konfigurace by měl odpovídat výpadkům zón dostupnosti, oblastním selháním a dalším běžným scénářům.
Definice clusteru
Máte mnoho možností pro nasazení clusteru Azure Kubernetes Service. Azure Portal, Azure CLI a modul Azure PowerShell jsou všechny slušné možnosti nasazení jednotlivých nebo neseskupených clusterů AKS. Tyto metody ale můžou představovat problémy při práci s mnoha úzce propojenými clustery AKS. Například použití webu Azure Portal otevře příležitost k chybné konfiguraci kvůli zmeškaným krokům nebo nedostupným možnostem konfigurace. Nasazení a konfigurace mnoha clusterů pomocí portálu je časově náročný proces vyžadující zaměření jednoho nebo více techniků. Pokud používáte Azure CLI nebo Azure PowerShell, můžete vytvořit opakovatelný a automatizovaný proces pomocí nástrojů příkazového řádku. Odpovědnost za idempotenci, řízení selhání nasazení a obnovení selhání je však na vás a skriptech, které sestavíte.
Při práci s několika instancemi AKS doporučujeme zvážit infrastrukturu jako řešení kódu, jako jsou Bicep, šablony Azure Resource Manageru nebo Terraform. Infrastruktura jako řešení kódu poskytuje automatizované, škálovatelné a idempotentní řešení nasazení. Můžete například použít jeden soubor Bicep pro sdílené služby řešení a druhý pro clustery AKS a další regionální služby. Pokud jako kód používáte infrastrukturu, můžete definovat razítko nasazení s generalizovanými konfiguracemi, jako jsou sítě, autorizace a diagnostika. Soubor parametrů nasazení lze poskytnout s hodnotami specifickými pro danou oblast. V této konfiguraci se dá použít jedna šablona k nasazení téměř identického razítka napříč libovolnou oblastí.
Náklady na vývoj a údržbu infrastruktury, protože prostředky kódu mohou být nákladné. V některých případech může režie definování infrastruktury jako kódu převažovat nad výhodami, například když máte velmi malý počet instancí AKS (například 2 nebo 3). V těchto případech je přijatelné použít imperativní přístup, například pomocí nástrojů příkazového řádku nebo dokonce ručních přístupů na webu Azure Portal.
Nasazení clusteru
Po definování razítka clusteru máte mnoho možností pro nasazení jednotlivých nebo více instancí kolku. Naším doporučením je použít moderní technologie kontinuální integrace, jako je GitHub Actions nebo Azure Pipelines. Mezi výhody řešení pro průběžné nasazování založené na integraci patří:
- Nasazení založená na kódu, která umožňují přidávat a odebírat razítka pomocí kódu
- Integrované možnosti testování
- Integrované prostředí a pracovní možnosti
- Integrovaná řešení pro správu tajných kódů
- Integrace se správou zdrojového kódu pro kód aplikace i skripty a šablony nasazení
- Historie nasazení a protokolování
- Možnosti řízení přístupu a auditování pro řízení, kdo může provádět změny a za jakých podmínek
Při přidání nebo odebrání nových razítek z globálního clusteru je potřeba aktualizovat kanál nasazení, aby zůstal konzistentní. Jedním z přístupů je nasazení prostředků jednotlivých oblastí jako jednotlivého kroku v rámci pracovního postupu GitHub Actions. Tato konfigurace je jednoduchá, protože každá instance clusteru je jasně definovaná v rámci kanálu nasazení. Tato konfigurace zahrnuje administrativní režii při přidávání a odebírání clusterů z nasazení.
Další možností je vytvořit obchodní logiku pro vytváření clusterů na základě seznamu požadovaných umístění nebo jiných datových bodů. Kanál nasazení může například obsahovat seznam požadovaných oblastí; Krok v rámci kanálu by pak mohl procházet tímto seznamem a nasadit cluster do každé oblasti nalezené v seznamu. Nevýhodou této konfigurace je složitost generalizace nasazení a že každé razítko clusteru není explicitně podrobně popsáno v kanálu nasazení. Pozitivní výhodou je, že přidání nebo odebrání razítek clusteru z kanálu se stane jednoduchou aktualizací seznamu požadovaných oblastí.
Odebrání razítka clusteru z kanálu nasazení také nemusí vždy vyřadit prostředky kolku z provozu. V závislosti na řešení nasazení a konfiguraci možná budete potřebovat další krok pro vyřazení instancí AKS a dalších prostředků Azure z provozu. Zvažte použití zásobníků nasazení k povolení úplné správy životního cyklu prostředků Azure, včetně vyčištění, pokud je už nepotřebujete.
Spouštění clusteru
Po nasazení každé instance nebo razítka Kubernetes je potřeba nasadit a nakonfigurovat komponenty clusteru, jako jsou kontrolery příchozího přenosu dat, řešení identit a komponenty úloh. Musíte také zvážit použití zásad zabezpečení, přístupu a zásad správného řízení v clusteru.
Podobně jako při nasazení může být správa těchto konfigurací náročná na několik instancí Kubernetes ručně. Místo toho zvažte následující možnosti konfigurace a zásad ve velkém měřítku.
GitOps
Místo ruční konfigurace komponent Kubernetes se doporučuje použít automatizované metody pro použití konfigurací v clusteru Kubernetes, protože tyto konfigurace se kontrolují do zdrojového úložiště. Tento proces se často označuje jako GitOps a oblíbená řešení GitOps pro Kubernetes zahrnují Flux a Argo CD. Například rozšíření Flux pro AKS umožňuje automatické spouštění clusterů a okamžitě po nasazení clusterů.
GitOps je podrobnější v referenční architektuře standardních hodnot AKS. Pomocí přístupu založeného na GitOps ke konfiguraci se ujistěte, že každá instance Kubernetes je nakonfigurovaná podobně bez úsilí. Zjednodušený proces konfigurace se stává ještě důležitějším, jak roste velikost vašeho vozového parku.
Azure Policy
S tím, jak se přidává více instancí Kubernetes, se zvyšuje výhoda zásad správného řízení, dodržování předpisů a konfigurace. Použití zásad, konkrétně Azure Policy, poskytuje centralizovanou a škálovatelnou metodu pro řízení clusteru. Výhody zásad AKS jsou podrobně popsané v referenční architektuře standardních hodnot AKS.
Při vytváření clusterů AKS by se měla povolit služba Azure Policy. Iniciativy by se měly přiřazovat v režimu auditování, aby bylo možné získat přehled o nedodržování předpisů. Můžete také nastavit další zásady, které nejsou součástí žádné předdefinované iniciativy. Tyto zásady jsou nastavené v režimu Odepření. Existují například zásady, které zajistí, aby se v clusteru spouštěly jenom schválené image kontejnerů. Zvažte vytvoření vlastních iniciativ. Zkombinujte zásady platné pro vaši úlohu do jednoho přiřazení.
Rozsah zásad odkazuje na cíl každé zásady a iniciativy zásad. Pomocí Bicep můžete přiřadit zásady ke skupině prostředků, do které je každý cluster AKS nasazený. S rostoucími nároky globálního clusteru vede k mnoha duplicitním zásadám. Zásady můžete také nastavit na předplatné Azure nebo skupinu pro správu Azure. Tato metoda umožňuje použít jednu sadu zásad pro všechny clustery AKS v rámci oboru předplatného nebo všechna předplatná nalezená ve skupině pro správu.
Při navrhování zásad pro více clusterů AKS zvažte následující položky:
- Použijte zásady, které by se měly vztahovat globálně na všechny instance AKS na skupinu pro správu nebo předplatné.
- Umístěte jednotlivé regionální clustery do vlastní skupiny prostředků, což umožňuje použití zásad specifických pro jednotlivé oblasti na skupinu prostředků.
Informace o materiálech, které vám pomůžou vytvořit strategii správy zásad, najdete v organizaci prostředků architektury přechodu na cloud.
Nasazení úloh
Kromě konfigurace instance AKS zvažte zatížení nasazené do každé místní instance nebo razítka. Řešení nasazení nebo kanály vyžadují konfiguraci pro přizpůsobení každého místního razítka. S tím, jak se do globálního clusteru přidávají další razítka, je potřeba proces nasazení rozšířit nebo musí být dostatečně flexibilní, aby vyhovoval novým místním instancím.
Při plánování nasazení úloh zvažte následující položky.
- Zobecnit nasazení, například pomocí chartu Helm, aby se zajistilo, že se dá použít jedna konfigurace nasazení napříč několika kolky clusteru.
- Použijte jeden kanál průběžného nasazování nakonfigurovaný k nasazení úlohy napříč všemi kolky clusteru.
- Zadejte podrobnosti o instanci specifické pro razítko jako parametry nasazení.
- Zvažte konfiguraci protokolování diagnostiky aplikací a distribuovaného trasování pro pozorovatelnost v celé aplikaci.
Dostupnost a převzetí služeb při selhání
Významnou motivací pro výběr architektury Kubernetes pro více oblastí je dostupnost služeb. To znamená, že pokud se komponenta služby nebo služby stane nedostupnou v jedné oblasti, provoz by se měl směrovat do oblasti, kde je stále dostupná jiná instance této služby. Architektura s více oblastmi zahrnuje mnoho různých bodů selhání. V této části jsou popsány všechny tyto potenciální body selhání.
Selhání podů aplikace
Objekt nasazení Kubernetes slouží k vytvoření sady replik, která spravuje více replik podu. Pokud jeden pod není dostupný, provoz se směruje mezi zbývajícími. Sada replik Kubernetes se pokusí udržet zadaný počet replik v provozu. Pokud dojde k výpadku jedné instance, měla by se automaticky vytvořit nová instance. Sondy aktivity se dají použít ke kontrole stavu aplikace nebo procesu spuštěného v podu. Pokud služba nereaguje, sonda aktivity odebere pod, který vynutí Replikset vytvořit novou instanci.
Další informace najdete v tématu Kubernetes ReplicaSet.
Selhání hardwaru datacenter
K lokalizované chybě může občas dojít. Napájení může být například nedostupné pro jeden rack serverů Azure. Pokud chcete chránit uzly AKS před kritickým bodem selhání, použijte zóny dostupnosti Azure. Pomocí zón dostupnosti zajistíte, aby uzly AKS v jedné zóně dostupnosti byly fyzicky oddělené od těchto uzlů definovaných v jiné zóně dostupnosti.
Další informace najdete v tématu AKS a zóny dostupnosti Azure.
Selhání oblastí Azure
Jakmile bude celá oblast nedostupná, pody v clusteru už nebudou k dispozici pro obsluhu požadavků. V tomto případě Azure Front Door směruje veškerý provoz do zbývajících oblastí, které jsou v pořádku. Clustery a pody Kubernetes v oblastech, které jsou v pořádku, nadále obsluhují požadavky.
V této situaci se starají o kompenzaci zvýšených požadavků a provozu do zbývajícího clusteru. Zvažte následující skutečnosti:
- Ujistěte se, že síťové a výpočetní prostředky mají správnou velikost, 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 CNI, ujistěte se, že máte podsíť, která je dostatečně velká, aby podporovala všechny IP adresy podů při spouštění 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.
Další informace najdete v tématu Horizontální automatické škálování podů a automatické škálování clusteru AKS.
Topologie sítě
Podobně jako základní referenční architektura AKS používá tato architektura hvězdicovou síťovou topologii. Kromě aspektů uvedených v referenční architektuře standardních hodnot AKS zvažte následující osvědčené postupy:
- Implementujte hvězdicovou sadu virtuálních sítí pro každou místní instanci AKS. V rámci každé oblasti mezi jednotlivými paprsky a virtuální sítí rozbočovače.
- Směrujte veškerý odchozí provoz přes instanci služby Azure Firewall nalezenou v každé místní centrální síti. Ke správě zásad brány firewall napříč všemi oblastmi využijte zásady Azure Firewall Manageru.
- Postupujte podle velikosti IP adres zjištěných v referenční architektuře směrného plánu AKS a povolte více IP adres pro operace škálování uzlů i podů v případě, že dojde k selhání oblasti v jiné oblasti a provoz do zbývajících oblastí se podstatně zvyšuje.
Správa provozu
S referenční architekturou standardních hodnot AKS se provoz úloh směruje přímo do instance Aplikace Azure lication Gateway a pak se předává do back-endového nástroje pro vyrovnávání zatížení a prostředků příchozího přenosu dat AKS. Když pracujete s více clustery, požadavky klientů se směrují přes instanci služby Azure Front Door, která směruje do instance Aplikace Azure lication Gateway.
Stáhněte si soubor Visia tohoto diagramu.
Uživatel odešle požadavek na název domény (například
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), který se přeloží do profilu služby Azure Front Door. Tento požadavek je zašifrovaný certifikátem se zástupným znakem (*.azurefd.net) vydaným pro všechny subdomény služby Azure Front Door. Azure Front Door ověří požadavek na zásady firewallu webových aplikací, vybere nejrychlejší zdroj (na základě stavu a latence) a použije veřejný DNS k překladu IP adresy původu (Aplikace Azure lication Gateway).Azure Front Door předá požadavek vybrané instanci služby Application Gateway, která slouží jako vstupní bod pro místní razítko. Provoz prochází přes internet. Azure Front Door zajišťuje šifrování provozu do zdroje.
Zvažte metodu, která zajistí, že instance služby Application Gateway přijímá provoz pouze z instance služby Front Door. Jedním z přístupů je použití skupiny zabezpečení sítě v podsíti, která obsahuje službu Application Gateway. Pravidla můžou filtrovat příchozí (nebo odchozí) provoz na základě vlastností, jako je Zdroj, Port, Cíl. Vlastnost Source umožňuje nastavit integrovanou značku služby, která označuje IP adresy pro prostředek Azure. Tato abstrakce usnadňuje konfiguraci a údržbu pravidla a sledování IP adres. Kromě toho zvažte použití hlavičky
X-Azure-FDID, kterou Azure Front Door přidá do požadavku před odesláním do zdroje, aby se zajistilo, že instance služby Application Gateway přijímá provoz pouze z instance služby Front Door. Další informace o hlavičkách služby Front Door najdete v tématu Podpora protokolů pro hlavičky HTTP ve službě Azure Front Door.
Důležité informace o sdílených prostředcích
I když se tento scénář zaměřuje na několik instancí Kubernetes rozložených do několika oblastí Azure, dává smysl sdílet některé prostředky napříč všemi oblastmi. Jedním z přístupů je použití jednoho souboru Bicep k nasazení všech sdílených prostředků a následného nasazení každého místního razítka. Tato část podrobně popisuje všechny tyto sdílené prostředky a důležité informace o použití jednotlivých instancí AKS.
Container Registry
Azure Container Registry se v této architektuře používá k poskytování služeb imagí kontejneru. Cluster načítá image kontejneru z registru. Při práci se službou Azure Container Registry v nasazení clusteru s více oblastmi zvažte následující položky.
Geografická dostupnost
Umístěte registr kontejneru do každé oblasti, ve které je nasazen cluster AKS. Tento přístup umožňuje síťové operace s nízkou latencí, což umožňuje rychlé a spolehlivé přenosy vrstev imagí. Také to znamená, že máte několik koncových bodů služby image, které poskytují dostupnost v případech, kdy jsou regionální služby nedostupné. Pomocí funkcí geografické replikace služby Azure Container Registry můžete spravovat jeden registr kontejneru, který se automaticky replikuje do více oblastí.
Zvažte vytvoření jednoho registru s replikami do každé oblasti Azure, která obsahuje clustery. Další informace o replikaci služby Azure Container Registry najdete v tématu Geografická replikace ve službě Azure Container Registry.
Obrázek znázorňující několik replik služby Azure Container Registry z webu Azure Portal
Přístup ke clusteru
Každý cluster AKS vyžaduje přístup k registru kontejneru, aby mohl načíst vrstvy imagí kontejneru. Existuje několik způsobů, jak vytvořit přístup ke službě Azure Container Registry. V této architektuře se pro každý cluster vytvoří spravovaná identita, která se pak udělí AcrPull roli v registru kontejneru. Další informace a doporučení týkající se používání spravovaných identit pro přístup ke službě Azure Container Registry najdete v referenční architektuře standardních hodnot AKS.
Tato konfigurace je definovaná v souboru Bicep s razítkem clusteru, takže při každém nasazení nového razítka se nové instanci AKS udělí přístup. Vzhledem k tomu, že registr kontejneru je sdílený prostředek, ujistěte se, že vaše nasazení jako parametr obsahují ID prostředku registru kontejneru.
Azure Monitor
Funkce Azure Monitor Container Insights je doporučený nástroj pro monitorování a pochopení výkonu a stavu úloh clusteru a kontejnerů. Container Insights využívá pracovní prostor služby Log Analytics k ukládání dat protokolů a metrik azure Monitor k ukládání číselných dat časových řad. Metriky Prometheus je možné shromažďovat také službou Container Insights a data je možné odesílat do spravované služby Azure Monitor pro prometheus nebo do protokolů služby Azure Monitor. Další informace najdete v referenční architektuře standardních hodnot AKS.
Můžete také nakonfigurovat nastavení diagnostiky clusteru AKS tak, aby shromažďovala a analyzovala protokoly prostředků z komponent řídicí roviny AKS a předávala je do pracovního prostoru služby Log Analytics.
Při navrhování řešení monitorování pro architekturu s více oblastmi je důležité zvážit propojení mezi jednotlivými kolky. Můžete nasadit jeden pracovní prostor služby Log Analytics sdílený jednotlivými clustery Kubernetes. Stejně jako u ostatních sdílených prostředků definujte místní razítko, abyste mohli využívat informace o jednom globálně sdíleném pracovním prostoru služby Log Analytics a připojte každý místní cluster k danému sdílenému pracovnímu prostoru. Když každý regionální cluster vysílá diagnostické protokoly do jednoho pracovního prostoru služby Log Analytics, můžete tato data používat společně s metrikami prostředků k snadnějšímu vytváření sestav a řídicích panelů, které vám pomůžou pochopit, jak je spuštěné celé řešení ve více oblastech.
Azure Front Door
Azure Front Door se používá k vyrovnávání zatížení a směrování provozu do každého clusteru AKS. Azure Front Door také umožňuje globální směrování vrstvy 7. Tyto funkce jsou pro tento scénář vyžadovány.
Konfigurace clusteru
Při přidání každé místní instance AKS musí být služba Application Gateway nasazená společně s clusterem Kubernetes zaregistrovaná jako původ ve službě Azure Front Door, která ji zpřístupní ke směrování. Tato operace vyžaduje aktualizaci infrastruktury jako prostředků kódu. Případně můžete tuto operaci oddělit od konfigurace nasazení a spravovat ji pomocí nástrojů, jako je Azure CLI.
Certifikáty
Azure Front Door nepodporuje původy pomocí certifikátů podepsaných svým držitelem ani ve vývojových nebo testovacích prostředích. Pokud chcete povolit provoz HTTPS, musíte vytvořit certifikát TLS/SSL podepsaný certifikační autoritou . Informace o dalších certifikačních autoritách, které služba Front Door podporuje, najdete v tématu Povolené certifikační autority pro povolení vlastního HTTPS ve službě Azure Front Door.
Pro testování nebo pro neprodukční clustery můžete zvážit použití nástroje Certbot k vytvoření certifikátu Let's Encrypt Authority X3 pro každou z aplikačních bran.
Při plánování produkčního clusteru použijte upřednostňovanou metodu pro nákup certifikátů TLS ve vaší organizaci.
Přístup ke clusteru a identita
Jak je popsáno v referenční architektuře standardních hodnot AKS, doporučujeme jako zprostředkovatele identity pro vaše clustery použít ID Microsoft Entra. Skupiny Microsoft Entra je pak možné použít k řízení přístupu k prostředkům clusteru.
Při správě více clusterů se musíte rozhodnout o schématu přístupu. K dispozici jsou následující možnosti:
- Vytvořte globální skupinu přístupu pro celý cluster, kde členové můžou přistupovat ke všem objektům v každé instanci Kubernetes v clusteru. Tato možnost poskytuje minimální potřeby správy; uděluje však významné oprávnění každému členu skupiny.
- Vytvořte individuální přístupovou skupinu pro každou instanci Kubernetes, která se používá k udělení přístupu k objektům v instanci jednotlivého clusteru. Díky této možnosti se zvýší režijní náklady na správu; poskytuje však také podrobnější přístup ke clusteru.
- Definujte podrobné řízení přístupu pro typy objektů a obory názvů Kubernetes a korelujte výsledky se strukturou skupiny Microsoft Entra. Díky této možnosti se administrativní režie výrazně zvyšuje; Poskytuje však podrobný přístup nejen ke každému clusteru, ale také k oborům názvů a rozhraním API Kubernetes nalezených v rámci každého clusteru.
Pro přístup pro správu zvažte vytvoření skupiny Microsoft Entra pro každou oblast. Udělte každé skupině úplný přístup k odpovídajícímu razítku clusteru v dané oblasti. Členové každé skupiny pak mají přístup pro správu k odpovídajícím clusterům.
Další informace o správě přístupu ke clusteru AKS pomocí ID Microsoft Entra najdete v tématu Integrace AKS Microsoft Entra.
Data, stav a mezipaměť
Při použití globálně distribuované sady clusterů AKS zvažte architekturu aplikace, procesu nebo jiných úloh, které se můžou spouštět v rámci clusteru. Pokud jsou úlohy založené na stavu rozložené mezi clustery, potřebují mít přístup k úložišti stavů? Pokud je proces znovu vytvořený jinde v clusteru kvůli selhání, má úloha nebo proces nadále přístup k závislému úložišti stavů nebo řešení ukládání do mezipaměti? Stav je možné ukládat mnoha způsoby, ale správa je složitá i v jednom clusteru Kubernetes. Složitost se zvyšuje při přidávání do několika clusterů Kubernetes. Vzhledem k oblastním problémům s přístupem a složitostí zvažte návrh aplikací tak, aby používaly globálně distribuovanou službu úložiště stavů.
Návrh této architektury nezahrnuje konfiguraci pro problémy se stavem. Pokud spouštíte jednu logickou aplikaci napříč několika clustery AKS, zvažte návrh úlohy tak, aby používala globálně distribuovanou datovou službu, jako je Azure Cosmos DB. Azure Cosmos DB je globálně distribuovaný databázový systém, který umožňuje číst a zapisovat data z místních replik databáze a služba Cosmos DB za vás spravuje geografickou replikaci. Další informace najdete v tématu Azure Cosmos DB.
Pokud vaše úloha využívá řešení ukládání do mezipaměti, zajistěte, abyste služby ukládání do mezipaměti navrhli tak, aby zůstaly funkční i během událostí převzetí služeb při selhání. Ujistěte se, že samotná úloha je odolná vůči převzetí služeb při selhání souvisejícím s mezipamětí a že řešení ukládání do mezipaměti jsou k dispozici ve všech místních instancích AKS.
Optimalizace nákladů
Pomocí cenové kalkulačky Azure můžete odhadnout náklady na služby používané v architektuře. Další osvědčené postupy jsou popsány v části Optimalizace nákladů v architektuře Microsoft Azure a konkrétní možnosti konfigurace optimalizace nákladů v článku Optimalizace nákladů .
Zvažte povolení analýzy nákladů AKS pro podrobné přidělování nákladů na infrastrukturu clusteru podle konstruktorů specifických pro Kubernetes.
Další kroky
- Zóny dostupnosti AKS
- Azure Kubernetes Fleet Manager
- Geografická replikace ve službě Azure Container Registry
- Spárované oblasti Azure