Dostupnost aplikací v AKS povolená službou Azure Arc

Platí pro: AKS ve Službě Azure Stack HCI 22H2, AKS na Windows Serveru

Azure Kubernetes Service (AKS) povolenou službou Azure Arc nabízí plně podporovanou kontejnerovou platformu, která může spouštět aplikace nativní pro cloud na platformě pro orchestraci kontejnerů Kubernetes. Architektura podporuje spouštění virtualizovaných úloh Windows a Linuxu.

Architektura AKS je vytvořená s clusteringem s podporou převzetí služeb při selhání a migrací za provozu, která se automaticky povoluje pro cílové clustery (úlohy). Během různých událostí přerušení se virtuální počítače, které hostují úlohy zákazníků, volně přesunují bez vnímaných výpadků aplikací. Tato architektura znamená, že tradiční podnikový zákazník, který spravuje starší verzi aplikace jako jediný objekt pro AKS ve službě Azure Stack HCI nebo Windows Server, získá podobnou (nebo lepší) dobu provozu než v současné době ve starších aplikacích virtuálních počítačů.

Tento článek popisuje některé základní koncepty pro uživatele, kteří chtějí spouštět kontejnerizované aplikace v AKS Arc s povolenou migrací za provozu, aby se zajistilo, že aplikace budou během přerušení k dispozici. Terminologie Kubernetes, jako je dobrovolné přerušení nebo nedobrovolné přerušení, se používá k označení výpadku aplikace spuštěné v podu.

Co je migrace za provozu?

Migrace za provozu je funkce Technologie Hyper-V, která umožňuje transparentně přesouvat spuštěné virtuální počítače z jednoho hostitele Hyper-V na jiného bez vnímaných výpadků. Hlavní výhodou migrace za provozu je flexibilita. spuštěné virtuální počítače nejsou vázané na jeden hostitelský počítač. To umožňuje uživatelům provádět akce, jako je vyprázdnění konkrétního hostitele virtuálních počítačů před vyřazením nebo upgradem hostitele. Ve spojení s clusteringem Windows s podporou převzetí služeb při selhání umožňuje migrace za provozu vytvoření vysoce dostupných systémů odolných proti chybám.

Aktuální architektura AKS ve službě Azure Stack HCI a Windows Server předpokládá, že jste povolili migraci za provozu v prostředí clusteru Azure Stack HCI. Proto se všechny virtuální počítače pracovních uzlů Kubernetes vytvoří s nakonfigurovanou migrací za provozu. Tyto uzly je možné přesunout po fyzických hostitelích v případě přerušení, aby byla platforma vysoce dostupná.

Když v Kubernetes spustíte starší verzi aplikace jako jednoúčelovou verzi, tato architektura splňuje vaše požadavky na vysokou dostupnost. Kubernetes spravuje plánování podů na dostupných pracovních uzlech, zatímco migrace za provozu spravuje plánování virtuálních počítačů pracovních uzlů na dostupných fyzických hostitelích.

Scénáře přerušení aplikace

Srovnávací studie doby obnovení aplikací běžících na virtuálních počítačích v AKS ve službě Azure Stack HCI a Windows Server jasně ukazuje, že když dojde k běžným událostem přerušení, má to na aplikaci minimální dopad. Mezi tři příklady scénářů přerušení patří:

• Použití aktualizace, která má za následek restartování fyzického počítače.
• Instalace aktualizace, která zahrnuje opětovné vytvoření pracovního uzlu.
• Neplánované selhání hardwaru fyzického počítače.

Poznámka

Tyto scénáře předpokládají, že vlastník aplikace stále používá nastavení spřažení Kubernetes a nastavení ochrany proti spřažení, aby zajistil správné plánování podů napříč pracovními uzly.

Událost přerušení	Spouštění aplikací ve virtuálních počítačích ve službě Azure Stack HCI	Spouštění aplikací ve virtuálních počítačích v AKS ve službě Azure Stack HCI nebo Windows Serveru
Použití aktualizace, která způsobí restartování fyzického počítače	Žádný dopad	Žádný dopad
Nainstalujte aktualizaci, která zahrnuje opětovné vytvoření pracovního uzlu (nebo restartování virtuálního počítače).	Žádný dopad	Různé
Neplánované selhání hardwaru fyzického počítače	6-8 minut	6-8 minut

Použití aktualizace, která způsobí restartování fyzického počítače

Během události údržby fyzického hostitele, jako je použití aktualizace, která má za následek restartování hostitelského počítače, se neočekává žádný dopad na aplikace spuštěné v clusteru. Správce clusteru vyprázdní hostitele a před instalací aktualizace zajistí migraci všech virtuálních počítačů za provozu.

Instalace aktualizace, která zahrnuje opětovné vytvoření pracovního uzlu

Tento scénář zahrnuje přenesení virtuálního počítače pracovního uzlu za účelem provádění běžné údržby. Aby se správce clusteru připravil na aktualizaci, vyprázdní a izoluje uzel, aby se všechny pody před instalací aktualizací vyřadily na dostupný pracovní uzel. Po dokončení aktualizace se pracovní uzel znovu připojí a zpřístupní se pro plánování.

Poznámka

Dostupnost aplikace se liší, protože zahrnuje dobu potřebnou ke stažení základní image kontejneru, zejména u větších imagí uložených ve veřejném cloudu. Proto se doporučuje používat malé základní image kontejneru a pro kontejnery Windows doporučujeme použít nano server základní image.

Neplánované selhání hardwaru fyzického počítače

V tomto scénáři dojde k nedobrovolné události přerušení fyzického počítače, který je hostitelem staršího kontejneru nebo podu aplikace v jednom z virtuálních počítačů pracovního uzlu. Clustering s podporou převzetí služeb při selhání umístí hostitele do izolovaného stavu a po uplynutí 6 až 8 minut zahájí proces migrace těchto virtuálních počítačů na přeživší hostitele za provozu. V tomto případě je výpadek aplikace ekvivalentem doby potřebné k restartování virtuálních počítačů hostitele a pracovního uzlu.

Závěr

Technologie clusteringu AKS s podporou převzetí služeb při selhání jsou navržené tak, aby výpočetní prostředí v Azure Stack HCI i Windows Serveru byla vysoce dostupná a odolná proti chybám. Vlastník aplikace ale stále musí nakonfigurovat nasazení tak, aby používala funkce Kubernetes, jako Deploymentsje , Affinity Mapping, RelicaSetsa zajistil tak odolnost podů ve scénářích přerušení.

Další kroky

Přehled AKS ve Windows Serveru a Azure Stack HCI