Omówienie wysokiej dostępności i odzyskiwania po awarii dla usługi Azure Kubernetes Service (AKS)
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.
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 Rekomendacje na potrzeby korzystania ze 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:
- Azure Front Door
- Azure Traffic Manager
- Usługa Azure Load Balancer między regionami
- Azure Kubernetes Fleet Manager
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:
Utwórz dwa identyczne wdrożenia w dwóch różnych regionach świadczenia usługi Azure.
Utwórz dwa wystąpienia aplikacji internetowej.
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.
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.
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:
Utwórz dwa identyczne wdrożenia w dwóch różnych regionach świadczenia usługi Azure.
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.
Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym klastrze.
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.
Ogranicz ruch sieciowy do aplikacji internetowych tylko z wystąpienia usługi Azure Front Door.
Skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
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:
- Utwórz dwa identyczne wdrożenia w różnych strefach/regionach.
- 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.
- Utwórz dwa wystąpienia aplikacji internetowej z jednym w każdym klastrze.
- Skonfiguruj wszystkie inne usługi platformy Azure zaplecza, takie jak bazy danych, konta magazynu i dostawcy uwierzytelniania.
- 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ę | 5000 Uwaga: rozprzestrzenianie klastrów w różnych regionach w celu uwzględnienia limitów ograniczania interfejsu API platformy Azure |
| 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)1 | 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 Kontenery systemu Windows Server muszą używać wtyczki sieci azure CNI. Platforma Kubenet nie jest obsługiwana w przypadku kontenerów systemu Windows Server.
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: