Omówienie rozwiązania pasywnego chłodnego 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 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, gdy aplikacja jest potrzebna.
Uwaga
Poniższa praktyka została przejrzyona wewnętrznie i sprawdzona w połączeniu z naszymi partnerami firmy Microsoft.
Omówienie rozwiązania pasywnego chłodnego
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 pasywnego 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 zimnego jako kopii zapasowej, a obciążenie może zostać uruchomione w nim zamiast tego.
- 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 odzyskiwania po awarii pasywnej korzysta z 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. 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 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.
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 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 potrwać kilka minut, ponieważ został wyłączony i musi ukończyć proces instalacji. Takie podejście nie jest idealne w przypadku aplikacji wrażliwych na czas. W takim przypadku zalecamy rozważenie trybu failover aktywne-aktywne.
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:
Azure Kubernetes Service