Versioni disponibili IBM Cloud Kubernetes Service

IBM Cloud Kubernetes Service supporta contemporaneamente più versioni di Kubernetes. Quando viene rilasciata una versione più recente (n), sono supportate fino a 2 versioni precedenti (n-2). Le versioni che sono più di 2 precedenti rispetto all'ultima (n-3) sono prima dichiarate obsolete e quindi non più supportate. Per continuare a ricevere importanti aggiornamenti di sicurezza, assicurati che i tuoi cluster utilizzino sempre una versione supportata di Kubernetes. I cluster obsoleti potrebbero non ricevere gli aggiornamenti di sicurezza. Per ulteriori informazioni, vedi Ciclo di vita della release.

Le date contrassegnate con un simbolo che sembra un pugnale (†) non sono definitive e sono soggette a variazioni. I sistemi operativi contrassegnati da un asterisco (*) sono deprecati. Migrare tutti i nodi worker che utilizzano un sistema operativo deprecato a una versione più recente del sistema operativo.

Tipi di aggiornamento

Per il tuo cluster Kubernetes sono disponibili tre tipi di aggiornamento: principale, secondario e patch. Man mano che gli aggiornamenti diventano disponibili, ricevi una notifica quando visualizzi le informazioni relative al master cluster o ai nodi di lavoro, ad esempio con i comandi ibmcloud ks cluster ls, cluster get, worker ls o worker get.

IBM fornisce fix pack del nodo di lavoro bisettimanali. IBM l'obiettivo è quello di rimediare alle vulnerabilità rilevate e legittime entro un tempo adeguato ai rischi che rappresentano. Per garantire la qualità e la stabilità della release, i fix pack potrebbero essere ritardati.

I fix pack vengono applicati all'ultima versione del kernel stabile upstream fornita da Canonical.

Per mantenere i tuoi nodi protetti, devi installare i fix pack del nodo di lavoro il prima possibile. È possibile sottoscrivere le notifiche per essere avvisati quando è disponibile un nuovo aggiornamento.

Aggiornamenti principali e secondari (1.x)

Per prima cosa, aggiorna il tuo nodo master e poi aggiorna i nodi di lavoro.

• Non è possibile aggiornare un master “ Kubernetes ” a una versione con due o più versioni minori successive ( n+2 ). Ad esempio, se il tuo master attuale è la versione 1.22 e desideri passare alla versione 1.24, devi prima effettuare l'aggiornamento alla versione 1.23.
• I nodi di lavoro non possono eseguire una versione principale o secondaria di Kubernetes superiore a quella dei master. Inoltre, i tuoi nodi di lavoro possono essere solo due versioni dietro la versione master (n-2).
• Se utilizzi una versione della CLI kubectl che non corrisponde almeno alla versione major.minor dei tuoi cluster, potresti riscontrare risultati imprevisti. Assicurati di mantenere aggiornate le versioni della CLI e dei cluster Kubernetes.

Aggiornamenti patch (x.x.4_1510)

Le modifiche tra patch sono documentate nel log delle modifiche di ogni versione. Le patch master vengono applicate automaticamente, mentre le patch e gli aggiornamenti dei nodi worker vengono avviati dall'utente. I nodi di lavoro possono anche eseguire versioni patch superiori ai master. Man mano che gli aggiornamenti diventano disponibili, ricevi una notifica quando visualizzi le informazioni relative al master e ai nodi di lavoro nella console o nella CLI IBM Cloud, ad esempio con i seguenti comandi: ibmcloud ks cluster ls, cluster get, worker ls o worker get.

Le patch possono essere per nodi di lavoro, master o entrambi.

• Aggiornamenti dei nodi di lavoro: verificare mensilmente se è disponibile un aggiornamento e utilizzare il ibmcloud ks worker update comando o il ibmcloud ks worker reload per applicare queste patch di sicurezza e del sistema operativo. Durante un aggiornamento o un caricamento, viene ricreata l'immagine della macchina del nodo di lavoro e i dati vengono eliminati se non sono archiviati all'esterno del nodo di lavoro.
• Patch master: le patch master vengono applicate automaticamente nel corso di diversi giorni, pertanto una versione della patch master potrebbe essere disponibile prima che venga applicata al tuo master. L'automazione degli aggiornamenti ignora anche i cluster che si trovano in uno stato non integro o che hanno operazioni attualmente in corso. A volte, IBM potrebbe disabilitare gli aggiornamenti automatici per uno specifico "master fix pack", come indicato nel registro delle modifiche, ad esempio nel caso di una patch necessaria solo se un "master" viene aggiornato da una versione minore a un'altra. In uno qualsiasi di questi casi, puoi scegliere di utilizzare in tutta sicurezza il ibmcloud ks cluster master update comando in modo sicuro senza attendere che venga applicata l'aggiornamento automatico.

Ciclo di vita della release

Ogni versione supportata di IBM Cloud Kubernetes Service passa attraverso un ciclo di vita di test, sviluppo, release generale, supporto, deprecazione e il diventare non supportata. Esaminare le descrizioni di ciascuna fase del ciclo di vita di una versione.

Per una comprensione generale vengono forniti i giorni e le versioni stimati. Le date di disponibilità e release reali sono soggette a modifiche e dipendono da vari fattori, ad esempio dagli aggiornamenti della community, dalle patch di sicurezza e dalle modifiche alla tecnologia tra le versioni.

1. Release comunità: la comunità rilascia la nuova versione. Gli ingegneri IBM iniziano a testare e a rendere più dura la versione della community in preparazione per rilasciare una versione IBM Cloud Kubernetes Service supportata.

2. Ciclo di vita della versione supportato:

   Release di sviluppo

   La release è in fase di sviluppo e potrebbe essere disponibile come Beta per selezionare i clienti. IBM fornisce il supporto migliore per la release.

   Disponibilità generale

   La release è generalmente disponibile (GA). IBM fornisce il supporto completo per la release. IBM fornisce una data di destinazione provvisoria perché la release non sia supportata. La release diventa la versione predefinita utilizzata durante la creazione del cluster una volta che ci sono restrizioni minime e un tasso di adozione ragionevole per la release.

   Manutenzione

   La release ha immesso il supporto di manutenzione come definito dalla community Kubernetes. IBM fornisce supporto di manutenzione per Kubernetes basato sulla politica della community. IBM fornisce il supporto completo in caso contrario.

3. Versione obsoleta: la versione è obsoleta. IBM fornisce una data di destinazione non supportata aggiornata per la release. Un conto alla rovescia non supportato fino a questa data viene fornito almeno 45 giorni prima che la release diventi non supportata. IBM fornisce un supporto minimo per la release in linea con la community Kubernetes. Questa fase di supporto è in genere la fase finale prima che il rilascio diventi non supportato e sovrascrive le fasi di manutenzione e di supporto esteso in caso di sovrapposizione. Gli aggiornamenti della patch di sicurezza potrebbero non essere forniti. Durante il periodo di obsolescenza, la versione è ancora supportata e il tuo cluster è ancora funzionante, ma potrebbe richiedere l'aggiornamento a una release supportata per correggere le vulnerabilità di sicurezza. Ad esempio, aggiungendo o ricaricando i nodi di lavoro.

4. Versione non supportata: la versione non è supportata. IBM fornisce solo il supporto per l'aggiornamento a una release supportata. La versione non è supportata. I cluster non supportati non vengono forniti con gli aggiornamenti di sicurezza e patch e non sono supportati dal supporto IBM Cloud. Sebbene il tuo cluster e le tue applicazioni possano continuare l'esecuzione per un certo periodo di tempo, non puoi più creare, ricaricare o eseguire altre azioni correttive sul tuo master cluster o sui tuoi nodi di lavoro quando si verifica un problema. Puoi ancora eliminare il cluster o i nodi di lavoro o aggiornare il cluster alla versione successiva. Verificate i possibili effetti e visitate subito il sito aggiornare il cluster per continuare a ricevere importanti aggiornamenti di sicurezza e assistenza. Se il master cluster esegue due o più versioni dopo la versione meno recente supportata, non è più possibile applicare gli aggiornamenti e deve eliminare il cluster e crearne uno nuovo.

   I cluster che eseguono una versione non supportata alla fine non funzioneranno più perché i certificati dei cluster scadono. I guasti possono includere, ma non sono limitati a, un piano di controllo del cluster non disponibile, nodi operativi dell NotReady, o un Ingresso non integro.

5. Archiviato: la versione non è supportata senza percorso di aggiornamento. IBM non fornisce supporto. IBM si riserva il diritto di arrestare i piani di controllo per tali cluster.

IBM Cloud Kubernetes Service non ha ampliato la sua inclinazione supportata tra il nodo centrale e i componenti del piano di controllo di una versione minore. Il disallineamento supportato rimane n-2. Per ulteriori informazioni, consulta Modifiche all'inclinazione supportata tra le versioni del piano di controllo e dei nodi per le Kubernetes informazioni sulla community.

Se si attende che il cluster sia in ritardo di due o più versioni minori rispetto alla versione più vecchia supportata, non sarà possibile aggiornarlo. Invece, crea un nuovo cluster, distribuisci le tue applicazioni nel nuovo cluster ed elimina il cluster non supportato. Per evitare questo problema, aggiornare i cluster deprecati a una versione supportata che sia una o due versioni indietro rispetto a quella attuale, come 1.21 o 1.22 e poi aggiornare alla versione più recente, 1.23. Se i nodi di lavoro eseguono una versione che precede di due o più versioni quella del master, potresti osservare un malfunzionamento dei pod, che assumono stati quali MatchNodeSelector, CrashLoopBackOff o ContainerCreating, finché non aggiorni i nodi di lavoro alla stessa versione del master. Sebbene le versioni non supportate non siano supportate dall'assistenza di IBM Cloud, IBM Technology Expert Labs dispone di servizi di costruzione che possono aiutare a risolvere i problemi con le versioni non supportate. Selezionate "Partner with IBM Technology Expert Labs" nel catalogo IBM Cloud per iniziare a usufruire dei loro servizi. Dopo che effettui l'aggiornamento a una versione supportata, il tuo cluster può riprendere le normali operazioni e continuare a ricevere supporto. È possibile verificare se il proprio cluster è un cluster di tipo " non supportato " controllando il campo " Stato " nell'output del comando " ibmcloud ks cluster ls " oppure nel file " IBM Cloud Kubernetes Service console".

Preparazione dell'aggiornamento

L'aggiornamento di un cluster a una nuova versione dalla precedente probabilmente avrà un impatto sulle app distribuite. Per un elenco completo delle modifiche, consulta i log delle Kubernetes modifiche della community, i log IBM delle modifiche di versione e gli Kubernetes avvisi utili.

Per le azioni che devi intraprendere prima e dopo l'aggiornamento del tuo cluster, vedi i collegamenti alle informazioni sulla versione in Available IBM Cloud® Kubernetes Service versions.

Archivia

I cluster non supportati non vengono forniti con gli aggiornamenti di sicurezza e patch e non sono supportati dal supporto IBM Cloud. Sebbene il tuo cluster e le tue applicazioni possano continuare l'esecuzione per un certo periodo di tempo, non puoi più creare, ricaricare o eseguire altre azioni correttive sul tuo master cluster o sui tuoi nodi di lavoro quando si verifica un problema. Puoi ancora eliminare il cluster o i nodi di lavoro o aggiornare il cluster alla versione successiva. Verificate i possibili effetti e visitate subito il sito aggiornare il cluster per continuare a ricevere importanti aggiornamenti di sicurezza e assistenza. Se il tuo master cluster è di due o più versioni rispetto alla versione supportata meno recente, devi creare un nuovo cluster e distribuire le tue applicazioni nel nuovo cluster.