Versioni di Kubernetes supportate nel servizio Kubernetes di Operatore Nexus di Azure
Questo documento offre una panoramica dello schema di controllo delle versioni usato per il servizio Kubernetes di Operatore Nexus, incluse le versioni di Kubernetes supportate. Illustra le differenze tra le versioni principali, secondarie e patch, e fornisce indicazioni sull'aggiornamento delle versioni di Kubernetes e sull'esperienza di aggiornamento. Il documento illustra anche il ciclo di vita del supporto della versione e la fine del servizio (EOL) per ogni versione secondaria di Kubernetes.
La community di Kubernetes rilascia le versioni secondarie all'incirca ogni tre mesi. A partire dalla versione 1.19, la community di Kubernetes ha allargato la finestra di supporto da nove mesi a un anno per ogni versione.
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.24.7
1.25.4
Ogni numero nella versione indica la compatibilità generale con la versione precedente:
- I numeri delle versioni principali cambiano quando potrebbero essere introdotte modifiche di rilievo all'API
- I numeri delle versioni secondarie cambiano se gli aggiornamenti delle funzionalità sono compatibili con le versioni secondarie precedenti.
- I numeri delle versioni patch cambiano quando vengono apportate correzioni di bug compatibili con le versioni precedenti.
È consigliabile rimanere aggiornati con le patch più recenti disponibili. Ad esempio, se il cluster di produzione è in 1.25.4 e 1.25.6 è la versione patch disponibile più recente per la serie 1.25. È consigliabile eseguire l'aggiornamento a 1.25.6 il prima possibile, per assicurarsi che il cluster sia completamente patch e supportato. Per altri dettagli sull'aggiornamento del cluster, vedere la documentazione relativa all'aggiornamento delle versioni di Kubernetes.
Calendario di rilascio di Kubernetes di Nexus
Visualizzare le versioni che verranno rilasciate nel calendario di rilascio di Kubernetes di Nexus.
Nota
Altre informazioni sui criteri di supporto per il controllo delle versioni di Kubernetes.
Per la cronologia delle versioni precedenti, vedere Cronologia di Kubernetes.
| Versione K8s | Disponibilità generale di Nexus | Fine del ciclo di vita | Disponibilità estesa |
|---|---|---|---|
| 1.25 | Giugno 2023 | Dic. 2023 | Fino alla fine di ottobre 2024 |
| 1,26 | sett. 2023 | Mar. 2024 | Fino alla fine del marzo 2025 |
| 1.27* | sett. 2023 | Luglio 2024, Supporto a Lungo termine fino a luglio 2025 | ND |
| 1.28 | Nov. 2023 | Ottobre 2024 | Fino alla fine di ottobre 2025 |
| 1,29 | Ago 2024 | Febbraio 2025 | Fino alla fine di febbraio 2026 |
| 1.30* | Ottobre 2024 | Luglio 2025, LTS fino a luglio 2026 | ND |
* Indica che la versione è designata per il supporto a lungo termine
Componenti della versione del servizio Kubernetes di Nexus
Una versione del servizio Kubernetes di Operatore Nexus è costituita da due componenti discreti combinati in una singola rappresentazione:
- Versione di Kubernetes. Ad esempio 1.25.4, è la versione di Kubernetes distribuita in Operatore Nexus. Questi pacchetti vengono forniti dal servizio Azure Kubernetes, incluse tutte le versioni patch supportate da Operatore Nexus. Per altre informazioni sulle versioni del servizio Azure Kubernetes, vedere Versioni di Kubernetes supportate dal servizio Azure Kubernetes
- Bundle di versione, che incapsula le funzionalità (componenti aggiuntivi) e l'immagine del sistema operativo usata dai nodi nel cluster Kubernetes di Operatore Nexus, come singolo numero. Ad esempio, 2.
La combinazione di questi valori è rappresentata nell'API come l'unica versione di Kubernetes. Ad esempio,
1.25.4-2o la notazione "v" supportata in alternativa:v1.25.4-2.
Bundle di versione
Estendendo la versione di Kubernetes in modo da includere un valore secondario per la versione patch, il bundle di versione, il servizio Kubernetes di Operatore Nexus può tenere conto dei casi in cui la distribuzione viene modificata per includere aggiornamenti aggiuntivi correlati al sistema operativo. Tali aggiornamenti possono includere, ma non sono limitati a: immagini aggiornate del sistema operativo, versioni patch per le funzionalità (componenti aggiuntivi) e così via. I bundle di versione sono sempre compatibili con le versioni precedenti di bundle all'interno della stessa versione di patch, ad esempio 1.25.4-2 è compatibile con le versioni precedenti con 1.25.4-1.
Le modifiche alla configurazione di un cluster Kubernetes di Operatore Nexus distribuito devono essere applicate solo all'interno di un aggiornamento della versione secondaria di Kubernetes, non durante un aggiornamento della versione patch. Di seguito sono riportati alcuni esempi di modifiche alla configurazione che possono essere applicate durante l'aggiornamento della versione secondaria:
- Modifica della configurazione del kube-proxy da iptables a ipvs
- Modifica della CNI da un prodotto a un altro
Quando si seguono questi principi, diventa più semplice prevedere e gestire il processo di spostamento tra versioni diverse dei cluster Kubernetes offerti dal servizio Kubernetes di Operatore Nexus.
È possibile passare facilmente da un aggiornamento di piccole dimensioni a una versione di Kubernetes a un aggiornamento di piccole dimensioni alla versione successiva, con flessibilità. Ad esempio, è consentito un aggiornamento da 1.24.1-x a 1.25.4-x, indipendentemente dalla presenza di una versione intermedia 1.24.2-x.
Versione dei componenti e modifiche di rilievo
Esaminare le seguenti modifiche importanti prima di eseguire l'aggiornamento a una delle versioni secondarie disponibili:
| Versione di Kubernetes | Bundle di versione | Componenti | Componenti del sistema operativo | Modifiche di rilievo | Note |
|---|---|---|---|---|---|
| 1.30.3 | 1 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 3.0.20240824 | Nessuna modifica che causa un'interruzione | |
| 1.29.7 | 3 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | Patch disponibili estese 1.29.4-1 |
| 1.29.7 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.29.6 | 4 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.29.6 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.28.12 | 3 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | Patch disponibili estese 1.28.9-2, 1.28.0-6 |
| 1.28.12 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.28.11 | 4 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.28.11 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240731 | Nessuna modifica che causa un'interruzione | |
| 1.27.13 | 3 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | Patch disponibili estese 1.27.3-7, 1.27.1-8 |
| 1.27.13 | 2 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.27.9 | 5 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.7.0 Csi-nfs v4.9.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.27.9 | 4 | Calico v3.27.4 metrics-server v0.7.2 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.26.12 | 4 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.26.12 | 3 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.8.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.26.6 | 6 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | Patch disponibili estese: 1.26.3-8 |
| 1.26.6 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.25.11 | 6 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.25.11 | 5 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.2 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.15 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | |
| 1.25.6 | 8 | Calico v3.27.4 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione | Patch disponibili estese 1.25.5-5 |
| 1.25.6 | 7 | Calico v3.27.3 metrics-server v0.7.1 Multus v4.0.0 azure-arc-servers v1.1.0 CoreDNS v1.9.4 etcd v3.5.13 sriov-dp v3.5.1 Csi-nfs v4.7.0 csi-volume v0.1.0 metallb v0.14.5-3 |
Azure Linux 2.0.20240425 | Nessuna modifica che causa un'interruzione |
Funzionalità del bundle della versione
| Funzionalità | Bundle di versione | Note |
|---|---|---|
| La connettività dell'orchestrazione del volume è crittografata da TLS | A partire da 1.28.9-1, 1.28.0-5, 1.27.9-1, 1.27.3-5, 1.26.12-1, 1.26.6-5, 1.25.11-5 e 1.25.6-7 | |
| I nodi del cluster sono abilitati per Azure Arc | A partire da 1.25.6-4, 1.25.11-2, 1.26.3-4, 1.26.6-2, 1.27.1-4, 1.27.3-2 e 1.28.0-2 | |
| I volumi nexus-shared hanno il loro attributo di capacità applicato come limite di dimensioni del volume | A partire dalla versione 1.27.13-3, v1.27.9-5, v1.28.11-4, v1.28.12-3, v1.29.6-4, v1.29.7-3, v1.30.3-1 |
Aggiornamento delle versioni di Kubernetes
Per altre informazioni sull'aggiornamento del cluster, vedere Aggiornare un cluster del servizio Kubernetes di Operatore Nexus di Azure.
Criteri di supporto della versione di Kubernetes
Operatore Nexus supporta tre versioni secondarie di Kubernetes:
- La versione secondaria con disponibilità generale più recente rilasciata in Operatore Nexus (a cui si fa riferimento come N).
- Due versioni secondarie precedenti.
- Ogni versione secondaria supportata supporta anche un massimo di due patch stabili più recenti, mentre le patch precedenti sono gestite da criteri di disponibilità estesa per la durata della versione secondaria.
Il servizio Kubernetes di Operatore Nexus offre una durata standardizzata del supporto per ogni versione secondaria di Kubernetes rilasciata. Le versioni sono conformi a due diverse sequenze temporali, che riflettono:
- Durata del supporto: la durata della manutenzione attiva di una versione. Al termine del periodo supportato, la versione raggiunge la "fine del servizio".
- Disponibilità estesa: il periodo in cui è possibile selezionare una versione per la distribuzione dopo la "fine del servizio".
La finestra supportata delle versioni di Kubernetes in Operatore Nexus è nota come "N-2": (N (versione più recente) - 2 (versioni secondarie)) e ".letter" indica le versioni patch.
Ad esempio, se Operatore Nexus introduce la versione 1.17.a, viene fornito il supporto per le versioni seguenti:
| La 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, viene ritirato il supporto della versione secondaria precedente e delle versioni delle patch precedenti. Ad esempio, l'elenco delle versioni supportate corrente è:
1.17.a
1.17.b
1.16.c
1.16.d
1.15.e
1.15.f
Quando Operatore Nexus rilascia 1.18.*, le versioni 1.15.* non sono più supportate.
Sequenza temporale del supporto
Generalmente, il servizio Kubernetes di Operatore Nexus offre supporto per 12 mesi dal rilascio con disponibilità generale del servizio Azure Kubernetes di una versione secondaria. Questa sequenza temporale segue la tempistica del servizio Azure Kubernetes, che include una versione di supporto a lungo termine dichiarata 1.27.
Versioni supportate:
- Possono essere distribuite come nuovi cluster Kubernetes di Operatore Nexus.
- Possono essere sottoposte agli aggiornamenti delle versioni precedenti. Con le limitazioni dei normali percorsi di aggiornamento.
- La versione secondaria potrebbe includere patch aggiuntive o bundle di versione.
Nota
In circostanze eccezionali, se viene identificata una vulnerabilità o un problema di sicurezza, il supporto del servizio Kubernetes di Nexus potrebbe terminare in anticipo o immediatamente. Qualora si verificasse tale eventualità, Microsoft informerà in modo proattivo ai clienti e lavorerà per attenuare eventuali problemi potenziali.
Fine del servizio (EOL)
Fine del servizio (EOL) significa che non vengono generati più bundle di patch o di versione. È possibile che il cluster configurato non possa più essere aggiornato perché le versioni supportate più recenti non sono più disponibili. In questo caso, l'unico modo per eseguire l'aggiornamento consiste nel ricreare completamente il cluster Kubernetes di Nexus usando la versione più recente supportata. Gli aggiornamenti non supportati tramite Extended availability potrebbero essere utilizzati per tornare a una versione supportata.
Criteri di disponibilità estesa
Durante il periodo di disponibilità estesa per le versioni Kubernetes non supportate (ovvero le versioni di Kubernetes EOL), gli utenti non ricevono patch di sicurezza o correzioni di bug. Per informazioni dettagliate sulle categorie di supporto, vedere la tabella seguente.
| Categoria di supporto | Da N-2 a N | Disponibilità estesa |
|---|---|---|
| Aggiornamenti da N-3 a una versione supportata | Supportata | Supportata |
| Ridimensionamento del pool di nodi | Supportata | Supportata |
| Creazione di cluster o pool di nodi | Supportata | Supportata |
| 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 di Kubernetes | Supportato | Non supportato |
| Applicazione di patch di sicurezza di Kubernetes | Supportato | Non supportato |
| Patch di sicurezza delle immagini del nodo | Supportato | Non supportato |
Nota
Operatore Nexus 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. Operatore Nexus può garantire un supporto completo solo finché tali versioni vengono gestite upstream. Poiché non sono presenti più patch prodotte upstream, Operatore Nexus può lasciare tali versioni senza patch o creare una copia tramite fork. A causa di questa limitazione, la disponibilità estesa non supporta nulla che si basi su Kubernetes upstream.
Cluster Nexus Kubernetes abbandonati
Dopo la fine del periodo di disponibilità estesa, la versione K8s viene completamente rimossa da Nexus. A questo punto, tutti i cluster Nexus Kubernetes esistenti basati su questa versione K8s verranno abbandonati. L'unica operazione supportata sui cluster abbandonati è l'eliminazione. Importante, una volta abbandonato un cluster, l'aggiornamento a una versione K8s successiva non funzionerà.
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.17, allora è possibile usare le versioni dalla 1.16 alla 1.18 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)
La community di Kubernetes rilascia una nuova versione secondaria circa ogni quattro mesi, con una finestra di supporto per ogni versione per un anno. Nel servizio Azure Kubernetes questa finestra di supporto è denominata "Supporto della community".
Il servizio Azure Kubernetes supporta le versioni di Kubernetes che si trovano all'interno di questa finestra di supporto della community, per eseguire il push delle correzioni di bug e degli aggiornamenti della sicurezza dalle versioni della community.
Anche se l'innovazione fornita con questa frequenza di rilascio offre enormi vantaggi, è necessario mantenere aggiornati i rilasci di Kubernetes, che possono essere resi più difficili in base al numero di cluster che è necessario gestire.
Tipi di supporto
Dopo circa un anno, la versione di Kubernetes esce dal supporto della community e i cluster del servizio Azure Kubernetes sono ora a rischio quando le correzioni di bug e gli aggiornamenti della sicurezza non sono disponibili.
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.
LTS intende offrire un lungo periodo di tempo per pianificare e testare gli aggiornamenti in un periodo di due anni dalla disponibilità generale della versione kubernetes designata.
| Supporto della community | Supporto a lungo termine | |
|---|---|---|
| Quando utilizzare | Quando è possibile tenere il passo con le versioni upstream di Kubernetes | Scenari in cui le applicazioni non sono compatibili con le modifiche introdotte nelle versioni più recenti di Kubernetes e non è possibile passare a un ciclo di rilascio continuo a causa di vincoli tecnici o di altri fattori |
| Versioni di supporto | Tre versioni secondarie GA | Una versione di Kubernetes (attualmente 1.27) per due anni |
Importante
Kubernetes 1.27 è la prima versione LTS supportata di Kubernetes nel servizio Kubernetes di Operatore Nexus. La versione LTS successiva alla 1.27 è la 1.30, che avvierà il supporto LTS nell'ottobre 2024.
Eseguire la migrazione da LTS alla versione successiva LTS
I cluster Nexus Kubernetes non supportano gli aggiornamenti diretti tra le versioni LTS. Per passare da una versione LTS alla successiva, sono disponibili due opzioni: creare un nuovo cluster con la versione LTS desiderata e spostare i carichi di lavoro in questo nuovo cluster oppure eseguire una serie di aggiornamenti intermedi tramite le versioni supportate prima di raggiungere la versione LTS successiva.
Domande frequenti
In che modo Microsoft invia una notifica delle nuove versioni di Kubernetes?
Questo documento viene aggiornato periodicamente con le date pianificate delle nuove versioni di Kubernetes.
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. Operatore Nexus esegue il commit per abilitare le patch e supportare la corrispondenza degli impegni upstream. Per i cluster di Operatore Nexus 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, non si rientra nella finestra di supporto. Quando si esegue l'aggiornamento dalla versione N-3 alla N-2, si ritorna all'interno della finestra di supporto. Ad esempio:
- Se la versione meno recente del servizio Azure Kubernetes supportata è 1.25.x e la versione in uso è 1.24.x o una versione precedente, non si rientra nel supporto.
- L'aggiornamento dalla versione 1.24.x alla versione 1.25.x o successiva riporta all'interno della finestra di supporto.
- Gli "aggiornamenti con salto di livello gerarchico" non sono supportati. Per eseguire l'aggiornamento dalla versione 1.23.x alla versione 1.25.x, è necessario eseguire prima l'aggiornamento alla versione 1.24.x e quindi alla versione 1.25.x.
I downgrade non sono supportati.
Cosa accade se non si aggiorna il cluster?
Se non si aggiorna il cluster, si continua a ricevere supporto per la versione di Kubernetes in esecuzione fino alla fine del periodo di supporto. Successivamente, non si riceverà più il supporto per il cluster. Per continuare a ricevere il supporto, è necessario aggiornare il cluster a una versione supportata.
Cosa accade se non si aggiorna il cluster prima della fine del periodo di disponibilità estesa?
Se non si aggiorna il cluster prima della fine del periodo di disponibilità estesa, non sarà più possibile aggiornare il cluster a una versione supportata o eseguire lo scale-out dei pool di agenti. Per continuare a ricevere il supporto, è necessario ricreare il cluster usando una versione supportata.
Cosa significa "Fuori dal supporto"?
"Fuori dal supporto" significa che:
- La versione in esecuzione non rientra nell'elenco delle versioni supportate.
- Quando si richiede il supporto, viene richiesto di aggiornare il cluster a una versione supportata.
Inoltre, Operatore Nexus 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 che non è supportata?
Per le versioni secondarie non supportate da Operatore Nexus, lo scale-in e lo scale-out dovrebbe continuare a funzionare. Poiché non esistono garanzie di qualità del servizio, è consigliabile eseguire l'aggiornamento per ripristinare il supporto del cluster.
È possibile ignorare più versioni di Kubernetes durante l'aggiornamento del cluster?
Quando si aggiorna un cluster Kubernetes di Operatore Nexus supportato, non è possibile ignorare le versioni secondarie 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.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:
- Eseguire l'aggiornamento da 1.12.x ->1.13.x.
- Eseguire l'aggiornamento da 1.13.x ->1.14.x.
È possibile creare un nuovo cluster durante la finestra di disponibilità estesa?
Sì, è possibile creare un nuovo cluster 1.xx.x durante la finestra di disponibilità estesa. Tuttavia, è consigliabile creare un nuovo cluster con la versione supportata più recente.
È possibile aggiornare un cluster a una versione più recente durante la finestra di disponibilità estesa?
Sì, è possibile aggiornare un cluster N-3 a N-2 durante la finestra di disponibilità estesa. Se il cluster è attualmente in N-4, è possibile usare la disponibilità estesa per eseguire prima l'aggiornamento da N-4 a N-3, quindi procedere con l'aggiornamento a una versione supportata (N-2).
Se si è in una finestra di disponibilità estesa, è comunque possibile aggiungere nuovi pool di nodi? O bisogna eseguire l'aggiornamento?
Sì, è consentito aggiungere pool di nodi al cluster.