Supporto a lungo termine per le versioni del servizio Azure Kubernetes

Articolo
09/25/2024

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 gli aggiornamenti della sicurezza dalle versioni della community. Anche se la frequenza di rilascio del supporto della community offre vantaggi, richiede di rimanere aggiornati con le versioni di Kubernetes, che possono essere difficili a seconda delle dipendenze dell'applicazione e del ritmo di modifica nell'ecosistema Kubernetes.

Per gestire gli aggiornamenti delle versioni di Kubernetes, il servizio Azure Kubernetes offre un'opzione di supporto a lungo termine (LTS), che estende la finestra di supporto per una versione di Kubernetes per offrire più tempo per pianificare e testare gli aggiornamenti alle versioni più recenti di Kubernetes.

Tipi di supporto del servizio Azure Kubernetes

Dopo circa un anno, una determinata versione secondaria di Kubernetes esce dal supporto della community, rendendo le correzioni di bug e gli aggiornamenti della sicurezza non disponibili per i cluster del servizio Azure Kubernetes.

Il servizio Azure Kubernetes offre un anno di supporto per la community e un anno di supporto a lungo termine per supportare le correzioni di sicurezza delle porte dalla community upstream nel repository del servizio Azure Kubernetes pubblico. Il gruppo di lavoro upstream LTS contribuisce a fornire ai clienti una finestra di supporto più lunga. LTS intende offrire un lungo periodo di tempo per pianificare e testare gli aggiornamenti in un periodo di due anni dalla disponibilità generale (GA) 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 di LTS richiede lo spostamento del cluster nel livello Premium e la selezione esplicita del piano di supporto LTS. Anche se è possibile abilitare LTS quando il cluster è in *supporto della community, l'addebito verrà addebitato dopo aver abilitato il livello Premium.

Abilitare LTS in un nuovo cluster

Creare un nuovo cluster con LTS abilitato usando il az aks create comando .

Il comando seguente crea un nuovo cluster del servizio Azure Kubernetes con LTS abilitato usando Kubernetes versione 1.27 come esempio. Per esaminare le versioni di Kubernetes disponibili, vedere lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.
```
az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --tier premium \
    --k8s-support-plan AKSLongTermSupport \
    --kubernetes-version 1.27 \
    --generate-ssh-keys
```

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

Eseguire la migrazione alla versione LTS più recente

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.

Se si vuole 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.

Eseguire la migrazione alla versione LTS più recente usando il az aks upgrade comando .

Il comando seguente usa Kubernetes versione 1.32.2 come versione di esempio. Per esaminare le versioni di Kubernetes disponibili, vedere lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.
```
az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.32.2
```
Nota

1.30 è la versione LTS successiva dopo la 1.27. È possibile acconsentire esplicitamente a LTS da un cluster versione 1.30 tramite i passaggi descritti in precedenza. LTS versione 1.27 passerà alla fine della vita (EOL) entro luglio 2025.

Disabilitare il supporto a lungo termine in un cluster esistente

La disabilitazione di LTS in un cluster esistente richiede lo spostamento del cluster al livello gratuito o standard e la selezione esplicita del piano di supporto KubernetesOfficial.

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.

Disabilitare LTS in un cluster esistente usando il az aks update comando .

az aks update --resource-group <resource-group-name> --name <cluster-name> --tier [free|standard] --k8s-support-plan KubernetesOfficial

Aggiornare il cluster a una versione supportata successiva usando il az aks upgrade comando .

Il comando seguente usa Kubernetes versione 1.28.3 come versione di esempio. Per esaminare le versioni di Kubernetes disponibili, vedere lo strumento di rilevamento delle versioni del servizio Azure Kubernetes.
```
az aks upgrade --resource-group <resource-group-name> --name <cluster-name> --kubernetes-version 1.28.3
```

Componenti aggiuntivi e funzionalità non supportati

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 affida ai 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 al di fuori di queste finestre di supporto della community upstream.

La tabella seguente fornisce un elenco di componenti aggiuntivi e funzionalità non supportati e i motivi per cui non sono supportati:

Componente aggiuntivo/Funzionalità	Motivo per cui non è supportato
Istio	Il ciclo di supporto di Istio è breve (sei mesi) e non verranno rilasciate 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.
Servizio di gestione delle chiavi	KMSv2 sostituisce il 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 contenitori avviene durante il periodo LTS.
Open Service Mesh	OSM è 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.

Anche se questi componenti aggiuntivi gestiti del servizio Azure Kubernetes non sono supportati da Microsoft, è possibile installare le versioni open source nel cluster se si vuole usarli oltre il supporto della community.

Come si decide la prossima versione LTS

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

È trascorso tempo sufficiente per consentire ai clienti di eseguire la migrazione dalla versione LTS precedente alla versione LTS 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.

Domande frequenti

Il supporto della community per il servizio Azure Kubernetes 1.27 scade a luglio 2024. Dopo tale data è possibile creare un nuovo cluster del servizio Azure Kubernetes con la versione 1.27?

Sì, purché LTS sia abilitato nel cluster, è possibile creare un nuovo cluster del servizio Azure Kubernetes con la versione 1.27 al termine della finestra di supporto della community.

È possibile abilitare e disabilitare LTS nel servizio Azure Kubernetes 1.27 dopo la fine del supporto della community?

È possibile abilitare il piano di supporto LTS nel servizio Azure Kubernetes 1.27 dopo la fine del supporto della community. Tuttavia, non è possibile disabilitare LTS nel servizio Azure Kubernetes 1.27 dopo la fine del supporto della community.

È in esecuzione un cluster nella versione 1.27. Significa che è automaticamente in LTS?

No, è necessario abilitare in modo esplicito LTS nel cluster per ricevere il supporto LTS. L'abilitazione di LTS richiede anche il livello Premium.

Qual è il modello di determinazione prezzi per LTS?

LTS è disponibile nel livello Premium. Per altre informazioni, consultare i prezzi del piano Premium.

Dopo l'abilitazione di LTS, l'autoUpgradeChannel del cluster è cambiato in canale patch

Si tratta di un comportamento previsto. Se non è stato definito autoUpgradeChannel per il cluster del servizio Azure Kubernetes, per impostazione predefinita verrà predefinito patch con LTS.

Condividi tramite