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

W przypadku zarządzania klastrami w Azure Kubernetes Service (AKS) czas pracy aplikacji staje się ważny. Domyślnie usługi AKS zapewniają 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 z wyprzedzeniem zachowanie ciągłości działania i przygotowanie do odzyskiwania po awarii.

W tym artykule opisano sposób planowania ciągłości działania i odzyskiwania po awarii w u usługi AKS. Omawiane kwestie:

  • Planowanie klastrów usługi AKS w wielu regionach.
  • Przekieruj ruch między wieloma klastrami przy użyciu Azure Traffic Manager.
  • Użyj replikacji geograficznej dla rejestrów obrazów kontenerów.
  • 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, wd wdrażaj 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ę:

  • Dostępność regionu usługi AKS
    • Wybierz regiony w pobliżu użytkowników.
    • AKS nieustannie 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 sparowanych regionami.
    • Działania w zakresie odzyskiwania dla sparowanych regionów mają priorytety w razie potrzeby.
  • Dostępność usługi
    • Zdecyduj, czy sparowane regiony powinny być gorące/gorące, gorące/gorące 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ć jednemu regionowi czas, aby przygotować się do obsługi ruchu?

Wspólną kwestią jest dostępność regionów usługi AKS i sparowanych regionów. Wdrażanie klastrów usługi AKS w sparowanych regionach zaprojektowanych do zarządzania odzyskiwaniem po awarii regionów razem. Na przykład 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 dla usług AKS.

Podczas wdrażania aplikacji dodaj kolejny krok do potoku ciasnych/cd w celu wdrożenia w tych wielu klastrach usługi AKS. Aktualizacja potoków wdrażania uniemożliwia wdrażanie aplikacji tylko w jednym z regionów i klastrach usługi AKS. W tym scenariuszu ruch klientów skierowany do regionu pomocniczego nie otrzyma najnowszych aktualizacji kodu.

Używanie Azure Traffic Manager do rozsyłania ruchu

Najlepsze rozwiązanie

Azure Traffic Manager może kierować Cię do najbliższego klastra I wystąpienia aplikacji usługi AKS. Aby uzyskać najlepszą wydajność i nadmiarowość, przekieruj cały ruch aplikacji przez Traffic Manager przed jego skierowaniem do klastra usługi AKS.

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

AKS z Traffic Manager

Jeśli masz pojedynczy klaster usługi AKS, zazwyczaj łączysz się z adresem IP usługi lub nazwą DNS danej aplikacji. W przypadku wdrożenia z wieloma klastrami należy połączyć się z Traffic Manager DNS, która wskazuje usługi w każdym klastrze usługi AKS. Zdefiniuj te usługi przy użyciu Traffic Manager końcowych. Każdy punkt końcowy jest adresem IP usługi równoważenia obciążenia. Ta konfiguracja pozwala kierować ruch sieciowy z punktu końcowego Traffic Manager w jednym regionie do punktu końcowego w innym regionie.

Routing geograficzny za pośrednictwem Traffic Manager

Traffic Manager wykonuje wyszukiwania 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, Traffic Manager do regionu pomocniczego. Takie podejście zapewnia, że możesz nawiązać połączenie 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 geograficznegoprzy użyciu Traffic Manager .

Routing aplikacji przy użyciu Azure Front Door Service

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

  • Zakończenie 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.

Wzajemne połączenie regionów za pomocą globalnej komunikacji równorzędnej sieci wirtualnych

Połącz obie sieci wirtualne 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 firmy Microsoft — nawet w różnych regionach geograficznych.

Przed rozpoczęciem komunikacji równorzędnej sieci wirtualnych z uruchomionymi klastrami usługi AKS użyj 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 zreplikuj geograficznie rejestr do każdego regionu AKS.

Aby wdrożyć i uruchomić aplikacje w u usługi AKS, musisz mieć sposób na przechowywanie i ściąganie obrazów kontenerów. Container Registry integruje się z usługą AKS, dzięki czemu może bezpiecznie przechowywać obrazy kontenerów lub wykresy Helm. Container Registry obsługuje wielowątkową replikację geograficzną w celu automatycznego replikowania obrazów do regionów świadczenia usługi Azure na całym świecie.

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

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

Container Registry replikacji geograficznej dla obrazów kontenerów

Gdy używasz Container Registry replikacji geograficznej do ściągania obrazów z tego samego regionu, wyniki są:

  • Szybciej: ściągaj obrazy z szybkich połączeń sieciowych o małych opóźnieniach 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ńszy: brak opłat za ruch wychodzący między centrami danych.

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

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 jako usługi (PaaS) platformy Azure, 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 projektowana, stan może również obejmować pliki lub inne zasoby przechowywane na dysku. Na przykład stan może obejmować 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 jest zewnętrzny przy użyciu bazy danych lub innego magazynu danych, który działa na różnych maszynach za pośrednictwem sieci lub na tym samym komputerze wybiega proces.

Kontenery i mikrousługi są najbardziej odporne, gdy procesy, które są w nich uruchamiane, nie zachowują stanu. Ponieważ aplikacje prawie zawsze zawierają jakiś stan, należy użyć rozwiązania PaaS, takiego jak:

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

Aby tworzyć aplikacje przenośne, zapoznaj się z następującymi wytycznymi:

Tworzenie planu migracji magazynu

Najlepsze rozwiązanie

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

Aplikacje mogą używać usługi Azure Storage do przechowywania danych. Jeśli tak, aplikacje są rozłożone w wielu klastrach 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 kubernetes można utrwalać magazyn danych przy użyciu trwałych woluminów. Trwałe woluminy są instalowane na maszynie wirtualnej węzła, a następnie udostępniane w zasobnikach. Woluminy trwałe podążają za zasobnikami, nawet jeśli zasobniki są przenoszone do innego węzła w tym samym klastrze.

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

Zazwyczaj jest to wspólny punkt magazynowania, 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ć narzędzia Velero na platformie Azure i platformy Kasten do obsługi replikacji i odzyskiwania po awarii. Te opcje są kopiami zapasowymi rozwiązań natywnych dla rozwiązania kubernetes, ale nieobsługiwanych przez usługę Kubernetes.

Replikacja asynchroniczna oparta na aplikacji

Obecnie kubernetes nie zapewnia natywnej implementacji replikacji asynchronicznej opartej na aplikacji. Ponieważ kontenery i rozwiązania Kubernetes są luźno powiązane, każde tradycyjne podejście do aplikacji lub języka powinno 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

Ten artykuł koncentruje się na zagadnieniach z uwzględnieniem 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 u usługi AKS, zobacz następujące artykuły dotyczące najlepszych rozwiązań: