Punkt odniesienia usługi AKS dla klastrów wieloregionowych

Ta architektura zawiera szczegółowe informacje na temat uruchamiania wielu wystąpień klastra usługi Azure Kubernetes Service (AKS) w wielu regionach w konfiguracji aktywne/aktywne i wysoce dostępne.

Ta architektura opiera się na architekturze punktu odniesienia usługi AKS, zalecanego punktu wyjścia firmy Microsoft dla infrastruktury usługi AKS. Podstawowe funkcje planu bazowego usługi AKS, takie jak Tożsamość obciążeń Microsoft Entra, ograniczenia ruchu przychodzącego i ruchu wychodzącego, limity zasobów i inne bezpieczne konfiguracje infrastruktury usługi AKS. Te szczegóły infrastruktury nie są omówione w tym dokumencie. Zalecamy zapoznanie się z punktem odniesienia usługi AKS przed kontynuowaniem pracy z zawartością w wielu regionach.

Architektura

Pobierz plik programu Visio z tą architekturą.

Składniki

Wiele składników i usług platformy Azure jest używanych w tej architekturze usługi AKS w wielu regionach. W tym miejscu wymieniono tylko te składniki z unikatowością tej architektury wielu klastrów. W przypadku pozostałych informacji zapoznaj się z architekturą punktu odniesienia usługi AKS.

• Regionalne klastry AKS: wdrażanych jest wiele klastrów usługi AKS, z których każdy jest w osobnym regionie świadczenia usługi Azure. Podczas normalnych operacji ruch sieciowy jest kierowany między wszystkimi regionami. Jeśli jeden region stanie się niedostępny, ruch jest kierowany do regionu znajdującego się najbliżej użytkownika, który wystawił żądanie.
• Regionalne sieci piasty i szprych: dla każdego regionalnego wystąpienia usługi AKS jest wdrażana para sieci piasty i szprych. Zasady usługi Azure Firewall Manager służą do zarządzania zasadami zapory we wszystkich regionach.
• Regionalny magazyn kluczy: usługa Azure Key Vault jest aprowizowana w każdym regionie. Magazyny kluczy są używane do przechowywania poufnych wartości i kluczy specyficznych dla klastra usługi AKS i usług pomocniczych, które znajdują się w tym regionie.
• Wiele obszarów roboczych dziennika: regionalne obszary robocze usługi Log Analytics są używane do przechowywania regionalnych metryk sieci i dzienników diagnostycznych. Ponadto udostępnione wystąpienie usługi Log Analytics służy do przechowywania metryk i dzienników diagnostycznych dla wszystkich wystąpień usługi AKS.
• Globalny profil usługi Azure Front Door: usługa Azure Front Door służy do równoważenia obciążenia i kierowania ruchu do regionalnego wystąpienia usługi aplikacja systemu Azure Gateway, które znajduje się przed każdym klastrem usługi AKS. Usługa Azure Front Door umożliwia routing globalny warstwy 7, z których oba są wymagane dla tej architektury.
• Globalny rejestr kontenerów: obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. W tej architekturze pojedynczy rejestr kontenerów platformy Azure jest używany dla wszystkich wystąpień platformy Kubernetes w klastrze. Replikacja geograficzna dla usługi Azure Container Registry umożliwia replikowanie obrazów do wybranych regionów świadczenia usługi Azure i zapewnienie ciągłego dostępu do obrazów, nawet jeśli w regionie występuje awaria.

Wzorce projektowe

Ta architektura używa dwóch wzorców projektowych chmury:

• Geody (węzły geograficzne), w których dowolny region może obsłużyć dowolne żądanie.
• Sygnatury wdrażania, w których wdrożono wiele niezależnych kopii składnika aplikacji lub aplikacji z jednego źródła, takiego jak szablon wdrożenia.

Zagadnienia dotyczące wzorca geode

Podczas wybierania regionów do wdrożenia każdego klastra usługi AKS należy wziąć pod uwagę regiony zbliżone do odbiorcy obciążenia lub klientów. Należy również rozważyć użycie replikacji między regionami. Replikacja między regionami asynchronicznie replikuje te same aplikacje i dane w innych regionach świadczenia usługi Azure na potrzeby ochrony odzyskiwania po awarii. W miarę skalowania klastra poza dwoma regionami kontynuuj planowanie replikacji między regionami dla każdej pary klastrów usługi AKS.

W każdym regionie węzły w pulach węzłów usługi AKS są rozmieszczone w wielu strefach dostępności, aby zapobiec problemom spowodowanym awariami strefowymi. Strefy dostępności są obsługiwane w ograniczonym zestawie regionów, co wpływa na rozmieszczenie klastra regionalnego. Aby uzyskać więcej informacji na temat usługi AKS i stref dostępności, w tym listę obsługiwanych regionów, zobacz Strefy dostępności usługi AKS.

Zagadnienia dotyczące sygnatury wdrożenia

Podczas zarządzania rozwiązaniem usługi AKS w wielu regionach wdraża się wiele klastrów usługi AKS w wielu regionach. Każdy z tych klastrów jest uważany za sygnaturę. Jeśli wystąpi awaria regionalna lub konieczne jest dodanie większej pojemności lub obecności regionalnej dla klastrów, może być konieczne utworzenie nowego wystąpienia sygnatury. Podczas wybierania procesu tworzenia sygnatur wdrożenia i zarządzania nimi należy wziąć pod uwagę następujące kwestie:

• Wybierz odpowiednią technologię dla definicji sygnatur, która umożliwia uogólnioną konfigurację. Na przykład można użyć Bicep do definiowania infrastruktury jako kodu.
• Podaj wartości specyficzne dla wystąpienia przy użyciu mechanizmu wejściowego wdrożenia, takiego jak zmienne lub pliki parametrów.
• Wybierz narzędzia wdrażania, które umożliwia elastyczne, powtarzalne i idempotentne wdrożenie.
• W konfiguracji aktywnej/aktywnej sygnatury należy wziąć pod uwagę sposób równoważenia ruchu między poszczególnymi sygnaturami. Ta architektura używa usługi Azure Front Door do równoważenia obciążenia globalnego.
• W miarę dodawania i usuwania sygnatur z kolekcji należy wziąć pod uwagę kwestie związane z pojemnością i kosztami.
• Zastanów się, jak uzyskać wgląd w kolekcję sygnatur i monitorować je jako pojedynczą jednostkę.

Każdy z tych elementów został szczegółowo opisany wraz z konkretnymi wskazówkami w poniższych sekcjach.

Zarządzanie flotą

To rozwiązanie reprezentuje topologię z wieloma klastrami i wieloma regionami bez dołączania zaawansowanego orkiestratora do traktowania wszystkich klastrów w ramach ujednoliconej floty. W przypadku zwiększenia liczby klastrów rozważ zarejestrowanie członków w usłudze Azure Kubernetes Fleet Manager , aby lepiej zarządzać uczestniczącymi klastrami na dużą skalę. Przedstawiona tutaj architektura infrastruktury nie zmienia się zasadniczo wraz z rejestracją w programie Fleet Manager, ale operacje z dnia 2 i podobne działania wynikają z płaszczyzny sterowania, która może kierować wiele klastrów jednocześnie.

Kwestie wymagające rozważenia

Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.

Wdrażanie klastra i uruchamianie aplikacji

Podczas wdrażania wielu klastrów Kubernetes w konfiguracjach o wysokiej dostępności i geograficznie rozproszonych należy wziąć pod uwagę sumę każdego klastra Kubernetes jako jednostki połączonej. Warto opracować strategie oparte na kodzie na potrzeby zautomatyzowanego wdrażania i konfiguracji, aby upewnić się, że każde wystąpienie platformy Kubernetes jest tak samo identyczne, jak to możliwe. Rozważ strategie skalowania w górę i w miejscu, w tym przez dodawanie lub usuwanie innych klastrów Kubernetes. Projekt, wdrożenie i plan konfiguracji powinny uwzględniać awarie strefy dostępności, awarie regionalne i inne typowe scenariusze.

Definicja klastra

Istnieje wiele opcji wdrażania klastra usługi Azure Kubernetes Service. Witryna Azure Portal, interfejs wiersza polecenia platformy Azure i moduł azure PowerShell to wszystkie przyzwoite opcje wdrażania pojedynczych lub niezwiązanych klastrów usługi AKS. Te metody mogą jednak stanowić wyzwanie podczas pracy z wieloma ściśle powiązanymi klastrami usługi AKS. Na przykład użycie witryny Azure Portal otwiera możliwość błędnej konfiguracji z powodu nieodebranych kroków lub niedostępnych opcji konfiguracji. Wdrożenie i konfiguracja wielu klastrów korzystających z portalu jest czasochłonnym procesem wymagającym skupienia się na co najmniej jednym inżynierze. Jeśli używasz interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell, możesz utworzyć powtarzalny i zautomatyzowany proces przy użyciu narzędzi wiersza polecenia. Jednak odpowiedzialność za idempotentność, kontrolę niepowodzeń wdrażania i odzyskiwanie po awarii jest na Ciebie i na skryptach, które tworzysz.

Podczas pracy z wieloma wystąpieniami usługi AKS zalecamy rozważenie infrastruktury jako rozwiązań kodu, takich jak Bicep, szablony usługi Azure Resource Manager lub narzędzie Terraform. Infrastruktura jako rozwiązania kodu zapewniają zautomatyzowane, skalowalne i idempotentne rozwiązanie wdrażania. Możesz na przykład użyć jednego pliku Bicep dla usług udostępnionych rozwiązania, a drugi dla klastrów usługi AKS i innych usług regionalnych. Jeśli używasz infrastruktury jako kodu, sygnaturę wdrożenia można zdefiniować za pomocą uogólnionych konfiguracji, takich jak sieć, autoryzacja i diagnostyka. Plik parametrów wdrożenia może być dostarczany z wartościami specyficznymi dla regionu. Dzięki tej konfiguracji można użyć pojedynczego szablonu do wdrożenia niemal identycznej sygnatury w dowolnym regionie.

Koszt opracowywania i utrzymywania infrastruktury jako zasobów kodu może być kosztowny. W niektórych przypadkach obciążenie związane z definiowaniem infrastruktury jako kodu może przewyższać korzyści, takie jak w przypadku bardzo małej liczby wystąpień usługi AKS (np. 2 lub 3) i niezmiennej liczby wystąpień usługi AKS. W takich przypadkach dopuszczalne jest użycie bardziej imperatywnego podejścia, takiego jak narzędzia wiersza polecenia, a nawet ręczne podejścia w witrynie Azure Portal.

Wdrażanie klastra

Po zdefiniowaniu sygnatury klastra istnieje wiele opcji wdrażania pojedynczych lub wielu wystąpień sygnatury. Naszym zaleceniem jest użycie nowoczesnej technologii ciągłej integracji, takiej jak GitHub Actions lub Azure Pipelines. Zalety rozwiązań do ciągłego wdrażania opartego na integracji obejmują:

• Wdrożenia oparte na kodzie, które umożliwiają dodawanie i usuwanie sygnatur przy użyciu kodu
• Zintegrowane możliwości testowania
• Zintegrowane środowisko i możliwości przemieszczania
• Zintegrowane rozwiązania do zarządzania wpisami tajnymi
• Integracja z kontrolą źródła zarówno dla kodu aplikacji, jak i skryptów wdrażania oraz szablonów
• Historia wdrożenia i rejestrowanie
• Możliwości kontroli dostępu i inspekcji w celu kontrolowania, kto może wprowadzać zmiany i w jakich warunkach

Gdy nowe sygnatury są dodawane lub usuwane z klastra globalnego, potok wdrażania musi być aktualizowany, aby zachować spójność. Jednym z podejść jest wdrożenie zasobów każdego regionu jako indywidualnego kroku w przepływie pracy funkcji GitHub Actions. Ta konfiguracja jest prosta, ponieważ każde wystąpienie klastra jest jasno zdefiniowane w potoku wdrażania. Ta konfiguracja obejmuje pewne nakłady administracyjne związane z dodawaniem i usuwaniem klastrów z wdrożenia.

Inną opcją jest utworzenie logiki biznesowej w celu utworzenia klastrów na podstawie listy żądanych lokalizacji lub innych punktów danych. Na przykład potok wdrażania może zawierać listę żądanych regionów; krok w potoku może następnie wykonać pętlę na tej liście, wdrażając klaster w każdym regionie znajdującym się na liście. Wadą tej konfiguracji jest złożoność uogólniania wdrożenia i że każda sygnatura klastra nie jest jawnie szczegółowa w potoku wdrażania. Pozytywną korzyścią jest to, że dodanie lub usunięcie sygnatur klastra z potoku staje się prostą aktualizacją listy żądanych regionów.

Ponadto usunięcie sygnatury klastra z potoku wdrażania nie zawsze powoduje zlikwidowanie zasobów sygnatury. W zależności od rozwiązania i konfiguracji wdrożenia może być potrzebny dodatkowy krok w celu zlikwidowania wystąpień usługi AKS i innych zasobów platformy Azure. Rozważ użycie stosów wdrażania w celu włączenia pełnego zarządzania cyklem życia zasobów platformy Azure, w tym czyszczenia, gdy nie są już potrzebne.

Uruchamianie klastra

Po wdrożeniu każdego wystąpienia lub sygnatury platformy Kubernetes należy wdrożyć i skonfigurować składniki klastra, takie jak kontrolery ruchu przychodzącego, rozwiązania tożsamości i składniki obciążenia. Należy również rozważyć zastosowanie zasad zabezpieczeń, dostępu i ładu w klastrze.

Podobnie jak w przypadku wdrożenia te konfiguracje mogą stać się trudne do ręcznego zarządzania wieloma wystąpieniami platformy Kubernetes. Zamiast tego należy wziąć pod uwagę następujące opcje konfiguracji i zasad na dużą skalę.

GitOps

Zamiast ręcznie konfigurować składniki platformy Kubernetes, zaleca się stosowanie zautomatyzowanych metod stosowania konfiguracji do klastra Kubernetes, ponieważ te konfiguracje są sprawdzane w repozytorium źródłowym. Ten proces jest często określany jako GitOps, a popularne rozwiązania GitOps dla platformy Kubernetes obejmują rozwiązania Flux i Argo CD. Na przykład rozszerzenie Flux dla usługi AKS umożliwia automatyczne uruchamianie klastrów i natychmiast po wdrożeniu klastrów.

Metodyka GitOps jest bardziej szczegółowa w architekturze referencyjnej punktu odniesienia usługi AKS. Korzystając z podejścia opartego na metodyce GitOps do konfiguracji, upewnij się, że każde wystąpienie kubernetes jest skonfigurowane podobnie bez nakładu pracy na zamówienie. Usprawniony proces konfiguracji staje się jeszcze ważniejszy w miarę wzrostu wielkości floty.

Azure Policy

W miarę dodawania wielu wystąpień platformy Kubernetes korzyść zapewniania ładu, zgodności i konfiguracji opartej na zasadach zwiększa się. Korzystanie z zasad, w szczególności usługi Azure Policy, zapewnia scentralizowaną i skalowalną metodę kontroli klastra. Korzyści wynikające z zasad usługi AKS są szczegółowo opisane w architekturze referencyjnej punktu odniesienia usługi AKS.

Usługa Azure Policy powinna być włączona po utworzeniu klastrów usługi AKS. Inicjatywy powinny być przypisywane w trybie inspekcji, aby uzyskać wgląd w niezgodności. Można również ustawić więcej zasad, które nie są częścią żadnych wbudowanych inicjatyw. Te zasady są ustawiane w trybie odmowy. Istnieją na przykład zasady zapewniające uruchamianie w klastrze tylko zatwierdzonych obrazów kontenerów. Rozważ utworzenie własnych inicjatyw niestandardowych. Połącz zasady, które mają zastosowanie do obciążenia w ramach pojedynczego przypisania.

Zakres zasad odnosi się do celu każdej inicjatywy zasad i zasad. Możesz użyć Bicep, aby przypisać zasady do grupy zasobów, do której wdrożono każdy klaster usługi AKS. Wraz ze wzrostem śladu klastra globalnego powoduje to wiele zduplikowanych zasad. Możesz również ograniczyć zakres zasad do subskrypcji platformy Azure lub grupy zarządzania platformy Azure. Ta metoda umożliwia zastosowanie jednego zestawu zasad do wszystkich klastrów usługi AKS w zakresie subskrypcji lub wszystkich subskrypcji znalezionych w grupie zarządzania.

Podczas projektowania zasad dla wielu klastrów usługi AKS należy wziąć pod uwagę następujące elementy:

• Zastosuj zasady, które powinny być stosowane globalnie do wszystkich wystąpień usługi AKS w grupie zarządzania lub subskrypcji.
• Umieść każdy klaster regionalny we własnej grupie zasobów, co umożliwia zastosowanie zasad specyficznych dla regionu do grupy zasobów.

Zobacz Organizacja zasobów przewodnika Cloud Adoption Framework, aby uzyskać materiały ułatwiające ustanowienie strategii zarządzania zasadami.

Wdrażanie obciążeń

Oprócz konfiguracji wystąpienia usługi AKS należy wziąć pod uwagę obciążenie wdrożone w każdym wystąpieniu regionalnym lub sygnaturze. Rozwiązania wdrażania lub potoki wymagają konfiguracji w celu uwzględnienia każdej sygnatury regionalnej. W miarę dodawania kolejnych sygnatur do klastra globalnego proces wdrażania musi zostać rozszerzony lub musi być wystarczająco elastyczny, aby pomieścić nowe wystąpienia regionalne.

Podczas planowania wdrożenia obciążenia należy wziąć pod uwagę następujące elementy.

• Uogólnij wdrożenie, na przykład za pomocą wykresu programu Helm, aby upewnić się, że pojedyncza konfiguracja wdrożenia może być używana w wielu sygnaturach klastra.
• Użyj jednego potoku ciągłego wdrażania skonfigurowanego do wdrożenia obciążenia we wszystkich sygnaturach klastra.
• Podaj szczegóły wystąpienia specyficzne dla sygnatury jako parametry wdrożenia.
• Rozważ sposób konfigurowania rejestrowania diagnostycznego aplikacji i śledzenia rozproszonego pod kątem możliwości obserwowania w całej aplikacji.

Dostępność i tryb failover

Istotną motywacją do wyboru architektury Kubernetes w wielu regionach jest dostępność usługi. Oznacza to, że jeśli usługa lub składnik usługi staną się niedostępne w jednym regionie, ruch powinien być kierowany do regionu, w którym inne wystąpienie tej usługi jest nadal dostępne. Architektura z wieloma regionami obejmuje wiele różnych punktów awarii. W tej sekcji omówiono każdy z tych potencjalnych punktów awarii.

Błędy zasobnika aplikacji

Obiekt wdrożenia Kubernetes służy do tworzenia zestawu replik, który zarządza wieloma replikami zasobnika. Jeśli jeden zasobnik jest niedostępny, ruch jest kierowany między pozostałymi zasobnikami. Zestaw replik Kubernetes próbuje zachować określoną liczbę replik do uruchomienia. Jeśli jedno wystąpienie ulegnie awarii, nowe wystąpienie powinno zostać utworzone automatycznie. Sondy wydajności mogą służyć do sprawdzania stanu aplikacji lub procesu uruchomionego w zasobniku. Jeśli usługa nie odpowiada, sonda aktualności usuwa zasobnik, co wymusza utworzenie nowego wystąpienia przez zestaw replik.

Aby uzyskać więcej informacji, zobacz Kubernetes ReplicaSet.

Awarie sprzętu centrum danych

Lokalna awaria może wystąpić od czasu do czasu. Na przykład zasilanie może stać się niedostępne dla pojedynczego stojaka serwerów platformy Azure. Aby chronić węzły usługi AKS przed stanie się pojedynczym punktem awarii, użyj stref dostępności platformy Azure. Korzystając ze stref dostępności, upewnij się, że węzły usługi AKS w jednej strefie dostępności są fizycznie oddzielone od tych węzłów zdefiniowanych w innej strefie dostępności.

Aby uzyskać więcej informacji, zobacz AKS i strefy dostępności platformy Azure.

Błędy regionów świadczenia usługi Azure

Gdy cały region stanie się niedostępny, zasobniki w klastrze nie będą już dostępne do obsługi żądań. W takim przypadku usługa Azure Front Door kieruje cały ruch do pozostałych regionów w dobrej kondycji. Klastry i zasobniki Kubernetes w regionach w dobrej kondycji nadal obsługują żądania.

Należy zachować ostrożność w tej sytuacji, aby zrekompensować zwiększone żądania i ruch do pozostałego klastra. Rozważ następujące punkty:

• Upewnij się, że zasoby sieciowe i obliczeniowe mają odpowiedni rozmiar, aby wchłonąć nagły wzrost ruchu z powodu przejścia w tryb failover w regionie. Na przykład w przypadku korzystania z usługi Azure CNI upewnij się, że masz podsieć, która jest wystarczająco duża, aby obsługiwać wszystkie adresy IP zasobników, gdy ruch jest rozszydlony.
• Użyj narzędzia Horizontal Pod Autoscaler, aby zwiększyć liczbę replik zasobników, aby zrekompensować zwiększone zapotrzebowanie regionalne.
• Użyj narzędzia AKS Cluster Autoscaler, aby zwiększyć liczbę węzłów wystąpienia kubernetes w celu zrekompensowania zwiększonego zapotrzebowania regionalnego.

Aby uzyskać więcej informacji, zobacz Horizontal Pod Autoscaler and AKS cluster autoscaler (Narzędzie do automatycznego skalowania zasobników w poziomie) i AKS cluster autoscaler (Skalowanie automatyczne klastra usługi AKS).

Topologia sieci

Podobnie jak w przypadku architektury referencyjnej punktu odniesienia usługi AKS, ta architektura korzysta z topologii sieci piasty i szprych. Oprócz zagadnień określonych w architekturze referencyjnej punktu odniesienia usługi AKS należy wziąć pod uwagę następujące najlepsze rozwiązania:

• Zaimplementuj zestaw sieci wirtualnych piasty i szprych dla każdego regionalnego wystąpienia usługi AKS. W każdym regionie należy połączyć każdą szprychę z siecią wirtualną koncentratora.
• Kierowanie całego ruchu wychodzącego przez wystąpienie usługi Azure Firewall znalezionego w każdej sieci koncentratora regionalnego. Skorzystaj z zasad usługi Azure Firewall Manager, aby zarządzać zasadami zapory we wszystkich regionach.
• Postępuj zgodnie z ustalaniem rozmiaru adresów IP znalezionych w architekturze referencyjnej punktu odniesienia usługi AKS i zezwól na zwiększenie liczby adresów IP dla operacji skalowania węzłów i zasobników w przypadku wystąpienia awarii regionalnej w innym regionie i znacznego wzrostu ruchu do pozostałych regionów.

Zarządzanie ruchem

Dzięki architekturze referencyjnej punktu odniesienia usługi AKS ruch obciążenia jest kierowany bezpośrednio do wystąpienia usługi aplikacja systemu Azure Gateway, a następnie przekazywany do zasobów modułu równoważenia obciążenia zaplecza i ruchu przychodzącego usługi AKS. Podczas pracy z wieloma klastrami żądania klientów są kierowane przez wystąpienie usługi Azure Front Door, które kieruje do wystąpienia usługi aplikacja systemu Azure Gateway.

