Upgrade modulu runtime clusteru z Azure CLI

Tento průvodce postupy vysvětluje kroky pro instalaci požadovaného Azure CLI a rozšíření potřebných pro interakci s operátorem Nexus.

Požadavky

1. Instalace Azure CLI musí být nainstalovaná.
2. Vyžaduje se rozšíření rozhraní příkazového networkcloud řádku. networkcloud Pokud rozšíření není nainstalované, můžete ho nainstalovat podle zde uvedených kroků.
3. Přístup k webu Azure Portal pro upgrade cílového clusteru
4. Musíte být přihlášeni ke stejnému předplatnému jako cílový cluster prostřednictvím az login
5. Cílový cluster musí být ve spuštěném stavu, přičemž všechny uzly řídicí roviny jsou v pořádku a 80 + % výpočetních uzlů ve spuštěném a v pořádku.

Vyhledání dostupných verzí modulu runtime

Prostřednictvím portálu

Pokud chcete najít dostupné upgradovatelné verze modulu runtime, přejděte na cílový cluster na webu Azure Portal. V podokně přehledu clusteru přejděte na kartu Dostupné verze upgradu.

Na kartě dostupné verze upgradu uvidíme různé verze clusteru, které jsou aktuálně k dispozici pro upgrade. Operátor může vybrat z uvedených cílových verzí modulu runtime. Po výběru pokračujte upgradem clusteru.

Přes Azure CLI

Dostupné upgrady se dají načíst přes Azure CLI:

az networkcloud cluster show --name "clusterName" --resource-group "resourceGroup"

Ve výstupu availableUpgradeVersions najdete vlastnost a podíváte se na targetClusterVersion pole:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Pokud nejsou dostupné upgrady clusteru, seznam bude prázdný.

Upgrade modulu runtime clusteru pomocí rozhraní příkazového řádku

Pokud chcete provést upgrade modulu runtime, použijte následující příkaz Azure CLI:

az networkcloud cluster update-version --cluster-name "clusterName" --target-cluster-version
  "versionNumber" --resource-group "resourceGroupName"

Upgrade modulu runtime je dlouhý proces. Upgrade nejprve upgraduje uzly pro správu a následně postupně rack podle racku pro pracovní uzly. Upgrade se považuje za dokončený, když bylo úspěšně upgradováno 80 % pracovních uzlů na rack a 100 % uzlů pro správu. Úlohy můžou být ovlivněné, zatímco pracovní uzly v racku probíhají v procesu upgradu, ale úlohy ve všech ostatních rackech nebudou ovlivněny. Vzhledem k tomuto návrhu implementace se doporučuje zvážit umístění úloh.

Upgrade všech uzlů trvá několik hodin, ale může to trvat i v případě, že jsou součástí upgradu i jiné procesy, jako jsou aktualizace firmwaru. Vzhledem k délce procesu upgradu se doporučuje pravidelně kontrolovat stav podrobností clusteru o aktuálním stavu upgradu. Pokud chcete zkontrolovat stav upgradu, podívejte se na podrobný stav clusteru. Tuto kontrolu můžete provést prostřednictvím portálu nebo az CLI.

Pokud chcete zobrazit stav upgradu prostřednictvím webu Azure Portal, přejděte k cílovému prostředku clusteru. Na obrazovce Přehled clusteru je k dispozici podrobný stav spolu s podrobnou stavovou zprávou.

Upgrade clusteru probíhá, když je podrobný stav nastavený na Updating a podrobný stav Zprávy ukazuje průběh upgradu. Některé příklady průběhu upgradu zobrazené v podrobnéStatusMessage jsou Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading...atd.

Upgrade clusteru je dokončen, když je podrobný stav nastaven na Running a podrobnéStatusMessage zobrazí zprávu. Cluster is up and running

Pokud chcete zobrazit stav upgradu prostřednictvím Azure CLI, použijte az networkcloud cluster show.

az networkcloud cluster show --cluster-name "clusterName" --resource-group "resourceGroupName"

Výstupem by měly být informace o cílovém clusteru a měl by se zobrazit podrobný stav clusteru a podrobná stavová zpráva. Podrobnější přehled o průběhu upgradu najdete v jednotlivých rackech pro jednotlivé nástroje BMM. Příklad je uveden v referenční části v části BareMetal Machine role.

Konfigurace parametrů prahové hodnoty výpočetních prostředků pro upgrade za běhu pomocí aktualizace clusteruStrategy

Následující příkaz Azure CLI slouží ke konfiguraci parametrů prahové hodnoty výpočetních prostředků pro upgrade modulu runtime:

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks>

Požadované parametry:

• typ strategie: Definuje strategii aktualizace. V takovém případě "Rack" znamená, že dojde k aktualizacím do racku. Výchozí hodnota je Rack.
• typ prahové hodnoty: Určuje, jak má být prahová hodnota vyhodnocena v jednotkách definovaných strategií. Výchozí hodnota je PercentSuccess.
• prahová hodnota: Číselná prahová hodnota použitá k vyhodnocení aktualizace. Výchozí hodnota je 80.

Volitelné parametry:

• max-unavailable: Maximální počet pracovních uzlů, které mohou být offline, tj. upgradované racky najednou. Výchozí hodnota je 32767.
• wait-time-minutes: Prodleva nebo čekací doba před aktualizací racku. Výchozí hodnota je 15.

Příklad použití příkazu je následující:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Po úspěšném spuštění příkazu se zadané hodnoty updateStrategy použijí v clusteru:

    "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    }

Upgrade s využitím strategie PauseRack

Počínaje rozhraním API verze 2024-06-01-Preview je možné aktivovat upgrady modulu runtime pomocí strategie PauseRack. Když spustíte upgrade modulu runtime clusteru s strategií PauseRack, aktualizuje se vždy jeden rack v clusteru a pak se zastaví a čeká na potvrzení před pokračováním do dalšího racku. Všechny stávající prahové hodnoty budou i nadále respektovány ve strategii PauseRack. Pokud chcete provést upgrade modulu runtime clusteru pomocí strategie PauseRack, postupujte podle kroků uvedených v tématu Upgrade modulu runtime clusteru se strategií pozastavení racku.

Nejčastější dotazy

Identifikace zablokovaného nebo zablokovaného upgradu clusteru

Během upgradu za běhu je možné, že se upgrade nepovede dopředu, ale podrobný stav odráží, že upgrade stále probíhá. Vzhledem k tomu, že dokončení upgradu za běhu může trvat velmi dlouho, není aktuálně zadaná délka časového limitu. Proto doporučujeme pravidelně kontrolovat stav a protokoly clusteru, abyste zjistili, jestli se upgrade nečasově pokouší upgradovat.

Když se podíváme na protokoly clusteru, podrobnou zprávu a podrobnou stavovou zprávu, můžeme zjistit, kdy se jedná o tento případ. Pokud dojde k vypršení časového limitu, zjistíme, že cluster neustále konkonciuje stejnou neomezenou dobu a nepřechází vpřed. Odsud doporučujeme zkontrolovat protokoly clusteru nebo nakonfigurovat ZÁKON, abyste zjistili, jestli nedošlo k selhání, nebo konkrétní upgrade, který způsobuje nedostatek pokroku.

Selhání hardwaru nevyžaduje opětovné spuštění upgradu

Pokud během upgradu dojde k selhání hardwaru, upgrade za běhu bude pokračovat, pokud jsou splněny nastavené prahové hodnoty pro výpočetní a řídicí uzly a správu a řízení. Jakmile je počítač pevný nebo nahrazený, zřídí se s operačním systémem aktuální platformy runtime, který obsahuje cílovou verzi modulu runtime.

Pokud dojde k selhání hardwaru a upgrade modulu runtime selhal, protože prahové hodnoty nebyly splněny pro výpočetní a řídicí uzly, může být potřeba opětovné spuštění upgradu za běhu v závislosti na tom, kdy došlo k selhání, a stavu jednotlivých serverů v racku. Pokud se rack aktualizoval před selháním, při opětovném zřízení uzlů by se použila upgradovaná verze modulu runtime. Pokud se specifikace racku neaktualizovala na upgradovanou verzi modulu runtime před selháním hardwaru, zřídí se počítač s předchozí verzí modulu runtime. Pokud chcete upgradovat na novou verzi modulu runtime, odešlete novou žádost o upgrade clusteru a upgradují se pouze uzly s předchozí verzí modulu runtime. Hostitelé, kteří byli úspěšní v předchozí akci upgradu, nebudou.

Po upgradu za běhu se v clusteru zobrazí stav zřizování selhal.

Během upgradu za běhu cluster přejde do stavu Upgrading. V případě selhání upgradu modulu runtime cluster přejde do Failed stavu zřizování. Selhání během upgradu můžou být způsobená komponentami infrastruktury (např. zařízením úložiště). V některých scénářích může být nutné diagnostikovat selhání pomocí podpory Microsoftu.

Dopad na úlohy tenanta Nexus Kubernetes během upgradu modulu runtime clusteru

Během upgradu za běhu se ovlivněné uzly clusteru Nexus Kubernetes vyprázdní a vyprázdní se před upgradem holých hostitelů (BMH). Připojení uzlu clusteru Kubernetes brání v plánování nových podů a vyprázdnění uzlu clusteru Kubernetes umožňuje podům, na kterých běží úlohy tenantů, možnost přesunout se na jiný dostupný uzel clusteru Kubernetes, což pomáhá snížit dopad na služby. Efektivita vyprázdnění mechanismu je podmíněná dostupnou kapacitou v rámci clusteru Nexus Kubernetes. Pokud se cluster Kubernetes blíží plné kapacitě a nemá prostor, aby se pody přemísťoval, přejdou po procesu vyprázdnění do stavu Čeká na vyřízení.

Po dokončení procesu cordonu a vyprázdnění uzlu clusteru tenanta pokračuje upgrade BMH. Každý uzel clusteru tenanta je povolený až 10 minut, než se dokončí proces vyprázdnění, po kterém se zahájí upgrade BMH. To zaručuje, že upgrade BMH bude pokračovat. BMH se upgradují po jednom racku a upgrady se provádějí paralelně v rámci stejného racku. Upgrade BMH nečeká, až se prostředky tenanta přejdou do režimu online, než budete pokračovat v upgradu BMHs v racku. Výhodou je, že maximální celková doba čekání na upgrade racku se uchovává na 10 minut bez ohledu na to, kolik uzlů je k dispozici. Tato maximální doba čekání je specifická pro postup odtoku a kabelu a nevztahuje se na celkový postup upgradu. Po dokončení každého upgradu BMH se spustí uzel clusteru Nexus Kubernetes, znovu se připojí ke clusteru a je bez opravy a umožní opětovné naplánování podů na uzlu.

Je důležité si uvědomit, že uzel clusteru Nexus Kubernetes se po procesu cordonu a vyprázdnění nevypíná. BMH se restartuje s novou imagí, jakmile se všechny uzly clusteru Nexus Kubernetes propojí a vyprázdní, po 10 minutách, pokud se proces vyprázdnění nedokončí. Kromě toho není kabel a vyprázdnění inicializováno pro akce vypnutí nebo restartování BMH; je aktivovaný výhradně během upgradu za běhu.

Je důležité si uvědomit, že po upgradu za běhu může existovat instance, kde uzel clusteru Nexus Kubernetes zůstává pod kabelem. V takovém scénáři můžete uzel ručně zrušit spuštěním následujícího příkazu.

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table