Punkt odniesienia usługi AKS dla klastrów wieloregionowych

Ta architektura referencyjna 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. Zaleca się 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ą.

Implementacja referencyjna tej architektury jest dostępna w witrynie GitHub.

Elementy

Wiele składników i usług platformy Azure jest używanych w architekturze referencyjnej usługi AKS w wielu regionach. Poniżej wymieniono tylko te składniki o unikatowości tej architektury wielu klastrów. W przypadku pozostałych odwołaj się do architektury punktu odniesienia usługi AKS.

• Wdrożono wiele klastrów/wielu regionów 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.
• sieć piasty i szprych na region Pary sieci piasty i szprych są wdrażane dla każdego regionalnego wystąpienia usługi AKS. Zasady usługi Azure Firewall Manager służą do zarządzania zasadami zapory we wszystkich regionach.
• Magazyn kluczy regionalnych usługi Azure Key Vault jest aprowizowany w każdym regionie na potrzeby przechowywania poufnych wartości i kluczy specyficznych dla wystąpienia usługi AKS i usług pomocniczych znalezionych w tym regionie.
• Usługa Azure Front Door 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 siedem, z których oba są wymagane dla tej architektury referencyjnej.
• Regionalne wystąpienia usługi Log Analytics usługi Log Analytics służą 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.
• Container registry 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 referencyjna używa dwóch wzorców projektowych chmury. Węzeł geograficzny (geody), w którym dowolny region może obsłużyć dowolne żądanie, oraz sygnatury wdrożenia, w których wiele niezależnych kopii aplikacji lub składnika aplikacji jest wdrażanych z jednego źródła (szablon wdrożenia).

Zagadnienia dotyczące wzorca węzła geograficznego

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 klastrem usługi AKS w wielu regionach wiele wystąpień usługi AKS jest wdrażanych w wielu regionach. Każde z tych wystąpień jest uznawane za sygnaturę. W przypadku awarii regionalnej lub konieczności dodania większej pojemności i / lub obecności regionalnej dla klastra 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ę, taką jak infrastruktura jako kod
• Podawanie wartości specyficznych dla wystąpienia przy użyciu mechanizmu wejściowego wdrożenia, takiego jak zmienne lub pliki parametrów
• Wybieranie narzędzi 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
• 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ć widoczność i/lub monitorować kolekcję sygnatur jako pojedynczą jednostkę.

Każdy z tych elementów zawiera szczegółowe wskazówki w poniższych sekcjach tej architektury referencyjnej.

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. Warto rozważyć strategie skalowania w górę i w miejscu, dodając lub usuwając inne wystąpienia platformy Kubernetes. Chcesz, aby projekt oraz plan wdrażania i konfiguracji uwzględniał awarie regionalne lub 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ł programu Azure PowerShell to wszystkie przyzwoite opcje wdrażania pojedynczych lub nieprzywią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 szansę na chybiłą konfigurację z powodu nieodebranych kroków lub niedostępnych opcji konfiguracji. Ponadto wdrożenie i konfiguracja wielu klastrów korzystających z portalu jest odpowiednim procesem wymagającym skupienia się na co najmniej jednym inżynierze. Można 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 szablony usługi Azure Resource Manager, szablony Bicep lub konfiguracje narzędzia Terraform. Infrastruktura jako rozwiązania kodu zapewniają zautomatyzowane, skalowalne i idempotentne rozwiązanie wdrażania. Ta architektura referencyjna obejmuje szablon usługi ARM dla usług udostępnionych rozwiązań, a następnie inny dla klastrów AKS i 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, takich jak w przypadku wdrożenia statycznej/stałej liczby wystąpień usługi AKS, obciążenie związane z infrastrukturą, ponieważ kod może przewyższać korzyści. W takich przypadkach użycie bardziej imperatywnego podejścia, takiego jak narzędzia wiersza polecenia, a nawet podejście ręczne, jest ok.

Wdrażanie klastra

Po zdefiniowaniu definicji sygnatury klastra istnieje wiele opcji wdrażania pojedynczych lub wielu wystąpień sygnatur. 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 kodem/kontrolą źródła wdrożenia
• Historia wdrożenia i rejestrowanie

Gdy nowe sygnatury są dodawane lub usuwane z klastra globalnego, potok wdrażania musi być aktualizowany, aby zachować spójność. W implementacji referencyjnej każdy region jest wdrażany jako pojedynczy krok w przepływie pracy akcji usługi GitHub (przykład). Ta konfiguracja jest prosta w tym, że 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 użycie logiki do tworzenia klastrów na podstawie listy żądanych lokalizacji lub innych wskazujących punkty 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 musi mieć pewność, że został również zlikwidowany. W zależności od rozwiązania i konfiguracji wdrożenia może być potrzebny dodatkowy krok, aby upewnić się, że wystąpienia usługi AKS zostały odpowiednio zlikwidowane.

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 Kubernetes, rozważ użycie 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. Ta implementacja używa rozszerzenia Flux dla usługi AKS, aby umożliwić 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. Ważnym punktem jest to, że użycie podejścia opartego na metodyce GitOps do konfiguracji pomaga zapewnić, że każde wystąpienie Kubernetes jest skonfigurowane podobnie bez nakładu pracy na zamówienie. Staje się to jeszcze ważniejsze 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 jest włączona w tej implementacji referencyjnej podczas tworzenia klastrów usługi AKS i przypisuje restrykcyjną inicjatywę w trybie inspekcji, aby uzyskać wgląd w niezgodność. Implementacja określa również 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, że w klastrze są uruchamiane tylko zatwierdzone obrazy 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. Implementacja referencyjna skojarzona z tą architekturą używa szablonu usługi ARM do przypisywania zasad do grupy zasobów, do której jest wdrażany 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 i/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:

• Zasady, które powinny być stosowane globalnie do wszystkich wystąpień usługi AKS, można zastosować do grupy zarządzania lub subskrypcji
• Umieszczenie każdego klastra regionalnego we własnej grupie zasobów umożliwia stosowanie zasad specyficznych dla regionu do grupy zasobów

Zobacz Organizacja zasobów przewodnika Cloud Adoption Framework, aby uzyskać materiały, które pomogą Ci ustanowić strategię 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 będą wymagały konfiguracji, aby uwzględnić każdą sygnaturę regionalną. W miarę dodawania kolejnych sygnatur do klastra globalnego proces wdrażania musi zostać rozszerzony lub 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 ta usługa jest dostępna. Architektura z wieloma regionami obejmuje wiele różnych punktów awarii. W tej sekcji omówiono każdy z tych potencjalnych punktów awarii.

Zasobniki aplikacji (regionalne)

Obiekt wdrożenia platformy Kubernetes służy do tworzenia wielu replik zasobnika (ReplicaSet). Jeśli jeden jest niedostępny, ruch jest kierowany między pozostałymi. Zestaw replik Kubernetes próbuje zachować określoną liczbę replik do uruchomienia. Jeśli jedno wystąpienie ulegnie awarii, należy ponownie utworzyć nowe wystąpienie. Na koniec 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 usunie zasobnik, co wymusza utworzenie nowego wystąpienia przez zestaw replik.

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

Zasobniki aplikacji (globalne)

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

Należy zachować ostrożność w tej sytuacji, aby zrekompensować zwiększony ruch /żądania do pozostałego klastra. Kilka kwestii, które należy wziąć pod uwagę:

• 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 może obsługiwać wszystkie adresy IP zasobników z gwałtownym obciążeniem ruchem.
• Użyj narzędzia Horizontal Pod Autoscaler, aby zwiększyć liczbę replik zasobników, aby zrekompensować zwiększone zapotrzebowanie regionalne.
• Użyj narzędzia automatycznego skalowania klastra usługi AKS, 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).

Pule węzłów kubernetes (regionalne)

Czasami zlokalizowane awarie mogą wystąpić w przypadku zasobów obliczeniowych, na przykład jeśli moc stanie się niedostępna dla pojedynczego stojaka serwerów platformy Azure. Aby chronić węzły usługi AKS przed stanie się awarią regionalną pojedynczego punktu, skorzystaj ze stref dostępności platformy Azure. Użycie stref dostępności zapewnia, że węzły usługi AKS w danej strefie dostępności są fizycznie oddzielone od tych zdefiniowanych w innej strefie dostępności.

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

Pule węzłów platformy Kubernetes (globalne)

W przypadku całkowitej awarii regionalnej usługa Azure Front Door będzie kierować ruch do pozostałych i w dobrej kondycji regionów. Ponownie należy zachować ostrożność w tej sytuacji, aby zrekompensować zwiększony ruch / żądania do pozostałego klastra.

Aby uzyskać więcej informacji, zobacz Azure Front Door.

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 szprychę piasty dla każdego regionalnego wystąpienia usługi AKS, w którym sieci wirtualne piasty i szprych są równorzędne.
• 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 więcej adresów IP dla operacji skalowania węzłów i zasobników, jeśli wystąpi awaria regionalna.

Zarządzanie ruchem

W 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 przychodzących modułu równoważenia obciążenia zaplecza/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.azurefd.net), która jest rozpoznawana w wystąpieniu 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. Wystąpienie usługi Azure Front Door weryfikuje żądanie względem zasad zapory aplikacji internetowej, wybiera najszybsze zaplecze (na podstawie kondycji i opóźnienia) i używa publicznego systemu DNS do rozpoznawania adresu IP zaplecza (aplikacja systemu Azure wystąpienia bramy).

2. Usługa 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 i jest szyfrowany przez usługę Azure Front Door. 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 usługi Front Door do zaplecza X-Azure-FDID , 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 tej architektury referencyjnej jest posiadanie wielu wystąpień platformy Kubernetes rozmieszczonych w wielu regionach świadczenia usługi Azure, warto mieć pewne współdzielone zasoby we wszystkich wystąpieniach. Implementacja referencyjna wielu regionów usługi AKS przy użyciu pojedynczego szablonu usługi ARM w celu wdrożenia wszystkich udostępnionych zasobów, a następnie innego 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 referencyjnej do dostarczania usług obrazów kontenera (ściąganie). 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 

Pozycjonowanie rejestru kontenerów w każdym regionie, w którym wdrożony jest klaster usługi AKS, umożliwia szybkie i niezawodne transfery warstwy obrazów w sieci. Mieć 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 rejestrów kontenerów platformy Azure umożliwia zarządzanie jednym wystąpieniem usługi Container Registry replikowanym do wielu regionów.

Implementacja referencyjna usługi AKS w wielu regionach utworzyła pojedyncze wystąpienie usługi Container Registry i repliki tego wystąpienia w każdym regionie klastra. 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 ACR z poziomu witryny Azure Portal.

Dostęp do klastra

Każde wystąpienie usługi AKS wymaga dostępu do ściągania warstw obrazu z usługi Azure Container Registry. Istnieje wiele sposobów ustanawiania dostępu do usługi Azure Container Registry; Ta architektura referencyjna używa tożsamości zarządzanej platformy Azure dla każdego klastra, który następnie otrzymuje rolę AcrPull w wystąpieniu usługi Container Registry. Aby uzyskać więcej informacji i rekomendacji dotyczących używania tożsamości zarządzanych na potrzeby dostępu do usługi Container Registry, zobacz architekturę referencyjną punktu odniesienia usługi AKS.

Ta konfiguracja jest definiowana w szablonie usługi ARM sygnatury klastra, dzięki czemu za każdym razem, gdy zostanie wdrożona nowa sygnatura, nowe wystąpienie usługi AKS ma dostęp. Ponieważ usługa Container Registry jest zasobem udostępnionym, upewnij się, że szablon sygnatury wdrożenia może korzystać z niezbędnych szczegółów, w tym przypadku identyfikator zasobu rejestru kontenerów.

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ć przez usługę Container Szczegółowe informacje i wysyłać dane do usługi zarządzanej Azure Monitor dla usługi Prometheus lub Dzienników usługi Azure Monitor.

Możesz również skonfigurować ustawienia diagnostyczne klastra usługi AKS w celu zbierania i analizowania dzienników zasobów ze składników płaszczyzny sterowania usługi AKS i przekazywania ich do obszaru roboczego usługi Log Analytics.

Usługa AKS Aby uzyskać więcej informacji, zobacz architekturę referencyjną punktu odniesienia usługi AKS.

Podczas rozważania monitorowania implementacji między regionami, takiej jak ta architektura referencyjna, należy wziąć pod uwagę sprzężenie między poszczególnymi sygnaturami. W takim przypadku należy rozważyć każdy sygnatura składnika pojedynczej jednostki (klastra regionalnego). Implementacja referencyjna usługi AKS w wielu regionach korzysta z jednego obszaru roboczego usługi Log Analytics współużytkowanego przez każdy klaster Kubernetes. Podobnie jak w przypadku innych zasobów udostępnionych, zdefiniuj sygnaturę regionalną, aby korzystać z informacji o pojedynczym obszarze roboczym usługi Log Analytics i połączyć z nim każdy klaster.

Teraz, gdy każdy klaster regionalny emituje dzienniki diagnostyczne do jednego obszaru roboczego usługi Log Analytics, te dane wraz z metrykami zasobów mogą służyć do łatwiejszego tworzenia raportów i pulpitów nawigacyjnych reprezentujących cały klaster globalny.

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 routing globalny warstwy siedem, z których oba są wymagane dla tej architektury referencyjnej.

Konfiguracja klastra

W miarę dodawania regionalnych wystąpień usługi AKS usługa Application Gateway wdrożona obok klastra Kubernetes musi zostać zarejestrowana jako zaplecze usługi Front Door w celu odpowiedniego routingu. Ta operacja wymaga aktualizacji infrastruktury jako zasobów kodu. Alternatywnie tę operację można rozdzielić z konfiguracji wdrożenia i zarządzać nimi za pomocą narzędzi, takich jak interfejs wiersza polecenia platformy Azure. Dołączony potok wdrażania implementacji odwołań korzysta z odrębnego kroku interfejsu wiersza polecenia platformy Azure dla tej operacji.

Certyfikaty

Usługa Front Door nie obsługuje certyfikatów z podpisem własnym nawet w środowiskach tworzenia i testowania. Aby włączyć ruch HTTPS, należy utworzyć certyfikat TLS/SSL podpisany przez urząd certyfikacji. Implementacja referencyjna używa narzędzia Certbot do utworzenia certyfikatu Let's Encrypt Authority X3. Podczas planowania klastra produkcyjnego użyj preferowanej przez organizację metody pozyskiwania certyfikatów TLS.

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.

Dostęp do klastra i tożsamość

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

Podczas zarządzania wieloma klastrami należy zdecydować o schemacie 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 usługi Azure Directory. 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 Kubernetes znalezionych w każdym klastrze.

W przypadku dołączonej implementacji referencyjnej dwie grupy firmy Microsoft Entra są tworzone na potrzeby dostępu administratora. Te grupy są określane w czasie wdrażania sygnatury klastra przy użyciu pliku parametrów wdrożenia. Członkowie każdej grupy mają pełny dostęp do odpowiedniej sygnatury klastra.

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 klastra wystąpień usługi AKS należy wziąć pod uwagę architekturę aplikacji, procesu lub innych obciążeń, które mogą być uruchamiane w klastrze. W miarę rozprzestrzeniania się obciążenia opartego na stanie w klastrze będzie konieczne uzyskanie dostępu do magazynu stanów? Jeśli proces jest ponownie utworzony w innym miejscu w klastrze z powodu awarii, czy obciążenie lub proces będzie nadal mieć dostęp do zależnego magazynu stanów lub rozwiązania buforowania? Stan można osiągnąć na wiele sposobów; jednak może być złożony w jednym klastrze Kubernetes. Złożoność zwiększa się podczas dodawania wielu klastrowanych wystąpień 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.

Implementacja referencyjna z wieloma klastrami nie obejmuje demonstracji ani konfiguracji dla problemów ze stanem. Jeśli uruchamiasz aplikacje w klastrowanych wystąpieniach 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 bazy danych, który umożliwia odczytywanie i zapisywanie danych w lokalnych replikach bazy danych. Aby uzyskać więcej informacji, zobacz Azure Cosmos DB.

Jeśli obciążenie korzysta z rozwiązania buforowania, upewnij się, że jest ona zaprojektowana tak, aby usługi buforowania pozostały funkcjonalne. W tym celu upewnij się, że obciążenie jest odporne na tryb failover związany 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 na potrzeby szczegółowej alokacji kosztów infrastruktury klastra według określonych konstrukcji 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