Versioni di Kubernetes supportate nel servizio Azure Operator Nexus Kubernetes
Questo documento offre una panoramica dello schema di controllo delle versioni usato per il servizio Operator Nexus Kubernetes, 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 della durata (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 aumentato la finestra di supporto per ogni versione da nove mesi a un anno.
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 di versione principali cambiano quando potrebbero essere introdotte modifiche di rilievo all'API
- I numeri di versione secondaria cambiano quando vengono apportati aggiornamenti delle funzionalità compatibili con le versioni precedenti delle altre versioni secondarie.
- I numeri di versione 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.4ed 1.25.6 è la versione di patch disponibile più recente disponibile 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 della versione di Nexus Kubernetes
Visualizzare le versioni future nel calendario di rilascio di Nexus Kubernetes.
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 | Nexus GA | Fine del ciclo di vita | Disponibilità estesa |
|---|---|---|---|
| 1.25 | Giugno 2023 | Dic. 2023 | Fino alla disponibilità generale 1.31 |
| 1,26 | sett. 2023 | Mar. 2024 | Fino alla disponibilità generale 1.32 |
| 1.27* | sett. 2023 | Luglio 2024, Supporto a Lungo termine fino a luglio 2025 | Fino alla disponibilità generale 1.33 |
| 1.28 | Nov. 2023 | Ottobre 2024 | Fino alla versione 1.34 disponibile a livello generale |
* Indica che la versione è designata per il supporto a lungo termine
Componenti della versione del servizio Nexus Kubernetes
Una versione del servizio Operator Nexus Kubernetes è costituita da due componenti discreti combinati in una singola rappresentazione:
- Versione di Kubernetes. Ad esempio, 1.25.4, è la versione di Kubernetes distribuita in Operator Nexus. Questi pacchetti vengono forniti dal servizio Azure Kubernetes, incluse tutte le versioni patch supportate da Operator 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 Operator Nexus Kubernetes, come singolo numero. Ad esempio, 2.
La combinazione di questi valori è rappresentata nell'API come singolo kubernetesVersion. 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 Operator Nexus Kubernetes 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 con bundle di versioni precedenti 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 Operator Nexus Kubernetes distribuito devono essere applicate solo all'interno di un aggiornamento della versione secondaria di Kubernetes, non durante un aggiornamento della versione patch. Esempi di modifiche alla configurazione che possono essere applicate durante l'aggiornamento della versione secondaria includono:
- Modifica della configurazione del proxy kube da tramite iptables a ipvs
- Modifica dell'interfaccia 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 Operator Nexus Kubernetes.
È possibile eseguire facilmente l'aggiornamento da qualsiasi piccolo aggiornamento in una versione di Kubernetes a qualsiasi piccolo aggiornamento nella versione successiva, offrendo flessibilità. Ad esempio, sarebbe 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
Si notino le modifiche importanti seguenti da apportare 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.25.6 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.25.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.25.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.25.6 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.25.6 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.25.11 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.25.11 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.25.11 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.3 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.3 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.26.3 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.6 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.26.6 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.26.6 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.27.1 | 1 | Calico v3.24.0 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.5.1 |
Azure Linux 2.0 | Cgroupv2 | I passaggi per disabilitare cgroupv2 sono disponibili qui |
| 1.27.1 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | I passaggi per disabilitare cgroupv2 sono disponibili qui |
| 1.27.1 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | I passaggi per disabilitare cgroupv2 sono disponibili qui |
| 1.27.1 | 4 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.27.1 | 5 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.27.3 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Cgroupv2 | I passaggi per disabilitare cgroupv2 sono disponibili qui |
| 1.27.3 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.27.3 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.28.0 | 1 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | |
| 1.28.0 | 2 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione | I nodi del cluster sono abilitati per Azure Arc |
| 1.28.0 | 3 | Calico v3.26.1 metrics-server v0.6.3 Multus v3.8.0 azure-arc-servers v1.0.0 CoreDNS v1.9.3 etcd v3.5.6-5 sriov-dp v3.7.0-48 Csi-nfs v4.6.0 |
Azure Linux 2.0 | Nessuna modifica che causa un'interruzione |
Aggiornamento delle versioni di Kubernetes
Per altre informazioni sull'aggiornamento del cluster, vedere Aggiornare un cluster del servizio Nexus Kubernetes dell'operatore di Azure.
Criteri di supporto della versione di Kubernetes
Operator Nexus supporta tre versioni secondarie di Kubernetes:
- La versione secondaria ga più recente rilasciata in Operator 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 in base ai criteri di disponibilità estesa per la durata della versione secondaria.
Il servizio Operator Nexus Kubernetes offre una durata standardizzata del supporto per ogni versione secondaria di Kubernetes rilasciata. Le versioni sono conformi a due diverse sequenze temporali, riflettendo:
- Durata del supporto: durata della manutenzione attiva di una versione. Alla fine del periodo supportato, la versione è "Fine della vita".
- Disponibilità estesa: per quanto tempo è possibile selezionare una versione per la distribuzione dopo la fine del ciclo di vita.
La finestra supportata delle versioni di Kubernetes in Operator Nexus è nota come "N-2": (N (versione più recente) - 2 (versioni secondarie) e ".letter" è rappresentativo delle versioni patch.
Ad esempio, se Operator Nexus introduce 1.17.a oggi, 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, la versione secondaria supportata meno recente e le versioni patch non sono supportate. 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 Operator Nexus rilascia 1.18.*, tutte le versioni 1.15.* escono dal supporto.
Sequenza temporale del supporto
Il servizio Operator Nexus Kubernetes offre supporto per 12 mesi dalla versione iniziale del servizio Azure Kubernetes disponibile a livello generale 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:
- Può essere distribuito come nuovo cluster Operator Nexus Kubernetes.
- Può essere la destinazione degli aggiornamenti delle versioni precedenti. Limitato dai normali percorsi di aggiornamento.
- Potrebbero essere presenti patch aggiuntive o bundle di versione all'interno della versione secondaria.
Nota
In circostanze eccezionali, il supporto del servizio Nexus Kubernetes potrebbe essere terminato in anticipo o immediatamente se viene identificata una vulnerabilità o un problema di sicurezza. Microsoft comunicherà in modo proattivo ai clienti se ciò dovesse verificarsi e lavorerà per attenuare eventuali problemi potenziali.
Fine della vita (EOL)
Fine del ciclo di vita (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 Nexus Kubernetes 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à esteso per le versioni kubernetes non supportate( ovvero le versioni di EOL Kubernetes), 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 Kubernetes | Supportato | Non supportato |
| Patch di sicurezza delle immagini del nodo | Supportato | Non supportato |
Nota
Operator Nexus si basa sulle versioni e sulle patch di kubernetes, ovvero un progetto Open Source che supporta solo una finestra scorrevole di tre versioni secondarie. Operator Nexus può garantire solo il supporto completo mentre queste versioni vengono gestite a monte. Poiché non sono presenti più patch prodotte a monte, Operator Nexus può lasciare tali versioni senza patch o fork. A causa di questa limitazione, la disponibilità estesa non supporta nulla dalla relying on kubernetes upstream.
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)
servizio Azure Kubernetes (servizio Azure Kubernetes) offre una versione LTS (Long Term Support) di Kubernetes per un periodo di due anni. Esiste una sola versione secondaria di Kubernetes considerata LTS in una sola volta.
| 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 |
La community upstream gestisce una versione secondaria di Kubernetes per un anno dal rilascio. Dopo questo periodo, Microsoft crea e applica gli aggiornamenti della sicurezza alla versione LTS di Kubernetes per fornire un totale di due anni di supporto nel servizio Azure Kubernetes.
Importante
Kubernetes versione 1.27 è la prima versione LTS supportata di Kubernetes nel servizio Operator Nexus Kubernetes.
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. Operator Nexus esegue il commit per abilitare le patch e supportare la corrispondenza degli impegni upstream. Per i cluster Operator Nexus sulla 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, si è fuori dalla finestra di supporto. Quando si esegue l'aggiornamento dalla versione N-3 alla N-2, si torna nella finestra di supporto. Ad esempio:
- Se la versione del servizio Azure Kubernetes supportata meno recente è 1.25.x e si usa la versione 1.24.x o precedente, non si è supportati.
- L'aggiornamento dalla versione 1.24.x alla versione 1.25.x o successiva riporta all'interno della finestra di supporto.
- Gli aggiornamenti a livello di skip 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. È necessario aggiornare il cluster a una versione supportata per continuare a ricevere il supporto.
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 a pool di agenti con scalabilità orizzontale. 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.
Operator Nexus non garantisce inoltre alcun runtime o altre garanzie per i cluster all'esterno dell'elenco delle versioni supportate.
Cosa accade quando un utente ridimensiona un cluster Kubernetes con una versione secondaria non supportata?
Per le versioni secondarie non supportate da Operator Nexus, l'aumento o l'aumento del 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 ignorare più versioni di Kubernetes durante l'aggiornamento del cluster?
Quando si aggiorna un cluster Operator Nexus Kubernetes 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 e quindi procedere con l'aggiornamento a una versione supportata (N-2).
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.