Condividi tramite

Versioni di Kubernetes supportate nel servizio Azure Kubernetes (AKS)

  • Articolo

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 è su 1.29.1 e 1.29.2 è la versione di patch disponibile più recente per la versione minore 1.29, è necessario eseguire l'aggiornamento a 1.29.2 quanto prima per far sì che il cluster sia completamente aggiornato e supportato.

Calendario delle versioni di AKS Kubernetes

Visualizza le prossime versioni nel calendario delle release di AKS Kubernetes. Per vedere gli aggiornamenti in tempo reale sullo stato di rilascio delle regioni e le note di rilascio delle versioni, visitare la pagina dello stato di rilascio di AKS. Per ulteriori informazioni sulla pagina Web relativa allo stato di rilascio, consulta il tracciatore di rilascio AKS.

Nota

AKS segue 12 mesi di supporto per una versione di Kubernetes generalmente disponibile (GA). Per altre informazioni sui criteri di supporto per il controllo delle versioni di Kubernetes, leggere le domande frequenti.

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

Versione K8s Rilascio della versione upstream Anteprima di AKS Disponibilità Generale del Servizio Azure Kubernetes Fine del ciclo di vita Supporto per la piattaforma
1,29 Dic. 2023 Feb 2024 Marzo 2024 Marzo 2025 Fino alla disponibilità generale 1.33
1,30 Aprile 2024 Giugno 2024 Luglio 2024 Luglio 2025 Fino alla disponibilità generale 1.34
1.31 Ago 2024 Ottobre 2024 Novembre 2024 Novembre 2025 Fino alla disponibilità generale 1.35
1.32 Dicembre 2024 Febbraio 2025 Aprile 2025 Marzo 2026 Fino alla disponibilità generale 1.36

Versioni LTS

Nota

Azure Linux supporta solo 1.27 LTS. Per altre informazioni sulla versione 1.30 LTS di Azure Linux, vedere la sezione Versioni LTS di Azure Linux AKS.

Versione K8s Rilascio della versione upstream Anteprima del servizio AKS (Azure Kubernetes Service) Disponibilità Generale del Servizio Azure Kubernetes Fine del ciclo di vita Fine vita LTS
1.27 aprile 2023 Giugno 2023 luglio 2023 Luglio 2024 Luglio 2025
1.28 Agosto 2023 Settembre 2023 nov 2023 Gennaio 2025 Febbraio 2026
1,30 Aprile 2024 Giugno 2024 Luglio 2024 Luglio 2025 Luglio 2026

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:

Diagramma di Gantt che mostra il ciclo di vita di tutte le versioni di Kubernetes attualmente attive nel servizio Azure Kubernetes, incluso il supporto a lungo termine.

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.32

Componenti aggiuntivi gestiti di AKS Componenti AKS Componenti del sistema operativo Modifiche di rilievo Note
• Criteri di Azure 1.8.0
• Metrics-Server 0.6.3
• Operatore di routing delle app v0.2.3
• KEDA 2.14.1
• Open Service Mesh v1.2.9
• DNS principale V1.9.4
• Overlay VPA 1.0.0
• Azure-Keyvault-SecretsProvider v1.4.5
• Controller in ingresso del gateway applicazione (AGIC) 1.7.2
• Image Cleaner v1.3.1
• Identità del carico di lavoro di Azure v1.3.0
• Agente di raccolta di basso livello di Data center modulare Defender 2.0.186
• open-policy-agent-gatekeeper v3.17.1
• Retina v0.0.17
 • Cilium v1.17.0
• Cluster Autoscaler v1.30.6-aks
• Tigera-Operator v1.34.7
 • Immagine del sistema operativo Ubuntu 22.04 Cgroup V2
• ContainerD 1.7.23-ubuntu22.04u1 per Linux e v1.6.35+azure per Windows
• Azure Linux 3.0
• Cgroups V2
• ContainerD 1.7.13-3.azl
 • Calico v1.34.7 N/D

Kubernetes 1.31

Componenti aggiuntivi gestiti dal servizio Azure Kubernetes Componenti di AKS Componenti del sistema operativo Modifiche di rilievo Note
• Criteri di Azure 1.8.0
• Metrics-Server 0.6.3
• Operatore di routing delle app v0.2.3
• KEDA 2.14.1
• Open Service Mesh v1.2.9
• DNS principale V1.9.4
• Overlay VPA 1.0.0
• Azure-Keyvault-SecretsProvider v1.4.5
• Controller in ingresso del gateway applicazione (AGIC) 1.7.2
• Image Cleaner v1.3.1
• Identità del carico di lavoro di Azure v1.3.0
• Agente di raccolta di basso livello di Data center modulare Defender 2.0.186
• open-policy-agent-gatekeeper v3.17.1
• Retina v0.0.17
 • Cilium v1.16.6
• Cluster Autoscaler v1.30.6-aks
• Tigera-Operator v1.30.11
 • Immagine del sistema operativo Ubuntu 22.04 Cgroups V2
• ContainerD 1.7.23-ubuntu22.04u1 per Linux e v1.6.35+azure per Windows
• Azure Linux 3.0
• Cgroups V2
• ContainerD 1.7.13-3.azl
 • Calico 1.30.11 N/D

Kubernetes 1.30

Componenti aggiuntivi gestiti dal servizio Azure Kubernetes Componenti AKS Componenti del sistema operativo Modifiche di rilievo Note
• Azure Policy 1.3.0
• Operatore di routing delle app v0.2.3
• Metrics-Server 0.6.3
• KEDA 2.11.2
• Open Service Mesh 1.2.7
• DNS principale V1.9.4
• Overlay VPA 0.13.0
• Azure-Keyvault-SecretsProvider 1.4.1
• Application Gateway Ingress Controller (AGIC) 1.7.2
• Image Cleaner v1.2.3
• Identità del carico di lavoro di Azure v1.2.0
• Data center modulare Defender Security Publisher 1.0.68
• MDC Defender Old File Cleaner 1.3.68
• Data center modulare Defender Pod agente di raccolta 1.0.78
• Agente di raccolta di basso livello di Data center modulare Defender 2.0.186
• Identità di pod di Azure Active Directory 1.8.13.6
• GitOps 1.8.1
• Driver dell'archivio dei segreti CSI 1.3.4-1
• azurefile-csi-driver 1.29.3
 • Cilium v1.14.9
• CNI v1.4.43.1 (impostazione predefinita)/v1.5.11 (sovrimpressione di Azure CNI)
• Cluster Autoscaler 1.27.3
• Tigera-Operator 1.30.7
 • Immagine del sistema operativo Ubuntu 22.04 Cgroup V2
• ContainerD 1.7.5 per Linux e 1.7.1 per Windows
• Azure Linux 2.0
• Cgroups V2
• ContainerD 1.6
 • Tigera-Operator 1.30.7 Non applicabile

Kubernetes 1.29

Componenti aggiuntivi gestiti dal servizio Azure Kubernetes Componenti del servizio Azure Kubernetes Componenti del sistema operativo Modifiche di rilievo Note
• Azure Policy 1.3.0
• csi-provisioner v4.0.0
• Operatore di routing delle app v0.2.1
• csi-attacher v4.5.0
• csi-snapshotter v6.3.3
• snapshot-controller versione 6.3.3
• Metrics-Server 0.6.3
• KEDA 2.11.2
• Open Service Mesh 1.2.7
• DNS principale V1.9.4
• Overlay VPA 0.13.0
• Azure-Keyvault-SecretsProvider 1.4.1
• Application Gateway Ingress Controller (AGIC) 1.7.2
• Image Cleaner v1.2.3
• Identità del carico di lavoro di Azure v1.2.0
• MDC Defender Security Publisher 1.0.68
• MDC Defender Old File Cleaner 1.3.68
• Data center modulare Defender Pod agente di raccolta 1.0.78
• Agente di raccolta di basso livello di Data center modulare Defender 2.0.186
• Identità di pod di Azure Active Directory 1.8.13.6
• GitOps 1.8.1
• Driver dell'archivio dei segreti CSI 1.3.4-1
• azurefile-csi-driver 1.29.3
 • Cilium v1.14.9
• CNI v1.4.43.1 (impostazione predefinita)/v1.5.11 (sovrimpressione di Azure CNI)
• Cluster Autoscaler 1.27.3
• Tigera-Operator 1.30.7
 • Immagine del sistema operativo Ubuntu 22.04 Cgroups V2
• ContainerD 1.7.5 per Linux e 1.7.1 per Windows
• Azure Linux 2.0
• Cgroups V2
• ContainerD 1.6
 • Tigera-Operator 1.30.7
• csi-provisioner v4.0.0
• csi-attacher v4.5.0
• csi-snapshotter v6.3.3
• snapshot-controller v6.3.3		 N/D

Versione secondaria dell'alias

Nota

La versione minor di Alias richiede Azure CLI versione 2.37 o superiore e API versione 20220401 o superiore. Usare az upgrade per installare la versione più recente dell'interfaccia della riga di comando.

AKS consente di creare un cluster senza specificare esattamente la versione patch. Quando si crea un cluster senza designare una patch, il cluster esegue la patch GA più recente della versione minore. Ad esempio, se crei un cluster con 1.29 e 1.29.2 rappresenta l'ultima patch di GA disponibile, il cluster sarà 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

AKS definisce una versione di disponibilità generale (GA) come una versione disponibile in tutte le regioni e abilitata in tutte le metriche SLO o SLA. AKS supporta tre versioni secondarie GA 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. AKS si riserva il diritto di deprecare le patch se viene rilevata una vulnerabilità di sicurezza critica o una CVE. Per informazioni sulla disponibilità delle patch e su qualsiasi deprecazione ad hoc, vedere le note sulla versione e visitare la pagina dello stato del rilascio di AKS.

AKS potrebbe anche supportare le versioni di anteprima, che sono etichettate esplicitamente e soggette a termini e condizioni 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.

Nota

Il servizio Azure Kubernetes usa procedure di distribuzione sicure che comportano la distribuzione regionale graduale. Ciò significa che potrebbero essere necessari fino a 10 giorni lavorativi per una nuova versione o una nuova versione disponibile in tutte le regioni.

La finestra supportata delle versioni minori di Kubernetes su AKS è nota come "N-2", dove N si riferisce all'ultima versione rilasciata, significando che sono supportate anche le due versioni minori precedenti.

Ad esempio, nel giorno in cui AKS introduce la versione 1.29, viene fornito il supporto per le versioni seguenti:

Nuova versione minore Elenco delle versioni secondarie supportate
1,29 1.29, 1.28, 1.27

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 AKS rilascia la versione 1.30, tutte le versioni 1.27 non saranno più supportate 30 giorni dopo.

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

La politica di supporto della piattaforma è un piano di supporto ridotto per alcune 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 la versione disponibilità generale 1.30, la versione 1.26 verrà automaticamente aggiornata alla versione 1.27. Se si sta utilizzando una versione n-2, nel momento in cui diventa n-3 essa diventa deprecata e si rientra nella politica 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. AKS può garantire un supporto completo solo mentre tali versioni vengono supportate 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.

Categoria di supporto Supporto della community (N-2) Supporto della piattaforma (N-3)
Aggiornamenti da N-3 a una versione supportata Supportato Supportato
Disponibilità della piattaforma (Azure) Supportato/a Supportato
Ridimensionamento del pool di nodi Supportato Supportato/a
Disponibilità di macchine virtuali Supportato Supportato
Archiviazione, problemi relativi alla rete Supportato/a Coperto da supporto ad eccezione delle correzioni di bug e dei componenti ritirati
Avvio/arresto Supportato Supportato
Ruotare i certificati Supportato/a Supportato
Contratto di servizio dell'infrastruttura Supportato/a Supportato
Contratto di servizio del piano di controllo Supportato Supportato/a
Accordo sul livello di servizio della piattaforma (AKS) Supportato Non supportato
Componenti kubernetes (inclusi i componenti aggiuntivi) Supportato Non supportato
Aggiornamenti dei componenti Supportato Non supportato
Aggiornamento dei componenti Supportato Non supportato
Applicazione di correzioni di bug Supportato Non supportato
Applicazione di patch di sicurezza Supportato Non supportato
Supporto dell'API Kubernetes Supportato Non supportato
Creazione del pool di nodi Supportato Supportato
Creazione del cluster Supportato Non supportato
Snapshot del pool di nodi Supportato Non supportato
Aggiornamento dell'immagine del nodo Supportato Supportato

Nota

La tabella è soggetta a modifiche e descrive gli scenari di supporto comuni. Gli scenari correlati alle funzionalità e ai componenti di Kubernetes non sono coperti da supporto per N-3. Per altre informazioni sul supporto, vedere Supporto e risoluzione dei problemi per il servizio Azure Kubernetes.

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

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 servizio Azure Kubernetes.

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 annuncia la data di rilascio pianificata di una nuova versione e la deprecazione della versione precedente nelle note sulla versione del servizio Azure Kubernetes almeno 30 giorni prima della rimozione.
  • AKS utilizza Azure Advisor per avvisarti se una nuova versione potrebbe causare problemi nel tuo 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, AKS 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, AKS ti notifica di eseguire l'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

AKS si riserva il diritto di aggiungere o rimuovere versioni nuove/esistenti con uno o più bug critici che influiscono sulla produzione o problemi di sicurezza senza alcun 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

Se si distribuisce un cluster AKS con il portale di Azure, l'interfaccia della riga di comando di Azure o Azure PowerShell, il cluster, per impostazione predefinita, utilizza la versione secondaria N-1 e la patch più recente. 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.

Per scoprire quali versioni sono attualmente disponibili per la sottoscrizione e la regione in uso, usare il comando az aks get-versions. L'esempio seguente elenca le versioni di Kubernetes disponibili per l'area EastUS:

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

Domande frequenti

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

Il team di AKS annuncia le nuove date di rilascio della versione di Kubernetes nella documentazione, su GitHub e tramite posta elettronica agli amministratori delle sottoscrizioni per i cluster vicini alla fine del supporto. AKS usa anche Azure Advisor per avvisare l'utente all'interno del portale Azure nel caso sia superato il supporto e 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 si è al di fuori del supporto e si deve eseguire l'aggiornamento. Se l'aggiornamento dalla versione n-3 alla n-2 ha esito positivo, siete nuovamente all'interno dei criteri di supporto. Ad esempio:

  • Se la versione più vecchia supportata di AKS è 1.27 e la tua versione è 1.26 o precedente, sei fuori supporto.
  • Se si esegue correttamente l'aggiornamento dalla versione 1.26 alla versione 1.27 o successiva, 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, AKS non offre alcuna garanzia di runtime né altre garanzie per i cluster al di fuori 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 per più di tre versioni secondarie e comporta rischi per la sicurezza, Azure contatterà in modo proattivo l'utente. Ti consigliano di 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 control plane se il pool di nodi non è in una delle versioni AKS 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 disallineamento delle versioni ora consente una differenza di massimo 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 saltare più versioni di AKS durante l'aggiornamento del cluster?

Se si aggiorna un cluster AKS supportato, non è possibile saltare le versioni minori di Kubernetes. 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.

Per gli aggiornamenti della versione del piano di controllo, è possibile passare fino a 3 versioni minori 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 dalla versione 1.28, le versioni del pool di agenti possono essere aggiornate fino a 3 versioni precedenti rispetto alle versioni del piano di controllo secondo la politica di disallineamento delle versioni. Se 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. 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 è 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 in loco, ovvero il piano di controllo e il pool di agenti insieme, si applicano le stesse regole applicabili all'aggiornamento del piano di controllo.

Se, eseguendo un aggiornamento da una versione non supportata , l'aggiornamento viene eseguito senza alcuna garanzia di funzionalità e viene 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 non è aggiornata, è consigliabile 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 dovrei 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: