Red Hat annuncia il servizio Extended Update Support per OpenShift 4.14 e versioni successive

Red Hat annuncia un periodo aggiuntivo opzionale di 12 mesi per il servizio EUS per OpenShift 4.14 e per le successive versioni pari di Red Hat OpenShift della serie 4.x. L'intero ciclo di vita disponibile per le versioni EUS di OpenShift è di tre (3) anni.

Ha inizio il Red Hat Summit a Denver con OpenShift Commons Gathering. Ascolteremo i partecipanti e i clienti che si affidano a Red Hat OpenShift ogni giorno. Negli ultimi anni, i clienti di OpenShift hanno applicato la sua tecnologia a scenari di utilizzo in mercati specializzati che richiedono cicli di vita più lunghi.Per esigenze di conformità, ma anche per via dei diversi utilizzi che enti pubblici e aziende fanno dei servizi essenziali offerti da OpenShift, i nostri clienti si rivolgono a Red Hat per trovare il modo di prolungare l'utilizzo dei nostri componenti open source.Ogni anno Red Hat esamina i cicli di vita più lunghi in base a una serie di criteri.Quest'anno abbiamo trovato la giusta combinazione di condizioni che ci permetteranno di fare qualcosa per aiutare i nostri clienti.

Tenendo conto delle complesse esigenze dei nostri clienti, stiamo ampliando l'offerta Extended Update Support (EUS) per Red Hat OpenShift, offrendo la possibilità di estendere notevolmente il ciclo di vita supportato dei deployment OpenShift.

Il supporto verrà prolungato oltre il periodo EUS di 6 mesi precedentemente introdotto al momento del rilascio di OpenShift 4.12. Questo nuovo periodo EUS aggiuntivo di 12 mesi sarà disponibile attraverso una sottoscrizione aggiuntiva e porterà il ciclo di vita di OpenShift a 3 anni in totale.

Con il termine EUS aggiuntivo, OpenShift 4.14 sarà supportato fino al 31 ottobre 2026:

Il prossimo rilascio di Extended Update Support coinciderà con il prossimo rilascio di OpenShift 4.16. Di seguito è raffigurato anche l'impatto sul ciclo di vita dei rilasci EUS:

Qual è il livello di supporto incluso?

Il termine aggiuntivo EUS include backport di aggiornamenti di sicurezza con impatto Critico e Importante, oltre a correzioni di bug prioritari. Le informazioni ufficiali saranno pubblicate nella pagina dedicata a Red Hat OpenShift Container Platform Lifecycle Policy, da considerare il principale riferimento per ottenere informazioni aggiornate sul ciclo di vita di OpenShift.

Lo SLA di supporto offerto durante il periodo EUS aggiuntivo verrà ereditato dall'offerta di base acquistata (Premium o Standard).

Quali componenti sono inclusi?

Il termine EUS aggiuntivo si applica a tutti gli operatori allineati alla piattaforma inclusi in OpenShift Kubernetes Engine. Gli altri operatori non saranno inclusi automaticamente e manterranno i propri cicli di vita.

Un cliente che acquista OpenShift Platform Plus o OpenShift Container Platform come sottoscrizione base può comunque acquistare l'equivalente Extended Update Support Term corrispondente a quell'offerta, ma riceverà il termine EUS aggiuntivo solo per i componenti per i quali è disponibile.

In futuro, prevediamo di offrire il periodo EUS aggiuntivo a più operatori Red Hat. Controlla sempre la pagina del ciclo di vita dell'operatore a più livelli pertinente per avere le informazioni più recenti sul ciclo di vita.

In che modo questo incide sugli upgrade?

OpenShift 4.14 mantiene il supporto per una versione N-2 di compensazione tra i servizi del piano di controllo e i nodi di lavoro, dove N è la relativa versione secondaria di OpenShift. Ciò significa, ad esempio, che un piano di controllo che è passato a OpenShift 4.14 può interagire con i nodi di lavoro su 4.13 e/o 4.12 all'interno di una sequenza di aggiornamento.

Per quanto riguarda i nodi del piano di controllo, gli aggiornamenti rimangono di natura sequenziale. Per i nodi di lavoro, tuttavia, è disponibile una funzione che consente di sospendere i pool di lavoro per ignorare ogni secondo rilascio e il relativo riavvio, che, se combinato con il supporto per il disallineamento tra versioni, consente di mitigare l'impatto aggiuntivo di più upgrade sui carichi di lavoro in esecuzione.

Esempio di flusso di upgrade per il piano di controllo e i nodi di lavoro dalla versione 4.14 alla versione futura 4.18.

In attesa di ulteriori test, questa funzionalità verrà ampliata nelle versioni future, in linea con l'espansione upstream delle versioni di Kubernetes, che sta passando al supporto di un criterio di compensazione per le versioni N-3.

Con l'aumentare del periodo tra la versione di origine e quella di destinazione, aumenta anche il numero di aggiornamenti sequenziali necessari per passare all'ultima versione di EUS. Con l'aumento del numero di upgrade sequenziali necessari, aumentano anche la complessità dell'upgrade, il livello di interruzione del carico di lavoro e il tempo necessario per il completamento. Pertanto, se possibile, è preferibile eseguire l'upgrade tramite un processo di upgrade blue/green, per aumentare la scalabilità su un nuovo cluster, spostando i carichi di lavoro e rimuovendo il cluster precedente.

Ogni cluster è diverso, pertanto ogni cluster richiederà un percorso specifico per l'upgrade. Ti consigliamo di prendere in considerazione e scegliere un piano di upgrade mentre scegli di utilizzare i termini di OpenShift EUS per un cluster.

Come avere più informazioni?

Red Hat ha aderito al gruppo di lavoro Long Term Support (LTS) all'interno dell'ecosistema Kubernetes per promuovere idee su come estendere il ciclo di vita di Kubernetes e delle relative tecnologie.Invitiamo tutti gli utenti interessati a questi argomenti ad entrare a far parte della community.

Scopri di più nel prossimo evento virtuale "What’s New in OpenShift 4.16". Seguici su YouTube o Twitch per ricevere informazioni sulla data di trasmissione.

E se non sei già un utente OpenShift e abbiamo suscitato il tuo interesse... provalo!