Aggiornamenti avviati dalla piattaforma in Servizio Azure Kubernetes (AKS)

Servizio Azure Kubernetes (AKS) aggiorna automaticamente tutti i cluster che rimangono in una versione Kubernetes non supportata dopo la fine del periodo di tolleranza del supporto della piattaforma. Questo aggiornamento automatico viene chiamato aggiornamento avviato dalla piattaforma.

Un cluster che esegue una versione kubernetes non supportata non riceve più patch della community, correzioni di bug o correzioni CVE. Gli aggiornamenti avviati dalla piattaforma assicurano che ogni cluster del servizio Azure Kubernetes torni a una versione supportata, anche se non viene eseguita alcuna azione.

Warning

A differenza di un aggiornamento avviato mentre il cluster è supportato, un aggiornamento avviato dalla piattaforma non si arresta quando il controllo delle modifiche che causano interruzioni per API deprecate rileva l'utilizzo di un'API rimossa dalla versione di Kubernetes di destinazione. L'aggiornamento procede e i carichi di lavoro, i client o i controller che dipendono dall'API rimossa potrebbero smettere di funzionare. AKS inoltre non convalida i componenti aggiuntivi autogestiti per la compatibilità con la versione di destinazione. Aggiornare i manifesti e aggiornare o sostituire i componenti aggiuntivi autogestiti incompatibili prima dell'inizio dell'aggiornamento avviato dalla piattaforma. Per altre informazioni, vedere Opzioni di aggiornamento e raccomandazioni per AKS.

Un aggiornamento avviato dalla piattaforma inoltre non rispetta la finestra di manutenzione e può eseguire l'override di un budget di interruzione dei pod (PDB) che impedisce lo svuotamento di un nodo. I workload potrebbero essere interrotti.

Mantenere il cluster in una versione supportata è l'unico modo per evitare un aggiornamento avviato dalla piattaforma. Vedere Come evitare gli aggiornamenti avviati dalla piattaforma.

Gli aggiornamenti avviati dalla piattaforma non modificano il livello di fatturazione, il canale di aggiornamento o il livello di supporto. Si applicano solo ai cluster che non sono più supportati.

Preparare prima che il servizio Azure Kubernetes avvii l'aggiornamento

Seguire questi passaggi prima del mese dell'aggiornamento avviato dalla piattaforma del cluster:

Trovare i cluster che non sono più supportati o si avvicinano alla fine del ciclo di vita. Usare la query Azure Resource Graph e controllare il calendario di rilascio.
Rimuovere le dipendenze dalle API deprecate. Nel portale di Azure passare a Diagnosticare e risolvere i problemi>Deprecazioni dell'API Kubernetes. Aggiornare carichi di lavoro, manifesti, client, controller e componenti aggiuntivi autogestiti che usano le API rimosse dalla versione di Kubernetes di destinazione. Un aggiornamento avviato dalla piattaforma non si arresta quando rileva questo utilizzo.
Convalidare i componenti aggiuntivi autogestiti. Controllare la compatibilità delle versioni di Kubernetes di ogni componente aggiuntivo autogestito, incluse le definizioni di risorse personalizzate e i controller. Aggiornare o sostituire un componente aggiuntivo incompatibile con la versione di Kubernetes di destinazione prima che AKS aggiorni il cluster.
Garantire la capacità di eseguire aggiornamenti. Esaminare la quota della famiglia di macchine virtuali, la disponibilità dello SKU a livello di area e la capacità IP della subnet prima del mese di aggiornamento previsto. Richiedere aumenti delle quote oppure collaborare con il supporto di Azure sui vincoli di capacità a livello di area in anticipo. Regolare maxSurge per la capacità ottenibile. Se non è disponibile capacità surge aggiuntiva, prendere in considerazione maxUnavailable, che aggiorna direttamente i pool di nodi utente idonei senza nodi surge, ma può ridurre la capacità dei carichi di lavoro durante l'aggiornamento.
Usare una cadenza di aggiornamento prevedibile. Per un singolo cluster, usare il canale di aggiornamento automatico delstable cluster con manutenzione pianificata per mantenere il cluster in una versione secondaria supportata ed eseguire gli aggiornamenti durante una finestra scelta. Il patch canale applica automaticamente le patch all'interno della versione secondaria corrente, ma non sposta il cluster in una versione secondaria più recente. Per più cluster, prendere in considerazione un profilo di aggiornamento automatico di Fleet Manager e una strategia di aggiornamento per scaglionare gli aggiornamenti nei gruppi di aggiornamento con periodi di attesa tra le fasi. Questo approccio fornisce una cadenza ripetibile, dandoti il tempo di convalidare ogni fase prima che inizi quella successiva.
Preparare i PDB per il drain dei nodi. Verificare che i PDB consentano il completamento di uno svuotamento del nodo. Se la gestione PDB è difficile, prendere in considerazione la gestione automatica PDB (anteprima), che può creare PDB mancanti e aggiungere temporaneamente repliche quando un PDB blocca uno svuotamento.
Aggiorna quando vuoi. Vedere Aggiornare il piano di controllo di un cluster AKS del servizio Azure Kubernetes o seguire Come evitare aggiornamenti avviati dalla piattaforma per mantenere sotto controllo gli aggiornamenti futuri.
Valutare il supporto a lungo termine. Se è necessaria una versione secondaria specifica supportata per più tempo, valutare il supporto a lungo termine di AKS.

Per aggiornare un cluster con il interfaccia della riga di comando di Azure:

# List the versions available in your region
az aks get-versions --location <region> --output table

# Upgrade the cluster
az aks upgrade --resource-group <resource-group> --name <cluster-name> --kubernetes-version <target-version>

Aggiornamenti avviati dalla piattaforma rispetto agli aggiornamenti che si controllano

Ogni altro modo per aggiornare un cluster del servizio Azure Kubernetes rispetta i controlli configurati. Gli aggiornamenti avviati dalla piattaforma non lo fanno, perché lo scopo è quello di riportare un cluster non supportato a una versione supportata.

Metodo di aggiornamento	Segue la finestra di manutenzione	Esegue il controllo dell'API deprecata	Rispetta le impostazioni PDB e di picco
Aggiornamento manuale con `az aks upgrade`	Non applicabile: si sceglie quando viene eseguito l'aggiornamento	Yes	Yes
Canale di aggiornamento automatico del cluster (`patch`, `stable`, `rapid`)	Yes	Yes	Yes
Aggiornamento di Fleet Manager e profili di aggiornamento automatico	Yes	Yes	Yes
Aggiornamento avviato dalla piattaforma	No	No	Solo al meglio delle possibilità

Poiché si mantiene il controllo completo con uno dei primi tre metodi, l'aggiornamento prima che il cluster esca dal supporto è sempre preferibile piuttosto che lasciare che venga eseguito un aggiornamento avviato dalla piattaforma.

Periodo di tolleranza per il supporto della piattaforma

Quando una versione secondaria di Kubernetes raggiunge la fine della vita, il supporto della community termina e la versione entra nella finestra di supporto della piattaforma di AKS. Il periodo di tolleranza del supporto della piattaforma è la finestra di 60 giorni che segue, durante la quale è comunque possibile eseguire l'aggiornamento in base alle proprie condizioni.

Phase	Che succede
Supporto della comunità	La versione riceve patch upstream, correzioni di bug e mitigazione delle CVE.
Fine del ciclo di vita	Il supporto della comunità termina. Il cluster entra nel supporto per la piattaforma e inizia il periodo di tolleranza di 60 giorni.
Periodo di tolleranza (60 giorni)	Azure supporta la piattaforma, ovvero la connettività del cluster, l'integrità dei nodi e l'esecuzione dell'aggiornamento, ma non i bug di Kubernetes o le CVE presenti nella versione non supportata. Eseguire l'aggiornamento in questa finestra temporale per mantenere il controllo.
Fine del periodo di tolleranza	Il cluster diventa idoneo per un aggiornamento avviato da AKS a una versione supportata.

Il periodo di tolleranza inizia il giorno dopo la data di fine vita e dura 60 giorni. Ad esempio, se una versione di Kubernetes raggiunge la fine del supporto il 30 giugno 2027, il periodo di grazia va dal 1° luglio al 29 agosto 2027. Un cluster ancora in tale versione diventa idoneo per un aggiornamento avviato dalla piattaforma dopo il periodo di tolleranza. Il calendario della versione mostra il mese di implementazione pianificato, non la data in cui viene aggiornato un particolare cluster.

Per visualizzare il mese di aggiornamento avviato dalla piattaforma per ogni versione, vedere il calendario delle versioni di Kubernetes di AKS.

Implementazione iniziale

Fino al 31 maggio 2027, identificare i cluster che eseguono versioni di Kubernetes non supportate e aggiornarli secondo i propri tempi. Questa finestra di aggiornamento gestita dal cliente è il periodo di tolleranza per l'implementazione iniziale.

A partire dal 1° giugno 2027, il servizio Azure Kubernetes avvia gli aggiornamenti avviati dalla piattaforma per i cluster che rimangono in versioni non supportate. È previsto che i cluster di supporto della community standard eseguano Kubernetes 1.36 o versione successiva e che i cluster registrati in LTS eseguano Kubernetes 1.33 LTS o versione successiva. Il servizio Azure Kubernetes non iscrive automaticamente i cluster in LTS.

Dopo l'implementazione iniziale, ogni evento di fine del supporto ha un periodo di tolleranza di 60 giorni prima dell'inizio degli aggiornamenti avviati dalla piattaforma.

La tempistica non è esatta

AKS limita gli aggiornamenti avviati dalla piattaforma per area, sottoscrizione e versione di origine, in modo che gli aggiornamenti non vengano eseguiti ovunque contemporaneamente. Il cluster viene aggiornato durante o dopo il mese visualizzato nel calendario di rilascio, non in una data specifica.

Non fare affidamento su un orario di aggiornamento preciso. Assicurati di usare una versione supportata prima del termine del periodo di tolleranza.

Come evitare aggiornamenti avviati dalla piattaforma

Un aggiornamento avviato dalla piattaforma viene eseguito solo in un cluster già fuori supporto. Mantenere attivo il supporto è ciò che tiene lontano da questo percorso e mantiene anche ogni aggiornamento all'interno della finestra di manutenzione.

Per singoli cluster

Impostare un canale di aggiornamento automatico. Il stable canale mantiene automaticamente il cluster in una versione secondaria/minore supportata. Il patch canale applica solo patch all'interno della versione secondaria corrente. Il canale none, o nessun canale, fa sì che il cluster non sia più supportato.
Configura una finestra di manutenzione. Associare il canale alla manutenzione pianificata in modo che gli aggiornamenti vengano eseguiti durante periodi di traffico ridotto. Usare un intervallo di almeno quattro ore.
Sottoscrivere le notifiche. Configurare AKS Communication Manager per ricevere informazioni sugli aggiornamenti prima che vengano eseguiti.
Mantieni i carichi di lavoro pronti per l'aggiornamento. Testa i PDB e prendi in considerazione la gestione automatica dei Pod Disruption Budget (PDB) per evitare che il drain dei nodi venga bloccato.

Per le flotte

Se si gestiscono molti cluster, usare Azure Kubernetes Fleet Manager per mantenere supportato ogni cluster membro:

Creare un profilo di aggiornamento automatico. Un profilo di aggiornamento automatico di Fleet Manager con il canale Stable o Rapid mantiene automaticamente i cluster membri nelle versioni supportate.
Usare le esecuzioni degli aggiornamenti e i gruppi di aggiornamento.Orchestrazione degli aggiornamenti aggiorna i cluster membro in una sequenza controllata, in modo da poter preparare gli aggiornamenti in ambienti diversi.
Fase con strategie di aggiornamento. Raggruppare i cluster in fasi, ad esempio test prima della produzione, e aggiungere tempi di attesa tra le fasi per convalidare ognuna di esse.
Monitorare le versioni del membro. Esaminare la versione kubernetes di ogni cluster membro rispetto al calendario di rilascio oppure usare la query Azure Resource Graph.

Importante

Le esecuzioni degli aggiornamenti di Fleet Manager e i gruppi di aggiornamento si applicano solo ai cluster ancora supportati. Una volta che un cluster membro esce dal supporto, il servizio Azure Kubernetes agisce direttamente con un aggiornamento avviato dalla piattaforma che ignora la sequenza di Fleet Manager. Mantenere i cluster membro nello stato supportato in modo che la sequenza della flotta rimanga attiva.

Quale versione di Kubernetes sceglie AKS

Il servizio Azure Kubernetes aggiorna il cluster alla versione più bassa supportata all'interno del livello di supporto corrente:

Livello di supporto corrente	Versione di destinazione
Supporto della comunità	Versione secondaria della community più bassa supportata.
Supporto a lungo termine (LTS)	Versione LTS applicabile.

Il servizio Azure Kubernetes seleziona sempre la versione della patch più recente disponibile all'interno della versione secondaria di destinazione.

Gli aggiornamenti avviati dalla piattaforma non passano mai tra i livelli di supporto. Un cluster di supporto della community non è registrato in LTS e un cluster LTS non viene declassato a una versione community. Poiché LTS è un'adesione esplicita che richiede il livello Premium, AKS non registra mai un cluster in LTS per conto dell'utente e non modifica mai il livello di fatturazione. Per altre informazioni, vedere Abilitare il supporto a lungo termine.

Cluster indietro di diverse versioni secondarie

Kubernetes non consente di saltare le versioni secondarie durante un aggiornamento del piano di controllo. Se il cluster è dietro più versioni secondarie, il servizio Azure Kubernetes lo sposta una versione secondaria alla volta fino a raggiungere una versione supportata.

Un cluster che è molto indietro richiede più tempo per tornare al supporto e comporta un rischio maggiore di problemi del carico di lavoro, perché ogni versione secondaria può rimuovere le API da cui dipendono i carichi di lavoro. È fortemente consigliato aggiornare autonomamente questi cluster.

Piano di controllo e pool di nodi

Un aggiornamento avviato dalla piattaforma porta l'intero cluster alla versione di destinazione. AKS aggiorna prima il piano di controllo, quindi i pool di nodi, usando la stessa orchestrazione di aggiornamento di az aks upgrade.

Cosa AKS sovrascrive durante un aggiornamento avviato dalla piattaforma

Per garantire il completamento dell'aggiornamento, AKS esegue l'override di alcuni dei controlli che si applicano a ogni altro metodo di aggiornamento.

Controllo	Comportamento durante un aggiornamento avviato dalla piattaforma
Finestra di manutenzione	Non rispettato. L'aggiornamento può essere avviato in qualsiasi momento dal mese di aggiornamento avviato dalla piattaforma in poi.
Canale di aggiornamento automatico	Ignorato. I cluster senza canale configurato o con il `none` canale o `patch` vengono comunque aggiornati.
Esecuzioni di aggiornamento di Fleet Manager e gruppi di aggiornamento	Non accettato. AKS agisce direttamente sul cluster membro.
Controllo dell'API deprecato	Ignorato. L'aggiornamento procede anche quando viene rilevato un utilizzo deprecato dell'API.
Pod Disruption Budget (PDB)	Onorato nei limiti del possibile. AKS tenta prima di tutto lo svuotamento normale di un nodo ed esegue l'override di un PDB solo se si verifica un timeout o un errore durante lo svuotamento.
Impostazioni di picco del nodo	Rispettato al meglio delle possibilità. Se AKS non riesce a creare capacità di surge, viene eseguito il fallback all'aggiornamento di un nodo alla volta (`maxSurge=0`, `maxUnavailable=1`).
Aggiornamenti del pool di nodi con strategia blue-green	Eseguito come aggiornamento progressivo. La strategia archiviata non è stata modificata.

Poiché AKS può eseguire l'override di un PDB e può ignorare il controllo dell'API deprecato, un aggiornamento avviato dalla piattaforma è un aggiornamento best effort senza garanzia di disponibilità del carico di lavoro. I workload potrebbero essere interrotti.

Non è possibile eseguire il rollback degli aggiornamenti avviati dalla piattaforma. Non è possibile eseguire il rollback a una versione non supportata, quindi la versione in esecuzione prima dell'aggiornamento non è più disponibile.

La configurazione non è stata modificata

Il servizio Azure Kubernetes ignora queste impostazioni in fase di esecuzione, ma non le modifica. Dopo un aggiornamento avviato dalla piattaforma, le impostazioni seguenti sono invariate:

Profilo per l'aggiornamento automatico e canale di aggiornamento
Configurazione della finestra di manutenzione
Strategia di aggiornamento del pool di nodi, incluso blu/verde
Numero massimo di incrementi e impostazioni di indisponibilità massima
Livello di fatturazione e registrazione LTS

Trovare cluster a rischio

Usare questa Azure Resource Graph query nel portale di Azure o con il interfaccia della riga di comando di Azure per elencare i cluster del servizio Azure Kubernetes tra le sottoscrizioni con la versione corrente di Kubernetes e il livello di supporto:

resources
| where type =~ 'microsoft.containerservice/managedclusters'
| project
    clusterName = name,
    resourceGroup,
    subscriptionId,
    location,
    kubernetesVersion = properties.kubernetesVersion,
    tier = properties.sku.tier,
    supportPlan = properties.supportPlan,
    upgradeChannel = properties.autoUpgradeProfile.upgradeChannel,
    powerState = properties.powerState.code
| order by kubernetesVersion asc, clusterName asc

Per eseguire la query con il interfaccia della riga di comando di Azure:

az graph query -q "resources | where type =~ 'microsoft.containerservice/managedclusters' | project clusterName = name, resourceGroup, subscriptionId, kubernetesVersion = properties.kubernetesVersion, tier = properties.sku.tier, supportPlan = properties.supportPlan | order by kubernetesVersion asc" --output table

Confrontare i kubernetesVersion valori con il calendario di rilascio del servizio Azure Kubernetes per individuare i cluster non più supportati o che si avvicinano alla fine del ciclo di vita. Un valore supportPlan per AKSLongTermSupport indica che il cluster è registrato in LTS.

Modalità di notifica

AKS presenta cluster a rischio tramite diversi canali prima dell'esecuzione di qualsiasi aggiornamento avviato dalla piattaforma:

Integrità risorse di Azure: un cluster nella finestra di supporto della piattaforma segnala uno stato di integrità Degradato che indica la versione corrente e quando il servizio Azure Kubernetes aggiorna il cluster.
Azure portal: un banner nella risorsa cluster avvisa che la versione non è più supportata e che AKS aggiorna automaticamente il cluster.
Azure Advisor: una raccomandazione identifica i cluster che eseguono versioni non supportate.
AKS Communication Manager: invia notifiche tramite posta elettronica sugli aggiornamenti imminenti e completati avviati dalla piattaforma.
Diagnostica e risolvi i problemi: mostra lo stato dell'aggiornamento del cluster e l'utilizzo deprecato dell'API nel portale di Azure.

Questi canali condividono lo stesso stato sottostante, quindi non sono in disaccordo tra loro. Per un aggiornamento pianificato o un aggiornamento in nuovo tentativo, è possibile visualizzare lo stato del ciclo di vita, il numero di tentativi, l'ora del tentativo successivo e l'ultimo errore.

Controllare un aggiornamento avviato dalla piattaforma

Gli aggiornamenti avviati dalla piattaforma vengono visualizzati nel log attività Azure con metadati che li distinguono dagli aggiornamenti avviati dall'utente:

Property	Value
`initiatedBy`	`System`
`upgradeTrigger`	`PlatformInitiatedUnsupportedVersion`
`upgradeSource`	`PlatformInitiated`

L'evento registra anche le versioni di Kubernetes di origine e destinazione. Filtrare il log attività in base a queste proprietà per attribuire la modifica durante una revisione della gestione delle modifiche o della conformità.

Quando non è possibile completare un aggiornamento

Se un aggiornamento avviato dalla piattaforma non riesce, AKS esegue automaticamente un nuovo tentativo in base a una pianificazione determinata dal sistema. Il cluster rimane in una versione non supportata finché l'aggiornamento non va a buon fine.

Un fattore bloccante non esenta il cluster dai criteri e lascia solo il cluster non supportato più a lungo. Gli ostacoli più comuni includono:

Componente aggiuntivo o funzionalità non supportato nella versione di destinazione. Per i cluster LTS, vedere Considerazioni sul ciclo di vita dei componenti aggiuntivi e delle funzionalità.
Dimensioni di macchina virtuale deprecata in un pool di nodi.
Indirizzi IP insufficienti nella subnet del nodo.
Vincoli di capacità a livello di area.
Blocco delle risorse sul cluster o sul relativo gruppo di risorse.
Un'assegnazione Criteri di Azure che nega le modifiche apportate alla versione di Kubernetes.

Controllare il motivo dell'errore in Azure Integrità risorse o Diagnosticare e risolvere i problemi, risolvere il blocco e quindi aggiornare il cluster manualmente. Se non è possibile identificare la causa, aprire una richiesta di supporto.

Cluster ignorati da AKS

Il servizio Azure Kubernetes non esegue gli aggiornamenti avviati dalla piattaforma in:

Cluster arrestati. Il servizio Azure Kubernetes rinvia l'aggiornamento mentre il cluster è arrestato. Dopo aver avviato il cluster, funziona normalmente e viene rivalutato per un aggiornamento avviato dalla piattaforma nel ciclo successivo. L'avvio di un cluster non attiva un aggiornamento immediato.
Cluster in eliminazione.
Cluster in stato di provisioning non riuscito. Risolvere prima lo stato non riuscito.

Availability

Gli aggiornamenti avviati dalla piattaforma si applicano ad AKS nel cloud pubblico di Azure. La disponibilità in Azure per enti pubblici e Microsoft Azure gestita da 21Vianet segue Azure procedure di distribuzione sicure e viene annunciata separatamente.

AKS abilitato da Azure Arc e AKS in Azure Locale non rientrano nell'ambito. Queste offerte hanno un proprio ciclo di vita e modelli di aggiornamento.

Domande frequenti

È possibile disattivare gli aggiornamenti avviati dalla piattaforma?

No. Non esiste alcuna impostazione di disattivazione. Mantieni il controllo mantenendo il cluster in una versione secondaria della community supportata o in una versione LTS a cui ti sei iscritto esplicitamente. Gli aggiornamenti avviati dalla piattaforma agiscono solo sui cluster che rimangono in una versione non supportata al termine del periodo di tolleranza della piattaforma di 60 giorni.

È possibile annullare un aggiornamento già avviato dalla piattaforma?

No. Non è possibile annullare un aggiornamento avviato dalla piattaforma in corso.

Cambia la fatturazione o il livello di servizio?

No. Non sono state apportate modifiche alla fatturazione o al piano. Se non si sceglie LTS, il cluster viene aggiornato a una versione community supportata senza costi aggiuntivi.

AKS iscrive il mio cluster nel supporto a lungo termine?

No. LTS è un'opzione facoltativa a prezzo separato che richiede il livello Premium. AKS non registra mai un cluster in LTS per conto dell'utente. Per mantenere una versione secondaria specifica supportata per più tempo, registrare manualmente il cluster in LTS.

Il cluster è registrato in LTS e la fine del ciclo di vita LTS è trascorsa. Quale versione sceglie AKS?

Il cluster rimane sulla traccia LTS e viene aggiornato alla versione LTS supportata successiva. Non viene eliminata in una versione supportata dalla community.

I miei carichi di lavoro subiranno interruzioni?

Possibilmente. Il servizio Azure Kubernetes tenta un normale svuotamento dei nodi e rispetta i PDB in cui è possibile, ma esegue l'override di un PDB se lo svuotamento raggiunge il timeout o ha esito negativo. Un aggiornamento avviato dalla piattaforma avviene a livello di best effort e non garantisce la disponibilità del carico di lavoro. Testare i PDB e le impostazioni di aggiornamento prima del mese di aggiornamento avviato dalla piattaforma per il cluster oppure aggiornare manualmente il cluster in modo che la finestra di manutenzione e i PDB siano completamente rispettati.

L'aggiornamento rispetta la finestra di manutenzione?

No. Gli aggiornamenti avviati dalla piattaforma non seguono le finestre di manutenzione e possono iniziare in qualsiasi momento dal mese di aggiornamento avviato dalla piattaforma in poi. Le finestre di manutenzione si applicano comunque agli aggiornamenti manuali, all'aggiornamento automatico del cluster e alle esecuzioni degli aggiornamenti di Fleet Manager.

Il canale di aggiornamento automatico influisce su questo problema?

No. L'impostazione del canale non esenta il cluster. I cluster senza canale configurato o con il canale none o patch vengono comunque aggiornati quando non sono più supportati. La configurazione del canale non è stata modificata.

Il stable canale consente di mantenere il cluster in una versione minor supportata. Il patch canale applica patch all'interno della versione secondaria corrente, ma non sposta il cluster in una versione secondaria più recente. Per altre informazioni, vedere Come evitare gli aggiornamenti avviati dalla piattaforma.

Fleet Manager protegge i miei cluster membri dagli aggiornamenti avviati dalla piattaforma?

Fleet Manager consente di mantenere supportati i cluster membri, il che evita gli aggiornamenti avviati dalla piattaforma. Tuttavia, una volta che un cluster membro non è supportato, il servizio Azure Kubernetes agisce direttamente su di esso e non segue le esecuzioni degli aggiornamenti di Fleet Manager, i gruppi di aggiornamento o le finestre di manutenzione. Per altre informazioni, vedere Per le flotte.

L'aggiornamento aggiorna anche le immagini del nodo o lo SKU del sistema operativo?

Gli aggiornamenti avviati dalla piattaforma riguardano la versione di Kubernetes. L'immagine dei nodi viene ricreata durante l'aggiornamento e i nodi si avviano con l'immagine corrente per la versione di destinazione. Lo SKU del sistema operativo non viene modificato. Per gestire separatamente le immagini dei nodi, vedere Aggiornare le immagini dei nodi del servizio Azure Kubernetes.

Cosa accade se i pool di nodi sono lontani dal pannello di controllo?

Il servizio Azure Kubernetes aggiorna prima il piano di controllo, quindi porta i pool di nodi alla versione di destinazione all'interno delle regole di aggiornamento della versione di Kubernetes. Se un pool di nodi è troppo indietro, il servizio Azure Kubernetes lo aggiorna in passaggi insieme al piano di controllo.

È possibile eseguire il rollback dopo un aggiornamento avviato dalla piattaforma?

No. Il servizio Azure Kubernetes non supporta i downgrade e non è possibile eseguire il rollback a una versione non supportata. Per altre informazioni, vedere Eseguire il rollback di un pool di nodi del servizio Azure Kubernetes.

È supportabile un problema di carico di lavoro causato da un aggiornamento avviato dalla piattaforma?

È possibile aprire una richiesta di supporto per assistenza con il cluster e l'aggiornamento stesso. Tuttavia, un aggiornamento avviato dalla piattaforma viene eseguito in modalità best effort e non garantisce la disponibilità del carico di lavoro, e i cluster che eseguono versioni non supportate non hanno garanzie di runtime. Verificare la compatibilità del carico di lavoro con la versione di destinazione prima del mese previsto per l'aggiornamento avviato dalla piattaforma del cluster.

Con quanto preavviso vengo informato?

Il cluster entra nella finestra di supporto della piattaforma alla fine del ciclo di vita, che offre un periodo di tolleranza di 60 giorni prima che diventi idoneo per un aggiornamento avviato dalla piattaforma. Il calendario di rilascio pubblica i mesi di implementazione pianificati in anticipo e Azure Integrità risorse, Azure Advisor e AKS Communication Manager ti avvisano durante il periodo di tolleranza.

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-10-10