Omówienie rozwiązania do odzyskiwania po awarii aktywne-pasywne dla usługi Azure Kubernetes Service (AKS)
Podczas tworzenia aplikacji w usłudze Azure Kubernetes Service (AKS) i wybraniu regionu świadczenia usługi 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 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 rozwiązanie do odzyskiwania po awarii aktywne-pasywne 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.
Uwaga
Poniższa praktyka została przejrzyona wewnętrznie i sprawdzona w połączeniu z naszymi partnerami firmy Microsoft.
Omówienie rozwiązania aktywne-pasywne
W tym podejściu do odzyskiwania po awarii mamy dwa niezależne klastry usługi AKS wdrażane w dwóch regionach świadczenia usługi 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 scenariuszach, w których należy hostować aplikacje bezstanowe wdrożone w obu regionach, takich jak skalowanie w poziomie, zalecamy rozważenie rozwiązania aktywne-aktywne, ponieważ aktywne-pasywne obejmuje dodatkowe opóźnienie.
Elementy
Rozwiązanie do odzyskiwania po awarii aktywne-pasywne używa wielu 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. Podczas normalnych operacji ruch sieciowy jest kierowany do podstawowego klastra usługi AKS ustawionego w konfiguracji usługi 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 usłudze Azure Front Door. Cały ruch musi przechodzić przez usługę Azure Front Door, aby ten system działał.
Azure Front Door: usługa Azure Front Door równoważy obciążenie i kieruje ruch do wystąpienia usługi aplikacja systemu Azure Gateway w regionie podstawowym (klaster musi być oznaczony priorytetem 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 piasty i szprych: para piasty i szprych jest wdrażana dla każdego regionalnego wystąpienia usługi AKS. Zasady usługi Azure Firewall Manager zarządzają regułami zapory w każdym regionie.
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.
Container Registry: obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. Dzięki temu rozwiązaniu pojedyncze wystąpienie usługi Azure Container Registry jest używane 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 zapewnia stały dostęp do obrazów, nawet jeśli region ulegnie awarii.
Proces trybu failover
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. 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. Sondy wydajności mogą sprawdzać stan aplikacji lub procesu uruchomionego w zasobniku. Jeśli zasobnik nie odpowiada, sonda aktualności usuwa zasobnik, co wymusza utworzenie nowego wystąpienia przez zestaw replicaSet .
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 kondycji. Klastry i zasobniki Kubernetes w tych regionach nadal obsługują żądania. Aby zrekompensować zwiększony ruch i żądania do pozostałego klastra, pamiętaj o następujących wskazówkach:
- 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 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 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.
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 pamiętaj, aby zrekompensować 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: