Red Hat OpenShift 4.16: Cosa devi sapere

Red Hat OpenShift 4.16 è ora disponibile. Basato su Kubernetes 1.29 e CRI-O 1.29, OpenShift 4.16 si concentra sulle funzionalità principali, sulla sicurezza, su virtualizzazione, telecomunicazioni ed edge computing. Red Hat OpenShift mira ad accelerare lo sviluppo e la distribuzione e la scalabilità di applicazioni moderne nel cloud ibrido attraverso una piattaforma affidabile, completa e coerente.

Ciclo di vita di 3 anni per Red Hat OpenShift 4.14 e versioni successive

Red Hat OpenShift 4.14 è disponibile come sottoscrizione aggiuntiva, ed ora è possibile estenderla per ulteriori 12 mesi con Extended Update Support (EUS) per Red Hat OpenShift 4.14 e tutte le successive versioni pari. In questo modo l'intero ciclo di vita disponibile per queste versioni EUS di Red Hat OpenShift è di 3 anni, prorogato rispetto al periodo EUS di 6 mesi precedente. Fare riferimento a Red Hat OpenShift Container Platform Life Cycle Policy per ulteriori dettagli.

Sicurezza shift left scalabile con Red Hat Advanced Cluster Security Cloud Service

Red Hat Advanced Cluster Security Cloud Service è ora passato da disponibilità limitata a disponibilità generale. Red Hat Advanced Cluster Security Cloud Service è un servizio cloud di sicurezza Kubernetes native completamente gestito che supporta sia Red Hat OpenShift che piattaforme Kubernetes non Red Hat, tra cui Amazon EKS, Google GKE e Microsoft AKS. Questo servizio cloud consente di adottare un approccio orientato alla sicurezza per creare, distribuire e gestire applicazioni cloud native in modo scalabile nel cloud ibrido, indipendentemente dalla piattaforma Kubernetes alla base.

Riduci i costi e ottimizza i tempi di deployment dei cluster con i piani di controllo in hosting autogestiti in AWS

I piani di controllo in hosting sono abilitati per impostazione predefinita nell'operatoremotore multicluster (MCE) for Kubernetes dalla versione 2.4. Con la versione 2.6 di MCE, i piani di controllo in hosting autogestiti in AWS sono generalmente disponibili insieme a Red Hat OpenShift 4.16.

I piani di controllo in hosting rendono più efficiente ed economica la gestione di più cluster OpenShift in modo scalabile. La gestione del piano di controllo è centralizzata, consentendo un migliore utilizzo delle risorse e una manutenzione più semplice. Con i piani di controllo in hosting, puoi concentrarti sulle applicazioni riducendo il carico di lavoro dell'infrastruttura e di gestione, ottimizzando i tempi di deployment dei cluster e consentendo di separare le problematiche tra gestione e carichi di lavoro.

Server di autenticazione esterni in Red Hat OpenShift on AWS con piano di controllo in hosting

Ora puoi portare la tua soluzione OpenID Connect (OIDC) su Red Hat OpenShift Service on AWS (ROSA) con piani di controllo in hosting, in modo da poter autenticare utenti e gruppi direttamente con il server API Kubernetes. I cluster ROSA utilizzano AWS Security Token Service (STS) e OIDC per garantire agli operatori interni al cluster l'accesso alle risorse AWS necessarie. Scopri di più leggendo l'articolo intitolato Simplify access to your ROSA clusters using external OIDC .

Proteggi la rete dei cluster OpenShift con Admin Network Policy

La nuova generazione di criteri di rete Kubernetes è ora completamente supportata nei deployment OpenShift che utilizzano OVN-Kubernetes per il networking. Admin Network Policy (noto anche come Global Network Policy) migliora la precedente implementazione dei criteri di rete upstream. Le funzionalità più richieste includono:

• Criteri di sicurezza della rete con privilegi di amministratore che non possono essere sostituiti da amministratori e sviluppatori dello spazio dei nomi;
• Un ambito a livello di cluster. Ad esempio, i criteri di uscita (egress policies) possono essere definiti una sola volta in un'unica posizione e applicati a tutto il traffico del cluster;
• La possibilità di delegare policy di sicurezza specifiche e controllate ad amministratori e sviluppatori dello spazio dei nomi, in modo che abbiano la flessibilità delle policy di rete necessaria per lo sviluppo delle applicazioni.

I criteri della rete di amministrazione consentono di:

• Isolare i tenant all'interno di un cluster con il controllo con privilegi di amministratore;
• Creare una lista di autorizzazione definitiva per il traffico che deve essere sempre consentito;
• Specificare una policy immutabile per tutto il traffico in uscita dal cluster. Ad esempio, puoi indirizzare tutto il traffico attraverso un dispositivo gateway per l'ispezione;
• Definire i criteri del traffico di rete con una risoluzione precisa per modelli di traffico altamente selettivi, in particolare da e verso gli spazi dei nomi sensibili.

Riduci l'accesso di gruppi e utenti non autenticati

A partire da OpenShift 4.16, esiste un limite alle autorizzazioni concesse all'utente system:anonymous e al gruppo system:unauthenticated. Per impostazione predefinita, sono consentiti solo due ruoli:

• system:openshift:public-info-viewer: necessario per i flussi di lavoro OIDC
• system:public-info-viewer: accesso in sola lettura alle informazioni non riservate sul cluster

Questo vale solo per i nuovi cluster. I cluster aggiornati non sono interessati.

Per gli scenari di utilizzo in cui è necessario l'accesso anonimo, l'amministratore del cluster deve aggiungere esplicitamente tali autorizzazioni. Ad esempio, se utilizzi webhook per BuildConfigs da un sistema esterno (come GitHub) che non supporta l'invio di token di autenticazione su HTTP, devi aggiungere esplicitamente autorizzazioni system:webhook. In questi scenari, consigliamo vivamente di utilizzare le associazioni di ruoli locali anziché le associazioni di ruoli cluster. Un amministratore del cluster può aggiungere nuovamente un ClusterRoleBinding per l'utente anonimo in base alle esigenze, dopo aver valutato i rischi e i vantaggi associati.

Risoluzione semplificata dei problemi di aggiornamento di OpenShift grazie allo stato di aggiornamento di oc adm

Red Hat OpenShift 4.16 include il nuovo comando oc adm upgrade status, disponibile come anteprima tecnologica. Questo comando mostra lo stato di avanzamento dell'aggiornamento del cluster, eliminando gli elementi di disturbo, e mostra all'amministratore se l'aggiornamento sta andando bene o se è necessario intervenire. In caso di problemi di aggiornamento, il comando restituisce informazioni su ciò che sta accadendo, accompagnate da indicazioni e collegamenti a risorse pertinenti (come la documentazione di Red Hat o gli articoli della knowledge base).

# oc adm upgrade status
An update is in progress for 55m7s: Working towards 4.16.0: 198 of 951 done (20% complete)
= Control Plane =
Assessment:      Progressing
Completion:      97%
Duration:        55m6.974951563s
Operator Status: 36 Total, 36 Available, 1 Progressing, 0 Degraded
= Worker Upgrade =
= Worker Pool =
Worker Pool:     worker
Assessment:      Progressing
Completion:      7%
Worker Status:   42 Total, 22 Available, 20 Progressing, 39 Outdated, 19 Draining, 0 Excluded, 0 Degraded
Worker Pool Node(s)
NAME                                       ASSESSMENT    PHASE      VERSION       EST    MESSAGE
build0-gstfj-ci-builds-worker-b-25ptt      Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-longtests-worker-b-ppxvc   Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-prowjobs-worker-b-gvthg    Progressing   Draining   4.16.0-ec.3   +30m   
build0-gstfj-ci-tests-worker-b-7hvhq       Progressing   Draining   4.16.0-ec.3   +30m   
...
Omitted additional 32 Total, 3 Completed, 22 Available, 10 Progressing, 29 Outdated, 9 Draining, 0 Excluded, and 0 Degraded nodes.
Pass along --details to see all information.
= Update Health =
SINCE   LEVEL   IMPACT   MESSAGE
55m7s   Info    None     Upgrade is proceeding well

Migrazione in-place a Microsoft Entra Workload ID

Se utilizzi Red Hat OpenShift on Azure autogestito, ora puoi eseguire la migrazione a Microsoft Entra Workload ID (in precedenza Azure AD Workload Identity) con tempi di fermo minimi. Il supporto per Microsoft Entra Workload ID è stato aggiunto in Red Hat OpenShift 4.14, che offre ai clienti un modo per creare e gestire cluster Red Hat OpenShift con credenziali temporanee e con privilegi limitati. Ora puoi adottare Microsoft Entra Workload ID senza dover ricominciare da capo con un nuovo cluster. Per i dettagli, vedere l'articolo Configuring OpenShift with Microsoft Entra Workload ID.

Ottimizza le prestazioni del cluster con i parametri etcd

È ora possibile aggiornare l'etcd per consentire al cluster di tollerare una latenza ridotta tra i membri dell'etcd. A tale scopo, imposta i parametri di latenza per l'intervallo di heartbeat e i timeout di elezione dei leader su valori che ottimizzano le prestazioni e riducono la latenza. I valori possibili sono:

• "" (il valore predefinito è vuoto)
• Standard
• Più lento

Ciò consente di adattarsi a scenari in cui i dischi sono più lenti ma accettabili o i cluster estesi che rientrano nelle procedure consigliate OpenShift per prestazioni e scalabilità.

Per ulteriori informazioni, fare riferimento alla specifica etcd.

Ottimizza la scalabilità automatica dei cluster in base alle esigenze dei carichi di lavoro

Il cluster autoscaler ora utilizza le strategie LeastWaste, Priority e Random expander. Puoi configurare questi expander per influenzare la selezione degli insiemi di macchine mentre ridimensioni il cluster.

• Casuale: consigliato per distribuire i carichi di lavoro in modo uniforme in un cluster omogeneo in cui i gruppi di nodi offrono risorse simili
• LeastWaste: per i cluster in cui l'efficienza e la riduzione degli sprechi di risorse sono priorità, in particolare con carichi di lavoro dinamici in cui scalabilità e flessibilità rapide sono più importanti
• Priorità: per decisioni di scalabilità complesse basate su priorità definite dall'utente; è adatto a cluster complessi con diversi gruppi di nodi

Utilizza il tuo sistema di bilanciamento del carico per il deployment on premise

Con Red Hat OpenShift 4.16, puoi utilizzare il tuo sistema di bilanciamento del carico gestito dall'utente insieme a un cluster su qualsiasi infrastruttura on premise (bare metal, VMware vSphere, Red Hat OpenStack Platform, Nutanix e altre ancora). Per questa configurazione, specifica loadBalancer.type:UserManaged nel file install-config.yaml del cluster. Consulta services for a user-managed load balancer per sapere di più su questa funzionalità.

Migliora l'osservabilità del cluster con il monitoraggio e la risoluzione dei problemi avanzati

Red Hat OpenShift 4.16 introduce miglioramenti significativi nelle capacità di osservabilità, fornendo strumenti avanzati per il monitoraggio, la risoluzione dei problemi e l'ottimizzazione di un cluster. Sono stati apportati aggiornamenti ai componenti dello stack di monitoraggio all'interno del cluster, come Prometheus, Thanos e nuove regole di avviso. Un nuovo Metrics Server semplifica la raccolta delle metriche, mentre il nuovo ruolo monitoring-alertmanager-view migliora la sicurezza e la collaborazione. Queste funzionalità sono incluse in Cluster Observability Operator versione 0.3.0, che funge da operatore punto di accesso unico per l'installazione e la gestione dell'osservabilità. Questa versione aggiunge anche miglioramenti aOpenTelemetry e funzionalità aggiuntive per l'API Cluster Logging.

Cluster Observability Operator introduce una nuova versione di Observability Signal Correlation per correlare i segnali di osservabilità, Incident Detection per dare priorità agli avvisi critici e miglioramenti al tracciamento distribuito con il supporto Tempo Operator per il deployment monolitico. Le visualizzazioni di tracciamento distribuito vengono ora visualizzate nella console di OpenShift.

Observability Signal Correlation e Incident Detection sono disponibili per Developer Preview.Power Monitoring, disponibile per l'anteprima tecnologica, ora offre un'interfaccia utente (UI) per gli sviluppatori e migliora la precisione dei dati.

Rinnova la gestione dell'infrastruttura con Red Hat OpenShift Virtualization

Sul fronteRed Hat OpenShift Virtualization, siamo lieti di annunciare la disponibilità generale di metro disaster recovery per le macchine virtuali (VM) che utilizzano lo storage distribuito su Red Hat OpenShift Data Foundation insieme a Red Hat Advanced Cluster Management for Kubernetes (RHACM) per la gestione.

Abbiamo aggiunto una serie di miglioramenti alle VM. Ora puoi aggiungere risorse vCPU aggiuntive a una VM in esecuzione in modo dichiarativo. Abbiamo migliorato la densità della memoria con un overcommit sicuro della memoria e abbiamo semplificato la scalabilità verticale delle VM con l'hotplug della CPU.

Con RHACM è ora possibile monitorare le VM multi-cluster. Da un Hub RHACM, puoi visualizzare tutte le VM su più cluster OpenShift. Puoi raccogliere e creare rapidamente report per tutte le VM. In un RHACM Global Hub, utilizzando Global Hub Search, puoi visualizzare tutte le VM su più hub.

L'ecosistema continua a crescere con partner di hardware, storage e infrastruttura di rete, oltre a provider di soluzioni per la protezione dei dati di terze parti. Oltre a Veeam Kasten, Trilio e Storaware, sono in arrivo le funzionalità di Cohesity, Commvault, Rubrik e Veritas.

Aggiornamento basato su immagini per cluster OpenShift a nodo singolo che utilizzano Lifecycle Agent

I partner di Red Hat nel settore delle telecomunicazioni stanno adottando i container per le reti RAN (Radio Access Networks), distribuendo le soluzioni susingle node OpenShift. Red Hat OpenShift 4.16 offre un approccio "shift left" con aggiornamenti basati su immagini (IBU). L'IBU offre un modo alternativo per aggiornare un cluster OpenShift a nodo singolo, in quanto gli utenti OpenShift a nodo singolo spostano gran parte del processo di aggiornamento in un ambiente di pre-produzione per ridurre il tempo dedicato all'aggiornamento nel sito di produzione.

IBU consente di eseguire gli aggiornamenti z-stream, gli aggiornamenti delle versioni secondarie e l'aggiornamento diretto EUS-to-EUS, in cui la versione provvisoria viene ignorata. Questo metodo di aggiornamento utilizza Lifecycle Agent per generare un'immagine OCI da un cluster di inizializzazione dedicato che viene installato nel cluster OpenShift a nodo singolo di destinazione come nuovoostree stateroot. Un cluster di inizializzazione è un cluster OpenShift a nodo singolo distribuito con la versione di destinazione di OpenShift Container Platform, gli operatori distribuiti e le configurazioni comuni a tutti i cluster di destinazione. L'immagine seed viene quindi utilizzata per aggiornare la versione della piattaforma su qualsiasi cluster OpenShift a nodo singolo con la stessa combinazione di hardware, operatori e configurazione del cluster del cluster seed.

Inoltre, se un aggiornamento non riesce o l'applicazione non torna allo stato di funzionamento, può essere ripristinato allo stato precedente all'aggiornamento. Nota: questo vale solo per i cluster OpenShift a nodo singolo. Ciò garantisce che il servizio venga ripristinato il più rapidamente possibile in caso di esito positivo o negativo dell'aggiornamento. IBU si integra perfettamente nei flussi Zero Touch Provisioning che utilizzano Red Hat OpenShift GitOps e Red Hat Advanced Cluster Management.

Crea un'appliance OpenShift autonoma scalabile

I partner che desiderano realizzare appliance personalizzate e pronte all'uso con OpenShift autonomo e servizi aggiuntivi su hardware prescritto in modo scalabile, ora possono utilizzare OpenShift-based Appliance Builder, disponibile per Technology Preview. OpenShift-based Appliance Builder è un'utilità basata su container che crea un'immagine disco che include il programma di installazione basato su agenti, che viene utilizzato per installare più cluster OpenShift. Per ulteriori informazioni, fare riferimento alla Guida per l'utente di OpenShift-based Appliance Builder.

Rete migliorata, gestione GitOps e aggiornamenti EUS per MicroShift

Per la versione Red Hat di MicroShift, l'ultima versione introduce tre aggiornamenti al fine di migliorare la gestione dell'edge:

1. Collegamento di più interfacce di rete ai pod Multus CNI for MicroShift:Multus consente ai pod Kubernetes di collegarsi a più reti. Questo è utile quando si utilizza SR-IOV o in presenza di configurazioni VLAN complesse. Con Multus abilitato su Microshift, puoi aggiungere facilmente più interfacce ai pod utilizzando i plugin CNI bridge, macvlan o ipvlan
2. Automatizza la gestione dell'infrastruttura e delle applicazioni con GitOps for MicroShift: Con GitOps for MicroShift, puoi configurare e distribuire in modo coerente l'infrastruttura e le applicazioni basate su Kubernetes nei cluster e nei cicli di sviluppo. GitOps with Argo CD for MicroShift è un controller aggiuntivo, leggero e opzionale, derivato da Red Hat OpenShift GitOps Operator. GitOps for MicroShift utilizza l'interfaccia a riga di comando di Argo CD per interagire con il controller GitOps che funge da motore GitOps dichiarativo
3. Aggiornamenti EUS diretti per MicroShift:MicroShift ora esegue l'aggiornamento diretto da Extended User Support (EUS) versione 4.14 alla versione 4.16 con un unico riavvio (Red Hat Enterprise Linux 9.4 è richiesto per la versione 4.16)

Prova subito Red Hat OpenShift 4.16

Inizia subito con Red Hat Hybrid Cloud Console e sfrutta le funzionalità e i miglioramenti più recenti di OpenShift. Per scoprire le novità, consulta le seguenti risorse:

• Novità e novità di Red Hat OpenShift
• Canale YouTube di OpenShift
• Blog di OpenShift
• OpenShift Commons
• Blog degli sviluppatori Red Hat
• Red Hat Portfolio Architecture Center

Un elenco completo degli aggiornamenti di Red Hat OpenShift 4.16 è disponibile nelle Note sulla versione di Red Hat OpenShift 4.16.Puoi inviarci commenti tramite i tuoi contatti Red Hat, scriverci sul canale Slack OpenShift Commons slack oppure creare un ticket su GitHub.