Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
Aggiornamenti avviati dalla piattaforma AKS. A partire dal 1° giugno 2027, AKS aggiorna automaticamente tutti i cluster che rimangono in una versione Kubernetes non supportata al termine del periodo di tolleranza della piattaforma di 60 giorni. Un aggiornamento avviato dalla piattaforma non segue la finestra di manutenzione, non si arresta per l'utilizzo deprecato dell'API e può ignorare un Pod Disruption Budget che blocca lo svuotamento di un nodo, in modo che i carichi di lavoro possano essere interrotti. Prima del mese precedente all'aggiornamento, sostituire le API rimosse dalla versione di Kubernetes di destinazione e aggiornare componenti aggiuntivi autogestiti incompatibili. Mantenere i cluster in una versione di Kubernetes supportata per evitare un aggiornamento avviato dalla piattaforma. Per altre informazioni, vedere Preparare gli aggiornamenti avviati dalla piattaforma in AKS.
La community di Kubernetes rilascia una nuova versione secondaria circa ogni quattro mesi e ogni versione ha una finestra di supporto di un anno. Nel servizio Azure Kubernetes questa finestra di supporto è denominata supporto della community.
Per le versioni di Kubernetes nel supporto della community, il servizio Azure Kubernetes fornisce correzioni di bug e aggiornamenti della sicurezza dalle release della community. Può essere difficile rimanere aggiornati con la frequenza di rilascio di Kubernetes quando le applicazioni hanno dipendenze complesse.
Il supporto a lungo termine (LTS) estende la finestra di supporto in modo da avere più tempo per pianificare e testare gli aggiornamenti alle versioni più recenti di Kubernetes.
Tipi di supporto AKS
Dopo circa un anno, una determinata versione secondaria di Kubernetes esce dal supporto della community e le correzioni di bug e gli aggiornamenti della sicurezza non sono disponibili per i cluster AKS.
Il servizio Azure Kubernetes offre un anno di supporto della community, seguito da un anno aggiuntivo di supporto a lungo termine. Insieme, il supporto della community e i periodi LTS offrono circa 24 mesi di supporto totale dalla disponibilità generale della versione di Kubernetes. Durante l'anno LTS, AKS applica retroattivamente le correzioni di sicurezza dalla community upstream. Il gruppo di lavoro upstream LTS contribuisce alla community, estendendo la finestra di supporto.
| Supporto della comunità | Supporto a lungo termine | |
|---|---|---|
| Quando usare | Quando è possibile tenere il passo con le versioni upstream di Kubernetes | Quando è necessario controllare quando eseguire la migrazione da una versione a un'altra |
| Versioni supportate | Tre versioni minori GA più recenti | Tutte le versioni di Kubernetes supportate sono idonee per LTS. Vedere il calendario delle versioni LTS di AKS. |
Processo di patch di supporto a lungo termine
LTS supporta solo le due versioni patch più recenti. Il supporto della community può includere un numero qualsiasi di patch attualmente offerte. Tuttavia, AKS si riserva il diritto di deprecare qualsiasi versione di patch in risposta a vulnerabilità di sicurezza critiche (CVE). Per altre informazioni sui criteri di supporto della community, vedere Criteri di supporto delle versioni di Kubernetes.
Per identificare le versioni patch supportate più recenti, vedere il tracker delle versioni di rilascio di AKS.
Abilitare il supporto a lungo termine
L'abilitazione di LTS richiede lo spostamento del cluster nel livello Premium e la selezione esplicita del piano di supporto LTS. È possibile partecipare in qualsiasi momento, anche se il cluster è ancora in supporto della comunità.
LTS è disponibile nel livello Premium. Per le tariffe correnti, vedere prezzi di AKS.
Nota
Abilitare il canale di aggiornamento automatico delle patch per mantenere il cluster aggiornato con le patch supportate più recenti. LTS supporta solo le due versioni patch più recenti per ogni versione secondaria. I cluster che non eseguono una di queste versioni di patch potrebbero perdere il supporto.
Abilitare LTS in un nuovo cluster
Creare un nuovo cluster con LTS abilitato usando il az aks create comando . AKS usa la versione predefinita supportata di Kubernetes e la patch più recente disponibile nell'area.
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--tier premium \
--k8s-support-plan AKSLongTermSupport \
--auto-upgrade-channel patch \
--generate-ssh-keys
Il comando usa i valori di parametro specifici di LTS seguenti:
-
--tier premiumimposta il livello di gestione del cluster su Premium, necessario per LTS. -
--k8s-support-plan AKSLongTermSupportregistra il cluster in LTS e fornisce un anno aggiuntivo di correzioni per la sicurezza. -
--auto-upgrade-channel patchaggiorna automaticamente il cluster alle versioni patch supportate mantenendo la stessa versione secondaria.
Abilitare LTS in un cluster esistente
Abilitare LTS in un cluster esistente usando il az aks update comando .
az aks update --resource-group <resource-group-name> --name <cluster-name> --tier premium --k8s-support-plan AKSLongTermSupport --auto-upgrade-channel patch
Il comando usa i valori di parametro specifici di LTS seguenti:
-
--tier premiumsposta il cluster al livello di gestione del cluster Premium, necessario per LTS. -
--k8s-support-plan AKSLongTermSupportregistra il cluster in LTS e fornisce un anno aggiuntivo di correzioni per la sicurezza. -
--auto-upgrade-channel patchaggiorna automaticamente il cluster alle versioni patch supportate mantenendo la stessa versione secondaria.
Suggerimento
Per vedere a quali versioni di Kubernetes è possibile eseguire l'aggiornamento, utilizza il tracker delle versioni AKS oppure esegui az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name>.
Eseguire la migrazione alla versione LTS più recente
Per eseguire un aggiornamento sul posto alla versione LTS più recente, specificare una versione LTS più recente offerta dal servizio Azure Kubernetes come destinazione di aggiornamento. Un cluster LTS può ignorare le versioni secondarie quando l'aggiornamento soddisfa i requisiti di version skew e i controlli di convalida. Per altre informazioni, vedere Regole di aggiornamento della versione di Kubernetes.
Durante un aggiornamento sul posto completo, AKS aggiorna prima il piano di controllo e quindi aggiorna ogni pool di nodi in sequenza. Testa i carichi di lavoro rispetto alle API deprecate e ad altre modifiche che causano incompatibilità tra le versioni correnti e di destinazione prima dell'aggiornamento.
Elencare le versioni che AKS offre come destinazioni di aggiornamento per il cluster usando il comando
az aks get-upgrades.az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableEseguire l'aggiornamento a una versione LTS offerta usando il
az aks upgradecomando .az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <lts-kubernetes-version>Nota
Tutte le versioni supportate di Kubernetes AKS sono compatibili con LTS. Per il calendario LTS più recente, vedere il calendario delle versioni di Kubernetes di AKS. Per visualizzare le versioni LTS disponibili e le relative patch in base all'area, vedere il AKS release tracker.
Disabilitare il supporto a lungo termine in un cluster esistente
Per disabilitare LTS in un cluster esistente, spostare il cluster nel livello Gratuito o Standard e selezionare in modo esplicito il piano di KubernetesOfficial supporto.
È possibile disabilitare LTS mentre la versione kubernetes del cluster è ancora supportata dalla community. Dopo che tale versione esce dal supporto della community, aggiornare il cluster a una versione supportata dalla community prima di disabilitare LTS. Controllare il calendario delle versioni di AKS Kubernetes per determinare lo stato di supporto della versione.
Se la versione corrente non è supportata dalla community, elencare le destinazioni di aggiornamento disponibili usando il
az aks get-upgradescomando .az aks get-upgrades --resource-group <resource-group-name> --name <cluster-name> --output tableSe necessario, aggiornare il cluster a una versione offerta che è supportata dalla community usando il comando
az aks upgrade.az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version <community-supported-kubernetes-version>Disabilita LTS usando il comando
az aks update. L'esempio seguente sposta il cluster nel livello Gratuito e seleziona ilKubernetesOfficialpiano di supporto.az aks update --resource-group <resource-group-name> --name <cluster-name> --tier free --k8s-support-plan KubernetesOfficialIl
--tier freevalore sposta il cluster nel livello di gestione del cluster gratuito e--k8s-support-plan KubernetesOfficialpassa il cluster da LTS al piano di supporto kubernetes standard del servizio Azure Kubernetes.
Considerazioni sul ciclo di vita dei componenti aggiuntivi e delle funzionalità
LTS estende il supporto per la versione di Kubernetes, ma i componenti aggiuntivi e le funzionalità possono avere cicli di vita di supporto separati. Prima di spostare un cluster in LTS, esaminare il ciclo di vita e la compatibilità della versione di Kubernetes di ogni componente aggiuntivo e di ogni funzionalità usati dal cluster.
La tabella seguente riepiloga le considerazioni correnti sul ciclo di vita:
| Componente aggiuntivo o funzionalità | Considerazioni sul ciclo di vita |
|---|---|
| Calicò | Verificare che la versione di Calico supporti la versione di Kubernetes di destinazione ed esaminare le condizioni di supporto di Tigera per l'uso oltre al supporto della community di Kubernetes. |
| Servizio di gestione delle chiavi | L'esperienza KMS esistente è ora designata come legacy. Per Kubernetes 1.33 e versioni successive, vedere la nuova esperienza di crittografia dei dati KMS e le indicazioni sulla migrazione applicabili. Sia la nuova esperienza che il flusso di lavoro di migrazione sono in anteprima. |
| Dapr | L'estensione Dapr gestita usa una finestra di supporto continuativa che include la versione corrente e quelle precedenti di Dapr. Mantenere l'estensione nell'intervallo di versioni supportate. |
| Application Gateway Ingress Controller (AGIC) | AGIC rimane disponibile. Inizia la transizione ad Application Gateway for Containers. |
| Open Service Mesh (OSM) | Il supporto di AKS per il componente aggiuntivo OSM gestito termina il 30 settembre 2027. Eseguire la migrazione al componente aggiuntivo Istio prima di tale data. |
| Microsoft Entra identità gestita da pod | Il supporto per il componente aggiuntivo gestito è terminato a settembre 2025. Eseguire la migrazione a ID dei carichi di lavoro di Microsoft Entra. |
| SGX (ACC SGX) Azure Confidential Compute | Verificare che ACC SGX supporti la versione di Kubernetes di destinazione prima di spostare il cluster oltre il supporto della community. |
Pianificare l'aggiornamento LTS successivo
AKS rende idonee le versioni consecutive di Kubernetes per LTS e pubblica una data di fine vita LTS separata per ogni versione. Usare il calendario delle versioni di rilascio LTS di AKS e il tracker delle versioni di AKS per scegliere una versione di destinazione offerta e pianificare la migrazione prima che la versione corrente raggiunga la data di fine vita LTS.
Se non si esegue l'aggiornamento, il servizio Azure Kubernetes aggiorna automaticamente il cluster dopo il periodo di tolleranza di 60 giorni che segue la data di fine vita LTS, tramite un aggiornamento avviato dalla piattaforma. Il cluster rimane sulla traccia LTS e passa alla versione LTS supportata successiva. Gli aggiornamenti avviati dalla piattaforma non seguono la finestra di manutenzione, quindi l'aggiornamento in base alla propria pianificazione è l'unico modo per mantenere il controllo dei tempi.
Domande frequenti
È possibile creare un nuovo cluster AKS con una versione LTS dopo il termine del supporto della community?
Sì, è possibile creare un nuovo cluster del servizio Azure Kubernetes usando una versione LTS al termine del periodo di supporto della community se si abilita LTS. Il supporto LTS continua solo fino alla fine del ciclo di vita di tale versione. È quindi necessario eseguire l'aggiornamento alla versione LTS supportata successiva. Per altre informazioni, vedere il calendario delle versioni di Kubernetes per AKS.
Posso abilitare e disabilitare LTS in una versione supportata da AKS dopo la fine del supporto della comunità?
Sì, è possibile abilitare il piano di supporto LTS in qualsiasi versione supportata dal servizio Azure Kubernetes anche dopo il termine del periodo di supporto della community. Tuttavia, una volta terminato il periodo di supporto della community, non è possibile disabilitare LTS per tale versione.
Un cluster AKS supportato dalla community diventa automaticamente idoneo per LTS dopo la fine del ciclo di vita?
No. È necessario abilitare in modo esplicito LTS e spostare il cluster nel livello Premium.
Un aggiornamento avviato dalla piattaforma registra il cluster in LTS?
No. Il servizio Azure Kubernetes non registra mai un cluster in LTS per conto dell'utente e non modifica mai il livello di fatturazione. Un aggiornamento avviato dalla piattaforma mantiene il cluster nel livello di supporto corrente: un cluster di supporto della community passa alla versione secondaria della community più bassa supportata e un cluster LTS passa alla versione LTS applicabile.
Cosa accade se la versione LTS del cluster raggiunge la fine del ciclo di vita e non si esegue l'aggiornamento?
Il servizio Azure Kubernetes aggiorna il cluster alla versione LTS supportata successiva dopo il periodo di tolleranza di 60 giorni che segue la data di fine vita LTS. Il cluster non viene declassato a una versione supportata dalla community. Per trovare il mese per la versione, vedere il calendario di rilascio del servizio Azure Kubernetes LTS. Per altre informazioni, vedere Aggiornamenti avviati dalla piattaforma.
Ogni versione del servizio Azure Kubernetes è idonea per il supporto a lungo termine?
Yes. Tutte le versioni di Kubernetes supportate sono idonee per LTS.
Qual è il modello di determinazione prezzi per LTS?
LTS è disponibile nel livello Premium. Per le tariffe correnti, vedere Prezzi del piano Premium.
L'abilitazione di LTS interrompe i carichi di lavoro?
No. Si tratta di una modifica di sola configurazione; non reinstalla l'immagine dei nodi né interrompe i carichi di lavoro, quindi non è previsto alcun tempo di inattività.