Omówienie rozwiązania typu passive-cold dla usługi Azure Kubernetes Service (AKS)

Podczas tworzenia aplikacji w Azure Kubernetes Service (AKS) i wyboru regionu Azure przy tworzeniu zasobów, aplikacja działa w jednym regionie. Gdy region stanie się niedostępny podczas awarii, aplikacja stanie się również niedostępna. Jeśli tworzysz identyczne wdrożenie w regionie pomocniczym platformy Azure, aplikacja stanie się mniej podatna na awarię w jednym regionie, co gwarantuje ciągłość działania, a każda replikacja danych w regionach umożliwia odzyskanie ostatniego stanu aplikacji.

W tym przewodniku opisano pasywne-zimne rozwiązanie dla usługi AKS. W tym rozwiązaniu wdrażamy dwa niezależne i identyczne klastry usługi AKS w dwóch sparowanych regionach platformy Azure z tylko jednym klastrem aktywnie obsługującym ruch, gdy aplikacja jest potrzebna.

Omówienie rozwiązania pasywnego chłodzenia

W tym podejściu mamy dwa niezależne klastry usługi AKS wdrażane w dwóch regionach świadczenia usługi Azure. Gdy aplikacja jest potrzebna, aktywujemy pasywny klaster w celu odbierania ruchu. Jeśli pasywny klaster ulegnie awarii, musimy ręcznie aktywować zimny klaster, aby przejąć przepływ ruchu. Ten warunek można ustawić za pomocą ręcznego wprowadzania danych wejściowych za każdym razem lub określenia określonego zdarzenia.

Scenariusze i konfiguracje

To rozwiązanie najlepiej zaimplementować jako obciążenie "użyj zgodnie z potrzebami", co jest przydatne w scenariuszach wymagających uruchamiania obciążeń o określonych porach dnia lub uruchamianiu na żądanie. Przykładowe przypadki użycia podejścia pasywno-zimnego obejmują:

• Firma produkcyjna, która musi uruchomić złożoną i intensywnie obciążającą zasoby symulację na dużym zestawie danych. W takim przypadku pasywny klaster znajduje się w regionie chmury, który oferuje usługi obliczeniowe i magazynowe o wysokiej wydajności. Klaster pasywny jest używany tylko wtedy, gdy symulacja jest wyzwalana przez użytkownika lub zgodnie z harmonogramem. Jeśli klaster nie działa po wyzwoleniu, można użyć klastra pasywnego jako kopii zapasowej, a obciążenie może zostać na nim uruchomione.
• Agencja rządowa, która musi zachować kopię zapasową swoich krytycznych systemów i danych w przypadku cyberataku lub klęski żywiołowej. W takim przypadku pasywny klaster znajduje się w bezpiecznej i izolowanej lokalizacji, która nie jest dostępna dla społeczeństwa.

Składniki

Rozwiązanie do pasywnego odzyskiwania po awarii wykorzystuje wiele usług platformy Azure. Ta przykładowa architektura obejmuje następujące składniki:

Wiele klastrów i regionów: wdrażasz wiele klastrów usługi AKS, z których każdy jest w osobnym regionie świadczenia usługi Azure. Gdy aplikacja jest potrzebna, pasywny klaster jest aktywowany w celu odbierania ruchu sieciowego.

Key Vault: aprowizujesz usługę Azure Key Vault w każdym regionie, aby przechowywać wpisy tajne i klucze.

Log Analytics: regionalne wystąpienia usługi Log Analytics przechowują regionalne metryki sieci i dzienniki diagnostyczne. Wystąpienie udostępnione przechowuje metryki i dzienniki diagnostyczne dla wszystkich wystąpień usługi AKS.

Para koncentrator-rozgaleziacz: Para koncentrator-rozgaleziacz jest wdrażana dla każdego regionalnego wystąpienia usługi AKS. Zasady usługi Azure Firewall Manager zarządzają regułami zapory sieciowej w każdym regionie.

Container Registry: obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. Dzięki temu rozwiązaniu pojedyncza instancja usługi Azure Container Registry jest używana dla wszystkich instancji 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 zapewnia stały dostęp do obrazów, nawet jeśli region ulegnie awarii.

Proces awaryjnego przełączania

Jeśli pasywny klaster nie działa prawidłowo z powodu problemu w określonym regionie świadczenia usługi Azure, możesz aktywować zimny klaster i przekierować cały ruch do regionu tego klastra. Tego procesu można użyć, gdy klaster pasywny jest dezaktywowany, dopóki nie zacznie działać ponownie. Zimny klaster może potrzebować kilku minut, aby się uruchomić, ponieważ został wcześniej wyłączony i musi ukończyć proces konfiguracji. Takie podejście nie jest idealne w przypadku aplikacji wrażliwych na czas. W takim przypadku zalecamy rozważenie aktywnego-aktywnego przełączenia awaryjnego.

Zasobniki aplikacji (regionalne)

Obiekt Deployment w Kubernetes tworzy wiele replik podu (ReplicaSet). Jeśli jedna z nich jest niedostępna, ruch jest kierowany między pozostałymi replikami. Zestaw replik Kubernetes próbuje utrzymać określoną liczbę replik w działaniu. Jeśli jedno wystąpienie ulegnie awarii, należy odtworzyć nowe wystąpienie. Sondy żywotności mogą sprawdzać stan aplikacji lub procesu uruchomionego w zasobniku. Jeśli zasobnik nie odpowiada, sonda żywotności usuwa zasobnik, co wymusza na ReplicaSet utworzenie nowego wystąpienia.

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

Zasobniki aplikacji (globalne)

Gdy cały region stanie się niedostępny, pody w klastrze nie będą już dostępne, aby obsługiwać żądania. W takim przypadku instancja Azure Front Door kieruje cały ruch do pozostałych regionów o zdrowym statusie. Klastry i zasobniki Kubernetes w tych regionach nadal obsługują żądania. Aby zrekompensować zwiększony ruch i żądania kierowane do pozostałego klastra, pamiętaj o następujących wskazówkach:

• Upewnij się, że zasoby sieciowe i obliczeniowe mają odpowiedni rozmiar, aby zaabsorbować nagły wzrost ruchu z powodu awaryjnego przełączenia w regionie. Na przykład w przypadku korzystania z interfejsu sieciowego kontenera platformy 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 podów, co pozwoli zrekompensować zwiększone zapotrzebowanie regionalne.
• Użyj narzędzia AKS Cluster Autoscaler, aby zwiększyć liczbę węzłów instancji Kubernetes w celu zrekompensowania zwiększonego zapotrzebowania regionalnego.

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

Czasami zlokalizowane awarie mogą wystąpić w przypadku zasobów obliczeniowych, takich jak niedostępność zasilania w jednym stojaku serwerów platformy Azure. Aby chronić węzły usługi AKS przed stanie się awarią regionalną pojedynczego punktu, użyj usługi Azure Strefy dostępności. Strefy dostępności zapewniają, że węzły usługi AKS w każdej strefie dostępności są fizycznie oddzielone od tych zdefiniowanych w innych strefach dostępności.

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

W przypadku całkowitej awarii regionalnej usługa Azure Front Door kieruje ruch do pozostałych regionów w dobrej kondycji. Ponownie upewnij się, że zrekompensujesz zwiększony ruch i żądania do pozostałego klastra.

Strategia testowania trybu failover

Chociaż w usłudze AKS nie ma obecnie dostępnych mechanizmów umożliwiających wyłączenie całego regionu wdrożenia na potrzeby testowania, usługa Azure Chaos Studio oferuje możliwość utworzenia eksperymentu chaosu w klastrze.

Następne kroki

Jeśli rozważasz inne rozwiązanie, zapoznaj się z następującymi artykułami:

• Omówienie aktywnego pasywnego rozwiązania odzyskiwania po awarii dla usługi Azure Kubernetes Service (AKS)
• Omówienie aktywnego rozwiązania o wysokiej dostępności dla usługi Azure Kubernetes Service (AKS)