Dostępność aplikacji w u usługi AKS na platformie Azure Stack HCI

Usługa AKS w Azure Stack HCI to w pełni obsługiwana platforma kontenerów, na której można uruchamiać aplikacje natywne dla chmury na platformie Kubernetes, która jest oparta na platformie orkiestracji kontenerów Kubernetes. Architektura obsługuje uruchamianie zwirtualizowanych obciążeń systemów Windows i Linux na Azure Stack HCI i Windows Server 2019 Datacenter.

Bieżąca architektura usługi AKS na platformie Azure Stack HCI jest łączona z klastrami trybu failover i migracją na żywo automatycznie włączaną dla klastrów docelowych (obciążeń). Podczas różnych 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 przenosi starszą aplikację jako pojedynczą do usługi AKS na platformie Azure Stack HCI, otrzyma podobny (lub lepszy) czas pracy niż ten, który jest obecnie doświadczany podczas uruchamiania starszej aplikacji na maszynach wirtualnych.

W tym temacie opisano niektóre podstawowe pojęcia dla użytkowników, którzy chcą uruchamiać konteneryzowane aplikacje w umacie AKS Azure Stack HCI z włączoną migracją na żywo, aby zapewnić, że aplikacje będą dostępne podczas zakłóceń. Terminologia kubernetes, taka jak dobrowolna przerwa w działaniu i mimowolne zakłócenia, jest używana w odniesieniu do przestoju aplikacji uruchomionej w zasobniku.

Co to jest migracja na żywo?

Migracja na żywo to funkcja funkcji Hyper-V, która umożliwia niewidoczne przenoszenie uruchomionych maszyn wirtualnych z jednego hosta funkcji Hyper-V do innego bez postrzeganego przestoju. Główną zaletą migracji na żywo jest elastyczność; Uruchomione maszyny wirtualne nie są powiązane z jedną maszyną hosta. Umożliwia to akcje, takie jak opróżnianie określonego hosta maszyn wirtualnych przed likwidacją lub uaktualnieniem hosta. W przypadku sparowania z klastrem trybu failover systemu Windows migracja na żywo umożliwia tworzenie systemów o wysokiej dostępnej i odporności na uszkodzenia.

W bieżącej architekturze usługi AKS na platformie Azure Stack HCI założono, że migracja na żywo jest włączona Azure Stack HCI środowisku klastrowym. W takim przypadku wszystkie maszyny wirtualne węzła roboczego kubernetes zostaną utworzone ze skonfigurowaną migracją na żywo. Te węzły można przenosić między hostami fizycznymi w przypadku zakłóceń w celu zapewnienia wysokiej dostępnej platformy.

Diagram przedstawiający usługę AKS w Azure Stack HCI z włączonym klastrem trybu failover

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

Diagram przedstawiający przykład starszej aplikacji uruchomionej jako pojedyncza

Scenariusze zakłóceń aplikacji

Badanie porównawcze czasów odzyskiwania dla aplikacji działających na platformach VMs i AKS na platformie Azure Stack HCI wyraźnie pokazuje, że występuje minimalny wpływ na aplikację w przypadku wystąpienia typowych zakłóceń. Oto trzy przykładowe scenariusze zakłóceń:

  • Zastosowanie aktualizacji, która powoduje ponowne uruchomienie komputera fizycznego.
  • Zastosowanie aktualizacji, która obejmuje ponownetworzenie 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 ustawień koligacji i koligacji kubernetes w celu zapewnienia odpowiedniego planowania zasobników między węzłami procesu roboczego.

Zdarzenie zakłóceń Dostępność aplikacji dla maszyn wirtualnych W UKS na platformie Azure Stack HCI Dostępność aplikacji dla usługi AKS na platformie Azure Stack HCI
Zastosowanie aktualizacji, która powoduje ponowne uruchomienie komputera fizycznego Brak wpływu Brak wpływu
Zastosowanie aktualizacji, która obejmuje ponowne uruchomienie węzła procesu roboczego (lub ponowne uruchomienie maszyny wirtualnej) Brak wpływu Różnie
Nieplanowana awaria sprzętowa maszyny fizycznej 6–8 min 6–8 min

Zastosowanie aktualizacji, która powoduje ponowne uruchomienie komputera fizycznego

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

Stosowanie aktualizacji, która obejmuje ponownetworzenie węzła procesu roboczego

Ten scenariusz obejmuje sprowadzenie maszyny wirtualnej węzła roboczego w celu przeprowadzenia rutynowej konserwacji. Aby przygotować się do aktualizacji, administrator klastra opróżniłby i wyizolował węzeł, dzięki czemu wszystkie zasobniki zostaną eksmisje do dostępnego węzła roboczego przed zastosowaniem aktualizacji. Po zakończeniu aktualizacji węzeł procesu roboczego zostanie ponownie przyłączony i będzie dostępny do planowania.

Uwaga

Dostępność aplikacji będzie różna, ponieważ będzie obejmować czas pobierania podstawowego obrazu kontenera, 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żywanie obrazu nano server podstawowego.

Nieplanowana awaria sprzętowa maszyny fizycznej

W tym scenariuszu zdarzenie mimowolnych zakłóceń występuje na maszynie fizycznej hostującym starszy kontener aplikacji/zasobnik na jednej z maszyn wirtualnych węzła roboczego. Klaster trybu failover spowoduje, że host zostanie w stanie Izolowany, a następnie po upływie od 6 do 8 minut rozpocznie proces migracji na żywo tych maszyn wirtualnych do pozostałych hostów. W takim przypadku przestój aplikacji jest odpowiednikiem czasu wymaganego do ponownego uruchomienia maszyn wirtualnych hosta i węzła procesu roboczego.

Podsumowanie

Technologie klastrów Azure Stack HCI i failover usługi AKS zaprojektowano w celu zapewnienia wysokiej dostępnej i odporności na uszkodzenia środowisk obliczeniowych. Jednak właściciel aplikacji nadal musi skonfigurować wdrożenia, aby używać funkcji rozwiązania Kubernetes, takich jak , , , w celu zapewnienia odporności zasobników w Deployments Affinity Mapping RelicaSets scenariuszach zakłóceń.