Versioni di Kubernetes supportate nel servizio Azure Kubernetes (AKS)
La community di Kubernetes rilascia versioni secondarie approssimativamente 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 è attivo 1.29.1 ed 1.29.2 è la versione di patch disponibile più recente disponibile per la versione secondaria 1.29 , è consigliabile eseguire l'aggiornamento a 1.29.2 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 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,26 | Dicembre 2022 | febbr. 2023 | apr. 2023 | Mar. 2024 | Fino alla disponibilità generale 1.30 |
| 1.27* | apr. 2023 | Giugno 2023 | luglio 2023 | Luglio 2024, Supporto a Lungo termine fino a luglio 2025 | Fino alla disponibilità generale 1.31 |
| 1.28 | Ag. 2023 | sett. 2023 | Nov. 2023 | Novembre 2024 | Fino alla disponibilità generale 1.32 |
| 1,29 | Dic. 2023 | febbr. 2024 | Mar. 2024 | Fino alla disponibilità generale 1.33 | |
| 1,30 | Apr 2024 | Maggio 2024 | Giugno 2024 | Fino alla versione 1.34 disponibile a livello generale |
* Indica che la versione è designata per il supporto a lungo termine
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 delle Componenti AKS per versione
Visionare le seguenti modifiche importanti prima di eseguire l'aggiornamento a una delle versioni secondarie disponibili:
| Versione di Kubernetes | Componenti aggiuntivi gestiti da AKS | Componenti del servizio Azure Kubernetes | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|---|
| 1,26 | Criteri di Azure 1.3.0 Metrics-Server 0.6.3 KEDA 2.10.1 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.5.3 Image Cleaner v1.2.3 Identità del carico di lavoro di Azure v1.0.0 Data center modulare Defender 1.0.56 Identità Pod di Azure Active Directory 1.8.13.6 GitOps 1.7.0 KMS 0.5.0 azurefile-csi-driver 1.26.10 |
Cilium 1.12.8 CNI 1.4.44 Cluster Autoscaler 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 azuredisk-csi driver v1.28.5 azurefile-csi driver 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 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à 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 segreto 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 Cgroup 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. |
| 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 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 Server di pubblicazione Data center modulare Defender 1.0.68 Driver dell'archivio segreto 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à 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 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 azurefile-csi driver v1.29.2 azuredisk-csi driver 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 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 Server di pubblicazione Data center modulare Defender 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à 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 (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 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 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 ed 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 supporta anche fino a 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 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, ovvero sono supportate anche due versioni secondarie precedenti.
Ad esempio, nel giorno in cui il servizio Azure Kubernetes introduce la versione 1.29, 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 meno recente è deprecata e rimossa. Si supponga, ad esempio, che l'elenco delle versioni secondarie supportate corrente sia:
1.29
1.28
1.27
Quando il servizio Azure Kubernetes rilascia la versione 1.30, tutte le versioni 1.27 non supportano più di 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 seguenti versioni supportate:
Current Supported Version List
------------------------------
1.29.2, 1.29.1, 1.28.7, 1.28.6, 1.27.11, 1.27.10
Se il servizio Azure Kubernetes rilascia 1.29.3 e 1.28.8, le versioni patch meno recenti diventano obsolete e sono rimosse, e l'elenco delle versioni supportate diventa:
New Supported Version List
----------------------
1.29.3, 1.29.2, 1.28.8, 1.28.7, 1.27.11, 1.27.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 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 disponibile a livello generale più recente. Tuttavia, durante la versione 1.30 ga, 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 di cluster o pool di nodi | Supportato | Non supportato |
| Snapshot del pool di nodi | Supportato | Non supportato |
| Aggiornamento dell'immagine del nodo | Supportato | 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 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 kube-apiserver è alla 1.28, è possibile usare le versioni da 1.27 a 1.29 di kubectl con tale 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 del servizio Azure Kubernetes supportata meno recente è 1.27 e la versione 1.26 o precedente non è supportata.
- Quando 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, 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 consente ora una differenza di fino a 3 versioni tra il piano di controllo e i pool di agenti. Il servizio Azure Kubernetes segue questa modifica dei criteri di versione asimmetria 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.
Per eseguire l'aggiornamento da 1.27.x ->1.29.x:
- Eseguire l'aggiornamento dalla versione 1.27.x ->1.28.x.
- Eseguire l'aggiornamento dalla versione 1.28.x ->1.29.x.
È possibile ignorare più versioni solo quando si passa da una versione non supportata alla versione secondaria supportata. Ad esempio, è possibile eseguire l'aggiornamento da una versione 1.25.x non supportata a una versione 1.27.x supportata se 1.27 è 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. I cluster che eseguono una 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 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. Man mano che la modifica viene introdotta, 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 alla regione.
Se si è in una versione appena deprecata, è comunque possibile aggiungere nuovi pool di nodi? O bisogna eseguire l'aggiornamento?
No. Non è consentito aggiungere pool di nodi della versione deprecata al cluster. La creazione o l'aggiornamento dei pool di nodi fino alla versione del piano di controllo della versione non supportata è consentita, indipendentemente dalla differenza di versione tra il pool di nodi e il piano di controllo. Sono consentiti solo gli aggiornamenti secondari alias.
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: