Tato referenční 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 se seznámit se směrným plánem AKS.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Referenční implementace této architektury je k dispozici na GitHubu.
Komponenty
V referenční architektuře AKS pro více oblastí se používá mnoho komponent a služeb Azure. Níže jsou uvedeny pouze komponenty s jedinečností této architektury s více clustery. U zbývajících odkazů na architekturu standardních hodnot AKS.
- Několik clusterů / více oblastí Více clusterů AKS se nasadí 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.
- Hvězdicová síť v jednotlivých oblastech : Pro každou místní instanci AKS se nasadí pár hvězdicové sítě. Zásady Azure Firewall Manageru slouží ke správě zásad brány firewall ve všech oblastech.
- Místní úložiště klíčů Azure Key Vault se zřizuje v každé oblasti pro ukládání citlivých hodnot a klíčů specifických pro instanci AKS a podpůrné služby nalezené v této oblasti.
- Azure Front Door Azure Front Door se používá k vyrovnávání zatížení a směrování provozu do místní instance služby Aplikace Azure Gateway, která se nachází před každým clusterem AKS. Azure Front Door umožňuje vrstvu sedm globálního směrování, z nichž obě jsou pro tuto referenční architekturu vyžadovány.
- Instance Log Analytics v oblasti 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.
- Kontejner registry Image kontejneru pro úlohu jsou uložené ve spravovaném 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 referenční architektura používá dva vzory návrhu cloudu. Geografický uzel (geodes), kde libovolná oblast může obsluhovat jakoukoliv žádost a razítka nasazení, kde se z jednoho zdroje (šablony nasazení) nasadí více nezávislých kopií aplikace nebo komponenty aplikace.
Aspekty vzoru geografického uzlu
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ě clusteru AKS s více oblastmi se v několika oblastech nasadí více instancí AKS. Každá z těchto instancí se považuje za razítko. V případě selhání oblasti nebo potřeba přidat pro cluster 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 kolků, která umožňuje generalizovanou konfiguraci, jako je infrastruktura jako kód.
- Poskytnutí hodnot specifických pro instanci pomocí vstupního mechanismu nasazení, jako jsou proměnné nebo soubory parametrů
- Výběr nástrojů pro nasazení, které umožňuje 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.
- Při přidání a odebrání kolek z kolekce zvažte problémy s kapacitou a náklady.
- Zvažte, jak získat přehled a/nebo monitorovat kolekci razítek 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 této referenční architektury.
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í kapacity a horizontálního navýšení kapacity přidáním nebo odebráním dalších instancí Kubernetes. Budete chtít, aby váš návrh a plán nasazení a konfigurace počítaly s regionálními selháními nebo jinými běžnými scénáři.
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 pro nasazení jednotlivých nebo nesouvisený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 pro neúspěšnou konfiguraci kvůli zmeškaným krokům nebo nedostupným možnostem konfigurace. Nasazení a konfigurace mnoha clusterů pomocí portálu je také včasný proces, který vyžaduje zaměření jednoho nebo více techniků. Pomocí nástrojů příkazového řádku můžete vytvořit opakovatelný a automatizovaný proces. 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 mnoha instancemi AKS doporučujeme zvážit infrastrukturu jako řešení kódu, jako jsou šablony Azure Resource Manageru, šablony Bicep nebo konfigurace Terraformu. Infrastruktura jako řešení kódu poskytuje automatizované, škálovatelné a idempotentní řešení nasazení. Tato referenční architektura zahrnuje šablonu ARM pro sdílené služby řešení a pak další pro clustery AKS a 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 jednotlivé oblasti. 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, například při nasazení statického nebo pevného počtu instancí AKS, může režie infrastruktury převažovat nad výhodami. V těchto případech je použití imperativního přístupu, například s nástroji příkazového řádku nebo dokonce ručním přístupem, v pořádku.
Nasazení clusteru
Po definování definice razítka clusteru máte řadu možností pro nasazení jednotlivých nebo více instancí kolků. 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 s kódem / správou zdrojového kódu
- Historie nasazení a protokolování
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í. V referenční implementaci se každá oblast nasadí jako jednotlivý krok v pracovním postupu Akce GitHubu (příklad). Tato konfigurace je jednoduchá v tom, ž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 využít logiku k 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í nutně zajistit vyřazení z provozu. V závislosti na vašem řešení nasazení a konfiguraci možná budete potřebovat další krok, abyste zajistili, že se instance AKS správně vyřadí z provozu.
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. Budete také muset 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 zvažte použití automatizovaných metod pro použití konfigurací v clusteru Kubernetes, protože tyto konfigurace se kontrolují ve zdrojovém úložišti. Tento proces se často označuje jako GitOps a oblíbená řešení GitOps pro Kubernetes zahrnují Flux a Argo CD. Tato implementace používá rozšíření Flux pro AKS k automatickému spuštění clusterů a okamžitě po nasazení clusterů.
GitOps je podrobnější v referenční architektuře standardních hodnot AKS. Důležitým bodem je, že použití přístupu založeného na GitOps ke konfiguraci pomáhá zajistit, aby každá instance Kubernetes byla nakonfigurovaná podobně bez úsilí. To je ještě důležitější, 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.
Azure Policy je v této referenční implementaci povolená při vytváření clusterů AKS a přiřazuje omezující iniciativu v režimu auditování, aby bylo možné získat přehled o nedodržování předpisů. Implementace také nastavuje 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. Referenční implementace přidružená k této architektuře používá šablonu ARM k přiřazení zásad 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 rozsahu předplatného a/nebo všechna předplatná, která najdete ve skupině pro správu.
Při navrhování zásad pro více clusterů AKS zvažte následující položky:
- Zásady, které by se měly vztahovat globálně na všechny instance AKS, je možné použít u skupiny pro správu nebo předplatného.
- Umístění jednotlivých oblastních clusterů do vlastní skupiny prostředků umožňuje použít zásady specifické pro jednotlivé oblasti pro skupinu prostředků.
Informace o materiálech, které vám pomůžou vytvořit strategii správy zásad, najdete v tématu Organizace 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 budou vyžadovat 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 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 součást služby nebo 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 jsou popsány všechny tyto potenciální body selhání.
Pody aplikací (regionální)
Objekt nasazení Kubernetes slouží k vytvoření více replik podu (ReplicaSet). Pokud je některý z nich nedostupný, provoz se směruje mezi zbývajícími. 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. Nakonec je možné použít sondy aktivity ke kontrole stavu aplikace nebo procesu spuštěného v podu. Pokud služba nereaguje, sonda živé aktivity odebere pod, který vynutí replikuset k vytvoření nové instance.
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í, které jsou v pořádku. Clustery a pody Kubernetes v těchto oblastech budou dál obsluhovat žádosti.
V této situaci se starají o kompenzaci zvýšeného provozu nebo požadavků na zbývající cluster. Několik věcí, které je potřeba vzít v úvahu:
- 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á podporuje 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 mohli kompenzovat zvýšenou regionální poptávku.
- Využijte automatické škálování clusteru AKS ke zvýšení počtu uzlů instancí Kubernetes, aby se kompenzuje zvýšená regionální poptávka.
Další informace najdete v tématu Horizontální automatické škálování podů a automatické škálování clusteru AKS.
Fondy uzlů Kubernetes (regionální)
Občas může dojít k lokalizované chybě výpočetních prostředků, například pokud se napájení stane nedostupným pro jeden rack serverů Azure. Pokud chcete chránit uzly AKS před selháním v jedné oblasti, využijte zóny dostupnosti Azure. Použití zón dostupnosti zajišťuje, že uzly AKS v dané zóně dostupnosti jsou fyzicky oddělené od uzlů definovaných v jiné zóně dostupnosti.
Další informace najdete v tématu AKS a zóny dostupnosti Azure.
Fondy uzlů Kubernetes (globální)
V případě úplného regionálního selhání bude Azure Front Door směrovat provoz do zbývajících a zdravých oblastí. Opět se v této situaci postaráme o kompenzaci zvýšeného provozu nebo požadavků na zbývající cluster.
Další informace najdete v tématu Azure Front Door.
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 paprskovou pro každou místní instanci AKS, kde jsou partnerské virtuální sítě hvězdicové.
- 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ů, pokud dojde k selhání oblasti.
Správa provozu
S referenční architekturou standardních hodnot AKS se provoz úloh směruje přímo do instance brány Aplikace Azure a pak se přesměruje do back-endového nástroje pro vyrovnávání zatížení nebo 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 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.azurefd.net), který se přeloží na instanci služby Azure Front Door. Tento požadavek je zašifrovaný pomocí certifikátu se zástupným znakem (*.azurefd.net) vydaným pro všechny subdomény služby Azure Front Door. Instance Služby Azure Front Door ověří požadavek na zásady WAF, vybere nejrychlejší back-end (na základě stavu a latence) a použije veřejný DNS k překladu IP adresy back-endu (instance brány Aplikace 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 a je šifrovaný službou Azure Front Door. 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í front Dooru k back-endové
X-Azure-FDIDhlavičce, 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 tato referenční architektura zaměřuje na několik instancí Kubernetes rozložených napříč několika oblastmi Azure, dává smysl mít některé sdílené prostředky napříč všemi instancemi. Referenční implementace AKS pro více oblastí pomocí jedné šablony ARM 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 referenční architektuře používá k poskytování služeb imagí kontejnerů (pull). 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ění registru kontejneru v každé oblasti, ve které je nasazený cluster AKS, umožňuje operace zavření sítě, což umožňuje rychlé a spolehlivé přenosy vrstev imagí. Pokud regionální služby nejsou k dispozici, máte k dispozici několik koncových bodů služby image. Použití funkce geografické replikace služby Azure Container Registry umožňuje spravovat jednu instanci služby Container Registry replikovanou do více oblastí.
Referenční implementace AKS pro více oblastí vytvořila jednu instanci služby Container Registry a repliky této instance do každé oblasti clusteru. 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 ACR z webu Azure Portal
Přístup ke clusteru
Každá instance AKS vyžaduje přístup k vyžádání vrstev imagí ze služby Azure Container Registry. Existuje několik způsobů, jak vytvořit přístup ke službě Azure Container Registry; tato referenční architektura používá spravovanou identitu Azure pro každý cluster, který se pak udělí roli AcrPull v instanci Container Registry. Další informace a doporučení týkající se použití spravovaných identit pro přístup ke službě Container Registry najdete v referenční architektuře standardních hodnot AKS.
Tato konfigurace je definovaná v šabloně ARM razítka clusteru, aby při každém nasazení nového razítka byla udělena nová instance AKS. Protože container Registry je sdílený prostředek, ujistěte se, že šablona razítka nasazení může využívat a používat potřebné podrobnosti, v tomto případě ID prostředku služby Container Registry.
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 můžou shromažďovat také kontejnerové Přehledy a odesílat data do spravované služby Azure Monitor pro prometheus nebo do protokolů služby Azure Monitor.
Můžete také nakonfigurovat nastavení diagnostiky clusteru AKS tak, aby shromáždila a analyzovala protokoly prostředků z komponent řídicí roviny AKS a předávala je do pracovního prostoru služby Log Analytics.
AKS Další informace najdete v referenční architektuře standardních hodnot AKS.
Při zvažování monitorování implementace mezi oblastmi, jako je tato referenční architektura, je důležité zvážit propojení mezi jednotlivými kolky. V tomto případě zvažte každé razítko součásti jedné jednotky (regionální cluster). Referenční implementace AKS pro více oblastí využívá 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 pracovním prostoru služby Log Analytics a připojovat k němu jednotlivé clustery.
Teď, když každý regionální cluster vysílá diagnostické protokoly do jednoho pracovního prostoru služby Log Analytics, je možné tato data společně s metrikami prostředků použít k snadnějšímu vytváření sestav a řídicích panelů, které představují celý globální cluster.
Azure Front Door
Služba 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 umožňuje vrstvu sedm globálního směrování, z nichž obě jsou pro tuto referenční architekturu vyžadovány.
Konfigurace clusteru
Při přidání místních instancí AKS musí být služba Application Gateway nasazená společně s clusterem Kubernetes zaregistrovaná jako back-end služby Front Door, aby bylo možné správně směrovat. Tato operace vyžaduje aktualizaci infrastruktury jako prostředků kódu. Tuto operaci můžete také oddělit od konfigurace nasazení a spravovat ji pomocí nástrojů, jako je Azure CLI. Zahrnutý kanál nasazení referenčních implementací využívá pro tuto operaci jedinečný krok Azure CLI.
Certifikáty
Služba Front Door nepodporuje certifikáty podepsané svým držitelem ani v prostředích pro vývoj/testování. Pokud chcete povolit provoz HTTPS, musíte vytvořit certifikát TLS/SSL podepsaný certifikační autoritou . Referenční implementace používá Certbot k vytvoření certifikátu Let's Encrypt Authority X3. Při plánování produkčního clusteru použijte upřednostňovanou metodu pro nákup certifikátů TLS ve vaší organizaci.
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.
Přístup ke clusteru a identita
Jak je popsáno v referenční architektuře standardních hodnot AKS, doporučuje se jako zprostředkovatele identit přístupu clusterů 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 budete muset 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 adresářů Azure. Díky této možnosti se administrativní režie výrazně zvyšuje; Poskytuje ale podrobný přístup nejen ke každému clusteru, ale také k oborům názvů a rozhraníM API Kubernetes nalezeným v rámci každého clusteru.
V zahrnuté referenční implementaci se vytvoří dvě skupiny Microsoft Entra pro přístup správce. Tyto skupiny se zadají v době nasazení kolku clusteru pomocí souboru parametrů nasazení. Členové každé skupiny mají úplný přístup k odpovídajícímu razítku clusteru.
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ého clusteru instancí AKS zvažte architekturu aplikace, procesu nebo jiných úloh, které se můžou spouštět napříč clusterem. Vzhledem k tomu, že je úloha založená na stavu rozdělená do clusteru, bude potřebovat přístup k úložišti stavů? Pokud se proces znovu vytvoří jinde v clusteru kvůli selhání, bude úloha nebo proces mít nadále přístup k závislému úložišti stavu nebo řešení ukládání do mezipaměti? Stát lze dosáhnout mnoha způsoby; V jednom clusteru Kubernetes ale může být složité. Složitost se zvyšuje při přidávání do několika clusterovaných instancí 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ů.
Referenční implementace s více clustery neobsahuje ukázku ani konfiguraci pro problémy se stavem. Pokud spouštíte aplikace napříč clusterovanými instancemi 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 zapisovat a číst data z místních replik databáze. Další informace najdete v tématu Azure Cosmos DB.
Pokud vaše úloha využívá řešení ukládání do mezipaměti, ujistěte se, že je navržená tak, aby služby ukládání do mezipaměti zůstaly funkční. Za tímto účelem se ujistěte, ž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 konkrétních konstruktorů Kubernetes.
Další kroky
- Zóny dostupnosti AKS
- Azure Kubernetes Fleet Manager
- Geografická replikace ve službě Azure Container Registry
- Spárované oblasti Azure