AKS standardní hodnoty pro clustery s více oblastmi

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, doporučeného výchozího bodu pro infrastrukturu AKS od Microsoftu. Standardní hodnoty AKS podrobně propojí funkce infrastruktury, jako je identita podu Azure Active Directory (Azure AD), omezení příchozího a výchozího přenosu dat, limity prostředků a další zabezpečené konfigurace infrastruktury AKS. Tyto podrobnosti o infrastruktuře nejsou v tomto dokumentu zahrnuté. Než budete pokračovat s obsahem ve více oblastech, doporučujeme se seznámit se základními plány AKS.

dispozici na GitHub.

Komponenty

Mnoho komponent a služeb Azure se používá v referenční architektuře AKS pro více oblastí. Níže jsou uvedené pouze komponenty, které jsou jedinečné pro tuto architekturu s více clustery. Zbývající informace se dotápět na základní architekturu AKS.

• Několik clusterů / více oblastí Nasadí se několik clusterů AKS, z nichž každý je v samostatné oblasti Azure. Během normálního provozu se síťový provoz směruje mezi všemi oblastmi. Pokud se jedna oblast stane nedostupnou, provoz se směruje do oblasti, která je nejblíže uživateli, který požadavek vydal.
• Síť s paprsky rozbočovače na oblast Pro každou oblastní instanci AKS se nasadí pár sítí s paprsky oblasti. Azure Firewall Manager se používají ke správě zásad brány firewall ve všech oblastech.
• Regionální úložiště klíčů Azure Key Vault v každé oblasti pro ukládání citlivých hodnot a klíčů specifických pro instanci AKS a podpůrných služeb, které se v této oblasti nacházejí.
• Azure Front Door Služba Azure Front Door slouží k vyrovnávání zatížení a směrování provozu do místní Azure Application Gateway, 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 vyžadovány pro tuto referenční architekturu.
• Log Analytics Regionální instance Log Analytics se používají k ukládání regionálních síťových metrik a diagnostických protokolů. Sdílená instance Log Analytics se navíc používá k ukládání metrik a diagnostických protokolů pro všechny instance AKS.
• Registr kontejneru Image kontejneru pro úlohu se ukládají ve spravovaném registru kontejneru. V této architektuře se Azure Container Registry pro všechny instance Kubernetes v clusteru. Geografická replikace pro Azure Container Registry umožňuje replikaci imagí do vybraných oblastí Azure a poskytování trvalého přístupu k imagům i v případě, že v oblasti dochází k výpadku.

Vzory návrhu

Tato referenční architektura používá dva vzory cloudového návrhu. Geografický uzel (geodes),kde může libovolná oblast žádat o služby, a nasazovací razítka, kde se z jednoho zdroje (šablony nasazení) nasazovat několik nezávislých kopií aplikace nebo komponenty aplikace.

Aspekty vzoru geografického uzlu

Při výběru oblastí, ve kterých se bude každý cluster AKS nasazovat, zvažte oblasti blízko zákazníka úloh nebo vašich zákazníků. Zvažte také využití spárovaných oblastí Azure. Spárované oblasti se skládají ze dvou oblastí ve stejné geografické oblasti, které ovlivňují provádění údržby Azure. S tím, jak se cluster škáluje za dvě oblasti, pokračujte plánováním umístění párů oblastí pro každou dvojici clusterů AKS. Další informace o analyzovaných oblastech najdete v tématu Spárované oblasti Azure.

V každé oblasti jsou uzly ve fondech uzlů AKS rozložené mezi několik zón dostupnosti, aby se zabránilo problémům způsobeným selháním zón. Zóny dostupnosti jsou podporované v omezené sadě oblastí, což ovlivňuje umístění regionálního clusteru. Další informace o zónách dostupnosti a AKS, včetně seznamu podporovaných oblastí, najdete v tématu AKS Zóny dostupnosti.

Důležité informace o razítku nasazení

Při správě clusteru AKS s více oblastmi se nasazovat více instancí AKS napříč několika oblastmi. Každá z těchto instancí se považuje za kolek. V případě selhání oblasti nebo v případě potřeby 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 stampů nasazení je důležité vzít v úvahu následující věci:

• Vyberte technologii definice razítka, která umožňuje generalizovanou konfiguraci, jako je například infrastruktura jako kód.
• Zadejte hodnoty specifické pro instanci pomocí vstupního mechanismu nasazení, jako jsou proměnné nebo soubory parametrů.
• Výběr nástrojů pro nasazení, které umožňují flexibilní, opakovatelné a idempotentní nasazení
• V konfiguraci razítka aktivní/aktivní zvažte, jak je mezi jednotlivými kolky vyvážený provoz.
• Při přidání kolků a jejich odebrání z kolekce zvažte otázky ohledně kapacity a nákladů.
• Zvažte, jak získat přehled nebo monitorovat kolekci kolků jako jednu jednotku.

Každá z těchto položek je podrobně uvedená s konkrétními pokyny v následujících částech této referenční architektury.

Nasazení a spuštění clusteru

Při nasazování více clusterů Kubernetes ve vysoce dostupných a geograficky distribuovaných konfiguracích je nezbytné zvážit součet jednotlivých clusterů Kubernetes jako sjednocenou jednotku. Možná budete chtít vyvinout strategie automatizovaného nasazení a konfigurace řízené kódem, abyste zajistili, že každá instance Kubernetes bude co nejvíce stejná. Měli byste zvážit strategie horizontálního navýšení a navýšení kapacity přidáním nebo odebráním dalších instancí Kubernetes. Měli byste se zamyslet nad selháním oblasti a zajistit, aby každý vedlejší produkt selhání byl v plánu nasazení a konfigurace kompenzovat.

Definice clusteru

Máte mnoho možností pro nasazení clusteru Azure Kubernetes Service cluster. Všechny Azure Portal, Azure CLI a Azure PowerShell jsou decentrastrované možnosti pro nasazení jednotlivých nebo nesouskupovaných clusterů AKS. Tyto nástroje ale mohou při práci s mnoha těsně probáděných clustery AKS reagovat na problémy. Například použití příkazu Azure Portal otevírá příležitost pro chybnou konfiguraci z důvodu zmeškaných kroků nebo nedostupných možností konfigurace. Nasazení a konfigurace mnoha clusterů pomocí portálu je také včasný proces, který vyžaduje zaměření jednoho nebo více techniků. I když můžete pomocí nástrojů příkazového řádku vytvořit opakovatelný a automatizovaný proces, onus věcí, jako je idempotence, řízení selhání nasazení a obnovení selhání, je na vás a skriptech, které sestavíte.

Při práci s mnoha instancemi AKS doporučujeme uvažovat o infrastruktuře jako řešení kódu, jako jsou Azure Resource Manager šablony, šablony Bicep nebo konfigurace Terraformu. Řešení infrastruktury jako kódu poskytují automatizované, škálovatelné a idempotentní řešení nasazení. Tato referenční architektura zahrnuje šablonu ARM pro sdílená řešení a pak další pro clustery AKS a regionální služby. Pomocí infrastruktury jako kódu je možné definovat razítko nasazení pomocí generalizovaných konfigurací, jako jsou sítě, autorizace a diagnostika. Soubor parametrů nasazení lze zadat s hodnotami specifickými pro jednotlivé oblasti. Při této konfiguraci je možné pomocí jedné šablony nasadit téměř identický kolek napříč libovolnou oblastí.

Náklady na vývoj a údržbu infrastruktury jako prostředků 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 jako kódu převážit nad výhodami. Pro tyto případy je použití imperativního přístupu, například pomocí nástrojů příkazového řádku nebo dokonce ručního přístupu, v pořádku.

Nasazení clusteru

Po definování definice kolku clusteru máte mnoho možností pro nasazení jednotlivých nebo více instancí kolku. Doporučujeme používat moderní technologie kontinuální integrace, jako jsou GitHub Actions nebo Azure Pipelines. Mezi výhody řešení průběžného nasazování založeného na integraci patří:

• Nasazení založená na kódu, která umožňují přidání a odebrání razítek pomocí kódu
• Možnosti integrovaného testování
• Integrované prostředí a možnosti pracovních prostředí
• Integrovaná řešení pro správu tajných kódů
• Integrace s kódem / s nasazením správy 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 kanál nasazení aktualizovat, aby odrážel. V referenční implementaci se každá oblast nasazovat jako jednotlivé kroky v rámci pracovního GitHub akcí (například). Tato konfigurace je jednoduchá v tom, že každá instance clusteru je jasně definovaná v rámci kanálu nasazení. Tato konfigurace ale při přidávání a odebírání clusterů z nasazení nese určité administrativní režie.

Další možností je využít logiku k vytváření clusterů na základě seznamu požadovaných umístění nebo jiných indikující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 projít tímto seznamem a nasadit cluster do každé oblasti v seznamu. Nevýhodou této konfigurace je složitost zobecnění nasazení a to, že každý kolek clusteru není v kanálu nasazení explicitně podrobně podrobně. Pozitivní výhodou je, že přidání nebo odebrání kolků clusteru z kanálu se stane jednoduchou aktualizací seznamu požadovaných oblastí.

Nezapomeňte také, že odebráním razítka clusteru z kanálu nasazení se nemusí nutně zajistit, že bude také vyřazen z provozu. V závislosti na technologii a konfiguraci nasazení možná budete potřebovat další krok, který zajistí, že se instance AKS odpovídajícím způsobem vyřazeny z provozu.

Spuš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ích 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í napříč clusterem.

Podobně jako při nasazení může být správa těchto konfigurací v několika instancích 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 Kubertnets zvažte použití automatizovaných nástrojů k aplikování konfigurací na cluster Kubernetes, protože se tyto konfigurace zařizují do zdrojového úložiště. Tento proces se často označuje jako GitOps a mezi oblíbená řešení GitOps pro Kubernetes patří Flux a Argo CD.

Podrobnější informace o GitOps najdete v referenční architektuře standardních hodnot AKS. Důležitá poznámka je, že použití přístupu ke konfiguraci založenému na GitOps pomáhá zajistit, aby každá instance Kubernetes byla nakonfigurovaná podobně bez úsilí o vynaložit.

Azure Policy

Při přidání více instancí Kubernetes se zvyšuje výhoda zásad správného řízení, dodržování předpisů a konfigurace řízených zásadami. Použití zásad, zásady Azure, v tomto případě poskytuje centralizovanou a škálovatelnou metodu pro řízení clusteru. Výhodou zásad AKS je podrobně popsána v referenční architektuře AKS směrného plánu.

Azure Policy je v této referenční implementaci povolený, když se vytvoří clustery AKS, a přiřadí omezující iniciativu v režimu auditování, aby získala přehled o nedodržení předpisů. Implementace taky nastavuje další zásady, které nejsou součástí žádné integrované iniciativy. Tyto zásady jsou nastaveny v režimu odepření. Existují například zásady, které zajišťují, že v clusteru jsou spuštěny pouze schválené image kontejneru. Zvažte vytvoření vlastních iniciativ. Zkombinujte zásady, které platí pro vaše zatížení, do jediného přiřazení.

Obor zásad odkazuje na cíl jednotlivých zásad a iniciativ 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é se nasadí jednotlivé clustery AKS. Vzhledem k nárůstu počtu globálních clusterů to bude mít za následek mnoho duplicitních zásad. Můžete také oborovat zásady pro předplatné Azure nebo skupinu pro správu Azure, která umožňuje použití jedné sady zásad u všech clusterů AKS v rámci oboru předplatného nebo všech předplatných, která se nacházejí 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 měly platit globálně pro všechny instance AKS, se dají použít pro skupinu nebo předplatné pro správu.
• Umístění všech regionálních clusterů do vlastní skupiny prostředků umožňuje použít pro skupinu prostředků zásady specifické pro oblast.

Materiály, které vám pomůžou vytvořit strategii správy zásad, najdete v tématu skupina pro správu rozhraní pro přijetí do cloudu a organizaci předplatného .

Nasazení úloh

Kromě konfigurace instance AKS zvažte úlohu nasazenou do každé místní instance nebo razítka. Řešení pro nasazení nebo kanály budou vyžadovat konfiguraci pro každé regionální razítko. Jelikož se další razítka přidávají do globálního clusteru, je potřeba proces nasazení rozšířit nebo přizpůsobit dostatečně, aby bylo možné přizpůsobit nové místní instance.

Při plánování nasazení úloh Vezměte v úvahu následující položky.

• Generalizujte nasazení, například pomocí grafu Helm, abyste zajistili, že se jedna konfigurace nasazení dá použít napříč více razítky clusteru.
• Použijte jeden kanál průběžného nasazování nakonfigurovaný pro nasazení úloh napříč všemi razítky clusteru.
• Zadejte podrobnosti instance specifické pro razítko jako parametry nasazení.
• Vezměte v úvahu, jak protokolování diagnostiky aplikace a distribuované trasování jsou konfigurovány pro pozorování v nejrůznějších aplikacích.

Dostupnost/převzetí služeb při selhání

Významnou motivací pro výběr Kubernetes architektury s více oblastmi je dostupnost služeb. To znamená, že pokud služba nebo součást služby nebude k dispozici v jedné oblasti, provoz by měl být směrován do oblasti, kde je tato služba k dispozici. Architektura více oblastí zahrnuje mnoho různých bodů selhání. V této části je vysvětleno každé z těchto možných bodů selhání.

Aplikační lusky (místní)

Objekt nasazení Kubernetes se používá k vytvoření několika replik pod (ReplicaSet). Pokud je jeden z nich nedostupný, provoz se směruje mezi zbývající. Kubernetes ReplicaSet se pokusí zachovat a spustit zadaný počet replik. Pokud dojde k výpadku jedné instance, měla by se znovu vytvořit nová instance. A konečně, sondy živého využívání lze použít ke kontrole stavu aplikace nebo procesu spuštěného v pod. Pokud služba odpovídajícím způsobem nereaguje, sonda pro živý test odstraní hodnotu pod, což vynutí, aby ReplicaSet vytvořil novou instanci.

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

Lusky aplikací (globální)

Když se celá oblast stane nedostupnou, lusky v clusteru už nejsou k dispozici pro poskytování požadavků. V takovém případě instance služby Azure front-dveří směruje veškerý provoz do zbývajících oblastí v pořádku. Clustery Kubernetes a lusky v těchto oblastech budou dál obsluhovat požadavky.

V této situaci se při vyrovnávání zatížení/požadavků do zbývajícího clusteru postará. Zvažte několik věcí, které je třeba vzít v úvahu:

• Zajistěte, aby byly síťové a výpočetní prostředky v důsledku převzetí služeb při selhání v oblasti náročné na jakékoli náhlé zvýšení provozu. Pokud například používáte Azure CNI, ujistěte se, že máte podsíť, která může podporovat všechny IP adresy pod špičkou zatížení v provozu.
• Využijte horizontální automatické škálování pod a zvyšte počet replik pod tím, aby se zvýšila úroveň místní poptávky.
• Využijte AKS clusteru pro automatické škálování ke zvýšení počtu uzlů instancí Kubernetes, abyste mohli kompenzovat zvýšenou regionální poptávku.

Další informace najdete v části horizontální navýšení a automatické škálování clusteru AKS.

Fondy uzlů Kubernetes (místní)

Občas se může stát, že dojde k selhání ve výpočetních prostředcích, například pokud dojde k nedostupnosti pro jeden stojan serverů Azure. Pokud chcete chránit uzly AKS před tím, než se stane regionálním selháním s jednou bodem, využijte zóny dostupnosti Azure. Použití zón dostupnosti zajišťuje, aby uzly AKS v dané zóně dostupnosti byly fyzicky oddělené od těch, které jsou definované 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 místního selhání budou přední dveře Azure směrovat provoz do zbývajících a zdravých oblastí. Znovu se v této situaci postará o kompenzaci za zvýšení provozu nebo požadavků do zbývajícího clusteru.

Další informace najdete v tématu přední dvířka Azure.

Síťová topologie

Podobně jako u referenční architektury AKS směrného plánu používá tato architektura síťovou topologii hub. Kromě informací uvedených v architektuře referenčních informací standardních hodnot AKSzvažte následující:

• Implementujte centrum hub pro každou místní instanci AKS, ve které jsou partnerské vztahy mezi virtuálními sítěmi hub.
• Směrování všech odchozích přenosů prostřednictvím instance Azure Firewall nalezené v každé místní síti centra. Využijte zásady Azure Firewall Manageru ke správě zásad brány firewall ve všech oblastech.
• Dodržujte velikost IP adres nalezené v architektuře referenčních hodnot AKS standardních hodnot a v případě regionálního selhání povolte další IP adresy pro operace škálování uzlu i pod.

Správa provozu

V rámci referenční architektury AKS směrného plánu se provoz zatížení směruje přímo do instance služby Azure Application Gateway a pak se přesměruje do prostředků back-endu služby Load Balancer/AKS příchozího přenosu dat. Když pracujete s několika clustery, požadavky klientů se směrují přes instanci front-dveří Azure, která směruje do instance služby Azure Application Gateway.

1. 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 front-dveří Azure. Tento požadavek je zašifrovaný s certifikátem se zástupným znakem (*. azurefd.net) vydaným pro všechny subdomény front-dveří Azure. Instance front-endu Azure ověřuje požadavek na zásady WAF, vybírá nejrychlejší back-end (na základě stavu a latence) a využívá veřejnou službu DNS k překladu IP adresy back-endu (instance Azure Application Gateway).

2. Přední dveře předává požadavek do vybrané příslušné instance Application Gateway, která slouží jako vstupní bod pro regionální razítko. Provoz se přenese přes Internet a zašifruje se přes služby Azure front-dveří. Vezměte v úvahu metodu, která zajistí, že instance Application Gateway akceptuje jenom provoz z instance front-dveří. Jedním z přístupů je použití skupiny zabezpečení sítě v podsíti, která obsahuje Application Gateway. Pravidla mohou 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 udržování sledování IP adres. Kromě toho zvažte použití hlavičky front-endu do back-endu, aby X-Azure-FDID se zajistilo, že instance Application Gateway akceptuje jenom provoz z instance front-endu. Další informace o hlavičkách frontových dveří najdete v tématu Podpora protokolů hlaviček protokolu HTTP v front-end Azure.

Požadavky na sdílené prostředky

I když se tato referenční architektura zaměřuje na rozšíření více instancí Kubernetes napříč několika oblastmi Azure, má smysl, aby byly některé sdílené prostředky ve všech instancích. Referenční implementace AKS ve více oblastech, která používá jednu šablonu ARM k nasazení všech sdílených prostředků a další pro nasazení všech regionálních razítek. Tato část podrobně popisuje každý z těchto sdílených prostředků a důležitých informací pro použití v rámci více instancí AKS.

Container Registry

Azure Container Registry se v této referenční architektuře používá k zajištění služby image imagí (pull). Při práci s 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írání sítě a povoluje rychlé a spolehlivé přenosy vrstev imagí. Přístup k více koncovým bodům služby imagí taky zajišťuje dostupnost v regionálních službách událostí. Díky funkcím geografické replikace služby Azure Container Registry můžete spravovat jednu instanci Container Registry replikovat do několika oblastí.

Referenční implementace AKS pro více oblastí vytvořila jednu instanci Container Registry a repliky této instance do každé oblasti clusteru. Další informace o Azure Container Registry replikaci najdete v tématu geografická replikace v Azure Container Registry.

Obrázek znázorňující více replik ACR v rámci Azure Portal.

Přístup ke clusteru

Každá instance AKS vyžaduje přístup pro přijímání vrstev imagí z Azure Container Registry. Existuje několik způsobů, jak vytvořit přístup k Azure Container Registry; Tato referenční architektura používá pro každý cluster spravovanou identitu Azure, která pak uděluje roli AcrPull v instanci Container Registry. Další informace a doporučení k používání spravovaných identit pro přístup k Container Registry najdete v tématu Referenční architektura AKS standardních hodnot.

Tato konfigurace je definovaná v šabloně ARM pro razítka clusteru, takže při každém nasazení nového razítka se k nové instanci AKS udělí přístup. Vzhledem k tomu, že Container Registry je sdílený prostředek, ujistěte se, že šablona razítka nasazení může spotřebovat a používat potřebné podrobnosti, v tomto případě ID prostředku Container Registry.

Log Analytics a Azure Monitor

Funkce Azure Monitor for Containers je doporučeným nástrojem pro monitorování a protokolování, protože můžete zobrazit události v reálném čase. Azure Monitor využívá pracovní prostor Log Analytics k ukládání diagnostických protokolů. Další informace najdete v tématu Referenční architektura AKS směrného plánu .

Při zvažování monitorování pro implementaci v různých oblastech, jako je tato referenční architektura, je důležité vzít v úvahu spojení mezi jednotlivými razítky. V takovém případě zvažte, že všechna razítka komponenty jedné jednotky (oblastní cluster). Referenční implementace AKS ve více oblastech využívá jeden pracovní prostor Log Analytics, který sdílí každý cluster Kubernetes. Podobně jako u ostatních sdílených prostředků definujte své regionální razítko, aby se využívaly informace o jednom pracovním prostoru Log Analytics a aby se k němu připojily jednotlivé clustery.

Teď, když každý místní cluster vynechává protokoly diagnostiky do jednoho Log Analytics pracovního prostoru, můžete tato data společně s metrikami prostředků použít k snadnějšímu sestavování sestav a řídicích panelů, které reprezentují celý globální cluster.

Azure Front Door

Přední dvířka Azure slouží k vyrovnávání zatížení a směrování provozu do každého clusteru AKS. Přední dveře Azure umožňují pro globální směrování vrstvy 7, které jsou pro tuto referenční architekturu potřeba.

Konfigurace clusteru

Když se přidají regionální instance AKS, musí se Application Gateway nasazený společně s clusterem Kubernetes zaregistrovat jako back-endu front-endu pro správné směrování. Tato operace vyžaduje aktualizaci vaší infrastruktury jako prostředků kódu. Alternativně můžete tuto operaci oddělit od konfigurace nasazení a spravovat pomocí nástrojů, jako je Azure CLI. Zahrnuté reference implementují kanál nasazení pro tuto operaci používá odlišný krok Azure CLI.

Certifikáty

Přední dvířka nepodporují certifikáty podepsané svým držitelem ani ve vývojových a testovacích prostředích. Pokud chcete povolit přenosy přes protokol HTTPS, musíte si vytvořit certifikát TLS/SSL podepsaný certifikační autoritou (CA). Referenční implementace pomocí Certbot vytvoří certifikát autority pro šifrování X3. Při plánování pro produkční cluster použijte upřednostňovanou metodu vaší organizace pro proorganizování certifikátů TLS.

Informace o dalších certifikačních autoritách podporovaných přes dvířka najdete v tématu povolené certifikační autority pro povolení vlastního protokolu HTTPS na frontách Azure.

Přístup a identita clusteru

jak je popsáno v tématu referenční architektura AKS směrného plánu, doporučujeme použít Azure Active Directory jako zprostředkovatele identity přístupu ke clusterům. skupiny Azure Active Directory se pak dají použít k řízení přístupu k prostředkům clusteru.

Při správě více clusterů se musíte rozhodnout ve schématu přístupu. Vaše možnosti jsou:

• Vytvořte globální skupinu přístupu pro celou cluster, kde členové mají přístup ke všem objektům v rámci každé instance Kubernetes v clusteru. Tato možnost poskytuje minimální požadavky na správu; udělí ale významné oprávnění pro každého člena skupiny.
• Vytvořte individuální přístupovou skupinu pro každou instanci Kubernetes, která slouží k udělení přístupu k objektům v jednotlivých instancích clusteru. S touto možností se zvýšila administrativní režie; poskytuje ale i podrobnější přístup k clusteru.
• Definujte podrobné ovládací prvky přístupu pro typy objektů Kubernetes a obory názvů a korelujte je se strukturou skupin adresářů Azure. S touto možností se významně zvyšují nároky na správu. poskytuje ale detailní přístup nejen pro každý cluster, ale obory názvů a rozhraní Kubernetes API nalezené v každém clusteru.

V rámci zahrnuté referenční implementace jsou pro přístup správce vytvořeny dvě skupiny AAD. Tyto skupiny se zadává v době nasazení razítka 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í Azure Active Directory najdete v tématu věnovaném integraci AKS Azure AD.

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é mohou běžet v clusteru. V případě, že se zatížení na základě stavu rozšíří napříč clusterem, bude potřebovat přístup k úložišti stavů? Pokud je proces znovu vytvořen jinde v clusteru z důvodu selhání, bude mít zatížení nebo proces dál přístup k úložišti závislého stavu nebo řešení pro ukládání do mezipaměti? Stav lze dosáhnout mnoha způsoby; může to ale být složité v jednom clusteru Kubernetes. Složitost se zvyšuje při přidávání do několika clusterovaných instancí Kubernetes. V souvislosti s regionálním přístupem a složitou složitostí zvažte, jak budou vaše aplikace navrhovat, aby používaly globálně distribuovanou službu úložiště stavů.

Referenční implementace více clusterů neobsahuje ukázku nebo konfiguraci pro stav, který se týká. pokud spouštíte aplikace napříč clusterovanými instancemi AKS, zvažte, jak úlohy architektí použít globálně distribuovanou datovou službu, například 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 úlohy využívají řešení pro 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í. Pokud to chcete udělat, zajistěte, aby zatížení samotné bylo odolné proti selhání souvisejícím s mezipamětí a aby řešení pro ukládání do mezipaměti existovala ve všech regionálních instancích AKS

Správa 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 popsané v části věnované optimalizaci nákladů v Microsoft Azure Well-Architected Framework.