Versioni di Kubernetes supportate nel servizio Azure Kubernetes (AKS)
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 avviene il 1.29.1 e 1.29.2 è la versione di patch disponibile più recente per la versione 1.29 secondaria, è necessario eseguire l'aggiornamento a 1.29.2 quanto prima per far sì che il cluster sia completamente protetto e supportato.
Calendario delle versioni di Kubernetes del servizio Azure Kubernetes
Visualizzare le versioni che verranno rilasciate nel calendario delle versioni di Kubernetes del servizio Azure Kubernetes. Per vedere gli aggiornamenti in tempo reale sullo stato di rilascio della regione e le note di rilascio della versione, visitare la pagina web sullo stato di rilascio del servizio Azure Kubernetes. Per altre informazioni sulla pagina Web relativa allo stato di rilascio, vedere Monitorare il rilascio del servizio Azure Kubernetes.
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, vedere la sezione domande frequenti.
Per la cronologia delle versioni precedenti, vedere Cronologia di Kubernetes.
| Versione K8s | Rilascio della versione upstream | Anteprima del servizio Azure Kubernetes | Disponibilità Generale del Servizio Azure Kubernetes | Fine del ciclo di vita | Piattaforme supportate |
|---|---|---|---|---|---|
| 1.28 | Ag. 2023 | sett. 2023 | Nov. 2023 | Gennaio 2025 | Fino alla disponibilità generale 1.32 |
| 1,29 | Dic. 2023 | febbr. 2024 | Mar. 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 versione 1.35 disponibile a livello generale |
| 1.32 | Dicembre 2024 | Febbraio 2025 | Marzo 2025 | Mar 2026 | Fino alla versione 1.36 disponibile a livello generale |
Versioni LTS
| Versione K8s | Rilascio della versione upstream | Anteprima del servizio Azure Kubernetes | Disponibilità Generale del Servizio Azure Kubernetes | Fine del ciclo di vita | Fine vita LTS |
|---|---|---|---|---|---|
| 1.27 | apr. 2023 | Giugno 2023 | luglio 2023 | Luglio 2024 | Luglio 2025 |
| 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:
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.30
| Componenti aggiuntivi gestiti dal servizio Azure Kubernetes | Componenti del servizio Azure Kubernetes | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|
| • Criteri di Azure 1.3.0 • cloud-provider-node-manager v1.30.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.14.0 • Open Service Mesh 1.2.7 • DNS principale V1.9.4 • Overlay VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controller in ingresso del gateway applicazione (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 • Data center modulare 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 1.3.81 • 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 1.13.5 • 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 |
• KEDA 2.14.1 | N/D |
Kubernetes 1.29
| Componenti aggiuntivi gestiti dal servizio Azure Kubernetes | Componenti del servizio Azure Kubernetes | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|
| • 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 • Open Service Mesh 1.2.7 • DNS principale V1.9.4 • Overlay VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controller in ingresso del gateway applicazione (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 • Data center modulare 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 1.3.81 • 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 1.13.5 • 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 • csi-provisioner v4.0.0 • csi-attacher v4.5.0 • csi-snapshotter v6.3.3 • snapshot-controller v6.3.3 |
N/D |
Kubernetes 1.28
| Componenti aggiuntivi gestiti dal servizio Azure Kubernetes | Componenti del servizio Azure Kubernetes | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|
| • 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 • Open Service Mesh 1.2.7 • DNS principale V1.9.4 • Overlay VPA 0.13.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controller in ingresso del gateway applicazione (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 • Driver dell'archivio dei segreti CSI 1.3.4-1 • Data center modulare 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 1.3.81 • Identità di 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 (sovrimpressione di Azure CNI) • Cluster Autoscaler 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 • Cgroups 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 • azurefile-csi driver v1.29.2 • azuredisk-csi driver v1.29.2 • csi-livenessprobe v2.11.0 • csi-node-driver-registrar v2.9.0 |
N/D |
Kubernetes 1.27
| Componenti aggiuntivi gestiti dal servizio Azure Kubernetes | Componenti del servizio Azure Kubernetes | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|
| • Criteri di Azure 1.3.0 • azuredisk-csi driver v1.28.5 • azurefile-csi driver v1.28.10 • 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 • Open Service Mesh 1.2.3 • DNS principale V1.9.4 • Overlay VPA 0.11.0 • Azure-Keyvault-SecretsProvider 1.4.1 • Controller in ingresso del gateway applicazione (AGIC) 1.7.2 • Image Cleaner v1.2.3 • Identità del carico di lavoro di Azure v1.0.0 • Data center modulare Defender 1.0.56 • Identità di pod di Azure Active Directory 1.8.13.6 • GitOps 1.7.0 • azurefile-csi-driver 1.28.7 • KMS 0.5.0 • Driver dell'archivio dei segreti CSI 1.3.4-1 |
• Cilium 1.13.10-1 • CNI 1.4.44 • Cluster Autoscaler 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 • Cgroups V1 • ContainerD 1.6 |
• KEDA 2.11.2 • Cilium 1.13.10-1 • azurefile-csi-driver 1.28.7 • azuredisk-csi driver 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 di Ubuntu 22.04, i nodi FIPS del servizio Azure Kubernetes passeranno da 18.04 a 20.04 a partire dalla versione 1.27. |
Versione secondaria dell'alias
Nota
La versione secondaria di Alias richiede la versione 2.37 o superiore per l’interfaccia della riga di comando di Azure e API versione 20220401 o superiore. 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 patch esatta. Quando si crea un cluster senza designare una patch, il cluster esegue la patch di disponibilità generale più recente della versione secondaria. Ad esempio, se si crea un cluster con 1.29 e 1.29.2 è la patch disponibile a livello generale più recente, il cluster verrà 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
Il servizio Azure Kubernetes definisce una versione generalmente disponibile come versione disponibile in tutte le regioni e abilitata in tutte le misure SLO o SLA. Il servizio Azure Kubernetes supporta tre versioni secondarie di disponibilità generale 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. Il servizio Azure Kubernetes si riserva il diritto di deprecare le patch se viene rilevata una vulnerabilità di sicurezza o CVE critica. Per informazioni sulla disponibilità delle patch e su qualsiasi deprecazione ad hoc, vedere le note sulla versione e visitare la pagina Web relativa allo stato della versione del servizio Azure Kubernetes.
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 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 secondarie di Kubernetes nel servizio Azure Kubernetes è nota come "N-2", dove N fa riferimento alla versione più recente, mentre la cifra indica che sono supportate anche due versioni secondarie precedenti.
Ad esempio, nel giorno in cui il servizio Azure Kubernetes introduce la versione 1.29.a, viene fornito il supporto per le versioni seguenti:
| La versione secondaria | 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 il servizio Azure Kubernetes rilascia la versione 1.30, dopo 30 giorni non è più fornito supporto per tutte le versioni 1.27.
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
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 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 il rilascio della versione disponibile a livello generale 1.30, la versione 1.26 eseguirà l'aggiornamento automatico alla versione 1.27. Se si esegue una versione n-2, il momento in cui diventa n-3, tale versione diventa deprecata e si accede ai 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 temporale scorrevole di tre versioni secondarie. Il servizio Azure Kubernetes può garantire un supporto completo solo mentre tali versioni vengono gestite 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 | Supportata | Supportata |
| Disponibilità della piattaforma (Azure) | Supportata | Supportata |
| Ridimensionamento del pool di nodi | Supportata | Supportata |
| Disponibilità di macchine virtuali | Supportata | Supportata |
| Archiviazione, problemi relativi alla rete | Supportata | Coperto da supporto 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) | 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 | Supportata | Supportata |
| Creazione del cluster | Supportato | Non supportato |
| Snapshot del pool di nodi | Supportato | Non supportato |
| Aggiornamento dell'immagine del nodo | Supportata | Supportata |
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 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 servizioservizio Azure Kubernetes (AKS).
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 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 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, il servizio Azure Kubernetes 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, il servizio Azure Kubernetes invia una notifica di 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
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.
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
Quando si distribuisce un cluster del servizio Azure Kubernetes con il portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell, il cluster è impostato sulla versione secondaria N-1 e sull'ultima patch. 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 del servizio Azure Kubernetes pubblica annunci con date pianificate delle nuove versioni di Kubernetes nella documentazione, in GitHube nei messaggi di posta elettronica agli amministratori delle sottoscrizioni proprietari dei cluster che saranno esclusi dal supporto. Il servizio Azure Kubernetes usa anche Azure Advisor per avvisare l'utente all'interno del portale Azure se è fuori supporto e per 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 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 secondaria meno recente del servizio Azure Kubernetes supportata è 1.27 e la versione in uso è 1.26 o precedente, non si è coperti dall’assistenza.
- Quando si esegue correttamente l'aggiornamento dalla versione 1.26 alla versione 1.27 o successive, 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, 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, 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 da più di tre (3) versioni secondarie e ha riscontrato rischi per la sicurezza, Azure contatta direttamente 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, 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 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 su aggiornamento dei pool di nodi.
Qual è la differenza consentita nelle versioni tra piano di controllo e pool di nodi?
Il criterio di asimmetria della versione ora consente una differenza fino a 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 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. 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.
Si noti che per gli aggiornamenti della versione del piano di controllo, è possibile passare a 3 versioni secondarie per le versioni supportate dalla community in modo sequenziale.
Per eseguire l'aggiornamento da 1.27.x a>1.29.x:
- Eseguire l'aggiornamento da 1.27.x a>1.28.x.
- Eseguire l'aggiornamento da 1.28.x a>1.29.x.
Si noti che a partire dalla versione 1.28 in poi, le versioni del pool di agenti possono essere fino a 3 versioni precedenti alle versioni del piano di controllo per ogni criterio di asimmetria della versione. Quando 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. Ciò significa che 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 è alla 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 sul posto, ad esempio piano di controllo e pool di agenti, si applicano le stesse regole applicabili all'aggiornamento del piano di controllo scritto in precedenza.
Quando si esegue un aggiornamento da una versione non supportata, l'aggiornamento viene eseguito senza alcuna garanzia di funzionalità ed è 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 è particolarmente obsoleta, si consiglia di 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 bisogna 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:
Azure Kubernetes Service