Aggiornare un cluster Azure Red Hat OpenShift con piani di controllo ospitati (anteprima)

Aggiorna Azure Red Hat OpenShift con cluster con piani di controllo ospitati per accedere a nuove funzionalità di OpenShift, aggiornamenti di sicurezza e correzioni di bug. Azure Red Hat OpenShift con piani di controllo ospitati usa un modello di aggiornamento disaccoppiato in cui il piano di controllo e i pool di nodi vengono aggiornati in modo indipendente. Usa questo modello di aggiornamento per pianificare gli aggiornamenti del control plane y-stream e dei node pool in linea con le finestre di manutenzione.

Prerequisiti

• Un cluster Azure Red Hat OpenShift esistente con piani di controllo ospitati.
• interfaccia della riga di comando di Azure versione 2.67.0 o successiva. Per installare o aggiornare, vedere Installare l'interfaccia della riga di comando di Azure.

• L'estensione CLI di ARO HCP è installata. Se è necessario installarlo, eseguire az extension add --name aro.

• Il ruolo Collaboratore e il ruolo Amministratore dell'accesso utenti (o il ruolo Proprietario) per il gruppo di risorse o la sottoscrizione che contiene il cluster.

Funzionamento degli aggiornamenti

Azure Red Hat OpenShift con piani di controllo ospitati usa un modello di aggiornamento disaccoppiato in cui il piano di controllo e i pool di nodi vengono aggiornati in modo indipendente, con regole di compatibilità delle versioni che regolano le combinazioni supportate.

Aggiornamenti del piano di controllo

Esistono due tipi di aggiornamenti del piano di controllo:

• Aggiornamenti di Z stream (patch): i tecnici dell'affidabilità del sito Red Hat applicano automaticamente questi aggiornamenti. Gli aggiornamenti Z-stream sono aggiornamenti di manutenzione all'interno della stessa versione minore, ad esempio il passaggio da 4.22.1 a 4.22.2. Questi aggiornamenti applicano correzioni di bug e sicurezza senza bloccare le operazioni del cluster. È possibile continuare a creare pool di nodi, ridimensionare i carichi di lavoro e distribuire applicazioni durante l'aggiornamento del piano di controllo a una nuova versione di z-stream. Non è necessario eseguire alcuna azione per gli aggiornamenti del piano di controllo z-stream.

• Aggiornamenti Y-stream (versione secondaria): per avviare questi aggiornamenti, usa interfaccia della riga di comando di Azure. Gli aggiornamenti del flusso Y spostano il piano di controllo in una nuova versione secondaria, ad esempio l'aggiornamento dalla versione 4.21 alla versione 4.22. È possibile controllare quando vengono eseguiti gli aggiornamenti del flusso y in modo da poter allineare gli aggiornamenti ai processi di gestione delle modifiche e alle finestre di manutenzione.

Aggiornamenti del pool di nodi

Avvii sempre gli aggiornamenti del pool di nodi, sia per le versioni z-stream sia per le versioni y-stream. Gli aggiornamenti del pool di nodi usano una strategia di sostituzione in sequenza che sostituisce ogni nodo nel pool di nodi durante il processo di aggiornamento. È possibile aggiornare più pool di nodi contemporaneamente.

Combinazioni di versioni supportate

Prima di aggiornare il cluster, comprendere i vincoli di asimmetria della versione tra il piano di controllo e i pool di nodi. La violazione di questi vincoli può lasciare il cluster in uno stato non supportato.

Si applicano le seguenti regole:

• La versione secondaria del pool di nodi non deve superare la versione secondaria del piano di controllo. Un pool di nodi può eseguire una versione z-stream (patch) più recente del control plane nell'ambito della stessa versione secondaria. Aggiornare sempre il piano di controllo a una versione secondaria di destinazione prima di aggiornare tutti i pool di nodi a tale versione secondaria.
• Finestra di supporto di due versioni minori. Il piano di controllo supporta i pool di nodi entro due versioni secondarie dello y-stream. Ad esempio, un piano di controllo che esegue la versione 4.22 supporta i pool di nodi che eseguono la versione 4.21 e 4.20, ma non supporta i pool di nodi che eseguono la versione 4.19.
• Fino a due salti di versione minore. È possibile aggiornare un pool di nodi a una versione più recente di z-stream all'interno della stessa versione secondaria o passare a due versioni secondarie. Ad esempio, è possibile aggiornare un pool di nodi dalla versione 4.20.z alla versione 4.22.z, ma non dalla versione 4.20.z alla versione 4.23.z. La versione di destinazione non deve superare la versione secondaria del piano di controllo.

La tabella seguente mostra esempi di combinazioni di versioni consentite e non consentite:

Controllare la versione corrente del cluster

Prima di eseguire l'aggiornamento, controllare la versione corrente di OpenShift del cluster.

oc get clusterversion version

L'output mostra la versione corrente di OpenShift:

NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.20.26   True        False         70s     Cluster version is 4.20.26

Aggiornare il piano di controllo

Per aggiornare il piano di controllo a una nuova versione secondaria (flusso y), elencare le versioni disponibili e quindi avviare l'aggiornamento usando interfaccia della riga di comando di Azure.

1. Imposta le variabili di ambiente per il tuo gruppo di risorse, il nome del cluster e l'area geografica di Azure, se non l'hai già fatto:

   CUSTOMER_RG_NAME="<resource-group-name>"
   CLUSTER_NAME="<cluster-name>"
   LOCATION="<azure-region>"
   

2. Elencare le versioni di OpenShift disponibili nell'area Azure eseguendo il comando seguente:

   az aro hcp get-versions \
     --location "${LOCATION}" \
     --query "[].{name:Name, channelGroup:ChannelGroup}" \
     --output table
   

   L'output elenca le versioni disponibili:

   Name     ChannelGroup
   -------  --------------
   4.22.0   stable
   4.22.1   stable
   4.22.2   stable
   4.22.3   stable
   ...
   

3. Identificare la versione di destinazione per l'aggiornamento. È possibile eseguire l'aggiornamento solo alla versione minore successiva. Ad esempio, se il piano di controllo esegue la versione 4.20, è possibile eseguire l'aggiornamento alla versione 4.21, ma non direttamente alla versione 4.22.

4. Aggiornare il piano di controllo eseguendo il comando seguente. Sostituire <target-version> con la versione di OpenShift desiderata, ad esempio 4.22:

   az aro hcp cluster update \
     --name "${CLUSTER_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --version "<target-version>"
   

5. Verificare che la richiesta di aggiornamento sia stata accettata controllando lo stato di provisioning:

   az aro hcp cluster show \
     --name "${CLUSTER_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "{version:properties.version, provisioningState:properties.provisioningState}"
   

   provisioningState Quando restituisce Succeeded, il servizio convalida il percorso di aggiornamento dalla versione corrente alla versione di destinazione e attiva l'aggiornamento. L'aggiornamento viene eseguito in background senza bloccare altre operazioni nel cluster. Se restituisce provisioningStateFailed, il servizio non è riuscito a convalidare il percorso di aggiornamento.

Aggiornare un pool di nodi

Dopo aver aggiornato il piano di controllo, è possibile aggiornare uno o più pool di nodi a una versione compatibile. Gli aggiornamenti del pool di nodi usano una strategia di sostituzione in sequenza che sostituisce ogni nodo durante il processo di aggiornamento.

1. Imposta le variabili di ambiente per il gruppo di risorse, il nome del cluster, il nome del pool di nodi e l'area di Azure, se non l'hai già fatto:

   CUSTOMER_RG_NAME="<resource-group-name>"
   CLUSTER_NAME="<cluster-name>"
   NODE_POOL_NAME="<node-pool-name>"
   LOCATION="<azure-region>"
   

2. Verificare la versione corrente del pool di nodi eseguendo il comando seguente:

   az aro hcp cluster nodepool show \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "properties.version"
   

3. Elencare le versioni di OpenShift disponibili nell'area Azure:

   az aro hcp get-versions \
     --location "${LOCATION}" \
     --query "[].{name:Name, channelGroup:ChannelGroup}" \
     --output table
   

4. Selezionare una versione di destinazione per il pool di nodi che soddisfi i criteri seguenti:

   • La versione secondaria di destinazione è minore o uguale alla versione secondaria del piano di controllo. Il pool di nodi può eseguire una versione di patch superiore rispetto al piano di controllo all'interno della stessa versione secondaria.
   • La versione di destinazione è una release z-stream più recente all’interno della stessa versione secondaria oppure fino a due versioni secondarie successive. Non è possibile saltare più di due versioni secondarie. Ad esempio, se il pool di nodi esegue la versione 4.19.3, è possibile eseguire l'aggiornamento a 4.19.5 (z-stream), 4.20.x (una versione secondaria) o 4.21.x (due versioni secondarie), ma non direttamente a 4.22.0.

5. Aggiornare il pool di nodi eseguendo il comando seguente. Sostituire <target-version> con la versione di OpenShift desiderata, ad esempio 4.22.3:

   az aro hcp cluster nodepool update \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --version "<target-version>"
   

   L'aggiornamento inizia immediatamente. Durante la sostituzione graduale, i nodi del pool di nodi funzionano temporaneamente sia con la versione precedente sia con quella nuova.

   Note

   La proprietà nodeDrainTimeoutMinutes di un pool di nodi determina per quanto tempo il cluster rispetta i carichi di lavoro protetti da un Pod Disruption Budget durante l'aggiornamento. Dopo questo periodo di tolleranza, il cluster rimuove forzatamente i carichi di lavoro rimanenti. Il valore predefinito eredita dall'impostazione a livello di cluster. È possibile impostare questo valore da 0 (svuotare senza limitazioni di tempo fino al completamento) a 10080 minuti (una settimana).

6. Verificare che la richiesta di aggiornamento sia stata accettata controllando lo stato di provisioning:

   az aro hcp cluster nodepool show \
     --cluster-name "${CLUSTER_NAME}" \
     --name "${NODE_POOL_NAME}" \
     --resource-group "${CUSTOMER_RG_NAME}" \
     --query "{version:properties.version, provisioningState:properties.provisioningState}"
   

   Quando provisioningState restituisce Succeeded, il servizio ha convalidato il percorso di aggiornamento e ha attivato l'aggiornamento del pool di nodi. L'aggiornamento viene eseguito in background senza bloccare altre operazioni nel pool di nodi.

7. Ripetere i passaggi da 2 a 6 per ogni pool di nodi da aggiornare. È possibile aggiornare più pool di nodi contemporaneamente.

Contenuti correlati

• Ciclo di vita del supporto di Azure Red Hat OpenShift
• Ridimensionare e configurare i pool di nodi