Udostępnij za pośrednictwem

Omówienie wysokiej dostępności i odzyskiwania po awarii dla usługi Azure Kubernetes Service (AKS)

  • Artykuł

Podczas tworzenia aplikacji w chmurze i zarządzania nimi zawsze występuje ryzyko przerw w działaniu awarii i awarii. Aby zapewnić ciągłość działania (BC), należy zaplanować wysoką dostępność i odzyskiwanie po awarii (DR).

Wysoka dostępność odnosi się do projektowania i wdrażania systemu lub usługi, która jest wysoce niezawodna i doświadcza minimalnego przestoju. Wysoka dostępność to kombinacja narzędzi, technologii i procesów, które zapewniają dostępność systemu lub usługi w celu wykonania zamierzonej funkcji. Wysoka dostępność jest krytycznym składnikiem planowania odzyskiwania po awarii. Odzyskiwanie po awarii to proces odzyskiwania po awarii i przywracanie operacji biznesowych do normalnego stanu. Odzyskiwanie po awarii to podzbiór BC, który jest procesem utrzymywania funkcji biznesowych lub szybkiego wznawiania ich w przypadku poważnych zakłóceń.

W tym artykule opisano niektóre zalecane rozwiązania dotyczące aplikacji wdrożonych w usłudze AKS, ale w żaden sposób nie jest to wyczerpująca lista możliwych rozwiązań.

Omówienie technologii

Klaster Kubernetes jest podzielony na dwa składniki:

  • Płaszczyzna sterowania, która zapewnia podstawowe usługi Kubernetes i orkiestrację obciążeń aplikacji oraz
  • Węzły, które uruchamiają obciążenia aplikacji.

Diagram składników płaszczyzny sterowania i węzła platformy Kubernetes.

Podczas tworzenia klastra usługi AKS platforma Azure automatycznie tworzy i konfiguruje płaszczyznę sterowania. Usługa AKS oferuje dwie warstwy cenowe do zarządzania klastrem: warstwę Bezpłatna i warstwę Standardowa. Aby uzyskać więcej informacji, zobacz Warstwy cenowe Bezpłatna i Standardowa na potrzeby zarządzania klastrem usługi AKS.

Płaszczyzna sterowania i jego zasoby znajdują się tylko w regionie, w którym utworzono klaster. Usługa AKS udostępnia płaszczyznę sterowania z jedną dzierżawą z dedykowanym serwerem interfejsu API, harmonogramem itp. Definiujesz liczbę i rozmiar węzłów, a platforma Azure konfiguruje bezpieczną komunikację między płaszczyzną sterowania i węzłami. Interakcja z płaszczyzną sterowania odbywa się za pośrednictwem interfejsów API platformy Kubernetes, takich jak kubectl lub pulpit nawigacyjny platformy Kubernetes.

Do uruchamiania aplikacji i usług pomocniczych potrzebny jest węzeł Kubernetes. Klaster usługi AKS ma co najmniej jeden węzeł— maszynę wirtualną platformy Azure, która uruchamia składniki węzła Kubernetes i środowisko uruchomieniowe kontenera. Rozmiar maszyny wirtualnej platformy Azure dla węzłów definiuje procesory CPU, pamięć, rozmiar i dostępny typ magazynu (na przykład dyski SSD o wysokiej wydajności lub zwykły dysk TWARDY). Zaplanuj maszynę wirtualną i rozmiar magazynu w zależności od tego, czy aplikacje mogą wymagać dużych ilości procesora CPU i pamięci, czy magazynu o wysokiej wydajności. W usłudze AKS obraz maszyny wirtualnej dla węzłów klastra jest oparty na systemie Ubuntu Linux, Azure Linux lub Windows Server 2022. Podczas tworzenia klastra usługi AKS lub skalowania w poziomie liczby węzłów platforma Azure automatycznie tworzy i konfiguruje żądaną liczbę maszyn wirtualnych.

Aby uzyskać więcej informacji na temat składników klastra i obciążenia w usłudze AKS, zobacz Podstawowe pojęcia dotyczące usługi AKS platformy Kubernetes.

Ważne uwagi

Zasoby regionalne i globalne

