Eseguire il rollback delle versioni del pool di nodi in Servizio Azure Kubernetes (AKS)

La funzionalità di rollback della versione del pool di nodi in Servizio Azure Kubernetes (AKS) consente di eseguire il ripristino da comportamenti imprevisti dopo gli aggiornamenti di Kubernetes. In caso di problemi, è possibile eseguire il rollback dei pool di nodi alla precedente combinazione di versioni di Kubernetes e immagine del nodo, garantendo la continuità aziendale e riducendo al minimo i tempi di inattività. Questo articolo illustra quando e come usare la funzionalità di rollback, le relative funzionalità e limitazioni e le procedure consigliate per le azioni post-rollback.

Prerequisiti

interfaccia della riga di comando di Azure versione 2.88.0 o successiva. Trovare la versione usando il az --version comando . Se è necessario installare o aggiornare, vedere Installare interfaccia della riga di comando di Azure. L'estensione aks-preview non è necessaria.
Versione 2026-04-01 dell'API o successiva.

Funzionalità supportate per il rollback della versione del pool di nodi

La funzionalità di rollback della versione del pool di nodi supporta le funzionalità seguenti:

Caratteristica / Funzionalità	Descrzione
Ripristinare la versione	Ripristina sia Kubernetes che le versioni dell'immagine del nodo allo stato precedente.
Trigger manuale, esecuzione automatica	Il rollback richiede l'avvio manuale, ma una volta attivato, il sistema gestisce automaticamente l'intero processo di rollback senza ulteriori interventi.
Compatibilità del pool di nodi	Funziona in tutti i tipi di pool di nodi, inclusi pool di macchine virtuali (VM) e pool di nodi basati su set di scalabilità di macchine virtuali (VMSS).
Supporto dei sistemi operativi	Compatibile con tutte le unità di mantenimento delle scorte del sistema operativo (SKU), tra cui Ubuntu, Azure Linux e pool di Windows.
Processo semplificato	Non è necessaria alcuna gestione degli snapshot.

Limitazioni e considerazioni relative al rollback del pool di nodi

Quando si usa la funzionalità di rollback del pool di nodi, tenere presenti le limitazioni seguenti:

Limitato soltanto a modifiche di versione. Altre modifiche al pool di nodi non vengono ripristinate.
Nessuna operazione simultanea consentita durante il rollback.
È necessario disabilitare il canale di aggiornamento automatico di Kubernetes prima del rollback. Se il canale di aggiornamento del sistema operativo del nodo è abilitato, il rollback della versione di Kubernetes può continuare, ma l'immagine del nodo precedente potrebbe non essere ripristinata. Disabilitare il canale di aggiornamento del sistema operativo del nodo quando è necessario eseguire il rollback sia della versione di Kubernetes che dell'immagine del nodo.
Disponibile solo per sette giorni dopo il completamento dell'aggiornamento.
Non è possibile eseguire rollback consecutivi per tornare a versioni precedenti.
Il rollback non supporta l'annullamento delle modifiche di SKU del sistema operativo. Se lo SKU del sistema operativo del pool di nodi è stato modificato (ad esempio, da Ubuntu a Azure Linux), il rollback tenta di ripristinare la versione precedente dell'immagine del nodo, che appartiene a un diverso SKU del sistema operativo e viene rifiutato. Per ripristinare una modifica dello SKU del sistema operativo, usare invece il az aks nodepool update --os-sku comando .

Quando si usa il rollback del pool di nodi, tenere presenti le considerazioni seguenti:

Implicazioni per la sicurezza	Considerazioni operative
* Esposizione alla vulnerabilità: il rollback rimuove le patch di sicurezza e gli aggiornamenti dalla versione più recente. Pertanto, è consigliabile usare il rollback solo temporaneamente durante la risoluzione dei problemi, quindi eseguire di nuovo l'aggiornamento il prima possibile.	* Interruzione del servizio: il processo di rollback potrebbe causare interruzioni temporanee del carico di lavoro. * Disponibilità delle risorse: garantire una capacità sufficiente per l'operazione di rollback. * Requisiti di test: pianificare la risoluzione dei problemi sottostanti prima di tentare di nuovo gli aggiornamenti.

Perché usare il rollback

Il rollback offre un meccanismo di ripristino critico per gli ambienti di produzione:

Continuità aziendale: ridurre al minimo i tempi di inattività quando gli aggiornamenti causano problemi imprevisti
Mitigazione dei rischi: ripristinare rapidamente configurazioni valide senza procedure di ripristino complesse
Ripristino semplificato: evitare l'intervento manuale o la ricompilazione dei cluster dai backup

Quando usare il rollback del pool di nodi

Prendere in considerazione il rollback come opzione di ripristino negli scenari seguenti:

Si verificano errori di aggiornamento: problemi di infrastruttura, vincoli di risorse o problemi di compatibilità impediscono aggiornamenti riusciti.
Interruzione delle applicazioni: i carichi di lavoro riscontrano errori critici o danneggiamento dei dati con le versioni più recenti di Kubernetes.
Prestazioni ridotte: le nuove versioni causano una latenza inaccettabile, problemi di velocità effettiva o consumo di risorse.
Le lacune nei test emergono: I problemi si verificano in produzione che non sono stati rilevati durante i test di pre-produzione.

Flusso di lavoro di rollback del pool di nodi

Il diagramma seguente illustra il flusso di lavoro di rollback del pool di nodi:

Il processo di rollback ripristina tutti i nodi in un pool di nodi allo stato della versione precedente. Gli aspetti chiave del flusso di lavoro includono:

Approccio all-or-nothing: Tutti i nodi devono ripristinare correttamente la versione precedente per completare con successo il rollback. Se un nodo non riesce a eseguire il rollback, l'intera operazione non riesce per comunicare chiaramente lo stato del cluster, in modo analogo all'operazione di aggiornamento.
Monitoraggio dei progressi: monitorare lo stato di rollback usando il log attività di Azure per la cronologia delle operazioni e l'API di stato delle operazioni per gli aggiornamenti in tempo reale.

Eseguire il rollback di una versione del pool di nodi

Importante

Quando si esegue il rollback di una versione del pool di nodi, tenere presenti le informazioni seguenti:

Rimanere sulle versioni precedenti a lungo termine aumenta i rischi per la sicurezza e potrebbe infine impedire gli aggiornamenti a causa di limitazioni delle versioni. Considerare il rollback come un meccanismo di ripristino temporaneo, non una soluzione permanente.
Il rollback sostituisce i nodi nel pool di nodi e può interrompere temporaneamente i carichi di lavoro. Prima di iniziare, verificare che i carichi di lavoro abbiano capacità sufficiente e che i budget di interruzione dei pod consentano le interruzioni del nodo necessarie.
Quando si usa l'API REST, è possibile chiamare prima l'API Pool di agenti - Ottieni profilo di aggiornamento per recuperare le versioni usate di recente. Usare queste informazioni per specificare la versione di destinazione nella richiesta di rollback.

Il comando di rollback interfaccia della riga di comando di Azure seleziona automaticamente la versione registrata più di recente, nota anche come N-1. Non è possibile usare il comando per selezionare una versione arbitraria di Kubernetes o immagine del nodo e non è possibile eseguire rollback consecutivi per spostarsi tra più versioni precedenti.

Esaminare la configurazione dell'aggiornamento automatico del cluster.
```
az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query autoUpgradeProfile
```
Disabilitare il canale di aggiornamento automatico di Kubernetes prima del rollback. Se è necessario ripristinare l'immagine del nodo precedente, disabilitare anche il canale di aggiornamento del sistema operativo del nodo.
Esaminare la destinazione di rollback disponibile usando il az aks nodepool get-rollback-versions comando .
```
az aks nodepool get-rollback-versions \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster
```
Se il comando non restituisce versioni, il pool di nodi non ha una destinazione di rollback idonea. Il pool di nodi deve essere stato aggiornato entro i sette giorni precedenti e la versione di Kubernetes registrata deve comunque essere supportata dal servizio Azure Kubernetes.

Eseguire il rollback del pool di nodi usando il az aks nodepool rollback comando .

az aks nodepool rollback \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster

Verificare la versione di Kubernetes, la versione dell'immagine del nodo e lo stato di provisioning al termine del rollback.
```
az aks nodepool show \
    --name myNodePool \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --query '{provisioningState:provisioningState,kubernetesVersion:currentOrchestratorVersion,nodeImageVersion:nodeImageVersion}'
```
Viene restituito Succeeded un rollback riuscito per provisioningState e mostra le versioni registrate di Kubernetes e dell'immagine del nodo.

Se sono state modificate le impostazioni di aggiornamento automatico del cluster prima del rollback, ripristinare le impostazioni desiderate dopo aver esaminato e risolto il problema di aggiornamento.

Monitorare lo stato di rollback del pool di nodi

È possibile usare i metodi seguenti per monitorare lo stato di un'operazione di rollback del pool di nodi e convalidare un rollback riuscito:

Consulta i log delle attività sul tuo cluster.
Cercare eventi specifici correlati all'aggiornamento nel cluster.
Sottoscrivere eventi AKS con Griglia di eventi di Azure.
Se si sottoscrive un canale di aggiornamento automatico, è possibile usare Gestione comunicazioni del servizio Azure Kubernetes per le notifiche di aggiornamento.

Risolvere i problemi di rollback del pool di nodi

La tabella seguente descrive i problemi comuni di rollback e come risolverli:

Problema	Causa e risoluzione
Non vengono restituite versioni di rollback.	Il pool di nodi potrebbe non avere un aggiornamento registrato, la finestra di rollback di sette giorni potrebbe essere scaduta o la versione precedente di Kubernetes potrebbe non essere più supportata. Controllare la cronologia di aggiornamento del pool di nodi e i criteri di supporto della versione di Kubernetes del servizio Azure Kubernetes.
Il servizio Azure Kubernetes segnala che è in corso un'altra operazione.	Attendere il completamento dell'operazione corrente del cluster o del pool di nodi prima di ripetere il rollback. Se è necessario arrestare l'operazione, usare il `az aks nodepool operation-abort` comando .
La versione di Kubernetes esegue il rollback, ma l'immagine del nodo non lo esegue.	Il canale di aggiornamento del sistema operativo del nodo potrebbe essere abilitato. Disabilitare il canale quando è necessario ripristinare l'immagine del nodo precedente.
Il servizio Azure Kubernetes rifiuta la versione precedente dell'immagine del nodo.	Lo SKU del sistema operativo del pool di nodi potrebbe essere stato modificato dopo la versione registrata. Il rollback non supporta l'annullamento delle modifiche di SKU del sistema operativo. Usare `az aks nodepool update --os-sku` invece per ripristinare lo SKU del sistema operativo.
Il servizio Azure Kubernetes rifiuta la versione precedente di Kubernetes.	La versione registrata potrebbe non essere più supportata. Controllare i criteri di supporto della versione di Kubernetes del servizio Azure Kubernetes.

Procedure consigliate dopo il rollback

Dopo aver eseguito correttamente il rollback del pool di nodi, usare le procedure consigliate seguenti per garantire stabilità e sicurezza:

Esaminare la causa radice: identificare il motivo per cui l'aggiornamento non è riuscito prima di tentare un altro aggiornamento. Esaminare i log applicazioni, le metriche delle risorse e i requisiti di compatibilità.
Test in ambiente non di produzione: convalidare la versione più recente in un ambiente di sviluppo o staging per riprodurre e risolvere i problemi prima di aggiornare nuovamente la produzione.
Pianificare di nuovo l'aggiornamento: non rimanere nella versione di cui è stato eseguito il rollback per un periodo illimitato. Pianificare un nuovo aggiornamento per mantenere le patch di sicurezza e il supporto:
- Per i problemi di sicurezza critici: eseguire di nuovo l'aggiornamento entro giorni dalla convalida delle correzioni.
- Per i problemi di compatibilità delle applicazioni: eseguire di nuovo l'aggiornamento entro settimane dalla modifica del codice.
- Intervallo di tempo massimo consigliato: 30 giorni per evitare di accumulare vulnerabilità di sicurezza.

Domande frequenti

È possibile eseguire altre operazioni durante il rollback di un pool di nodi?

No, il rollback deve essere completato prima di avviare altre operazioni. Per eseguire operazioni diverse, interrompere prima il rollback.

Il rollback del pool di nodi ripristina sia la versione di Kubernetes che l'immagine del nodo?

Sì, il rollback ritorna alla versione di Kubernetes più recente utilizzata e alla sua immagine nodo corrispondente. Se entrambi i componenti sono stati modificati, il sistema ripristina la versione precedente di Kubernetes con l'ultima immagine del nodo compatibile per tale versione.

È possibile eseguire il rollback solo dell'immagine del nodo senza modificare la versione del pool di nodi?

Sì, se è stato eseguito solo un aggiornamento dell'immagine del nodo negli ultimi sette giorni (senza aggiornare la versione del pool di nodi), il rollback ripristina l'immagine del disco rigido virtuale precedente mantenendo la stessa versione di Kubernetes.

È possibile eseguire il rollback a una versione non supportata?

No, non è possibile eseguire il rollback a una versione di Kubernetes non più supportata dal servizio Azure Kubernetes. Ad esempio, se il pool di nodi era nella versione 1.27.9 (ora non supportata) ed è stato eseguito l'aggiornamento alla versione 1.28.5, non è possibile eseguire il rollback alla versione 1.27.9 perché non è più incluso nell'elenco delle versioni supportate. Controllare sempre i criteri di supporto di versione di AKS Kubernetes per verificare la disponibilità della versione.

È necessario disabilitare l'aggiornamento automatico prima di eseguire il rollback di un pool di nodi?

Sì, è necessario disabilitare il canale di aggiornamento automatico kubernetes prima di eseguire un rollback. Se si abilita solo il canale di aggiornamento del sistema operativo del nodo, il rollback della versione di Kubernetes può continuare, ma l'immagine del nodo precedente potrebbe non essere ripristinata. Disabilitare il canale di aggiornamento del sistema operativo del nodo quando è necessario eseguire il rollback sia della versione di Kubernetes che dell'immagine del nodo.

Se il cluster è incluso in un gruppo di aggiornamento in un profilo di aggiornamento automatico di Kubernetes Fleet Manager Azure, è necessario rimuovere anche il cluster dal gruppo di aggiornamento prima di eseguire il rollback. In caso contrario, il processo di aggiornamento automatico potrebbe aggiornare automaticamente il pool di nodi al termine del rollback.

È possibile eseguire il rollback dopo aver modificato lo SKU del sistema operativo(ad esempio, da Ubuntu a Azure Linux)?

No. Il rollback del pool di nodi è limitato alle modifiche della versione e non ripristina le modifiche apportate allo SKU del sistema operativo. Dopo la migrazione da uno SKU del sistema operativo a un altro (ad esempio, Ubuntu a Azure Linux), la versione precedente dell'immagine del nodo appartiene allo SKU del sistema operativo precedente ed è incompatibile con la configurazione corrente. L'operazione di rollback rifiuta la versione precedente dell'immagine con un errore simile al seguente:

NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'

Per ripristinare lo SKU del sistema operativo, usare il az aks nodepool update comando con il --os-sku parametro . Per altre informazioni, vedere Ripristinare la versione del sistema operativo.

Per altre informazioni sugli aggiornamenti del pool di nodi in AKS, vedere gli articoli seguenti:

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-08-13