Supporto a lungo termine

La community di Kubernetes rilascia una nuova versione secondaria circa ogni quattro mesi, con una finestra di supporto per ogni versione per un anno. In servizio Azure Kubernetes (servizio Azure Kubernetes), questa finestra di supporto è denominata "Supporto della community".

Il servizio Azure Kubernetes supporta le versioni di Kubernetes che si trovano all'interno di questa finestra di supporto della community, per eseguire il push delle correzioni di bug e degli aggiornamenti della sicurezza dalle versioni della community.

Anche se l'innovazione fornita con questa cadenza di rilascio offre enormi vantaggi, è difficile tenersi aggiornati con le versioni di Kubernetes, che possono essere rese più difficili in base al numero di cluster del servizio Azure Kubernetes che è necessario gestire.

Tipi di supporto del servizio Azure Kubernetes

Dopo circa un anno, la versione di Kubernetes esce dal supporto della community e i cluster del servizio Azure Kubernetes sono ora a rischio perché le correzioni di bug e gli aggiornamenti della sicurezza non sono più disponibili.

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

LTS intende offrire un lungo periodo di tempo per pianificare e testare gli aggiornamenti in un periodo di due anni dalla disponibilità generale della versione kubernetes designata.

	Supporto della community	Supporto a lungo termine
Quando utilizzare	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 di supporto	Tre versioni secondarie ga	Una versione di Kubernetes (attualmente 1.27) per due anni

Abilitare il supporto a lungo termine

L'abilitazione e la disabilitazione del supporto a lungo termine consiste nello spostamento del cluster nel livello Premium e nella selezione esplicita del piano di supporto LTS.

Nota

Anche se è possibile abilitare LTS quando il cluster è in supporto della community, verrà addebitato un addebito dopo aver abilitato il livello Premium.

Creare un cluster con LTS abilitato

az aks create --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport --kubernetes-version 1.27

Nota

L'abilitazione e la disabilitazione di LTS è una combinazione di spostamento del cluster nel livello Premium, oltre a abilitare il supporto a lungo termine. Entrambi devono essere attivati o disattivati.

Abilitare LTS in un cluster esistente

az aks update --resource-group myResourceGroup --name myAKSCluster --tier premium --k8s-support-plan AKSLongTermSupport

Disabilitare LTS in un cluster esistente

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

Supporto a lungo termine, componenti aggiuntivi e funzionalità

Il team del servizio Azure Kubernetes tiene attualmente traccia delle versioni dei componenti aggiuntivi in cui esiste il supporto della community di Kubernetes. Quando una versione lascia il supporto della community, ci si basa su progetti open source per i componenti aggiuntivi gestiti per continuare a supportare tale supporto. A causa di vari fattori esterni, alcuni componenti aggiuntivi e funzionalità potrebbero non supportare le versioni di Kubernetes all'esterno di queste finestre di supporto della community upstream.

Vedere la tabella seguente per un elenco di componenti aggiuntivi e funzionalità che non sono supportati e il motivo per cui.

Componente aggiuntivo/Funzionalità	Motivo per cui non è supportato
Istio	Il ciclo di supporto di Istio è breve (sei mesi) e non saranno disponibili versioni di manutenzione per Kubernetes 1.27
Keda	Impossibile garantire la compatibilità delle versioni future con Kubernetes 1.27
Calico	Richiede il supporto della Community per il contratto Calico Enterprise precedente
Cillium	Richiede il supporto di Cillium Enterprise Agreement in passato per la community
Servizio di gestione delle chiavi	Servizio di gestione delle chiavi v2 sostituisce Servizio di gestione delle chiavi durante questo ciclo LTS
Dapr	Le estensioni del servizio Azure Kubernetes non sono supportate
Controller di ingresso del gateway applicazione	La migrazione al gateway app per i contenitori avviene durante il periodo LTS
Open Service Mesh	OSM sarà deprecato
Identità pod AAD	Deprecato al posto dell'identità del carico di lavoro

Nota

Non è possibile spostare il cluster nel supporto a lungo termine se una di queste funzionalità o componenti aggiuntivi è abilitata.
Sebbene questi componenti aggiuntivi gestiti dal servizio Azure Kubernetes non siano supportati da Microsoft, è possibile installare le versioni Open Source di questi componenti nel cluster se si vuole usarlo in passato il supporto della community.

Come si decide la prossima versione LTS

Le versioni di Kubernetes LTS sono disponibili per due anni dalla disponibilità generale, contrassegnando una versione successiva di Kubernetes come LTS in base ai criteri seguenti:

• Tempo sufficiente per consentire ai clienti di eseguire la migrazione dalla versione LTS precedente alla versione corrente
• La versione precedente ha avuto una finestra di supporto di due anni

Leggere le note sulla versione del servizio Azure Kubernetes per rimanere informati su quando è possibile pianificare la migrazione.

Eseguire la migrazione da LTS al supporto della community

L'uso di LTS è un modo per estendere la finestra per pianificare un aggiornamento della versione di Kubernetes. È possibile eseguire la migrazione a una versione di Kubernetes all'interno della finestra di supporto standard.

Per passare da un cluster abilitato per LTS a una versione di Kubernetes all'interno della finestra di supporto standard, è necessario disabilitare LTS nel cluster:

az aks update --resource-group myResourceGroup --name myAKSCluster --tier [free|standard] --k8s-support-plan KubernetesOfficial

Aggiornare quindi il cluster a una versione successiva supportata:

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.28.3

Nota

Kubernetes 1.28.3 viene usato come esempio qui. Controllare lo strumento di rilevamento delle versioni del servizio Azure Kubernetes per le versioni di Kubernetes disponibili.

Ci sono circa due anni tra una versione LTS e la successiva. Al posto del supporto upstream per la migrazione di più di due versioni secondarie, è probabile che l'applicazione dipenda dalle API Kubernetes deprecate. È consigliabile testare accuratamente l'applicazione nella versione di Kubernetes LTS di destinazione ed eseguire una distribuzione blu/verde da una versione a un'altra.

Eseguire la migrazione da LTS alla versione successiva LTS

La community di Kubernetes upstream supporta un percorso di aggiornamento a due versioni secondarie. Il processo esegue la migrazione degli oggetti nel cluster Kubernetes come parte del processo di aggiornamento e fornisce un percorso di migrazione testato e accreditato.

Per i clienti che desiderano eseguire una migrazione sul posto, il servizio Servizio Azure Kubernetes eseguirà la migrazione del piano di controllo dalla versione LTS precedente alla versione più recente e quindi eseguirà la migrazione del piano dati.

Per eseguire un aggiornamento sul posto alla versione LTS più recente, è necessario specificare una versione kubernetes abilitata per LTS come destinazione di aggiornamento.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.32.2

Nota

Se si usa una logica di programmazione/scripting per elencare e selezionare una versione secondaria di Kubernetes prima di creare cluster con l'API ListKubernetesVersions , si noti che a partire da Kubernetes v1.27, l'API restituisce SupportPlan come [KubernetesOfficial, AKSLongTermSupport]. Assicurarsi di aggiornare qualsiasi logica per escludere AKSLongTermSupport le versioni per evitare interruzioni e scegliere KubernetesOfficial le versioni del piano di supporto. In caso contrario, se LTS è effettivamente il percorso in avanti, acconsentire esplicitamente al livello Premium e alle versioni del AKSLongTermSupport piano di supporto dall'API ListKubernetesVersions prima di creare cluster.

Nota

La prossima versione del supporto a lungo termine dopo la versione 1.27 deve essere determinata. Tuttavia, i clienti avranno almeno 6 mesi di sovrapposizione tra 1.27 LTS e la versione LTS successiva per pianificare gli aggiornamenti.
Kubernetes 1.32.2 viene usato come versione di esempio in questo articolo. Controllare lo strumento di rilevamento delle versioni del servizio Azure Kubernetes per le versioni disponibili di Kubernetes.