Punkt odniesienia usługi AKS dla klastrów wieloregionowych

Azure Kubernetes Service (AKS)

Azure Front Door

Usługa Azure Application Gateway

Azure Container Registry

Azure Firewall

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 unikatowe dla tej architektury wielu klastrów. W przypadku pozostałych informacji zapoznaj się z architekturą punktu odniesienia usługi AKS.

regionalnych klastrów usługi AKS: wdrożono wiele klastrów 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 pozostałego regionu znajdującego się najbliżej użytkownika, który wystawił żądanie.
Regionalne sieci piasty i szprych:Regionalna sieć wirtualna piasty i szprych jest wdrażana dla każdego regionalnego wystąpienia usługi AKS. zasady usługi Azure Firewall Manager są używane do zarządzania zasadami zapory we wszystkich regionach.
regionalnym magazynie kluczy: usługi 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: regionalnych obszarów roboczych 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.
Flota usługi AKS: Usługa Azure Kubernetes Fleet Manager jest wdrażana w celu koordynowania aktualizacji wersji klastra Kubernetes i aktualizacji wersji obrazu węzła w każdym z regionalnych klastrów usługi AKS.
Klaster centrum Fleet Hub (zarządzany przez firmę Microsoft):opcjonalnie można wdrożyć pojedynczy klaster koncentratora usługi Azure Kubernetes Fleet Manager w celu obsługi określonych funkcji floty, takich jak propagacja obciążeń. Klaster piasty to regionalnie o określonym zakresie zasób platformy Azure, który ułatwia zarządzanie propagacją obciążenia i równoważeniem obciążenia w wielu klastrach członkowskich. Najlepiej wdrożyć klaster koncentratora jako klaster koncentratora prywatnego, który musi być dostępny z klastrów członkowskich, aby obsługiwać sygnały pulsu i wykonywać procesy uzgadniania konfiguracji.
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 Azure Application 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 platformy Azure i zapewnienie ciągłego dostępu do obrazów, nawet jeśli w regionie występuje awaria.

Alternatywy

To rozwiązanie korzysta z usługi Azure Kubernetes Fleet Manager. Floty umożliwiają szereg możliwości zarządzania wieloma klastrami, koncentrując się na usprawnieniu operacji dnia 2, zapewniając płaszczyznę sterowania, która może organizować działania w wielu klastrach. Korzyści wynikające z usługi Fleet Manager zwiększają się wraz ze wzrostem liczby klastrów w twojej flocie.

W tym rozwiązaniu flota organizuje aktualizacje wersji rozwiązania Kubernetes w wielu klastrach, a także aktualizacje wersji obrazu węzła. Te możliwości nie wymagają wdrożenia klastra koncentratora. Każdy klaster może niezależnie wykonywać aktualizacje wersji i obrazu węzła platformy Kubernetes, co nie wymaga floty. Jeśli jednak to zrobisz, klastry prawdopodobnie będą otrzymywać aktualizacje wersji w różnym czasie i mogą być trudne do zweryfikowania obciążenia i konfiguracji z wieloma wersjami w środowisku produkcyjnym jednocześnie.

Opcjonalnie możesz również użyć floty na potrzeby koordynacji wdrażania obciążeń, co wymaga dodania klastra koncentratora. W dalszej części tego artykułu omówiono wdrożenia obciążeń.

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.

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.

Po utworzeniu klastra należy zarejestrować go w floty jako klaster członkowski. Ten krok można wykonać, wdrażając zasób usługi Resource Manager typu Microsoft.ContainerService/fleets/members, który odwołuje się do identyfikatora zasobu klastra członkowskiego. Po zarejestrowaniu klastra członkowskiego w flocie można dodać go do przebiegów aktualizacji i użyć innych skonfigurowanych funkcji floty.

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. Może być konieczne utworzenie przestrzeni nazw platformy Kubernetes, a także rozważ zastosowanie zasad zabezpieczeń, dostępu i ładu w klastrze. Te operacje są określane jako bootstrapping klastra w celu przygotowania do obciążeń, które zostaną wdrożone w nim.

Podobnie jak w przypadku wdrożenia, konfiguracje uruchamiania mogą stać się trudne do ręcznego zarządzania między kilkoma wystąpieniami platformy Kubernetes. Jeśli używasz klastra koncentratora z usługą Azure Kubernetes Fleet Manager, możesz wdrożyć niektóre konfiguracje bootstrappingu w całej flocie, takie jak przestrzenie nazw. Jednak inne składniki uruchamiania wymagają innego podejścia do wdrażania.

Należy rozważyć jedną z następujących opcji stosowania konfiguracji i zasad bootstrap na dużą skalę.

GitOps

Zamiast ręcznie konfigurować składniki Kubernetes w każdym klastrze, 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.

Aby wdrożyć konfigurację klastra podstawowego, można użyć metodyki GitOps. Klaster można zarejestrować w floty, aby uczestniczyć w działaniach obejmujących całą flotę, takich jak automatyczne wprowadzanie uaktualnień.

Opcjonalnie możesz również użyć metodyki GitOps do wdrożenia obciążeń. Aby dowiedzieć się więcej, zobacz sekcję dotyczącą wdrażania obciążeń poniżej.

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.

Rejestracja floty

Po wdrożeniu i skonfigurowaniu klastra należy zarejestrować go w floty jako klaster członkowski. Każdy klaster członkowski można przypisać do grupy aktualizacji, która może służyć jako część strategii aktualizacji w celu określenia, gdzie w aktualizacji jest aktualizowany klaster. Aby dowiedzieć się więcej na temat strategii rejestracji, grup i aktualizacji klastra, zobacz Definiowanie strategii aktualizacji wielokrotnego użytku przy użyciu usługi Azure Kubernetes Fleet Manager.

Wdrażanie obciążeń

Każdy klaster usługi AKS w architekturze uruchamia aplikacje, które obsługują obciążenie. Ważne jest, aby zaplanować wdrażanie i uaktualnianie składników obciążenia w bezpieczny i kontrolowany sposób oraz zachowanie spójności wersji aplikacji między poszczególnymi klastrami. W związku z tym oprócz konfiguracji wystąpienia usługi AKS należy wziąć pod uwagę obciążenia, które są wdrażane w każdym wystąpieniu regionalnym lub sygnaturze. Rozwiązania lub potoki wdrażania wymagają konfiguracji, aby uwzględnić każdą sygnaturę regionalną. 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.

Istnieje kilka metod wdrażania, które można wziąć pod uwagę, w tym:

Rurociągów: W przypadku scenariuszy z niewielką liczbą klastrów i stosunkowo niewielu prostych wdrożeń często najlepiej używać lekkich potoków ciągłego ciągłego dostarczania (CD).

Pojedynczy potok zwykle wdraża obciążenie w co najmniej jednym klastrze. Takie podejście minimalizuje nakłady pracy operacyjnej i pozostaje możliwe do zarządzania w środowiskach o niskiej skali. Podczas przechodzenia z modelu pojedynczego klastra do kilku klastrów możesz rozwijać już utworzone potoki wdrażania.
Propagacja obciążenia usługi Azure Kubernetes Fleet Manager: Propagacja obciążenia floty upraszcza zadanie organizowania definicji obciążeń w wielu klastrach członkowskich z scentralizowanej płaszczyzny sterowania. Floty obsługują niezawodne i skalowalne podejście do wdrożeń obciążeń, co pozwala na dużą liczbę obciążeń i klastrów członkowskich.

Propagacja obciążenia wymaga użycia klastra koncentratora, który jest klastrem AKS zarządzanym przez firmę Microsoft, który pomaga śledzić oczekiwany stan klastrów członkowskich. Ten klaster piasty jest zasobem regionalnym. Jeśli regionalna awaria wpłynie na klaster koncentratora, propagacja obciążenia może spowodować tymczasowe zakłócenia.
GitOps: W miarę rozwoju infrastruktury wdrażanie strategii opartej na metodyce GitOps staje się coraz bardziej korzystne. Usługa GitOps umożliwia deklaratywne, inspekcje i mechanizmy wdrażania oparte na ściąganiu, oferując skalowalność, ład i współpracę zespołową. Przejście do tego modelu jest szczególnie zalecane w przypadku zarządzania dużą i dynamiczną flotą klastrów w wielu regionach.

Aby dowiedzieć się więcej, zobacz GitOps dla usługi Azure Kubernetes Service.

Aby zdecydować, które podejście ma sens w twoim rozwiązaniu, rozważ następujące pytania:

Czy oczekujesz, że liczba klastrów pozostanie stała lub zwiększa się wraz z upływem czasu? Jeśli planujesz rozszerzyć liczbę klastrów lub jeśli planujesz dynamiczne dostosowywanie liczby klastrów, może to szybko stać się nieswoje, aby zachować konfigurację każdego klastra w potokach wdrażania.
Ile jednostek z możliwością wdrożenia trzeba zarządzać? Jeśli masz niewielką liczbę aplikacji monolitycznych, masz tylko niewielką liczbę pojedynczych wdrożeń do koordynowania. Jeśli jednak masz architekturę opartą na mikrousługach rozproszonych, dużą liczbę obciążeń lub obie te elementy. dzięki temu można szybko rozwijać się w setki jednostek, które można wdrożyć. Tworzenie potoku dla każdego wdrożenia może stać się niewykonalne.
Jakiego rodzaju strategie wdrażania są potrzebne? Typowe strategie obejmują aktualizacje stopniowe, wdrożenia niebiesko-zielone i wdrożenia kanary. Niektóre podejścia wdrażania muszą umożliwiać "czas pieczenia" między wdrożeniami, przy bliskim monitorowaniu, aby sprawdzić wszelkie regresje wprowadzone przez wdrożenie. Oceń każde podejście wdrażania, aby określić, czy spełnia określone wymagania.
Jakie ograniczenia zabezpieczeń sieci działają w klastrach? Usługa Azure Kubernetes Fleet Manager działa w topologii klastra piasty i szprych, gdzie klastry członkowskie utrzymują połączenia wychodzące z centralnym klastrem koncentratora na potrzeby uzgadniania obciążenia i monitorowania pulsu. Strategia oparta na metodyce GitOps wymaga od uczestniczących klastrów ustanowienia dostępu wychodzącego do repozytorium Git. W przypadku korzystania z potoków agent potoku zwykle wymaga łączności z każdym klastrem w celu wykonywania operacji wdrażania.

Niezależnie od sposobu organizowania wdrożeń, należy uogólnić każde 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 klastrach (sygnaturach). Należy również rozważyć sposób konfigurowania rejestrowania diagnostycznego aplikacji i śledzenia rozproszonego pod kątem możliwości obserwowania całej aplikacji w każdym klastrze.

Niezawodność

Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Design review checklist for Reliability(Lista kontrolna dotycząca niezawodności).

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.

Diagram architektury przedstawiający ruch obciążeń we wdrożeniu w wielu regionach.

Pobierz plik programu Visio z tego diagramu.

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).
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.

Rejestr kontenerów

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.

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

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.

Usługa 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.

Bezpieczeństwo

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotyczącazabezpieczeń.

Kontrola dostępu do klastra

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.

Bezpieczeństwo zasobów floty

Jeśli używasz floty do scentralizowanego aspektu zarządzania klastrem, ważne jest, aby chronić zasoby floty w celu uniknięcia nieprawidłowego użycia. Zasoby floty używają kontroli dostępu opartej na rolach platformy Azure i można udzielić uprawnień floty do ograniczonego zestawu administratorów. Przestrzegaj zasady najniższych uprawnień i udzielaj najmniejszego możliwego dostępu do zasobu floty ( płaszczyzny sterowania floty).

Jeśli flota korzysta z klastra koncentratora, rozważ następujące dodatkowe zalecenia:

Oceń przypisania ról tworzone w klastrze centrum (przypisania ról płaszczyzny danych ). Te przypisania ról zapewniają dostęp do zasobów platformy Kubernetes tworzonych przez flotę. Zakres przypisań ról do pojedynczej przestrzeni nazw Kubernetes tam, gdzie to możliwe.
Użyj klastra centrum prywatnego, aby ograniczyć łączność z Internetem. Upewnij się jednak, że architektura sieci umożliwia klastrom członkowskim dotarcie do klastra koncentratora.

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.

Doskonałość operacyjna

Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.

Jeśli pracujesz w środowisku wieloklasowym z zasobem floty, monitorowanie staje się trudniejsze. Podobnie rozważ koordynowanie aktualizacji składników klastra usługi AKS.

Monitorowanie klastrów i obciążeń

Ręczne przeglądanie pulpitów nawigacyjnych i dzienników może stać się trudne w miarę wzrostu liczby klastrów, dlatego rozważ systematyczne agregowanie dzienników i metryk.

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.

Aby dowiedzieć się więcej na temat konfigurowania obszarów roboczych usługi Azure Monitor w środowisku wieloklasowym, zobacz Azure Monitor.

Monitorowanie operacji floty

Gdy program Fleet Manager organizuje przebieg aktualizacji, możesz monitorować postęp przebiegu w miarę postępu w klastrach. Dane są przechowywane w usłudze Azure Resource Graph i można je eksportować do usługi Azure Monitor na potrzeby alertów i magazynowania.

Jeśli zdecydujesz się użyć rozwiązania Fleet Manager do propagacji obciążenia, możesz monitorować wdrożenie przy użyciu witryny Azure Portal lub narzędzia kubectl.

Możesz również zbierać dzienniki zasobów z zasobu floty i przekazywać je do obszaru roboczego usługi Log Analytics.

Stosowanie aktualizacji w całej flocie

W tej architekturze referencyjnej rozwiązanie Fleet Manager stosuje aktualizacje wersji platformy Kubernetes i aktualizacje obrazów węzłów w całej floty. Możesz określić strategie uaktualniania, które konfigurują sposób wdrażania uaktualnień w klastrach. Ponadto usługa Fleet Manager szanuje okna obsługi w każdym klastrze, dlatego dobrym rozwiązaniem jest ustawienie okien obsługi odpowiednich dla każdego klastra. Okna obsługi w każdym klastrze mogą się różnić w przypadku używania klastrów w wielu lokalizacjach geograficznych i w związku z tym w różnych strefach czasowych.

Aby uzyskać więcej informacji, zobacz Aktualizowanie obrazów platformy Kubernetes i węzłów w wielu klastrach członkowskich.

Optymalizacja kosztów

Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dlaoptymalizacji 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.