Aggiornamento di runtime del cluster dall'interfaccia della riga di comando di Azure

Articolo
09/26/2024

Questa guida pratica illustra i passaggi per installare l'interfaccia della riga di comando di Azure e le estensioni necessarie per interagire con Operator Nexus.

Prerequisiti

È necessario installare l'interfaccia della riga di comando di Azure.
È necessaria l'estensione dell'interfaccia della riga di comando networkcloud. Se l'estensione networkcloud non è installata, è possibile installarla seguendo i passaggi elencati qui.
Accesso al portale di Azure per l'aggiornamento del cluster di destinazione.
È necessario accedere alla stessa sottoscrizione del cluster di destinazione tramite az login
Il cluster di destinazione deve essere in esecuzione, con tutti i nodi del piano di controllo integri e più dell'80% dei nodi di calcolo in stato in corso di esecuzione e integri.

Ricerca delle versioni di runtime disponibili

Tramite il portale

Per trovare le versioni di runtime aggiornabili disponibili, passare al cluster di destinazione nel portale di Azure. Nel riquadro di panoramica del cluster passare alla scheda Versioni di aggiornamento disponibili.

Dalla scheda delle versioni di aggiornamento disponibili è possibile visualizzare le diverse versioni del cluster attualmente disponibili per l'aggiornamento. L'operatore può selezionare tra le versioni di runtime elencate. Dopo averlo selezionato, procedere all'aggiornamento del cluster.

Tramite l'interfaccia della riga di comando di Azure

Gli aggiornamenti disponibili possono essere recuperati tramite l'interfaccia della riga di comando di Azure:

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

Nell'output è possibile trovare la proprietà availableUpgradeVersions ed esaminare il campo targetClusterVersion:

  "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"
    }
  ],

Se non sono disponibili aggiornamenti del cluster disponibili, l'elenco sarà vuoto.

Aggiornamento di runtime del cluster tramite l'interfaccia della riga di comando

Per eseguire un aggiornamento di runtime, usare il comando seguente dell'interfaccia della riga di comando di Azure:

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

L'aggiornamento di runtime è un processo lungo. L'aggiornamento aggiorna prima i nodi di gestione e poi in sequenza rack per rack per i nodi di lavoro. L'aggiornamento si considera completato quando l'80% dei nodi di lavoro per rack e il 100% dei nodi di gestione sono stati aggiornati correttamente. I carichi di lavoro potrebbero subire ripercussioni durante l'aggiornamento dei nodi di lavoro in un rack; tuttavia, i carichi di lavoro in tutti gli altri rack non saranno interessati. È consigliabile considerare il posizionamento del carico di lavoro alla luce di questa progettazione di implementazione.

L'aggiornamento di tutti i nodi richiede diverse ore, ma può richiedere più tempo se altri processi, come gli aggiornamenti del firmware, fanno anche parte dell'aggiornamento. A causa della lunghezza del processo di aggiornamento, è consigliabile controllare periodicamente lo stato dei dettagli del cluster per lo stato corrente dell'aggiornamento. Per verificare lo stato dell'aggiornamento, osservare lo stato dettagliato del cluster. Questo controllo può essere eseguito tramite il portale o az CLI.

Per visualizzare lo stato di aggiornamento tramite il portale di Azure, passare alla risorsa cluster di destinazione. Nella schermata Panoramica del cluster viene fornito lo stato dettagliato insieme a un messaggio di stato dettagliato.

L'aggiornamento del cluster è in corso quando detailedStatus è impostato su Updating e detailedStatusMessage mostra lo stato di avanzamento dell'aggiornamento. Alcuni esempi di avanzamento dell'aggiornamento illustrati in detailedStatusMessage sono Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading... e così via.

L'aggiornamento del cluster è completo quando detailedStatus è impostato su Running e detailedStatusMessage mostra il messaggio Cluster is up and running

Per visualizzare lo stato di aggiornamento tramite l'interfaccia della riga di comando di Azure, usare az networkcloud cluster show.

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

L'output dovrebbe contenere le informazioni sul cluster di destinazione e dovrebbero essere presenti lo stato dettagliato del cluster e il messaggio di stato dettagliato. Per informazioni più dettagliate sullo stato dell'aggiornamento, è possibile verificare lo stato del singolo BMM in ogni rack. Questo esempio viene fornito nella sezione di riferimento in Ruoli computer BareMetal.

Configurare i parametri della soglia di calcolo per l'aggiornamento di runtime tramite cluster updateStrategy

Il comando dell'interfaccia della riga di comando di Azure seguente viene usato per configurare i parametri della soglia di calcolo per un aggiornamento di 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>

Parametri obbligatori:

strategy-type: definisce la strategia di aggiornamento. In questo caso, "Rack" indica che gli aggiornamenti avvengono rack per rack. Il valore predefinito è "Rack".
threshold-type: determina la modalità di valutazione della soglia, applicata nelle unità definite dalla strategia. Il valore predefinito è "PercentSuccess".
threshold-value: valore soglia numerico usato per valutare un aggiornamento. Il valore predefinito è 80.

Parametri facoltativi:

max-unavailable: numero massimo di nodi di lavoro che possono essere offline, ovvero un rack aggiornato alla volta. Il valore predefinito è 32767.
wait-time-minutes: il ritardo o il periodo di attesa prima di aggiornare un rack. Il valore predefinito è 15.

Di seguito è riportato un esempio di utilizzo del comando:

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

Se il comando viene eseguito correttamente, i valori di updateStrategy specificati verranno applicati al cluster:

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

Nota

Quando viene impostato un valore soglia inferiore al 100%, è possibile che tutti i nodi non integri non vengano aggiornati, ma lo stato "Cluster" potrebbe comunque indicare che l'aggiornamento è riuscito. Per la risoluzione dei problemi relativi ai computer bare metal, vedere Risoluzione dei problemi del server Operatore Nexus di Azure

Eseguire l'aggiornamento con la strategia PauseRack

A partire dalla versione API 2024-06-01-preview, gli aggiornamenti di runtime possono essere attivati utilizzando una strategia “PauseRack”. Quando si esegue un aggiornamento di runtime del cluster con la strategia PauseRack", verrà eseguito l'aggiornamento di un rack alla volta nel cluster e verrà quindi arrestato, in attesa di conferma prima di procedere con il rack successivo. Tutte le soglie esistenti continueranno a essere rispettate con la strategia “PauseRack”. Per eseguire un aggiornamento del runtime del cluster usando la strategia "PauseRack" seguire i passaggi descritti in Aggiornamento di runtime del cluster con la strategia PauseRack

Domande frequenti

Identificazione dell'aggiornamento del cluster In stallo/bloccato

Durante un aggiornamento di runtime, è possibile che l'aggiornamento non vada avanti e che lo stato dei dettagli indichi che l'aggiornamento è ancora in corso. Poiché l'aggiornamento di runtime può richiedere molto tempo per essere completato correttamente, non è stata specificata alcuna lunghezza di timeout.. È quindi consigliabile controllare periodicamente lo stato dei dettagli e i log del cluster per determinare se l'aggiornamento sta tentando di aggiornarsi a tempo indefinito.

È possibile identificare questi casi esaminando i log del cluster, i messaggi dettagliati e i messaggi di stato dettagliati. Se si è verificato un timeout, si osserverò che il cluster continua a riconciliarsi con lo stesso a tempo indefinito e non procede. Da qui è consigliabile controllare i log del cluster o il LAW configurato per verificare la presenza di un errore o un aggiornamento specifico che causa il mancato avanzamento.

L'errore hardware non richiede la riesecuzione dell'aggiornamento

Se si è verificato un errore hardware durante un aggiornamento, l'aggiornamento di runtime continua fino a quando vengono soddisfatte le soglie impostate per i nodi di calcolo e di gestione/controllo. Una volta corretto o sostituito il computer, viene eseguito il provisioning con il sistema operativo del runtime della piattaforma corrente, che contiene la versione di destinazione del runtime.

Se si verifica un errore hardware e l'aggiornamento di runtime non è riuscito perché le soglie non sono state soddisfatte per i nodi di calcolo e di controllo, potrebbe essere necessario eseguire di nuovo l'aggiornamento di runtime, a seconda del momento in cui si è verificato l'errore e lo stato dei singoli server in un rack. Se un rack è stato aggiornato prima di un errore, la versione aggiornata del runtime verrà usata quando i nodi verranno sottoposti a provisioning. Se le specifiche del rack non sono state aggiornate alla versione di runtime aggiornata prima dell'errore hardware, verrà eseguito il provisioning del computer con la versione di runtime precedente. Per eseguire l'aggiornamento alla nuova versione di runtime, inviare una nuova richiesta di aggiornamento del cluster e solo i nodi con la versione di runtime precedente verranno aggiornati. Gli host che hanno avuto esito positivo nell'azione di aggiornamento precedente non lo avranno.

Dopo un aggiornamento di runtime, il cluster mostra lo stato di provisioning "Non riuscito"

Durante un aggiornamento di runtime, il cluster entra in uno stato di Upgrading. In caso di errore dell'aggiornamento di runtime, il cluster passerà a uno stato di provisioning Failed. Gli errori durante l'aggiornamento possono essere causati dai componenti dell'infrastruttura (ad esempio l'appliance di archiviazione). In alcuni casi potrebbe essere necessario diagnosticare l'errore con il supporto Tecnico Microsoft.

Impatto sui carichi di lavoro del tenant Nexus Kubernetes durante l'aggiornamento del runtime del cluster

Durante un aggiornamento di runtime, i nodi del cluster Nexus Kubernetes interessati e vengono bloccati e svuotati prima che gli host Bare Metal (BMH) vengano aggiornati. Il blocco del nodo Kubernetes Cluster impedisce la programmazione di nuovi pod e lo svuotamento del nodo del cluster Kubernetes consente ai pod che eseguono carichi di lavoro dei tenant di passare a un altro nodo del cluster Kubernetes disponibile, riducendo così l'impatto sui servizi. L'efficacia del meccanismo di svuotamento dipende dalla capacità disponibile all'interno del cluster Nexus Kubernetes. Se il cluster Kubernetes sta per raggiungere la piena capacità e manca lo spazio per il trasferimento dei pod, questi passano allo stato In sospeso dopo il processo di svuotamento.

Dopo aver completato il processo di blocco e svuotamento del nodo cluster tenant, si procede con l'aggiornamento del BMH. Ogni nodo del cluster tenant ha a disposizione fino a 10 minuti per completare il processo di svuotamento, dopodiché inizierà l'aggiornamento del BMH. In questo modo viene garantito l'avanzamento dell'aggiornamento del BMH. Gli aggiornamenti BMH vengono eseguiti un rack alla volta e in parallelo all'interno dello stesso rack. L'aggiornamento del BMH non attende che le risorse del tenant siano online prima di continuare con l'aggiornamento di runtime dei BMH nel rack da aggiornare. Il vantaggio è che il tempo di attesa massimo complessivo per l'aggiornamento di un rack viene mantenuto a 10 minuti, indipendentemente dal numero di nodi disponibili. Questo tempo di attesa massimo è specifico per la procedura di blocco e svuotamento e non si applica alla procedura di aggiornamento generale. Al termine di ogni aggiornamento BMH, il nodo del cluster Nexus Kubernetes viene avviato, si ricongiunge al cluster e non è più bloccato, consentendo di pianificare nuovamente i pod nel nodo.

È importante notare che il nodo del cluster Nexus Kubernetes non verrà arrestato dopo il processo di blocco e svuotamento. Il BMH viene riavviato con la nuova immagine non appena tutti i nodi del cluster Nexus Kubernetes vengono bloccati e svuotati, dopo 10 minuti se il processo di svuotamento non viene completato. Inoltre, il blocco e lo svuotamento non vengono avviati in caso di spegnimento o riavvio del BMH, ma si attivano esclusivamente durante l'aggiornamento di runtime.

È importante notare che, dopo l'aggiornamento del runtime, potrebbero verificarsi casi in cui un nodo del cluster Nexus Kubernetes rimanga bloccato. In questo caso, è possibile sbloccare manualmente il nodo eseguendo il comando seguente

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

Condividi tramite