Zasoby regionalne są aprowizowane w ramach sygnatury wdrożenia w jednym regionie świadczenia usługi Azure. Te zasoby nie współużytkują żadnych zasobów w innych regionach i mogą zostać niezależnie usunięte lub zreplikowane w innych regionach. Aby uzyskać więcej informacji, zobacz Zasoby regionalne.

Zasoby globalne współdzielą okres istnienia systemu i mogą być dostępne globalnie w kontekście wdrożenia w wielu regionach. Aby uzyskać więcej informacji, zobacz Zasoby globalne.

Cele odzyskiwania

Kompletny plan odzyskiwania po awarii musi określać wymagania biznesowe dla każdego procesu implementowania aplikacji:

  • Cel punktu odzyskiwania (RPO) to maksymalny czas trwania akceptowalnej utraty danych. Cel punktu odzyskiwania jest mierzony w jednostkach czasu, takich jak minuty, godziny lub dni.
  • Cel czasu odzyskiwania (RTO) to maksymalny czas trwania akceptowalnego przestoju z przestojem zdefiniowanym przez specyfikację. Jeśli na przykład dopuszczalny czas trwania przestoju w awarii wynosi osiem godzin, cel czasu odzyskiwania wynosi osiem godzin.

Strefy dostępności

Strefy dostępności umożliwiają rozłożenie danych między wiele stref w tym samym regionie. W obrębie regionu strefy dostępności są wystarczająco blisko, aby mieć połączenia o małych opóźnieniach z innymi strefami dostępności, ale są wystarczająco daleko od siebie, aby zmniejszyć prawdopodobieństwo, że więcej niż jeden będzie miało wpływ na lokalne awarie lub pogodę. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące używania stref dostępności i regionów.

Odporność strefowa

Klastry usługi AKS są odporne na błędy strefowe. Jeśli strefa ulegnie awarii, klaster będzie nadal działać w pozostałych strefach. Płaszczyzna sterowania klastra i węzły są rozmieszczone w różnych strefach, a platforma Azure automatycznie obsługuje dystrybucję węzłów. Aby uzyskać więcej informacji, zobacz Odporność strefowa usługi AKS.

Równoważenie obciążenia

Globalne równoważenie obciążenia

Globalne usługi równoważenia obciążenia dystrybuują ruch między regionalnymi zapleczami, chmurami lub hybrydowymi usługami lokalnymi. Te usługi kierują ruch użytkowników końcowych do najbliższego dostępnego zaplecza. Reagują również na zmiany w niezawodności usługi lub wydajności, aby zmaksymalizować dostępność i wydajność. Następujące usługi platformy Azure zapewniają globalne równoważenie obciążenia:

Regionalne równoważenie obciążenia

Usługi równoważenia obciążenia regionalnego dystrybuują ruch w sieciach wirtualnych między maszynami wirtualnymi lub strefowo nadmiarowymi punktami końcowymi usługi w regionie. Następujące usługi platformy Azure zapewniają regionalne równoważenie obciążenia:

Wgląd w informacje

Musisz zebrać dane z aplikacji i infrastruktury, aby umożliwić efektywne operacje i zmaksymalizowaną niezawodność. Platforma Azure udostępnia narzędzia ułatwiające monitorowanie obciążeń usługi AKS i zarządzanie nimi. Aby uzyskać więcej informacji, zobacz Zasoby dotyczące obserwacji.

Definicja zakresu

Czas pracy aplikacji staje się ważny podczas zarządzania klastrami usługi AKS. Domyślnie usługa AKS zapewnia wysoką dostępność przy użyciu wielu węzłów w zestawie skalowania maszyn wirtualnych, ale te węzły nie chronią systemu przed awarią regionu. Aby zmaksymalizować czas pracy, zaplanuj ciągłość działania i przygotuj się do odzyskiwania po awarii, korzystając z następujących najlepszych rozwiązań:

  • 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.

Implementacje modelu wdrażania

Model wdrażania Plusy Minusy
Aktywne-aktywne • Brak utraty lub niespójności danych podczas pracy w trybie failover
• Wysoka odporność
• Lepsze wykorzystanie zasobów o wyższej wydajności		 • Złożone wdrażanie i zarządzanie
• Wyższy koszt
• Wymaga modułu równoważenia obciążenia i formy routingu ruchu
Aktywny-pasywny • Prostsza implementacja i zarządzanie
• Niższe koszty
• Nie wymaga modułu równoważenia obciążenia ani usługi Traffic Manager		 • Potencjalna utrata lub niespójność danych podczas pracy w trybie failover
• Dłuższy czas odzyskiwania i przestoje
• Niedostateczne wykorzystanie zasobów
Pasywne zimne • Najniższy koszt
• Nie wymaga synchronizacji, replikacji, modułu równoważenia obciążenia ani usługi Traffic Manager
• Nadaje się do obciążeń o niskim priorytcie, niekrytycznym		 • Wysokie ryzyko utraty lub niespójności danych podczas pracy w trybie failover
• Najdłuższy czas odzyskiwania i przestój
• Wymaga ręcznej interwencji w celu aktywowania klastra i wyzwalania kopii zapasowej

Model wdrażania o wysokiej dostępności aktywny-aktywny

W modelu wdrażania wysokiej dostępności aktywne-aktywne (HA) istnieją dwa niezależne klastry usługi AKS wdrożone w dwóch różnych regionach świadczenia usługi Azure (zazwyczaj sparowane regiony, takie jak Kanada Środkowa i Kanada Wschodnia lub Wschodnie stany USA 2 i Środkowe stany USA), które aktywnie obsługują ruch.

W przypadku tej przykładowej architektury:

  • Dwa klastry usługi AKS są wdrażane w oddzielnych regionach świadczenia usługi Azure.
  • Podczas normalnych operacji ruch sieciowy jest kierowany między obydwoma regionami. Jeśli jeden region stanie się niedostępny, ruch automatycznie kieruje się do regionu znajdującego się najbliżej użytkownika, który wystawił żądanie.
  • Istnieje wdrożona para piasty i szprych dla każdego regionalnego wystąpienia usługi AKS. Zasady usługi Azure Firewall Manager zarządzają regułami zapory w różnych regionach.
  • Usługa Azure Key Vault jest aprowizowana w każdym regionie do przechowywania wpisów tajnych i kluczy.
  • Usługa Azure Front Door równoważy obciążenie i kieruje ruch do regionalnego wystąpienia usługi aplikacja systemu Azure Gateway, które znajduje się przed każdym klastrem usługi AKS.
  • Regionalne wystąpienia usługi Log Analytics przechowują regionalne metryki sieci i dzienniki diagnostyczne.
  • Obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. Pojedynczy rejestr kontenerów platformy Azure jest używany 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 w regionie wystąpi awaria.

Aby utworzyć model wdrażania aktywny-aktywny w usłudze AKS, wykonaj następujące kroki:

  1. Utwórz dwa identyczne wdrożenia w dwóch różnych regionach świadczenia usługi Azure.

  2. Utwórz dwa wystąpienia aplikacji internetowej.

  3. Utwórz profil usługi Azure Front Door z następującymi zasobami:

    • Punkt końcowy.
    • Dwie grupy źródeł, z których każdy ma priorytet.
    • Trasa.

  4. Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door. 5. Skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.

  5. Wdrażanie kodu w obu aplikacjach internetowych przy użyciu ciągłego wdrażania.

Aby uzyskać więcej informacji, zobacz Omówienie zalecanego rozwiązania o wysokiej dostępności aktywne-aktywne dla usługi AKS.

Model wdrażania odzyskiwania po awarii aktywny-pasywny

W modelu wdrażania odzyskiwania po awarii aktywne-pasywne (DR) istnieją dwa niezależne klastry usługi AKS wdrożone w dwóch różnych regionach świadczenia usługi Azure (zazwyczaj sparowanych regionach, takich jak Kanada Środkowa i Kanada Wschodnia lub Wschodnie stany USA 2 i Środkowe stany USA), które aktywnie obsługują ruch. Tylko jeden z klastrów aktywnie obsługuje ruch w danym momencie. Drugi klaster zawiera te same dane konfiguracji i aplikacji co aktywny klaster, ale nie akceptuje ruchu, chyba że jest kierowany przez usługę Traffic Manager.

W przypadku tej przykładowej architektury:

  • Dwa klastry usługi AKS są wdrażane w oddzielnych regionach świadczenia usługi Azure.
  • Podczas normalnych operacji ruch sieciowy kieruje się do podstawowego klastra usługi AKS, który został ustawiony w konfiguracji usługi Azure Front Door.
    • Należy ustawić priorytet z zakresu od 1 do 5 , a 1 jest najwyższym i 5 najniższym.
    • Można ustawić wiele klastrów na ten sam poziom priorytetu i określić wagę każdego z nich.
  • Jeśli klaster podstawowy stanie się niedostępny (wystąpi awaria), 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 Traffic Manager, aby ten system działał.
  • Usługa Azure Front Door kieruje ruch do bramy aplikacja systemu Azure w regionie podstawowym (klaster musi być oznaczony priorytetem 1). Jeśli ten region zakończy się niepowodzeniem, usługa przekierowuje ruch do następnego klastra na liście priorytetów.
    • Reguły pochodzą z usługi Azure Front Door.
  • 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 różnych regionach.
  • Usługa Azure Key Vault jest aprowizowana w każdym regionie do przechowywania wpisów tajnych i kluczy.
  • Regionalne wystąpienia usługi Log Analytics przechowują regionalne metryki sieci i dzienniki diagnostyczne.
  • Obrazy kontenerów dla obciążenia są przechowywane w zarządzanym rejestrze kontenerów. Pojedynczy rejestr kontenerów platformy Azure jest używany 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 w regionie wystąpi awaria.

Aby utworzyć model wdrażania aktywne-pasywne w usłudze AKS, wykonaj następujące kroki:

  1. Utwórz dwa identyczne wdrożenia w dwóch różnych regionach świadczenia usługi Azure.

  2. Skonfiguruj reguły skalowania automatycznego dla aplikacji pomocniczej, aby była skalowana do tej samej liczby wystąpień co podstawowa, gdy region podstawowy stanie się nieaktywny. Nieaktywny nie musi być skalowany w górę. Pomaga to zmniejszyć koszty.

  3. Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym klastrze.

  4. Utwórz profil usługi Azure Front Door z następującymi zasobami:

    • Punkt końcowy.
    • Grupa pochodzenia z priorytetem jednego dla regionu podstawowego.
    • Druga grupa pochodzenia z priorytetem dwóch dla regionu pomocniczego.
    • Trasa.

  5. Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.

  6. Skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.

  7. Wdrażanie kodu w obu aplikacjach internetowych przy użyciu ciągłego wdrażania.

Aby uzyskać więcej informacji, zobacz Zalecane rozwiązanie do odzyskiwania po awarii aktywne-pasywne — omówienie usługi AKS.

Model wdrażania pasywnego trybu failover

Model wdrażania pasywnego trybu failover w trybie pasywnym jest skonfigurowany w taki sam sposób, jak model wdrażania odzyskiwania po awarii aktywny-pasywny, z wyjątkiem klastrów, dopóki użytkownik nie aktywuje ich w razie awarii. Rozważamy takie podejście poza zakresem , ponieważ obejmuje on podobną konfigurację do aktywne-pasywne, ale z dodatkową złożonością ręcznej interwencji w celu aktywowania klastra i wyzwalania kopii zapasowej.

W przypadku tej przykładowej architektury:

  • Utworzysz dwa klastry usługi AKS, najlepiej w różnych regionach lub strefach, aby zapewnić lepszą odporność.
  • Po przejściu w tryb failover należy aktywować wdrożenie, aby przejąć przepływ ruchu.
  • W przypadku awarii podstawowego pasywnego klastra należy ręcznie aktywować zimny klaster, aby przejąć przepływ ruchu.
  • Ten warunek musi być ustawiany przez ręczne dane wejściowe za każdym razem lub przez określone przez Ciebie zdarzenie.
  • Usługa Azure Key Vault jest aprowizowana w każdym regionie do przechowywania wpisów tajnych i kluczy.
  • Regionalne wystąpienia usługi Log Analytics przechowują regionalne metryki sieci i dzienniki diagnostyczne dla każdego klastra.

