Najlepsze rozwiązania dotyczące ciągłości działania i odzyskiwania po awarii w usłudze Azure Kubernetes Service (AKS)

Podczas zarządzania klastrami w usłudze Azure Kubernetes Service (AKS) czas pracy aplikacji staje się ważny. Domyślnie usługa AKS zapewnia wysoką dostępność przy użyciu wielu węzłów w zestawie skalowania maszyn wirtualnych (VMSS). Jednak te wiele węzłów nie chroni systemu przed awarią regionu. Aby zmaksymalizować czas pracy, zaplanuj ciągłość działania i przygotuj się do odzyskiwania po awarii.

Ten artykuł koncentruje się na sposobie planowania ciągłości działania i odzyskiwania po awarii w usłudze AKS. Omawiane kwestie:

  • Planowanie klastrów usługi AKS w wielu regionach.
  • Kierowanie ruchu między wieloma klastrami przy użyciu usługi Azure Traffic Manager.
  • Użyj replikacji geograficznej dla rejestrów obrazów kontenera.
  • Planowanie stanu aplikacji w wielu klastrach.
  • Replikowanie magazynu w wielu regionach.

Planowanie wdrożenia w wielu regionach

Najlepsze rozwiązanie

Podczas wdrażania wielu klastrów usługi AKS wybierz regiony, w których usługa AKS jest dostępna. Użyj sparowanych regionów.

Klaster usługi AKS jest wdrażany w jednym regionie. Aby chronić system przed awarią regionu, wdróż aplikację w wielu klastrach usługi AKS w różnych regionach. Podczas planowania miejsca wdrożenia klastra usługi AKS należy wziąć pod uwagę następujące kwestie:

  • Dostępność regionów usługi AKS
    • Wybierz regiony zbliżone do użytkowników.
    • Usługa AKS stale rozszerza się na nowe regiony.
  • Sparowane regiony platformy Azure
    • Dla obszaru geograficznego wybierz dwa sparowane ze sobą regiony.
    • Aktualizacje platformy AKS (planowana konserwacja) są serializowane z opóźnieniem co najmniej 24 godzin między sparowanymi regionami.
    • W razie potrzeby wysiłki związane z odzyskiwaniem sparowanych regionów mają wyższy priorytet.
  • Dostępność usługi
    • Zdecyduj, czy sparowane regiony powinny być gorące/gorące, gorące/ciepłe, czy gorące/zimne.
    • Czy chcesz uruchomić oba regiony w tym samym czasie, z jednym regionem gotowym do rozpoczęcia obsługi ruchu? Lub:
    • Czy chcesz dać jeden region, aby przygotować się do obsługi ruchu?

Dostępność i sparowane regiony usługi AKS to wspólna kwestia. Wdróż klastry usługi AKS w sparowanych regionach przeznaczonych do wspólnego zarządzania odzyskiwaniem po awarii w regionie. Na przykład usługa AKS jest dostępna w regionach Wschodnie stany USA i Zachodnie stany USA. Te regiony są sparowane. Wybierz te dwa regiony podczas tworzenia strategii bc/DR usługi AKS.

Podczas wdrażania aplikacji dodaj kolejny krok do potoku ciągłej integracji/ciągłego wdrażania, aby wdrożyć je w wielu klastrach usługi AKS. Aktualizowanie potoków wdrażania uniemożliwia wdrażanie aplikacji tylko w jednym z Twoich regionów i klastrów usługi AKS. W tym scenariuszu ruch klientów kierowany do regionu pomocniczego nie będzie otrzymywać najnowszych aktualizacji kodu.

Kierowanie ruchem za pomocą usługi Azure Traffic Manager

Najlepsze rozwiązanie

Usługa Azure Traffic Manager może kierować Cię do najbliższego klastra usługi AKS i wystąpienia aplikacji. Aby uzyskać najlepszą wydajność i nadmiarowość, należy skierować cały ruch aplikacji przez usługę Traffic Manager przed przejściem do klastra usługi AKS.

Jeśli masz wiele klastrów usługi AKS w różnych regionach, użyj usługi Traffic Manager, aby kontrolować przepływ ruchu do aplikacji uruchomionych w każdym klastrze. Usługa Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu, który może dystrybuować ruch sieciowy między regionami. Usługa Traffic Manager umożliwia kierowanie użytkowników na podstawie czasu odpowiedzi klastra lub na podstawie lokalizacji geograficznej.

Usługa AKS z usługą Traffic Manager

Jeśli masz jeden klaster usługi AKS, zazwyczaj łączysz się z adresem IP usługi lub nazwą DNS danej aplikacji. We wdrożeniu z wieloma klastrami należy nawiązać połączenie z nazwą DNS usługi Traffic Manager wskazującą usługi w każdym klastrze usługi AKS. Zdefiniuj te usługi przy użyciu punktów końcowych usługi Traffic Manager. Każdy punkt końcowy jest adresem IP modułu równoważenia obciążenia usługi. Ta konfiguracja umożliwia kierowanie ruchu sieciowego z punktu końcowego usługi Traffic Manager w jednym regionie do punktu końcowego w innym regionie.

Routing geograficzny za pośrednictwem usługi Traffic Manager

Usługa Traffic Manager wykonuje wyszukiwanie DNS i zwraca najbardziej odpowiedni punkt końcowy. Zagnieżdżone profile mogą określać priorytety lokalizacji podstawowej. Na przykład należy połączyć się z najbliższym regionem geograficznym. Jeśli ten region ma problem, usługa Traffic Manager kieruje Cię do regionu pomocniczego. Takie podejście zapewnia możliwość nawiązania połączenia z wystąpieniem aplikacji, nawet jeśli najbliższy region geograficzny jest niedostępny.

Aby uzyskać informacje na temat konfigurowania punktów końcowych i routingu, zobacz Konfigurowanie metody routingu ruchu geograficznego przy użyciu usługi Traffic Manager.

Routing aplikacji za pomocą usługi Azure Front Door Service

Korzystając z podzielonego protokołu emisji opartego na protokole TCP, usługa Azure Front Door Service natychmiast łączy użytkowników końcowych z najbliższym punktem POP usługi Front Door (punkt obecności). Więcej funkcji usługi Azure Front Door Service:

  • Zakończenie szyfrowania TLS
  • Domena niestandardowa
  • Zapora aplikacji internetowej
  • Ponowne zapisywanie adresów URL
  • Koligacja sesji

Przejrzyj potrzeby ruchu aplikacji, aby zrozumieć, które rozwiązanie jest najbardziej odpowiednie.

Łączenie regionów z globalną komunikacją równorzędną sieci wirtualnych

Połącz obie sieci wirtualne ze sobą za pośrednictwem komunikacji równorzędnej sieci wirtualnych , aby umożliwić komunikację między klastrami. Komunikacja równorzędna sieci wirtualnych łączy sieci wirtualne, zapewniając wysoką przepustowość w sieci szkieletowej Microsoft — nawet w różnych regionach geograficznych.

Przed komunikacją równorzędną sieci wirtualnych z uruchomionymi klastrami usługi AKS należy użyć standardowego Load Balancer w klastrze usługi AKS. To wymaganie wstępne sprawia, że usługi Kubernetes są dostępne w ramach komunikacji równorzędnej sieci wirtualnych.

Włączanie replikacji geograficznej dla obrazów kontenerów

Najlepsze rozwiązanie

Przechowuj obrazy kontenerów w Azure Container Registry i replikuj geograficznie rejestr do każdego regionu usługi AKS.

Aby wdrożyć i uruchomić aplikacje w usłudze AKS, potrzebujesz sposobu przechowywania i ściągania obrazów kontenerów. Usługa Container Registry integruje się z usługą AKS, dzięki czemu może bezpiecznie przechowywać obrazy kontenerów lub wykresy programu Helm. Usługa Container Registry obsługuje wielowzorcową replikację geograficzną, aby automatycznie replikować obrazy do regionów platformy Azure na całym świecie.

Aby zwiększyć wydajność i dostępność:

  1. Użyj replikacji geograficznej usługi Container Registry, aby utworzyć rejestr w każdym regionie, w którym istnieje klaster usługi AKS.
  2. Następnie każdy klaster usługi AKS pobiera obrazy kontenerów z lokalnego rejestru kontenerów w tym samym regionie:

Replikacja geograficzna usługi Container Registry dla obrazów kontenerów

Gdy używasz replikacji geograficznej usługi Container Registry do ściągania obrazów z tego samego regionu, wyniki są następujące:

  • Szybciej: ściąganie obrazów z szybkich, małych opóźnień połączeń sieciowych w tym samym regionie świadczenia usługi Azure.
  • Bardziej niezawodne: jeśli region jest niedostępny, klaster usługi AKS ściąga obrazy z dostępnego rejestru kontenerów.
  • Tańsze: brak opłat za ruch wychodzący w sieci między centrami danych.

Replikacja geograficzna to funkcja rejestru kontenerów jednostki SKU w warstwie Premium . Aby uzyskać informacje na temat konfigurowania replikacji geograficznej, zobacz Replikacja geograficzna usługi Container Registry.

Usuwanie stanu usługi z kontenerów

Najlepsze rozwiązanie

Unikaj przechowywania stanu usługi wewnątrz kontenera. Zamiast tego należy użyć platformy Azure jako usługi (PaaS), która obsługuje replikację w wielu regionach.

Stan usługi odnosi się do danych w pamięci lub na dysku wymaganych przez usługę do działania. Stan zawiera struktury danych i zmienne składowe, które usługa odczytuje i zapisuje. W zależności od tego, jak usługa jest zaprojektowana, stan może również obejmować pliki lub inne zasoby przechowywane na dysku. Na przykład stan może zawierać pliki używane przez bazę danych do przechowywania danych i dzienników transakcji.

Stan może być zewnętrznie lub kolokowany z kodem, który manipuluje stanem. Zazwyczaj stan można na zewnątrz przy użyciu bazy danych lub innego magazynu danych, który działa na różnych maszynach przez sieć lub który kończy się procesem na tej samej maszynie.

Kontenery i mikrousługi są najbardziej odporne, gdy procesy uruchamiane wewnątrz nich nie zachowują stanu. Ponieważ aplikacje prawie zawsze zawierają jakiś stan, użyj rozwiązania PaaS, takiego jak:

  • Azure Cosmos DB
  • Azure Database for PostgreSQL
  • Azure Database for MySQL
  • Azure SQL Database

Aby utworzyć aplikacje przenośne, zobacz następujące wskazówki:

Tworzenie planu migracji magazynu

Najlepsze rozwiązanie

Jeśli używasz usługi Azure Storage, przygotuj i przetestujesz sposób migracji magazynu z regionu podstawowego do regionu kopii zapasowej.

Aplikacje mogą używać usługi Azure Storage do ich danych. Jeśli tak, aplikacje są rozłożone na wiele klastrów usługi AKS w różnych regionach. Należy zachować synchronizację magazynu. Oto dwa typowe sposoby replikowania magazynu:

  • Replikacja asynchroniczna oparta na infrastrukturze
  • Replikacja asynchroniczna oparta na aplikacji

Replikacja asynchroniczna oparta na infrastrukturze

Aplikacje mogą wymagać trwałego magazynu nawet po usunięciu zasobnika. Na platformie Kubernetes można użyć woluminów trwałych do utrwalania magazynu danych. Woluminy trwałe są instalowane na maszynie wirtualnej węzła, a następnie udostępniane zasobnikom. Woluminy trwałe są zgodne z zasobnikami, nawet jeśli zasobniki są przenoszone do innego węzła wewnątrz tego samego klastra.

Używana strategia replikacji zależy od rozwiązania magazynu. Następujące typowe rozwiązania magazynu zawierają własne wskazówki dotyczące odzyskiwania po awarii i replikacji:

Zazwyczaj udostępniasz typowy punkt przechowywania, w którym aplikacje zapisują swoje dane. Te dane są następnie replikowane w różnych regionach i dostępne lokalnie.

Replikacja asynchroniczna oparta na infrastrukturze

Jeśli używasz usługi Azure Dyski zarządzane, możesz użyć platformy Velero na platformie Azure i platformie Kasten do obsługi replikacji i odzyskiwania po awarii. Te opcje są kopiami zapasowymi rozwiązań natywnych dla platformy Kubernetes, ale nieobsługiwanych przez platformę Kubernetes.

Replikacja asynchroniczna oparta na aplikacji

Platforma Kubernetes obecnie nie zapewnia natywnej implementacji replikacji asynchronicznej opartej na aplikacji. Ponieważ kontenery i platforma Kubernetes są luźno powiązane, każda tradycyjna metoda aplikacji lub języka powinna działać. Zazwyczaj same aplikacje replikują żądania magazynu, które są następnie zapisywane w bazowym magazynie danych każdego klastra.

Replikacja asynchroniczna oparta na aplikacji

Następne kroki

W tym artykule opisano zagadnienia dotyczące ciągłości działania i odzyskiwania po awarii dla klastrów usługi AKS. Aby uzyskać więcej informacji na temat operacji klastra w usłudze AKS, zobacz następujące artykuły dotyczące najlepszych rozwiązań: