Dostępność aplikacji w usłudze AKS włączona przez usługę Azure Arc

Dotyczy: usługa AKS w usłudze Azure Stack HCI 22H2, AKS w systemie Windows Server

Azure Kubernetes Service (AKS) włączone przez usługę Azure Arc oferuje w pełni obsługiwaną platformę kontenerów, która może uruchamiać aplikacje natywne dla chmury na platformie orkiestracji kontenerów Kubernetes. Architektura obsługuje uruchamianie zwirtualizowanych obciążeń systemów Windows i Linux.

Architektura usługi AKS jest tworzona z klastrami trybu failover i migracją na żywo, która jest automatycznie włączona dla klastrów docelowych (obciążeń). Podczas różnych zdarzeń zakłóceń maszyny wirtualne, które hostują obciążenia klientów, są swobodnie przenoszone bez postrzeganego przestoju aplikacji. Oznacza to, że tradycyjny klient korporacyjny, który zarządza starszą aplikacją jako pojedyncza aplikacja do usługi AKS w usłudze Azure Stack HCI lub Windows Server, będzie mieć podobny (lub lepszy) czas pracy niż to, czego obecnie doświadcza starsza aplikacja maszyny wirtualnej.

W tym artykule opisano niektóre podstawowe pojęcia dla użytkowników, którzy chcą uruchamiać konteneryzowane aplikacje w usłudze AKS Arc z włączoną migracją na żywo w celu zapewnienia dostępności aplikacji podczas zakłóceń. Terminologia platformy Kubernetes, taka jak dobrowolne zakłócenia i nieumyślne zakłócenia, służy do odwoływania się do przestoju aplikacji działającej w zasobniku.

Co to jest migracja na żywo?

Migracja na żywo to funkcja hyper-V, która umożliwia przezroczyste przenoszenie uruchomionych maszyn wirtualnych z jednego hosta funkcji Hyper-V do innego bez zauważalnego przestoju. Główną zaletą migracji na żywo jest elastyczność; uruchomione maszyny wirtualne nie są powiązane z jedną maszyną hosta. Dzięki temu użytkownicy mogą wykonywać akcje, takie jak opróżnianie określonego hosta maszyn wirtualnych przed zlikwidowaniem lub uaktualnieniem hosta. W połączeniu z klastrem trybu failover systemu Windows migracja na żywo umożliwia tworzenie systemów o wysokiej dostępności i odpornych na błędy.

Bieżąca architektura usługi AKS w usłudze Azure Stack HCI i systemie Windows Server zakłada, że klienci mają włączoną migrację na żywo w środowisku klastrowanym usługi Azure Stack HCI. W związku z tym wszystkie maszyny wirtualne węzła roboczego kubernetes zostaną utworzone przy użyciu skonfigurowanej migracji na żywo. Te węzły można przenosić wokół hostów fizycznych w przypadku zakłóceń w celu zapewnienia wysokiej dostępności platformy.

W przypadku klienta, który uruchamia starszą aplikację jako pojedynczą częścią platformy Kubernetes, ta architektura spełnia ich potrzeby dotyczące wysokiej dostępności. Platforma Kubernetes będzie zarządzać planowaniem zasobników w dostępnych węzłach roboczych, podczas gdy migracja na żywo będzie zarządzać planowaniem maszyn wirtualnych węzłów roboczych na dostępnych hostach fizycznych.

Scenariusze zakłóceń aplikacji

Badanie porównawcze czasów odzyskiwania aplikacji działających na maszynach wirtualnych w usłudze AKS w usłudze Azure Stack HCI i systemie Windows Server wyraźnie pokazuje, że w przypadku wystąpienia typowych zdarzeń zakłóceń istnieje minimalny wpływ na aplikację. Trzy przykładowe scenariusze zakłóceń obejmują:

• Zastosowanie aktualizacji, która powoduje ponowne uruchomienie maszyny fizycznej.
• Zastosowanie aktualizacji obejmującej ponowne utworzenie węzła procesu roboczego.
• Nieplanowana awaria sprzętowa maszyny fizycznej.

Uwaga

W tych scenariuszach założono, że właściciel aplikacji nadal używa koligacji Kubernetes i ustawień ochrony koligacji w celu zapewnienia prawidłowego planowania zasobników w węzłach roboczych.

Zdarzenie zakłóceń	Uruchamianie aplikacji na maszynach wirtualnych w usłudze Azure Stack HCI	Uruchamianie aplikacji na maszynach wirtualnych w usłudze AKS w usłudze Azure Stack HCI lub Windows Server
Zastosowanie aktualizacji, która powoduje ponowne uruchomienie maszyny fizycznej	Brak wpływu	Brak wpływu
Zastosowanie aktualizacji obejmującej ponowne utworzenie węzła procesu roboczego (lub ponowne uruchomienie maszyny wirtualnej)	Brak wpływu	Różnie
Nieplanowana awaria sprzętowa maszyny fizycznej	6–8 minut	6–8 minut

Zastosowanie aktualizacji, która powoduje ponowne uruchomienie maszyny fizycznej

Podczas zdarzenia konserwacji hosta fizycznego, takiego jak zastosowanie aktualizacji, która powoduje ponowne uruchomienie maszyny hosta, nie ma żadnego wpływu na aplikacje uruchomione w klastrze. Administrator klastra opróżni host i upewni się, że wszystkie maszyny wirtualne są migrowane na żywo przed zastosowaniem aktualizacji.

Stosowanie aktualizacji obejmującej ponowne utworzenie węzła procesu roboczego

Ten scenariusz obejmuje wyłączenie maszyny wirtualnej węzła roboczego w celu przeprowadzenia rutynowej konserwacji. Aby przygotować się do aktualizacji, administrator klastra opróżni i wyizoluje węzeł, więc wszystkie zasobniki są eksmitowane do dostępnego węzła procesu roboczego przed zastosowaniem aktualizacji. Po zakończeniu aktualizacji węzeł roboczy zostanie ponownie dodany i udostępniony do planowania.

Uwaga

Dostępność aplikacji będzie się różnić w zależności od czasu pobierania obrazu kontenera podstawowego, szczególnie w przypadku większych obrazów przechowywanych w chmurze publicznej. W związku z tym zaleca się używanie małych podstawowych obrazów kontenerów, a w przypadku kontenerów systemu Windows zaleca się użycie obrazu podstawowego nano server .

Nieplanowana awaria sprzętowa maszyny fizycznej

W tym scenariuszu do maszyny fizycznej hostująca starszy kontener/zasobnik aplikacji na jednej z maszyn wirtualnych węzła roboczego występuje zdarzenie zakłóceń. Klaster trybu failover umieści hosta w stanie izolowanym, a następnie po upływie od 6 do 8 minut rozpocznie proces migracji na żywo tych maszyn wirtualnych do zachowanych hostów. W takim przypadku przestój aplikacji jest odpowiednikiem czasu ponownego uruchomienia maszyn wirtualnych hosta i węzła roboczego.

Podsumowanie

Technologie klastrowania trybu failover usługi AKS zostały zaprojektowane w celu zapewnienia, że środowiska obliczeniowe w usługach Azure Stack HCI i Windows Server są wysoce dostępne i odporne na uszkodzenia. Jednak właściciel aplikacji nadal musi skonfigurować wdrożenia w celu korzystania z funkcji platformy Kubernetes, takich jak Deployments, Affinity Mapping, RelicaSets, w celu zapewnienia odporności zasobników w scenariuszach zakłóceń.