Aby utworzyć pasywny model wdrażania trybu failover w usłudze AKS, wykonaj następujące kroki:

  1. Utwórz dwa identyczne wdrożenia w różnych strefach/regionach.
  2. Skonfiguruj reguły skalowania automatycznego dla aplikacji pomocniczej, aby była skalowana do tej samej liczby wystąpień co podstawowa, gdy region podstawowy stanie się nieaktywny. Nieaktywny nie musi być skalowany w górę, co pomaga zmniejszyć koszty.
  3. Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym klastrze.
  4. Skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
  5. Ustaw warunek po wyzwoleniu klastra zimnego. Jeśli potrzebujesz, możesz użyć modułu równoważenia obciążenia.

Aby uzyskać więcej informacji, zobacz Omówienie zalecanego rozwiązania pasywnego trybu failover dla usługi AKS.

Limity i przydziały dotyczące usługi

Usługa AKS ustawia domyślne limity i limity przydziału dla zasobów i funkcji, w tym ograniczenia użycia dla niektórych jednostek SKU maszyn wirtualnych.

Zasób Limit
Maksymalna liczba klastrów na subskrypcję globalnie 5,000
Maksymalna liczba klastrów na subskrypcję na region 1 100
Maksymalna liczba węzłów na klaster z zestawami skalowania maszyn wirtualnych i jednostkami SKU usługa Load Balancer w warstwie Standardowa 5000 we wszystkich pulach węzłów
Uwaga: jeśli nie możesz skalować do 5000 węzłów na klaster, zobacz Najlepsze rozwiązania dotyczące dużych klastrów.
Maksymalna liczba węzłów na pulę węzłów (pule węzłów zestawów skalowania maszyn wirtualnych) 1000
Maksymalna liczba pul węzłów na klaster 100
Maksymalna liczba zasobników na węzeł: wtyczka sieciKubenet 1 Maksimum: 250
Ustawienie domyślne interfejsu wiersza polecenia platformy Azure: 110
Domyślna wartość szablonu usługi Azure Resource Manager: 110
Domyślna wartość wdrożenia w witrynie Azure Portal: 30
Maksymalna liczba zasobników na węzeł: za pomocą interfejsu azure Container Networking Interface (Azure CNI)2 Maksimum: 250
Maksymalna zalecana dla kontenerów systemu Windows Server: 110
Ustawienie domyślne: 30
Otwórz dodatek usługi Service Mesh (OSM) AKS Wersja klastra Kubernetes: obsługiwane wersje usługi AKS
Kontrolery OSM na klaster: 1
Zasobniki na kontroler OSM: 1600
Konta usługi Kubernetes zarządzane przez OSM: 160
Maksymalna liczba usług kubernetes z równoważeniem obciążenia na klaster przy użyciu jednostki SKU usługa Load Balancer w warstwie Standardowa 300
Maksymalna liczba węzłów na klaster przy użyciu zestawów dostępności maszyn wirtualnych i podstawowej jednostki SKU modułu równoważenia obciążenia 100

1 Więcej jest dozwolonych na żądanie.
2 Kontenery systemu Windows Server muszą używać wtyczki sieci azure CNI. Platforma Kubenet nie jest obsługiwana w przypadku kontenerów systemu Windows Server.

Warstwa płaszczyzny sterowania platformy Kubernetes Limit
Warstwa Standardowa Automatycznie skaluje serwer interfejsu API Kubernetes na podstawie obciążenia. Większe limity składników płaszczyzny sterowania i wystąpienia serwera interfejsu API/etcd.
Warstwa Bezpłatna Ograniczone zasoby z limitem żądań inflight 50 mutating i 100 wywołań tylko do odczytu. Zalecany limit węzłów równy 10 węzłów na klaster. Najlepsze rozwiązanie do eksperymentowania, uczenia się i prostego testowania. Nie zaleca się obsługi obciążeń produkcyjnych/krytycznych.

Aby uzyskać więcej informacji, zobacz Limity przydziału i limity usługi AKS.

Wykonywanie kopii zapasowej

Usługa Azure Backup obsługuje tworzenie kopii zapasowych zasobów klastra usługi AKS i trwałych woluminów dołączonych do klastra przy użyciu rozszerzenia kopii zapasowej. Magazyn kopii zapasowych komunikuje się z klastrem usługi AKS za pośrednictwem rozszerzenia w celu wykonywania operacji tworzenia kopii zapasowych i przywracania.

Aby uzyskać więcej informacji, zobacz następujące artykuły: