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. Ta architektura oznacza, ż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, ma podobny (lub lepszy) czas pracy niż w przypadku starszej aplikacji 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ść; uruchamianie maszyn wirtualnych nie jest 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 włączono migrację na żywo w środowisku klastrowanym usługi Azure Stack HCI. W związku z tym wszystkie maszyny wirtualne węzła roboczego kubernetes są tworzone 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.

Jeśli uruchamiasz starszą aplikację jako pojedynczą częścią platformy Kubernetes, ta architektura spełnia Twoje potrzeby dotyczące wysokiej dostępności. Platforma Kubernetes zarządza planowaniem zasobników w dostępnych węzłach roboczych, podczas gdy migracja na żywo 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
Zastosuj aktualizację, która obejmuje 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óżnia hosta i zapewnia, ż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óżnia i izoluje węzeł, aby wszystkie zasobniki zostały wykluczone z dostępnego węzła procesu roboczego przed zastosowaniem aktualizacji. Po zakończeniu aktualizacji węzeł roboczy jest ponownie dołączany i udostępniany do planowania.

Uwaga

Dostępność aplikacji jest różna, ponieważ obejmuje czas potrzebny na pobranie 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 obrazów kontenerów podstawowych, 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 umieszcza hosta w stanie izolowanym, a następnie po upływie od 6 do 8 minut rozpoczyna 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ń.

Następne kroki

Omówienie usługi AKS w systemach Windows Server i Azure Stack HCI