Pobierz plik programu Visio z tego diagramu.

1. Użytkownik wysyła żądanie do nazwy domeny (takiej jak https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), która jest rozpoznawana jako profil usługi Azure Front Door. To żądanie jest szyfrowane przy użyciu certyfikatu wieloznacznych (*.azurefd.net) wystawionego dla wszystkich domen podrzędnych usługi Azure Front Door. Usługa Azure Front Door weryfikuje żądanie względem zasad zapory aplikacji internetowej, wybiera najszybsze źródło (na podstawie kondycji i opóźnienia) i używa publicznego systemu DNS do rozpoznawania adresu IP pochodzenia (aplikacja systemu Azure wystąpienia bramy).

2. Usługa Azure Front Door przekazuje żądanie do wybranego odpowiedniego wystąpienia usługi Application Gateway, które służy jako punkt wejścia dla sygnatury regionalnej. Ruch przepływa przez Internet. Usługa Azure Front Door zapewnia szyfrowanie ruchu do źródła.

   Rozważ metodę, aby upewnić się, że wystąpienie usługi Application Gateway akceptuje tylko ruch z wystąpienia usługi Front Door. Jedną z metod jest użycie sieciowej grupy zabezpieczeń w podsieci zawierającej usługę Application Gateway. Reguły mogą filtrować ruch przychodzący (lub wychodzący) na podstawie właściwości, takich jak Źródło, Port, Miejsce docelowe. Właściwość Source umożliwia ustawienie wbudowanego tagu usługi wskazującego adresy IP dla zasobu platformy Azure. Ta abstrakcja ułatwia konfigurowanie i konserwację reguły oraz śledzenie adresów IP. Ponadto rozważ użycie nagłówka X-Azure-FDID , który usługa Azure Front Door dodaje do żądania przed wysłaniem go do źródła, aby upewnić się, że wystąpienie usługi Application Gateway akceptuje tylko ruch z wystąpienia usługi Front Door. Aby uzyskać więcej informacji na temat nagłówków usługi Front Door, zobacz Obsługa protokołu dla nagłówków HTTP w usłudze Azure Front Door.

Zagadnienia dotyczące zasobów udostępnionych

Chociaż celem tego scenariusza jest posiadanie wielu wystąpień platformy Kubernetes rozmieszczonych w wielu regionach świadczenia usługi Azure, warto udostępnić niektóre zasoby we wszystkich regionach. Jednym z podejść jest użycie pojedynczego pliku Bicep do wdrożenia wszystkich udostępnionych zasobów, a następnie drugiego w celu wdrożenia każdej sygnatury regionalnej. Ta sekcja zawiera szczegółowe informacje o poszczególnych udostępnionych zasobach i zagadnieniach dotyczących korzystania z nich w wielu wystąpieniach usługi AKS.

Container Registry

Usługa Azure Container Registry jest używana w tej architekturze do świadczenia usług obrazu kontenera. Klaster ściąga obrazy kontenerów z rejestru. Podczas pracy z usługą Azure Container Registry we wdrożeniu klastra z wieloma regionami należy wziąć pod uwagę następujące elementy.

Dostępność geograficzna 

Umieść rejestr kontenerów w każdym regionie, w którym wdrożono klaster usługi AKS. Takie podejście umożliwia wykonywanie operacji sieciowych o małych opóźnieniach, co umożliwia szybkie i niezawodne transfery warstwy obrazów. Oznacza to również, że masz wiele punktów końcowych usługi obrazów, aby zapewnić dostępność, gdy usługi regionalne są niedostępne. Korzystanie z funkcji replikacji geograficznej usługi Azure Container Registry umożliwia zarządzanie jednym rejestrem kontenerów, który jest automatycznie replikowany do wielu regionów.

Rozważ utworzenie pojedynczego rejestru z replikami w każdym regionie świadczenia usługi Azure zawierającym klastry. Aby uzyskać więcej informacji na temat replikacji usługi Azure Container Registry, zobacz Replikacja geograficzna w usłudze Azure Container Registry.

Obraz przedstawiający wiele replik usługi Azure Container Registry z poziomu witryny Azure Portal.

Dostęp do klastra

Każdy klaster usługi AKS wymaga dostępu do rejestru kontenerów, aby mógł ściągać warstwy obrazu kontenera. Istnieje wiele sposobów ustanawiania dostępu do usługi Azure Container Registry. W tej architekturze jest tworzona tożsamość zarządzana dla każdego klastra, który następnie otrzymuje AcrPull rolę w rejestrze kontenerów. Aby uzyskać więcej informacji i rekomendacji dotyczących korzystania z tożsamości zarządzanych na potrzeby dostępu do usługi Azure Container Registry, zobacz architekturę referencyjną punktu odniesienia usługi AKS.

Ta konfiguracja jest definiowana w pliku Bicep sygnatury klastra, dzięki czemu za każdym razem, gdy zostanie wdrożona nowa sygnatura, nowe wystąpienie usługi AKS ma przyznany dostęp. Ponieważ rejestr kontenerów jest zasobem udostępnionym, upewnij się, że wdrożenia zawierają identyfikator zasobu rejestru kontenerów jako parametr.

Azure Monitor

Funkcja Azure Monitor Container Insights jest zalecanym narzędziem do monitorowania i zrozumienia wydajności i kondycji obciążeń klastra i kontenera. Usługa Container Insights korzysta zarówno z obszaru roboczego usługi Log Analytics do przechowywania danych dzienników, jak i metryk usługi Azure Monitor do przechowywania danych szeregów czasowych liczbowych. Metryki rozwiązania Prometheus można również zbierać za pomocą usługi Container Insights, a dane można wysyłać do usługi zarządzanej Azure Monitor dla usługi Prometheus lub Dzienników usługi Azure Monitor. Aby uzyskać więcej informacji, zobacz architekturę referencyjną punktu odniesienia usługi AKS.

Możesz również skonfigurować ustawienia diagnostyczne klastra usługi AKS, aby zbierać i analizować dzienniki zasobów ze składników płaszczyzny sterowania usługi AKS i przekazywać je do obszaru roboczego usługi Log Analytics.

Podczas projektowania rozwiązania do monitorowania dla architektury obejmującej wiele regionów należy wziąć pod uwagę sprzężenie między poszczególnymi sygnaturami. Możesz wdrożyć jeden obszar roboczy usługi Log Analytics współużytkowany przez każdy klaster Kubernetes. Podobnie jak w przypadku innych zasobów udostępnionych, zdefiniuj sygnaturę regionalną, aby korzystać z informacji o jednym udostępnionym globalnie obszarze roboczym usługi Log Analytics i połączyć każdy klaster regionalny z tym jednym udostępnionym obszarem roboczym. Gdy każdy klaster regionalny emituje dzienniki diagnostyczne do tego pojedynczego obszaru roboczego usługi Log Analytics, można używać danych wraz z metrykami zasobów, aby łatwiej tworzyć raporty i pulpity nawigacyjne, które ułatwiają zrozumienie sposobu działania całego rozwiązania z wieloma regionami.

Azure Front Door

Usługa Azure Front Door służy do równoważenia obciążenia i kierowania ruchu do każdego klastra usługi AKS. Usługa Azure Front Door umożliwia również routing globalny warstwy 7. Te możliwości są wymagane w tym scenariuszu.

Konfiguracja klastra

Po dodaniu każdego regionalnego wystąpienia usługi AKS usługa Application Gateway wdrożona obok klastra Kubernetes musi zostać zarejestrowana jako źródło w usłudze Azure Front Door, która udostępnia ją na potrzeby routingu. Ta operacja wymaga aktualizacji infrastruktury jako zasobów kodu. Alternatywnie tę operację można rozdzielić z konfiguracji wdrożenia i zarządzać przy użyciu narzędzi, takich jak interfejs wiersza polecenia platformy Azure.

Certyfikaty

Usługa Azure Front Door nie obsługuje źródeł przy użyciu certyfikatów z podpisem własnym, nawet w środowiskach deweloperskich lub testowych. Aby włączyć ruch HTTPS, należy utworzyć certyfikat TLS/SSL podpisany przez urząd certyfikacji. Aby uzyskać informacje o innych urzędach certyfikacji, które obsługuje usługa Front Door, zobacz Dozwolone urzędy certyfikacji umożliwiające włączanie niestandardowego protokołu HTTPS w usłudze Azure Front Door.

W przypadku testowania lub klastrów nieprodukcyjnych warto rozważyć użycie narzędzia Certbot do utworzenia certyfikatu Let's Encrypt Authority X3 dla każdej bramy aplikacji.

Podczas planowania klastra produkcyjnego użyj preferowanej przez organizację metody pozyskiwania certyfikatów TLS.

Dostęp do klastra i tożsamość

Zgodnie z opisem w architekturze referencyjnej punktu odniesienia usługi AKS zalecamy użycie identyfikatora Entra firmy Microsoft jako dostawcy tożsamości dla klastrów. Grupy Entra firmy Microsoft mogą następnie służyć do kontrolowania dostępu do zasobów klastra.

W przypadku zarządzania wieloma klastrami należy zdecydować się na schemat dostępu. Dostępne opcje:

• Utwórz globalną grupę dostępu obejmującą cały klaster, w której członkowie mogą uzyskiwać dostęp do wszystkich obiektów w każdym wystąpieniu kubernetes w klastrze. Ta opcja zapewnia minimalne potrzeby administracyjne; przyznaje jednak znaczne uprawnienia każdemu członkowi grupy.
• Utwórz pojedynczą grupę dostępu dla każdego wystąpienia platformy Kubernetes używanego do udzielania dostępu do obiektów w pojedynczym wystąpieniu klastra. W przypadku tej opcji obciążenie administracyjne zwiększa się; jednak zapewnia on również bardziej szczegółowy dostęp do klastra.
• Zdefiniuj szczegółowe mechanizmy kontroli dostępu dla typów obiektów i przestrzeni nazw platformy Kubernetes oraz skoreluj wyniki ze strukturą grupy Entra firmy Microsoft. W przypadku tej opcji obciążenie administracyjne znacznie wzrasta; Zapewnia jednak szczegółowy dostęp nie tylko do każdego klastra, ale przestrzeni nazw i interfejsów API platformy Kubernetes znalezionych w każdym klastrze.

Aby uzyskać dostęp administracyjny, rozważ utworzenie grupy Microsoft Entra dla każdego regionu. Udziel każdej grupie pełnego dostępu do odpowiedniej sygnatury klastra w tym regionie. Członkowie każdej grupy mają następnie dostęp administracyjny do odpowiednich klastrów.

Aby uzyskać więcej informacji na temat zarządzania dostępem do klastra usługi AKS przy użyciu identyfikatora Entra firmy Microsoft, zobacz Integracja usługi AKS Firmy Microsoft.

Dane, stan i pamięć podręczna

W przypadku korzystania z globalnie rozproszonego zestawu klastrów usługi AKS należy wziąć pod uwagę architekturę aplikacji, procesu lub innych obciążeń, które mogą być uruchamiane w klastrze. Jeśli obciążenia oparte na stanie są rozłożone w klastrach, czy muszą uzyskać dostęp do magazynu stanów? Jeśli proces jest ponownie utworzony w innym miejscu w klastrze z powodu awarii, czy obciążenie lub proces nadal ma dostęp do zależnego magazynu stanów lub rozwiązania buforowania? Stan można przechowywać na wiele sposobów, ale jest złożony do zarządzania nawet w jednym klastrze Kubernetes. Złożoność zwiększa się podczas dodawania wielu klastrów Kubernetes. Ze względu na regionalny dostęp i złożoność należy rozważyć zaprojektowanie aplikacji w celu korzystania z globalnie rozproszonej usługi magazynu stanów.

Projekt tej architektury nie obejmuje konfiguracji dla kwestii dotyczących stanu. Jeśli uruchamiasz jedną aplikację logiczną w wielu klastrach usługi AKS, rozważ utworzenie architektury obciążenia w celu korzystania z globalnie rozproszonej usługi danych, takiej jak Azure Cosmos DB. Azure Cosmos DB to globalnie rozproszony system baz danych, który umożliwia odczytywanie i zapisywanie danych z lokalnych replik bazy danych, a usługa Cosmos DB zarządza replikacją geograficzną. Aby uzyskać więcej informacji, zobacz Azure Cosmos DB.

Jeśli obciążenie korzysta z rozwiązania buforowania, upewnij się, że utworzysz architekturę usług buforowania, aby zachować funkcjonalność nawet podczas zdarzeń trybu failover. Upewnij się, że obciążenie jest odporne na przejście w tryb failover związane z pamięcią podręczną i że rozwiązania buforowania są obecne we wszystkich regionalnych wystąpieniach usługi AKS.

Optymalizacja kosztów

Skorzystaj z kalkulatora cen platformy Azure, aby oszacować koszty usług używanych w architekturze. Inne najlepsze rozwiązania opisano w sekcji Optymalizacja kosztów w witrynie Microsoft Azure Well-Architected Framework i określonych opcji konfiguracji optymalizacji kosztów w artykule Optymalizowanie kosztów .

Rozważ włączenie analizy kosztów usługi AKS dla szczegółowej alokacji kosztów infrastruktury klastra według konstrukcji specyficznych dla platformy Kubernetes.

Następne kroki

• Strefy dostępności usługi AKS
• Azure Kubernetes Fleet Manager
• Replikacja geograficzna w usłudze Azure Container Registry
• Sparowane regiony platformy Azure

Powiązane zasoby

• Przegląd platformy Azure Well-Architected Framework dla usługi Azure Kubernetes Service (AKS)
• Architektura linii bazowej dla klastra usługi Azure Kubernetes Service (AKS)
• Potok ciągłej integracji/ciągłego wdrażania dla obciążeń opartych na kontenerach
• Integracja usługi AKS firmy Microsoft Entra
• Dokumentacja usługi Azure Front Door
• Dokumentacja usługi Azure Cosmos DB