Versioni di Kubernetes supportate nel servizio Azure Kubernetes (AKS)

La community di Kubernetes rilascia le versioni secondarie all'incirca ogni quattro mesi.

Le versioni secondarie includono nuove funzionalità e miglioramenti. Le versioni patch hanno una maggior frequenza (in alcuni casi settimanale) e sono destinate esclusivamente a correzioni di bug importanti in una versione secondaria. Le versioni patch includono correzioni per le vulnerabilità di sicurezza o i bug principali.

Versioni di Kubernetes

Kubernetes usa lo schema di Versionamento Semantico standard per ogni versione:

[major].[minor].[patch]

Examples:
  1.29.2
  1.29.1

Ogni numero nella versione indica la compatibilità generale con la versione precedente:

• Le versioni principali cambiano in caso di aggiornamenti incompatibili dell'API o quando potrebbe essere interrotta la compatibilità con le versioni precedenti.
• Le versioni secondarie cambiano se gli aggiornamenti delle funzionalità sono retrocompatibili con le altre versioni secondarie.
• Le versioni patch cambiano quando vengono apportate correzioni di bug compatibili con le versioni precedenti.

Lo scopo è eseguire la versione patch più recente della versione secondaria in esecuzione. Ad esempio, se il cluster di produzione avviene il 1.29.1 e 1.29.2 è la versione di patch disponibile più recente per la versione 1.29 secondaria, è necessario eseguire l'aggiornamento a 1.29.2 quanto prima per far sì che il cluster sia completamente protetto e supportato.

Calendario delle versioni di Kubernetes del servizio Azure Kubernetes

Visualizzare le versioni che verranno rilasciate nel calendario delle versioni di Kubernetes del servizio Azure Kubernetes. Per vedere gli aggiornamenti in tempo reale sullo stato di rilascio della regione e le note di rilascio della versione, visitare la pagina web sullo stato di rilascio del servizio Azure Kubernetes. Per altre informazioni sulla pagina Web relativa allo stato di rilascio, vedere Monitorare il rilascio del servizio Azure Kubernetes.

Per la cronologia delle versioni precedenti, vedere Cronologia di Kubernetes.

Versioni LTS

Grafico di Gantt del programma di rilascio di Kubernetes del servizio Azure Kubernetes

Per visualizzare queste informazioni, ecco un diagramma di Gantt con tutte le versioni correnti visualizzate:

Modifiche di rottura dei componenti AKS per versione

Visionare le seguenti modifiche importanti prima di eseguire l'aggiornamento a una delle versioni secondarie disponibili:

Kubernetes 1.30

Kubernetes 1.29

Kubernetes 1.28

Kubernetes 1.27

Versione secondaria dell'alias

Il servizio Azure Kubernetes consente di creare un cluster senza specificare la versione patch esatta. Quando si crea un cluster senza designare una patch, il cluster esegue la patch di disponibilità generale più recente della versione secondaria. Ad esempio, se si crea un cluster con 1.29 e 1.29.2 è la patch disponibile a livello generale più recente, il cluster verrà creato con 1.29.2. Se si vuole aggiornare la versione patch nella stessa versione secondaria, usare l'aggiornamento automatico.

Per visualizzare la patch attuale, eseguire il comando az aks show --resource-group myResourceGroup --name myAKSCluster. La currentKubernetesVersion proprietà mostra l'intera versione di Kubernetes.

{
 "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": null,
  "azurePortalFqdn": "myaksclust-myresourcegroup.portal.hcp.eastus.azmk8s.io",
  "currentKubernetesVersion": "1.29.2",
}

Criteri di supporto della versione di Kubernetes

Il servizio Azure Kubernetes definisce una versione generalmente disponibile come versione disponibile in tutte le regioni e abilitata in tutte le misure SLO o SLA. Il servizio Azure Kubernetes supporta tre versioni secondarie di disponibilità generale di Kubernetes:

• La versione secondaria generalmente disponibile più recente rilasciata nel servizio Azure Kubernetes (qui denominata N).
• Due versioni secondarie precedenti.
  • Ogni versione secondaria supportata può supportare qualsiasi numero di patch in un determinato momento. Il servizio Azure Kubernetes si riserva il diritto di deprecare le patch se viene rilevata una vulnerabilità di sicurezza o CVE critica. Per informazioni sulla disponibilità delle patch e su qualsiasi deprecazione ad hoc, vedere le note sulla versione e visitare la pagina Web relativa allo stato della versione del servizio Azure Kubernetes.

Il servizio Azure Kubernetes potrebbe supportare anche le versioni di anteprima, etichettate in modo esplicito e soggette a condizioni e termini di anteprima.

Il servizio Azure Kubernetes offre il supporto della piattaforma solo per una versione secondaria generalmente disponibile di Kubernetes, dopo le normali versioni supportate. La finestra di supporto della piattaforma delle versioni di Kubernetes nel servizio Azure Kubernetes è nota come "N-3". Per altre informazioni, vedere Criteri di supporto della piattaforma.

La finestra supportata delle versioni secondarie di Kubernetes nel servizio Azure Kubernetes è nota come "N-2", dove N fa riferimento alla versione più recente, mentre la cifra indica che sono supportate anche due versioni secondarie precedenti.

Ad esempio, nel giorno in cui il servizio Azure Kubernetes introduce la versione 1.29.a, viene fornito il supporto per le versioni seguenti:

Quando viene introdotta una nuova versione secondaria, la versione secondaria precedente diviene obsoleta e viene rimossa. Si supponga, ad esempio, che l'elenco attuale delle versioni secondarie supportate sia:

1.29
1.28
1.27

Quando il servizio Azure Kubernetes rilascia la versione 1.30, dopo 30 giorni non è più fornito supporto per tutte le versioni 1.27.

Il servizio Azure Kubernetes può supportare un numero qualsiasi di patch in base alla disponibilità delle versioni della community upstream per una determinata versione secondaria. Il servizio Azure Kubernetes si riserva il diritto di deprecare una di queste patch in qualsiasi momento a causa di un problema CVE o potenziale di bug. È sempre consigliabile usare la patch più recente per una versione secondaria.

Criteri di supporto della piattaforma

I criteri di supporto della piattaforma sono un piano di supporto ridotto per determinate versioni di Kubernetes non supportate. Durante il supporto della piattaforma, i clienti ricevono supporto da Microsoft solo per problemi correlati alla piattaforma del servizio Azure Kubernetes/Azure. Eventuali problemi relativi alla funzionalità e ai componenti di Kubernetes non sono coperti dal supporto.

I criteri di supporto della piattaforma si applicano ai cluster in una versione n-3 (dove n è la versione secondaria più recente supportata del servizio Azure Kubernetes generalmente disponibile), prima che il cluster sia sostituito da n-4. Ad esempio, Kubernetes v1.26 è considerato il supporto della piattaforma quando v1.29 è la versione di disponibilità generale più recente. Tuttavia, durante il rilascio della versione disponibile a livello generale 1.30, la versione 1.26 eseguirà l'aggiornamento automatico alla versione 1.27. Se si esegue una versione n-2, il momento in cui diventa n-3, tale versione diventa deprecata e si accede ai criteri di supporto della piattaforma.

Il servizio Azure Kubernetes si basa sulle versioni e sulle patch di Kubernetes, ovvero un progetto Open Source che supporta solo una finestra temporale scorrevole di tre versioni secondarie. Il servizio Azure Kubernetes può garantire un supporto completo solo mentre tali versioni vengono gestite upstream. Poiché non sono presenti più patch prodotte upstream, il servizio Azure Kubernetes può lasciare tali versioni senza patch o creare una copia tramite fork. A causa di questa limitazione, l’assistenza della piattaforma non supporta nulla che si basi su Kubernetes upstream.

Questa tabella illustra le linee guida per il supporto della community e per il supporto della piattaforma.

Versioni kubectl supportate

È possibile utilizzare una versione secondaria più vecchia o più recente rispetto kubectl alla versione di kube-apiserver, coerentemente con la politica di supporto di Kubernetes per kubectl.

Ad esempio, se la versione kube-apiserver è a 1.28, allora è possibile usare le versioni dalla 1.27 alla 1.29 di kubectl con quella versione kube-apiserver.

Per installare o aggiornare kubectl alla versione più recente, eseguire:

az aks install-cli

Install-AzAksKubectl -Version latest

Supporto a lungo termine (LTS)

Il servizio Azure Kubernetes fornisce un anno di supporto community e un anno di supporto a lungo termine (LTS) per il backup delle correzioni di sicurezza della comunità upstream nel nostro archivio pubblico. Il nostro gruppo di lavoro LTS upstream contribuisce agli sforzi della community per fornire ai clienti una finestra di supporto più ampia.

Per altre informazioni su LTS, vedere Supporto a lungo termine per il servizioservizio Azure Kubernetes (AKS).

Processo di rilascio e deprecazione

È possibile fare riferimento alle versioni future e alle versioni obsolete nel calendario di rilascio di Kubernetes del servizio Azure Kubernetes.

Per le nuove versioni secondarie di Kubernetes:

• Il servizio Azure Kubernetes pubblica un annuncio con la data pianificata di una nuova versione e la rispettiva deprecazione della versione precedente nelle note sulla versione del servizio Azure Kubernetes almeno 30 giorni prima della rimozione.
• Il servizio Azure Kubernetes usa Azure Advisor per avvisare se una nuova versione potrebbe causare problemi nel cluster a causa di API deprecate. Azure Advisor avvisa l'utente anche in caso di mancato supporto
• Il servizio Azure Kubernetes pubblica una notifica sull'integrità del servizio disponibile per tutti gli utenti con accesso al servizio Azure Kubernetes e al portale e invia un messaggio di posta elettronica agli amministratori delle sottoscrizioni con le date di rimozione della versione pianificata.

  Nota

  Per scoprire chi è l'amministratore della sottoscrizione o modificarlo, vedere Gestire le sottoscrizioni di Azure.

• A partire dalla rimozione della versione, l'utente ha 30 giorni di tempo per effettuare l'aggiornamento a una versione secondaria supportata e continuare a ricevere assistenza.

Per le nuove versioni patch di Kubernetes:

• A causa della natura urgente delle versioni patch, queste possono essere introdotte nel servizio quando diventano disponibili. Una volta disponibili, le patch hanno un ciclo di vita minimo di due mesi.
• In generale, il servizio Azure Kubernetes non comunica in modo ampio il rilascio di nuove versioni patch. Tuttavia, il servizio Azure Kubernetes monitora e convalida costantemente le patch CVE disponibili per un supporto tempestivo nel servizio Azure Kubernetes. Se viene trovata una patch critica o se è necessaria un'azione dell'utente, il servizio Azure Kubernetes invia una notifica di aggiornamento all’ultima patch disponibile.
• Dalla rimozione di una versione patch dal servizio Azure Kubernetes, si hanno 30 giorni di tempo per eseguire l'aggiornamento a una patch supportata e continuare a ricevere supporto. Tuttavia, non sarà più possibile creare cluster o pool di nodi dopo che la versione è deprecata/rimossa.

Eccezioni dei criteri delle versioni supportate

Il servizio Azure Kubernetes si riserva il diritto di aggiungere o rimuovere versioni nuove/esistenti con uno o più bug critici che influiscano sulla produzione o problemi di sicurezza senza preavviso.

A seconda della gravità del bug o del problema di sicurezza, le versioni patch specifiche potrebbero essere ignorate, oppure potrebbe esserne anticipato il lancio.

Portale di Azure e versioni dell'interfaccia della riga di comando

Quando si distribuisce un cluster del servizio Azure Kubernetes con il portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell, il cluster è impostato sulla versione secondaria N-1 e sull'ultima patch. Ad esempio, se il servizio Azure Kubernetes supporta 1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11 e 1.27.10, la versione predefinita selezionata è 1.28.7.

az aks get-versions --location eastus --output table

Get-AzAksVersion -Location eastus

Domande frequenti

In che modo Microsoft invia una notifica delle nuove versioni di Kubernetes?

Il team del servizio Azure Kubernetes pubblica annunci con date pianificate delle nuove versioni di Kubernetes nella documentazione, in GitHube nei messaggi di posta elettronica agli amministratori delle sottoscrizioni proprietari dei cluster che saranno esclusi dal supporto. Il servizio Azure Kubernetes usa anche Azure Advisor per avvisare l'utente all'interno del portale Azure se è fuori supporto e per informarlo sulle API deprecate che possono influire sull'applicazione o sul processo di sviluppo.

Con quale frequenza è consigliabile aggiornare le versioni di Kubernetes per mantenere il supporto?

A partire da Kubernetes 1.19, la community open source ha ampliato il supporto per un anno. Il servizio Azure Kubernetes esegue il commit per abilitare le patch e supportare la corrispondenza degli impegni upstream. Per i cluster del servizio Azure Kubernetes nella versione 1.19 e successive, è possibile eseguire l'aggiornamento almeno una volta all'anno per rimanere in una versione supportata.

Cosa accade quando si aggiorna un cluster Kubernetes con una versione secondaria non supportata?

Se si usa la versione n-3 o una versione precedente, significa che non si è supportati e verrà richiesto di eseguire l'aggiornamento. Quando l'aggiornamento dalla versione n-3 alla n-2 ha esito positivo, si è di nuovo all'interno dei criteri di supporto. Ad esempio:

• Se la versione secondaria meno recente del servizio Azure Kubernetes supportata è 1.27 e la versione in uso è 1.26 o precedente, non si è coperti dall’assistenza.
• Quando si esegue correttamente l'aggiornamento dalla versione 1.26 alla versione 1.27 o successive, si è di nuovo all'interno dei criteri di supporto.

I downgrade non sono supportati.

Cosa significa "Fuori dal supporto"?

"Fuori dal supporto" significa che:

• La versione in esecuzione non rientra nell'elenco delle versioni supportate.
• Al momento della richiesta di supporto, verrà richiesto di aggiornare il cluster a una versione supportata, a meno che non ci si trovi entro il periodo di tolleranza di 30 giorni dopo la deprecazione della versione.

Inoltre, il servizio Azure Kubernetes non garantisce alcun runtime o altre garanzie per i cluster all'esterno dell'elenco delle versioni supportate.

Cosa accade quando si ridimensiona un cluster Kubernetes con una versione secondaria non supportata?

Per le versioni secondarie non supportate dal servizio Azure Kubernetes, il ridimensionamento dovrebbe continuare a funzionare. Poiché non esistono garanzie di qualità del servizio, è consigliabile eseguire l'aggiornamento per ripristinare il supporto del cluster.

È possibile rimanere in una versione di Kubernetes per sempre?

Se un cluster non è supportato da più di tre (3) versioni secondarie e ha riscontrato rischi per la sicurezza, Azure contatta direttamente l'utente per aggiornare il cluster. Se non si esegue un'ulteriore azione, Azure si riserva il diritto di aggiornare automaticamente il cluster per conto dell'utente.

Cosa accade se si ridimensiona un cluster Kubernetes con una versione secondaria non supportata?

Per le versioni secondarie non supportate dal servizio Azure Kubernetes, il ridimensionamento dovrebbe continuare a funzionare. Poiché non esistono garanzie di qualità del servizio, è consigliabile eseguire l'aggiornamento per ripristinare il supporto del cluster.

Quale versione supporta il piano di controllo se il pool di nodi non è in una delle versioni del servizio Azure Kubernetes supportate?

Il piano di controllo deve trovarsi all'interno di una finestra di versioni di tutti i pool di nodi. Per informazioni dettagliate sull'aggiornamento del piano di controllo o dei pool di nodi, vedere la documentazione su aggiornamento dei pool di nodi.

Qual è la differenza consentita nelle versioni tra piano di controllo e pool di nodi?

Il criterio di asimmetria della versione ora consente una differenza fino a 3 versioni tra il piano di controllo e i pool di agenti. Il servizio Azure Kubernetes segue questa modifica dei criteri di asimmetria della versione a partire dalla versione 1.28 in poi.

È possibile ignorare più versioni del servizio Azure Kubernetes durante l'aggiornamento del cluster?

Quando si aggiorna un cluster del servizio Azure Kubernetes supportato, le versioni secondarie di Kubernetes non possono essere ignorate. La politica di spostamento della versione dei piani di controllo di Kubernetes non supporta il passaggio alla versione secondaria. Ad esempio, gli aggiornamenti tra:

• 1.28.x ->1.29.x: consentito.
• 1.27.x ->1.28.x: consentito.
• 1.27.x ->1.29.x: non consentito.

Si noti che per gli aggiornamenti della versione del piano di controllo, è possibile passare a 3 versioni secondarie per le versioni supportate dalla community in modo sequenziale.

Per eseguire l'aggiornamento da 1.27.x a>1.29.x:

1. Eseguire l'aggiornamento da 1.27.x a>1.28.x.
2. Eseguire l'aggiornamento da 1.28.x a>1.29.x.

Si noti che a partire dalla versione 1.28 in poi, le versioni del pool di agenti possono essere fino a 3 versioni precedenti alle versioni del piano di controllo per ogni criterio di asimmetria della versione. Quando la versione è molto inferiore alla versione minima supportata, potrebbe essere necessario eseguire più operazioni di aggiornamento del piano di controllo per ottenere la versione minima supportata. Ad esempio, se la versione corrente del piano di controllo è 1.23.x e si intende eseguire l'aggiornamento a una versione minima supportata di 1.27.x come esempio. Potrebbe essere necessario eseguire l'aggiornamento sequenziale 4 volte dalla versione 1.23.x per arrivare a 1.27.x. Si noti anche che le versioni del pool di agenti possono essere aggiornate alla versione secondaria del piano di controllo. Ciò significa che nell'esempio precedente è possibile aggiornare la versione del pool di agenti due volte, ad esempio una volta dalla versione 1.23.x alla 1.25.x, quando la versione del piano di controllo è alla 1.25.x. E successivamente da 1.25.x a 1.27.x , quando la versione del piano di controllo è 1.27.x. Quando si aggiorna sul posto, ad esempio piano di controllo e pool di agenti, si applicano le stesse regole applicabili all'aggiornamento del piano di controllo scritto in precedenza.

Quando si esegue un aggiornamento da una versione non supportata, l'aggiornamento viene eseguito senza alcuna garanzia di funzionalità ed è escluso dai contratti di servizio e dalla garanzia limitata. I cluster che eseguono la versione non supportata hanno la flessibilità di separare gli aggiornamenti del piano di controllo con gli aggiornamenti del pool di nodi. Tuttavia, se la versione è particolarmente obsoleta, si consiglia di ricreare il cluster.

È possibile creare un nuovo cluster 1.xx.x durante la finestra di supporto della piattaforma?

No, la creazione di nuovi cluster non è possibile durante il periodo di supporto della piattaforma.

Si è in una versione appena deprecata che non è supportata dalla piattaforma, è comunque possibile aggiungere nuovi pool di nodi? O bisogna eseguire l'aggiornamento?

Sì, è possibile aggiungere pool di agenti purché siano compatibili con la versione del piano di controllo.

Passaggi successivi

Per informazioni su come aggiornare il cluster, vedere:

• Aggiornare un cluster del servizio Azure Kubernetes
• Aggiornare più cluster del servizio Azure Kubernetes tramite la Gestione flotta Kubernetes di Azure