Scenariusze dostępności usługi Azure Kubernetes Service (AKS) włączone przez usługę Azure Arc w dwuwęźle — lokalnie na platformie Azure
Dotyczy: Azure Stack HCI, wersja 22H2
W tym artykule opisano architekturę wdrażania klastra Kubernetes w klastrze lokalnym platformy Azure z dwoma węzłami. W tym artykule opisano różne scenariusze awarii, które mogą wystąpić, ich wpływ na klaster i możliwości odzyskiwania po tych scenariuszach awarii.
Architektura
Tradycyjne wdrożenia platformy Kubernetes wymagają trzech maszyn fizycznych w celu wyeliminowania pojedynczego błędu. To wymaganie zwykle oznacza wyższy całkowity koszt posiadania (TCO). W przypadku wdrożeń wrażliwych na koszty usługa AKS włączona przez usługę Arc może zostać wdrożona w dwuwęźle lokalnym systemie azure, jak pokazano poniżej, z kilkoma kompromisami w dostępności. Te kompromisy opisano w scenariuszach dostępności i ich wpływ na klaster usługi AKS z dwoma węzłami.
Aby uzyskać więcej informacji na temat architektury, strategii wdrażania klastra, zagadnień dotyczących niezawodności i optymalizacji kosztów dla usługi AKS, zobacz Architektura punktu odniesienia usługi Azure Kubernetes Service (AKS).
Terminologia
W tym artykule jest używana następująca terminologia:
Termin | Definicja |
---|---|
Fizyczny host lokalny platformy Azure | Fizyczny węzeł klastra lokalnego platformy Azure hostujący maszyny wirtualne potrzebne do uruchomienia usługi AKS włączonej przez usługę Arc. |
System operacyjny gościa | System operacyjny działający wewnątrz maszyny wirtualnej płaszczyzny sterowania, maszyny wirtualnej modułu równoważenia obciążenia lub maszyn wirtualnych puli węzłów. |
Klaster trybu failover | Klaster trybu failover dla usługi Azure Local i Windows Server udostępnia funkcje infrastruktury, które obsługują wysoką dostępność maszyn wirtualnych i aplikacji. Jeśli węzeł klastra lub usługa ulegnie awarii, maszyny wirtualne lub aplikacje hostowane w tym węźle mogą być automatycznie lub ręcznie przenoszone do innego dostępnego węzła w procesie znanym jako tryb failover. |
Klaster obciążeń | Klaster Kubernetes wdrożony przez usługę Azure Kubernetes Service (AKS) do hostowania konteneryzowanej aplikacji lub obciążenia użytkownika końcowego, nazywanego również klastrem docelowym. |
Klaster zarządzania (host usługi AKS) | Udostępnia podstawowy mechanizm orkiestracji i interfejs do wdrażania co najmniej jednego klastra obciążenia i zarządzania nim. Klaster zarządzania zawiera jedną maszynę wirtualną płaszczyzny sterowania. |
Moduł równoważenia obciążenia | Jedna dedykowana maszyna wirtualna z systemem Linux z regułą równoważenia obciążenia dla serwera interfejsu API. |
Serwer interfejsu API | Umożliwia interakcję z klastrem Kubernetes, zapewniając interakcję z narzędziami do zarządzania, takimi jak Windows Admin Center, moduły programu PowerShell i kubectl . |
CRUD | Operacje tworzenia, odczytu, aktualizacji i usuwania. |
Scenariusze dostępności i ich wpływ na klaster usługi AKS z dwoma węzłami
Architektura skalowana w dół we wdrożeniu lokalnym platformy Azure z dwoma węzłami fizycznymi obejmuje pewne kompromisy w zakresie dostępności. W tej sekcji opisano zachowanie węzła podczas następujących trybów awarii i podczas aktualizacji:
- Aktualizacje
- Awaria sprzętu hosta
- Błąd systemu operacyjnego hosta
- Niepowodzenie maszyny wirtualnej płaszczyzny zarządzania
- Niepowodzenie maszyny wirtualnej płaszczyzny sterowania
- Niepowodzenie puli węzłów (węzła roboczego)
- Niepowodzenie maszyny wirtualnej modułu równoważenia obciążenia
Aktualizacje
Skorzystaj z poniższej tabeli, aby określić potencjalny wpływ aktualizacji usługi Azure Local i AKS na obciążenia:
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Brak zakłóceń | Brak zakłóceń | Brak zakłóceń | Brak zakłóceń |
Aktualizacja z obsługą klastra na żywo na platformie Azure lokalnie migruje węzły robocze do innego węzła przed ponownym uruchomieniem. Aplikacje nie są zakłócane podczas tej migracji. | Aktualizacja z obsługą klastra na żywo na platformie Azure lokalnie migruje maszynę wirtualną płaszczyzny sterowania klastra obciążenia do innego węzła przed ponownym uruchomieniem. Istniejące obciążenia można skalować bez zakłóceń podczas aktualizacji. | Aktualizacja z obsługą klastra na żywo na platformie Azure lokalnie migruje maszynę wirtualną płaszczyzny sterowania klastra zarządzania do innego węzła przed ponownym uruchomieniem. Nowe obciążenia można tworzyć bez zakłóceń podczas aktualizacji. | Aktualizacja z obsługą klastra na żywo na platformie Azure lokalnie migruje maszynę wirtualną płaszczyzny sterowania klastra obciążenia do innego węzła przed ponownym uruchomieniem. Klaster serwera interfejsu API pozostaje dostępny podczas aktualizacji. |
Awaria sprzętowa na hoście
Host fizyczny z uruchomionymi maszynami wirtualnymi hostującymi węzły Kubernetes może przestać działać z powodu problemów sprzętowych lub może stać się podzielony na partycje sieciowe.
Poniższa tabela umożliwia określenie potencjalnego wpływu awarii sprzętu hosta na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Istniejące obciążenia będą nadal działać bez zakłóceń, o ile: — Węzły procesu roboczego znajdują się na oddzielnych hostach. - Aplikacja zdefiniowała co najmniej dwie repliki z określoną określoną wartością podAntiAffinity .Jeśli aplikacja ma zależność od zewnętrznego wirtualnego adresu IP (VIP) serwera interfejsu API, wystąpi zakłócenia. |
Jeśli maszyna wirtualna płaszczyzny sterowania klastra obciążenia znajduje się na hoście, który spadł, obciążenia nie będą skalowane. Dodanie nowych węzłów roboczych i zasobników skalowania nie będzie działać. | Jeśli maszyna wirtualna płaszczyzny sterowania klastra zarządzania znajduje się na hoście, który spadł, nie można utworzyć nowych klastrów. Skalowanie istniejących klastrów nie będzie działać. | Jeśli maszyna wirtualna płaszczyzny sterowania klastra obciążenia lub maszyna wirtualna modułu równoważenia obciążenia znajduje się na hoście, który nie działa, serwer interfejsu API nie jest dostępny. |
Jeśli węzły procesu roboczego znajdują się na tym samym hoście fizycznym, klaster trybu failover przełączenie w tryb failover w tryb failover węzłów procesu roboczego na ocalałym hoście. Jeśli aplikacja nie została utworzona z anty-koligacją, platforma Kubernetes przenosi zasobnik do istniejącego węzła roboczego. Jeśli aplikacja zależy od serwera interfejsu API, a maszyna wirtualna płaszczyzny sterowania lub maszyna wirtualna modułu równoważenia obciążenia klastra obciążenia ulegnie awarii, klaster trybu failover przenosi te maszyny wirtualne na host ocalały, a aplikacja wznowi działanie. W zależności od tego, jak aplikacja obsługuje utratę serwera interfejsu API, zasobniki mogą zostać uruchomione ponownie na nowym hoście. |
Klaster trybu failover przejmie maszynę wirtualną płaszczyzny sterowania klastra obciążenia do hosta w dobrej kondycji. Po przejściu w tryb failover obciążenia można skalować. | Klaster trybu failover kończy się niepowodzeniem przez maszynę wirtualną płaszczyzny sterowania klastra zarządzania na hoście w dobrej kondycji. Po przejściu w tryb failover operacje CRUD w nowych klastrach docelowych działają. | Klaster trybu failover w trybie failover przejmie maszynę wirtualną płaszczyzny sterowania klastra obciążenia na hoście w dobrej kondycji. Po przejściu w tryb failover serwer interfejsu API jest dostępny. |
Błąd systemu operacyjnego hosta
Host fizyczny z uruchomionymi maszynami wirtualnymi hostującymi węzły Kubernetes może mieć problem z oprogramowaniem w systemie operacyjnym i powodować awarię.
Skorzystaj z poniższej tabeli, aby określić potencjalny wpływ awarii systemu operacyjnego hosta na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Istniejące obciążenia będą nadal działać bez zakłóceń, o ile: — Węzły procesu roboczego znajdują się na oddzielnych hostach. - Aplikacja zdefiniowała co najmniej dwie repliki z określoną określoną wartością podAntiAffinity .Jeśli aplikacja ma zależność od zewnętrznego adresu VIP serwera interfejsu API, wystąpi zakłócenia. |
Jeśli maszyna wirtualna płaszczyzny sterowania w klastrze docelowym znajduje się na hoście z błędami systemu operacyjnego, dodanie nowych węzłów procesu roboczego i zasobników skalowania nie będzie działać. | Jeśli maszyna wirtualna płaszczyzny sterowania klastra zarządzania znajduje się na hoście z błędami systemu operacyjnego, nowe klastry nie zostaną utworzone, a istniejące klastry nie będą skalowane. | Jeśli maszyna wirtualna płaszczyzny sterowania znajduje się na hoście z błędami systemu operacyjnego, serwer interfejsu API nie będzie dostępny. |
Jeśli węzły procesu roboczego znajdują się na tym samym hoście fizycznym, klaster trybu failover przełączenie w tryb failover w tryb failover węzłów procesu roboczego na ocalałym hoście. Jeśli aplikacja nie została utworzona z anty-koligacją, platforma Kubernetes przeniesie zasobnik do istniejącego węzła roboczego. Jeśli aplikacja ma zależność od serwera interfejsu API, a maszyna wirtualna płaszczyzny sterowania lub maszyna wirtualna modułu równoważenia obciążenia klastra obciążenia zostanie zamknięta, klaster trybu failover przenosi te maszyny wirtualne na host ocalały, a aplikacja zostanie wznowiony. W zależności od tego, jak aplikacja obsługuje utratę serwera interfejsu API, zasobniki mogą zostać uruchomione ponownie na nowym hoście. |
Klaster trybu failover w trybie failover przejmie maszynę wirtualną płaszczyzny sterowania klastra obciążenia na hoście w dobrej kondycji. Po przejściu w tryb failover obciążenia można skalować. | Klaster trybu failover kończy się niepowodzeniem przez maszynę wirtualną płaszczyzny sterowania klastra zarządzania na hoście w dobrej kondycji. Po przejściu w tryb failover operacje CRUD w nowych klastrach docelowych będą działać. | Klaster trybu failover uruchamia ponownie maszynę wirtualną płaszczyzny sterowania klastra obciążenia na hoście w dobrej kondycji. Następnie serwer interfejsu API jest dostępny. |
Niepowodzenie maszyny wirtualnej płaszczyzny zarządzania
Maszyna wirtualna płaszczyzny sterowania klastra zarządzania może zostać nieoczekiwanie usunięta, dysk rozruchowy może zostać uszkodzony lub maszyna wirtualna płaszczyzny sterowania klastra zarządzania może nie zostać uruchomiona z powodu problemów z systemem operacyjnym.
Poniższa tabela umożliwia określenie potencjalnego wpływu awarii maszyny wirtualnej płaszczyzny sterowania klastra zarządzania na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Brak zakłóceń |
Zakłócenie + Odzyskiwanie ręczne |
Zakłócenie + Odzyskiwanie ręczne |
Brak zakłóceń |
Istniejące obciążenia będą nadal działać, jeśli maszyna wirtualna klastra zarządzania ulegnie awarii. | Nie można dodać węzłów procesu roboczego do skalowania aplikacji. | Tworzenie nowego obciążenia nie powiedzie się, gdy klaster zarządzania nie działa. | Serwer interfejsu API powinien pozostać dostępny w przypadku awarii maszyny wirtualnej klastra zarządzania. |
Nie dotyczy | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną płaszczyzny zarządzania na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, klaster zarządzania musi zostać skompilowany ręcznie. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną płaszczyzny zarządzania na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, klaster zarządzania musi zostać skompilowany ręcznie. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. | Nie dotyczy |
Niepowodzenie maszyny wirtualnej płaszczyzny sterowania
Maszyna wirtualna płaszczyzny sterowania klastra obciążenia może zostać nieoczekiwanie usunięta, dysk rozruchowy może zostać uszkodzony lub maszyna wirtualna może nie zostać uruchomiona z powodu problemów z systemem operacyjnym.
Poniższa tabela umożliwia określenie potencjalnego wpływu awarii maszyny wirtualnej płaszczyzny sterowania klastra obciążenia na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Brak zakłóceń |
Zakłócenie + Odzyskiwanie ręczne |
Brak zakłóceń |
Zakłócenie + Odzyskiwanie ręczne |
Istniejące obciążenia będą nadal działać bez zakłóceń, o ile: — Węzły procesu roboczego znajdują się na oddzielnych hostach. - Aplikacja zdefiniowała co najmniej dwie repliki z określoną określoną wartością podAntiAffinity .Jeśli aplikacja ma zależność od zewnętrznego adresu VIP serwera interfejsu API, wystąpi zakłócenia. |
Nie można skalować obciążeń, gdy maszyna wirtualna płaszczyzny sterowania jest w stanie niepowodzenia. Dodanie nowych węzłów roboczych i zasobników skalowania nie będzie działać. | Tworzenie nowego obciążenia zakończy się pomyślnie. | Serwer interfejsu API nie jest dostępny, gdy maszyna wirtualna płaszczyzny sterowania jest w stanie niepowodzenia. |
Nie dotyczy | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną płaszczyzny sterowania na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, maszyna wirtualna płaszczyzny sterowania musi zostać ponownie skompilowana ręcznie. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. | Nie dotyczy | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną płaszczyzny sterowania na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, maszyna wirtualna płaszczyzny sterowania musi zostać ponownie skompilowana ręcznie. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. |
Niepowodzenie maszyny wirtualnej puli węzłów (węzłów procesu roboczego)
Maszyny wirtualne obsługujące węzły Kubernetes mogą zostać nieoczekiwanie usunięte, dysk rozruchowy może zostać uszkodzony lub maszyny wirtualne mogą nie zostać uruchomione z powodu problemów z systemem operacyjnym.
Poniższa tabela umożliwia określenie potencjalnego wpływu awarii maszyny wirtualnej w puli węzłów Kubernetes na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Potencjalne zakłócenia + Odzyskiwanie ręczne |
Brak zakłóceń | Brak zakłóceń | Brak zakłóceń |
Istniejące obciążenia będą nadal działać bez zakłóceń, o ile: — Węzły procesu roboczego znajdują się na oddzielnych hostach. - Aplikacja zdefiniowała co najmniej dwie repliki z określoną określoną wartością podAntiAffinity . |
Węzły robocze można dodawać. Planowanie zasobników powiedzie się, jeśli pozostałe węzły mają wystarczającą pojemność. |
Tworzenie nowego obciążenia zakończy się pomyślnie. | Serwer interfejsu API pozostaje dostępny w przypadku awarii pojedynczej maszyny wirtualnej procesu roboczego. |
Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną płaszczyzny sterowania na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, należy ręcznie utworzyć węzły robocze. | Nie dotyczy | Nie dotyczy | Nie dotyczy |
Niepowodzenie maszyny wirtualnej modułu równoważenia obciążenia
Maszyna wirtualna modułu równoważenia obciążenia może zostać nieoczekiwanie usunięta, dysk rozruchowy może zostać uszkodzony lub maszyna wirtualna może nie zostać uruchomiona z powodu problemów z systemem operacyjnym.
Poniższa tabela umożliwia określenie potencjalnego wpływu awarii maszyny wirtualnej modułu równoważenia obciążenia na obciążenia.
Istniejące obciążenia | CruD w klastrach obciążeń | Nowy cykl życia klastra obciążeń | Dostępność serwera interfejsu API |
---|---|---|---|
Potencjalne zakłócenia + Automatyczne odzyskiwanie |
Zakłócenie + Odzyskiwanie ręczne |
Brak zakłóceń |
Zakłócenie + Odzyskiwanie ręczne |
Istniejące obciążenia będą nadal działać bez zakłóceń, o ile: — Węzły procesu roboczego znajdują się na oddzielnych hostach. - Aplikacja zdefiniowała co najmniej dwie repliki z określoną określoną wartością podAntiAffinity .Jeśli aplikacja ma zależność od zewnętrznego adresu VIP serwera interfejsu API, wystąpi zakłócenia. |
Nie można skalować obciążeń, gdy maszyna wirtualna modułu równoważenia obciążenia jest w stanie niepowodzenia. Dodanie nowych węzłów roboczych i zasobników skalowania nie będzie działać. | Tworzenie obciążenia kończy się pomyślnie. | Serwer interfejsu API pozostaje niedostępny, gdy maszyna wirtualna modułu równoważenia obciążenia nie działa. |
Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną modułu równoważenia obciążenia na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, należy ręcznie skompilować maszynę wirtualną płaszczyzny sterowania. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną modułu równoważenia obciążenia na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, należy ręcznie skompilować maszynę wirtualną płaszczyzny sterowania. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. | Nie dotyczy | Jeśli klaster trybu failover może odzyskać po błędzie, spróbuje ponownie uruchomić maszynę wirtualną modułu równoważenia obciążenia na innym hoście. Jeśli klaster trybu failover nie może odzyskać maszyny wirtualnej, należy ręcznie skompilować maszynę wirtualną płaszczyzny sterowania. Aby uzyskać instrukcje, zobacz Tworzenie kopii zapasowych i przywracanie klastrów obciążeń. |
Następne kroki
- Dowiedz się więcej o architekturze punktu odniesienia usługi AKS, strategiach wdrażania klastra oraz zagadnieniach dotyczących niezawodności i cen
- Planowanie architektury
- Obliczenie kosztów za pomocą kalkulatora cen platformy Azure