Omówienie rozwiązania aktywno-pasywnego odzyskiwania po awarii dla usługi Azure Kubernetes Service (AKS)

Podczas tworzenia aplikacji w Azure Kubernetes Service (AKS) i wybraniu regionu Azure podczas tworzenia zasobów jest to aplikacja z jednym regionem. Gdy region stanie się niedostępny podczas awarii, aplikacja stanie się również niedostępna. Jeśli utworzysz identyczne wdrożenie w regionie pomocniczym 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 rozwiązanie typu aktywny-pasywny do odtwarzania po awarii dla AKS. W ramach tego rozwiązania wdrażamy dwa niezależne i identyczne klastry usługi AKS w dwóch sparowanych regionach Azure z tylko jednym klastrem aktywnie obsługującym ruch.

Omówienie rozwiązania aktywne-pasywne

W tym podejściu do odzyskiwania po awarii wdrażane są dwa niezależne klastry AKS w dwóch regionach platformy Azure. Jednak tylko jeden z klastrów aktywnie obsługuje ruch w dowolnym momencie. Klaster pomocniczy (nie obsługuje aktywnie ruchu) zawiera te same dane konfiguracji i aplikacji co klaster podstawowy, ale nie akceptuje żadnego ruchu, chyba że jest kierowany przez usługę Azure Front Door traffic manager.

Scenariusze i konfiguracje

To rozwiązanie jest najlepiej zaimplementowane podczas hostowania aplikacji zależnych od zasobów, takich jak bazy danych, które aktywnie obsługują ruch w jednym regionie. W sytuacjach, gdy trzeba hostować aplikacje bezstanowe wdrożone w obu regionach, na przykład w celu skalowania horyzontalnego, zalecamy rozważenie rozwiązania aktywne-aktywne, ponieważ model aktywne-pasywne wiąże się z dodatkowymi opóźnieniami.

Składniki

Rozwiązanie do odtwarzania po awarii typu aktywne-pasywne 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 Azure. Podczas normalnych operacji ruch sieciowy jest kierowany do podstawowego klastra usługi AKS ustawionego w konfiguracji Azure Front Door.

Skonfigurowana priorytetyzacja klastra: należy ustawić poziom priorytetyzacji z zakresu od 1 do 5 dla każdego klastra (z 1 najwyższym priorytetem i 5 jest najniższym priorytetem). Można ustawić wiele klastrów na ten sam poziom priorytetu i określić wagę dla każdego klastra. Jeśli klaster podstawowy stanie się niedostępny, ruch automatycznie kieruje się do następnego regionu wybranego w Azure Front Door. Cały ruch musi przechodzić przez Azure Front Door, aby ten system działał.

Azure Front Door: Azure Front Door równoważy obciążenie i kieruje ruch do wystąpienia Azure Application Gateway w regionie podstawowym (klaster musi być oznaczony jako priorytet 1). W przypadku awarii regionu usługa przekierowuje ruch do następnego klastra na liście priorytetów.

Aby uzyskać więcej informacji, zobacz Routing ruchu oparty na priorytecie.

Para hub-and-spoke: Para hub-and-spoke jest wdrażana dla każdego regionalnego wystąpienia AKS. Zasady usługi Azure Firewall Manager służą do zarządzania regułami zapory w poszczególnych regionach.

Key Vault: aprowizujesz Azure Key Vault w każdym regionie do przechowywania wpisów tajnych i kluczy.

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

Container Registry: obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. W przypadku tego rozwiązania pojedyncze wystąpienie Azure Container Registry jest używane dla wszystkich wystąpień platformy Kubernetes w klastrze. Replikacja geograficzna dla Azure Container Registry umożliwia replikowanie obrazów do wybranych regionów Azure i zapewnia stały dostęp do obrazów, nawet jeśli w regionie wystąpi awaria.

Proces przełączenia awaryjnego

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 potencjalne punkty awarii.

Zasobniki aplikacji (regionalne)

Obiekt wdrożenia platformy Kubernetes tworzy wiele replik zasobnika (ReplicaSet). Jeśli jedna z nich jest niedostępna, ruch jest kierowany między pozostałymi replikami. Obiekt Kubernetes ReplicaSet stara się utrzymać określoną liczbę działających replik. Jeśli jedna instancja przestanie działać, powinna zostać odtworzona. Sondy żywotności mogą sprawdzać stan aplikacji lub procesu uruchomionego w podzie. Jeśli zasobnik nie odpowiada, próba żywotności usuwa zasobnik, co zmusza element ReplicaSet do utworzenia nowej instancji.

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 tym przypadku instancja usługi Azure Front Door kieruje cały ruch do pozostałych zdrowych regionów. Klastry i zasobniki Kubernetes w tych regionach nadal obsługują żądania. Aby uwzględnić zwiększony ruch i liczbę żądań kierowanych do pozostałego klastra, pamiętaj o następujących wskazówkach:

• Upewnij się, że zasoby sieciowe i obliczeniowe są odpowiednio zwymiarowane, aby obsłużyć każdy nagły wzrost ruchu spowodowany przełączeniem awaryjnym do innego regionu. Na przykład podczas korzystania z Azure Container Network Interface (CNI) upewnij się, że masz podsieć, która może obsłużyć wszystkie adresy IP podów nawet przy nagłym wzroście natężenia ruchu.
• Użyj Horizontal Pod Autoscaler, aby zwiększyć liczbę replik zasobników i skompensować zwiększony popyt w danym regionie.
• Użyj narzędzia Cluster Autoscaler w usłudze AKS, aby zwiększyć liczbę węzłów instancji Kubernetes i skompensować zwiększone zapotrzebowanie w regionie.

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 Azure. Aby węzły usługi AKS w tym rozwiązaniu aktywno-pasywnym nie stanowiły pojedynczego punktu awarii w regionie, użyj 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 innej strefie dostępności.

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

W przypadku całkowitej awarii regionalnej Azure Front Door kieruje ruch do pozostałych regionów w dobrej kondycji. Ponownie pamiętaj, aby uwzględnić zwiększony ruch i liczbę żądań w pozostałym klastrze.

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, Azure Chaos Studio oferuje możliwość utworzenia eksperymentu chaosu w klastrze.

Następne kroki

Jeśli rozważasz inne rozwiązanie, zobacz następujące artykuły:

• Omówienie aktywnego rozwiązania o wysokiej dostępności dla Azure Kubernetes Service (AKS)
• Omówienie pasywnego rozwiązania zimnego dla Azure Kubernetes Service (AKS)