Versioni di Kubernetes supportate nel servizio Azure Kubernetes (AKS)

La community di Kubernetes rilascia le versioni secondarie all'incirca ogni tre mesi. Di recente, la community di Kubernetes ha aumentato la finestra di supporto per ogni versione da nove mesi a un anno, a partire dalla versione 1.19.

Le versioni secondarie includono nuove funzionalità e miglioramenti. Le versioni patch sono più frequenti (a volte settimanali) e sono destinate a correzioni di bug critiche all'interno di 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 controllo delle versioni semantiche standard per ogni versione:

[major].[minor].[patch]

Examples:
  1.17.7
  1.17.8

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

  • Le versioni principali cambiano quando gli aggiornamenti dell'API incompatibili o la compatibilità con le versioni precedenti potrebbero essere interrotti.
  • Le versioni secondarie cambiano quando vengono apportati aggiornamenti delle funzionalità compatibili con le versioni precedenti alle altre versioni secondarie.
  • Le versioni delle patch cambiano quando vengono apportate correzioni di bug compatibili con le versioni precedenti.

Mirare a eseguire la versione patch più recente della versione secondaria in esecuzione. Ad esempio, se il cluster di produzione è in 1.17.7, 1.17.8 è la versione di patch disponibile più recente disponibile per la serie 1.17 . È consigliabile eseguire l'aggiornamento a 1.17.8 il prima possibile per assicurarsi che il cluster sia completamente patch e supportato.

Calendario delle versioni di Kubernetes del servizio Azure Kubernetes

Visualizzare le versioni future nel calendario delle versioni di Kubernetes del servizio Azure Kubernetes. Per visualizzare gli aggiornamenti in tempo reale dello stato di rilascio dell'area e delle note sulla versione, visitare la pagina Web relativa allo stato della versione del servizio Azure Kubernetes. Per altre informazioni sulla pagina Web relativa allo stato della versione, vedere Rilevamento delle versioni del servizio Azure Kubernetes.

Nota

Il servizio Azure Kubernetes segue 12 mesi di supporto per una versione Kubernetes disponibile a livello generale. 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 Versione upstream Anteprima del servizio Azure Kubernetes Disponibilità generale del servizio Azure Kubernetes Fine della vita Piattaforme supportate
1.25 Agosto 2022 Ottobre 2022 Dicembre 2022 14 gennaio 2024 Fino alla versione 1.29 disponibile a livello generale
1,26 Dicembre 2022 febbr. 2023 apr. 2023 Mar. 2024 Fino alla versione 1.30 disponibile a livello generale
1.27* apr. 2023 Giugno 2023 luglio 2023 Luglio 2024, LTS fino a luglio 2025 Fino alla versione 1.31 disponibile a livello generale
1.28 Ag. 2023 sett. 2023 Nov. 2023 Novembre 2024 Fino alla versione 1.32 disponibile a livello generale
1,29 Dic. 2023 febbr. 2024 Mar. 2024 Fino alla versione 1.33 disponibile a livello generale

* Indica che la versione è designata per il supporto a lungo termine

Diagramma di Gantt della pianificazione della versione di Kubernetes del servizio Azure Kubernetes

Se si preferisce visualizzare queste informazioni visivamente, ecco un diagramma di Gantt con tutte le versioni correnti visualizzate:

Gantt chart showing the lifecycle of all Kubernetes versions currently active in AKS.

Componenti del servizio Azure Kubernetes che causano un'interruzione delle modifiche in base alla versione

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

Versione di Kubernetes Componenti aggiuntivi gestiti del servizio Azure Kubernetes Componenti del servizio Azure Kubernetes Componenti del sistema operativo Modifiche di rilievo Note
1.25 Criteri di Azure 1.0.1
Metrics-Server 0.6.3
KEDA 2.9.3
Aprire Service Mesh 1.2.3
DNS principale V1.9.4
Overlay VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
gateway applicazione Controller in ingresso (AGIC) 1.5.3
Image Cleaner v1.1.1
Identità del carico di lavoro di Azure v1.0.0
MDC Defender 1.0.56
Identità pod di Azure Active Directory 1.8.13.6
GitOps 1.7.0
Servizio di gestione delle chiavi 0.5.0
Cilium 1.12.8
CNI 1.4.44
Scalabilità automatica cluster 1.8.5.3
Immagine del sistema operativo Ubuntu 18.04 Cgroup V1
ContainerD 1.7
Azure Linux 2.0
Cgroup V1
ContainerD 1.6
Ubuntu 22.04 per impostazione predefinita con cgroupv2 e OVERLAY VPA 0.13.0 CgroupsV2: se si distribuiscono applicazioni Java con JDK, si preferisce usare JDK 11.0.16 e versioni successive o JDK 15 e versioni successive, che supportano completamente cgroup v2
1,26 Criteri di Azure 1.3.0
Metrics-Server 0.6.3
KEDA 2.10.1
Aprire Service Mesh 1.2.3
DNS principale V1.9.4
Overlay VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
gateway applicazione Controller in ingresso (AGIC) 1.5.3
Image Cleaner v1.2.3
Identità del carico di lavoro di Azure v1.0.0
MDC Defender 1.0.56
Identità pod di Azure Active Directory 1.8.13.6
GitOps 1.7.0
Servizio di gestione delle chiavi 0.5.0
azurefile-csi-driver 1.26.10
Cilium 1.12.8
CNI 1.4.44
Scalabilità automatica cluster 1.8.5.3
Immagine del sistema operativo Ubuntu 22.04 Cgroup V2
ContainerD 1.7
Azure Linux 2.0
Cgroup V1
ContainerD 1.6
azurefile-csi-driver 1.26.10 None
1.27 Criteri di Azure 1.3.0
driver azuredisk-csi v1.28.5
driver azurefile-csi v1.28.7
blob-csi v1.22.4
csi-attacher v4.3.0
csi-resizer v1.8.0
csi-snapshotter v6.2.2
snapshot-controller v6.2.2
Metrics-Server 0.6.3
Keda 2.11.2
Aprire Service Mesh 1.2.3
DNS principale V1.9.4
Overlay VPA 0.11.0
Azure-Keyvault-SecretsProvider 1.4.1
gateway applicazione controller di ingresso (AGIC) 1.7.2
Image Cleaner v1.2.3
Identità del carico di lavoro di Azure v1.0.0
MDC Defender 1.0.56
Identità pod di Azure Active Directory 1.8.13.6
GitOps 1.7.0
azurefile-csi-driver 1.28.7
Servizio di gestione delle chiavi 0.5.0
Driver dell'archivio segreto CSI 1.3.4-1
Cilium 1.13.10-1
CNI 1.4.44
Scalabilità automatica cluster 1.8.5.3
Immagine del sistema operativo Ubuntu 22.04 Cgroup V2
ContainerD 1.7 per Linux e 1.6 per Windows
Azure Linux 2.0
Cgroup V1
ContainerD 1.6
Keda 2.11.2
Cilium 1.13.10-1
azurefile-csi-driver 1.28.7
driver azuredisk-csi v1.28.5
blob-csi v1.22.4
csi-attacher v4.3.0
csi-resizer v1.8.0
csi-snapshotter v6.2.2
snapshot-controller v6.2.2
A causa dello stato di certificazione FIPS ubuntu 22.04, i nodi FIPS del servizio Azure Kubernetes verranno spostati da 18.04 a 20.04 dalla versione 1.27 in poi.
1.28 Criteri di Azure 1.3.0
azurefile-csi-driver 1.29.2
csi-node-driver-registrar v2.9.0
csi-livenessprobe 2.11.0
azuredisk-csi-linux v1.29.2
azuredisk-csi-windows v1.29.2
csi-provisioner v3.6.2
csi-attacher v4.5.0
csi-resizer v1.9.3
csi-snapshotter v6.2.2
snapshot-controller v6.2.2
Metrics-Server 0.6.3
KEDA 2.11.2
Aprire Service Mesh 1.2.7
DNS principale V1.9.4
Overlay VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
gateway applicazione controller di ingresso (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
Driver dell'archivio segreto CSI 1.3.4-1
MDC Defender Old File Cleaner 1.3.68
MDC Defender Pod Collector 1.0.78
Agente di raccolta di basso livello di MDC Defender 1.3.81
Identità pod di Azure Active Directory 1.8.13.6
GitOps 1.8.1
Cilium 1.13.10-1
CNI v1.4.43.1 (impostazione predefinita)/v1.5.11 (Overlay CNI di Azure)
Scalabilità automatica cluster 1.27.3
Tigera-Operator 1.28.13
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
Cgroup V1
ContainerD 1.6
azurefile-csi-driver 1.29.2
csi-resizer v1.9.3
csi-attacher v4.4.2
csi-provisioner v4.4.2
blob-csi v1.23.2
driver azurefile-csi v1.29.2
driver azuredisk-csi v1.29.2
csi-livenessprobe v2.11.0
csi-node-driver-registrar v2.9.0
None
1,29 Criteri di Azure 1.3.0
csi-provisioner v4.0.0
csi-attacher v4.5.0
csi-snapshotter v6.3.3
snapshot-controller v6.3.3
Metrics-Server 0.6.3
KEDA 2.11.2
Aprire Service Mesh 1.2.7
DNS principale V1.9.4
Overlay VPA 0.13.0
Azure-Keyvault-SecretsProvider 1.4.1
gateway applicazione controller di ingresso (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
MDC Defender Pod Collector 1.0.78
Agente di raccolta di basso livello di MDC Defender 1.3.81
Identità pod di Azure Active Directory 1.8.13.6
GitOps 1.8.1
Driver dell'archivio segreto CSI 1.3.4-1
azurefile-csi-driver 1.29.3
Cilium 1.13.5
CNI v1.4.43.1 (impostazione predefinita)/v1.5.11 (Overlay CNI di Azure)
Scalabilità automatica cluster 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
Cgroup V1
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
None

Versione secondaria dell'alias

Nota

La versione secondaria dell'alias richiede l'interfaccia della riga di comando di Azure versione 2.37 o successiva, nonché la versione api 20220401 o versione successiva. Usare az upgrade per installare la versione più recente dell'interfaccia della riga di comando.

Il servizio Azure Kubernetes consente di creare un cluster senza specificare la versione esatta della patch. Quando si crea un cluster senza designare una patch, il cluster esegue la patch ga più recente della versione secondaria. Ad esempio, se si crea un cluster con 1.21, il cluster esegue 1.21.7, ovvero la versione più recente della patch ga 1.21. Se si vuole aggiornare la versione della patch nella stessa versione secondaria, usare l'aggiornamento automatico.

Per visualizzare la patch attivata, eseguire il az aks show --resource-group myResourceGroup --name myAKSCluster comando . 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.21.7",
}

Criteri di supporto della versione di Kubernetes

Il servizio Azure Kubernetes definisce una versione disponibile a livello generale come versione disponibile in tutte le aree e abilitata in tutte le misurazioni SLO o sla. Il servizio Azure Kubernetes supporta tre versioni secondarie ga di Kubernetes:

  • La versione secondaria ga più recente rilasciata nel servizio Azure Kubernetes (che si fa riferimento a N).
  • Due versioni secondarie precedenti.
    • Ogni versione secondaria supportata supporta anche un massimo di due patch stabili.

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 ga 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 graduale dell'area. Ciò significa che potrebbero essere necessari fino a 10 giorni lavorativi per una nuova versione o una nuova versione in tutte le aree.

La finestra supportata delle versioni di Kubernetes nel servizio Azure Kubernetes è nota come "N-2": (N (versione più recente) - 2 (versioni secondarie) e ".letter" è rappresentativa delle versioni delle patch.

Ad esempio, se il servizio Azure Kubernetes introduce la versione 1.17.a , viene fornito il supporto per le versioni seguenti:

Nuova versione secondaria Elenco delle versioni supportate
1.17.a 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e, 1.15.f

Quando viene introdotta una nuova versione secondaria, la versione secondaria meno recente e le versioni patch supportate sono deprecate e rimosse. Si supponga, ad esempio, che l'elenco delle versioni supportate corrente sia:

1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f

Quando il servizio Azure Kubernetes rilascia la versione 1.18.*, tutte le versioni 1.15.* escono dal supporto 30 giorni dopo.

Il servizio Azure Kubernetes supporta anche un massimo di due versioni patch di una determinata versione secondaria. Ad esempio, in base alle versioni supportate seguenti:

Current Supported Version List
------------------------------
1.17.8, 1.17.7, 1.16.10, 1.16.9

Se il servizio Azure Kubernetes rilascia 1.17.9 e 1.16.11, le versioni delle patch meno recenti sono deprecate e rimosse e l'elenco delle versioni supportate diventa:

New Supported Version List
----------------------
1.17.*9*, 1.17.*8*, 1.16.*11*, 1.16.*10*

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 solo da Microsoft per problemi correlati alla piattaforma del servizio Azure Kubernetes/Azure. Eventuali problemi relativi alla funzionalità e ai componenti di Kubernetes non sono supportati.

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 ga), prima che il cluster venga eliminato a n-4. Ad esempio, Kubernetes v1.25 è considerato il supporto della piattaforma quando v1.28 è la versione ga più recente. Tuttavia, durante la versione disponibile a livello generale della versione 1.29, la versione 1.25 eseguirà l'aggiornamento automatico alla versione 1.26. Se si esegue una versione n-2, il momento in cui diventa anche n-3 diventa deprecato e si immette nei 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 scorrevole di tre versioni secondarie. Il servizio Azure Kubernetes può garantire solo il supporto completo mentre tali versioni vengono gestite a monte. Poiché non sono presenti più patch prodotte a monte, il servizio Azure Kubernetes può lasciare tali versioni senza patch o fork. A causa di questa limitazione, il supporto della piattaforma non supporta nulla dalla relying on Kubernetes upstream.

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

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

Nota

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

Versioni supportate kubectl

È possibile usare una versione secondaria precedente o successiva rispetto alla versione kube-apiserver, coerente con i criteri di kubectl supporto di Kubernetes per kubectl.

Ad esempio, se kube-apiserver è alla 1.17, è possibile usare le versioni da 1.16 a 1.18 di kubectl con tale kube-apiserver.

Per installare o aggiornare kubectl la 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 eseguire il backup delle correzioni della sicurezza delle porte dalla community upstream nel repository pubblico. Il nostro gruppo di lavoro upstream LTS contribuisce a contribuire alla community per fornire ai nostri clienti una finestra di supporto più lunga.

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

Processo di rilascio e deprecazione

È possibile fare riferimento alle versioni future e alle deprecazioni 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 anche l'utente se non si è supportati
  • 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.

  • Sono trascorsi 30 giorni dalla rimozione della versione all'aggiornamento a una versione secondaria supportata per continuare a ricevere il supporto.

Per le nuove versioni patch di Kubernetes:

  • A causa della natura urgente delle versioni patch, 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 generale la versione delle nuove versioni delle patch. Tuttavia, il servizio Azure Kubernetes monitora e convalida costantemente le patch CVE disponibili per supportarle nel servizio Azure Kubernetes in modo tempestivo. Se viene trovata una patch critica o è necessaria un'azione dell'utente, il servizio Azure Kubernetes invia una notifica all'aggiornamento alla patch appena disponibile.
  • Si hanno 30 giorni dalla rimozione di una versione patch dal servizio Azure Kubernetes 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.

Le versioni patch specifiche potrebbero essere ignorate o accelerate dall'implementazione, a seconda della gravità del bug o del problema di sicurezza.

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

Quando si distribuisce un cluster del servizio Azure Kubernetes con portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell, il cluster usa per impostazione predefinita la versione secondaria N-1 e la patch più recente. Ad esempio, se il servizio Azure Kubernetes supporta 1.17.a, 1.17.b, 1.16.c, 1.16.d, 1.15.e e 1.15.f, la versione predefinita selezionata è 1.16.c.

Per scoprire quali versioni sono attualmente disponibili per la sottoscrizione e l'area, usare il az aks get-versions comando . 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 alle nuove versioni di Kubernetes?

Il team del servizio Azure Kubernetes pubblica annunci con date pianificate delle nuove versioni di Kubernetes nella documentazione, In GitHub e nei messaggi di posta elettronica agli amministratori delle sottoscrizioni proprietari dei cluster che non supporteranno più. Il servizio Azure Kubernetes usa anche Azure Advisor per avvisare l'utente all'interno del portale di Azure se non si è supportati e si informano delle API deprecate che possono influire sul processo di sviluppo o sull'applicazione.

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 del servizio Azure Kubernetes supportata meno recente è la 1.15.a e la versione 1.14.b o precedente non è supportata.
  • Quando si esegue correttamente l'aggiornamento dalla versione 1.14.b alla versione 1.15.a o successiva, si è di nuovo all'interno dei criteri di supporto.

I downgrade non sono supportati.

Cosa significa "Al di fuori del supporto"?

"Al di fuori del 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 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, l'aumento o il numero di istanze deve 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 (3) versioni secondarie e ha riscontrato rischi per la sicurezza, Azure contatta in modo proattivo 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, l'aumento o il numero di istanze deve 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 sull'aggiornamento dei pool di nodi.

È 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. I criteri di sfasamento della versione dei piani di controllo Kubernetes non supportano l'ignorato della versione secondaria. Ad esempio, gli aggiornamenti tra:

  • 1.12.x ->1.13.x: consentito.
  • 1.13.x ->1.14.x: consentito.
  • 1.12.x ->1.14.x: non consentito.

Per eseguire l'aggiornamento da 1.12.x ->1.14.x:

  1. Eseguire l'aggiornamento dalla versione 1.12.x ->1.13.x.
  2. Eseguire l'aggiornamento dalla versione 1.13.x ->1.14.x.

Ignorare più versioni può essere eseguita solo quando si esegue l'aggiornamento da una versione non supportata alla versione minima supportata. Ad esempio, è possibile eseguire l'aggiornamento da una versione 1.10.x non supportata a una versione 1.15.x supportata se 1.15 è la versione secondaria minima supportata.

Quando si esegue un aggiornamento da una versione non supportata che ignora due o più versioni secondarie, l'aggiornamento viene eseguito senza alcuna garanzia di funzionalità ed è escluso dai contratti di servizio e dalla garanzia limitata. Se la versione non è aggiornata in modo significativo, è consigliabile ricreare il cluster.

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

No. Dopo aver deprecato o rimosso una versione, non è possibile creare un cluster con tale versione. Quando la modifica viene distribuita, si inizierà a vedere la versione precedente rimossa dall'elenco delle versioni. Questo processo potrebbe richiedere fino a due settimane dall'annuncio, progressivamente in base all'area.

Si è in una versione appena deprecata, è comunque possibile aggiungere nuovi pool di nodi? O devo eseguire l'aggiornamento?

No. Non è consentito aggiungere pool di nodi della versione deprecata al cluster. È possibile aggiungere pool di nodi di una nuova versione, ma potrebbe essere necessario aggiornare prima il piano di controllo.

Con quale frequenza si aggiornano le patch?

Le patch hanno un ciclo di vita minimo di due mesi. Per rimanere aggiornati quando vengono rilasciate nuove patch, seguire le note sulla versione del servizio Azure Kubernetes.

Passaggi successivi

Per informazioni su come aggiornare il cluster, vedere Aggiornare un cluster del servizio Azure Kubernetes.