Come accelerare la virtualizzazione e l'innovazione IA in azienda con Red Hat OpenShift 4.20

Red Hat OpenShift 4.20 è ora disponibile. Basato su Kubernetes 1.33 eCRI-O 1.33 e insieme a Red Hat OpenShift Platform Plus, la soluzione ribadisce il nostro impegno a fornire una piattaforma applicativa affidabile, completa e coerente. In OpenShift possono coesistere senza conflitti i carichi di lavoro dell'IA, i container e la virtualizzazione, consentendo alla tua azienda di introdurre le innovazioni per il cloud ibrido senza compromettere la sicurezza.

Disponibile in versione autogestita o completamente gestita nel cloud, OpenShift offre una piattaforma applicativa con un set completo di strumenti e servizi integrati per carichi di lavoro tradizionali, virtuali, basati su IA e cloud native. In questo articolo ti illustriamo le ultime novità di OpenShift 4.20 e i principali miglioramenti. Per un elenco completo degli aggiornamenti e dei miglioramenti, consulta le note di rilascio ufficiali.

L'ultima versione migliora le capacità di gestione della piattaforma dei carichi di lavoro di IA, grazie alla disponibilità generale di LeaderWorkerSet, l'estensione di inferenza API Gateway e la sorgente del volume dell'immagine Open Container Initiative (OCI) di runtime. Anche alcune funzionalità di base sono state migliorate, ad esempio con la possibilità di utilizzare il provider di identità esterno esistente, Zero Trust Workload Identity Manager, lo spazio dei nomi utente, l'operatore External Secrets per Red Hat OpenShift e il supporto per il protocollo BGP (Border Gateway Protocol). OpenShift 4.20 introduce importanti novità relative alla virtualizzazione, come il bilanciamento del carico compatibile con la CPU e la migrazione in tempo reale più rapida. La piattaforma risulta pertanto più robusta e versatile per le diverse esigenze di elaborazione.

In OpenShift 4.20 è abilitato il meccanismo X25519MLKEM768 per lo scambio di chiavi ibride con la versione Go 1.24, un elemento del percorso verso l'introduzione del supporto per la crittografia post-quantistica. La novità migliora le comunicazioni TLS tra i componenti principali del piano di controllo di Kubernetes, come il server API, kubelet, lo scheduler e il controller-manager, proteggendoli dagli attacchi che sfruttano le capacità di calcolo quantistico.

Le ultime versioni Red Hat di Trusted Artifact Signer 1.3 e Trusted Profile Analyzer 2.2 combinano in modo efficace funzionalità di firma crittografica e analisi avanzata della catena di distribuzione.

Distribuisci e ridimensiona i carichi di lavoro AI/ML con LeaderWorkerSet e JobSet

OpenShift 4.20 semplifica il deployment dei carichi di lavoro di IA distribuiti e complessi. LeaderWorkerSet permette ai team dedicati alla piattaforma di distribuire e ridimensionare in modo efficiente i modelli di IA che superano la capacità di un singolo pod, avvalendosi di un pod leader che gestisce in modo lineare la comunicazione tra i pod di lavoro. Oltre a JobSet, disponibile in anteprima tecnologica e in grado di raggruppare e gestire i processi distribuiti con una pianificazione flessibile e la tolleranza agli errori, i team possono sfruttare GitOps, il controllo degli accessi basato sui ruoli (RBAC) e i modelli di monitoraggio efficienti anche per i flussi di lavoro di machine learning più esigenti. La combinazione di queste soluzioni facilita l'orchestrazione end to end dei carichi di lavoro di addestramento (JobSet) e di inferenza (LeaderWorkerSet) in modo scalabile, favorendo una gestione del ciclo di vita AI/ML robusta, scalabile ed efficiente in OpenShift.

Routing nativo dell'IA con Red Hat OpenShift AI 3

I carichi di lavoro di IA e di machine learning presentano alcune sfide specifiche, per le quali le tradizionali strategie di bilanciamento del carico, come il round robin, non sono adeguate. Red Hat OpenShift AI 3 permette di superare queste sfide grazie all'inferenza distribuita con llm-d e Kubernetes Gateway API Inference Extensions (GIE). Basato sull'API Kubernetes Gateway, GIE è incluso in OpenShift 4.20 per fornire routing e gestione del traffico specifiche per i carichi di lavoro AI/ML. Se hai già familiarità con l'API Kubernetes Gateway per le tue applicazioni, potrai applicare lo stesso approccio dichiarativo al model serving dei modelli di IA.

GIE diventa automaticamente disponibile in OpenShift 4.20 al momento della creazione di una risorsa InferencePool, ovvero un set di pod di inferenza AI/ML e un "selettore di endpoint" che contiene una logica di routing specializzata. Lo scheduler di inferenza llm-d, un componente di Red Hat OpenShift AI 3, seleziona gli endpoint acquisendo i dati di telemetria esposti da vLLM tramite il protocollo del server dei modelli, consentendo decisioni di routing più intelligenti basate sulla migliore istanza del modello disponibile in uno specifico momento.

GIE viene implementato tramite l'implementazione del gateway di Istio supportata dal proxy Envoy in OpenShift Service Mesh 3.2. Al momento, è supportato solo in Red Hat OpenShift AI 3. GIE permette di gestire i carichi di lavoro IA tramite gli stessi criteri RBAC e pipeline GitOps. Che si tratti del serving di un singolo modello o di orchestrare una complessa pipeline di inferenza multimodello, GIE trasforma quella che era in precedenza un'infrastruttura di IA specializzata in un percorso nel cluster.

Aggiorna i modelli di IA senza intervenire sui pod

Poiché gli LLM e i modelli di ML superano spesso i 10 GB, la ricompilazione dei container risulta più lenta e richiede più storage. Tuttavia, non è necessario ricostruire i container ogni volta che si aggiorna il modello di IA. OpenShift 4.20 permette di montare i pesi dei modelli come volumi direttamente dal registro dei container, in modo che i data scientist possano inviare le nuove versioni dei modelli al registro senza modificare i container utilizzati per il model serving. È sufficiente fare riferimento all'immagine OCI nelle specifiche del pod e lasciare che OpenShift si occupi del resto. I modelli diventano così artefatti controllabili con versioni separati dal codice, estratti su richiesta tramite l'autenticazione del registro, memorizzati nella cache locale per prestazioni più elevate e aggiornati senza interferire con i deployment.

Formula le tue richieste ai cluster OpenShift o Kubernetes in linguaggio naturale

Siamo lieti di annunciare l'anteprima per gli sviluppatori del server Kubernetes Model Context Protocol (MCP) per OpenShift e Kubernetes. Il server Kubernetes MCP rivoluziona la gestione dell'infrastruttura integrando gli assistenti IA, come VS Code, Microsoft Copilot e Cursor, con gli ambienti OpenShift e Kubernetes. Operazioni CRUD complete, gestione avanzata dei pod, integrazione Helm e deployment multipiattaforma sono le funzionalità che permettono a Kubernetes MCP di trasformare la gestione dei cluster e la risoluzione dei problemi permettendo la creazione di prompt in linguaggio naturale.

Con il server MCP è stato inoltre possibile integrare il rilevamento degli incidenti in OpenShift Lightspeed. L'analisi degli incidenti è ora possibile direttamente nell'interfaccia di conversazione, semplificando le modalità di analisi e risoluzione dei problemi del cluster.

Accelera i carichi di lavoro IA con le DPU NVIDIA Bluefield

Disponibile in anteprima tecnologica, Red Hat OpenShift insieme alle unità di elaborazione dati (DPU) NVIDIA Bluefield offre un approccio semplificato al deployment delle soluzioni per la sicurezza, il routing e lo storage dei carichi di lavoro per l'IA, le telecomunicazioni e aziendali. Elementi fondamentali della soluzione sono l'accelerazione hardware e l'isolamento della sicurezza per i carichi di lavoro dell'infrastruttura e delle applicazioni, che permettono di migliorare l'utilizzo delle risorse e di ottimizzare la capacità del server. Già parte integrante dei progetti Spectrum-X e AI factory di NVIDIA, nelle versioni future di OpenShift le DPU Bluefield permetteranno di semplificare il deployment e l'orchestrazione della soluzione Spectrum-X di NVIDIA e dei progetti di AI factory.

Semplifica la gestione delle identità con il supporto OIDC nativo

In OpenShift 4.20 è ora abilitata l'integrazione diretta con provider di identità OpenID Connect (OIDC) esterni per l'emissione dei token di autenticazione; la novità offre un maggiore controllo sui sistemi di autenticazione. L'integrazione diretta con un provider OIDC esterno permette di utilizzare le funzionalità avanzate del provider OIDC preferito, senza doversi limitare alle capacità del server OAuth integrato. Un'unica interfaccia permette quindi di gestire utenti e gruppi, semplificando l'autenticazione negli ambienti multicluster e ibridi.

Gestisci le identità dei carichi di lavoro con Zero Trust su OpenShift

Nelle prossime settimane, Zero Trust Workload Identity Manager sarà disponibile in OpenShift 4.20. un gestore che fornisce identità attestate al runtime e verificabili con crittografia per tutti i carichi di lavoro. Basato su SPIFFE/SPIRE, Zero Trust Workload Identity Manager offre funzionalità di base come la registrazione automatica dei carichi di lavoro, la federazione SPIRE-to-SPIRE per l'attendibilità universale negli ambienti ibridi e multicloud, la federazione OIDC per l'integrazione con i sistemi di identità aziendali esistenti e l'autenticazione senza segreti grazie all'integrazione di Hashicorp Vault.

Zero Trust Workload Identity Manager garantisce l'attendibilità universale, elimina i segreti statici e abilita identità verificabili di breve durata per una comunicazione incentrata tra carichi di lavoro sulla sicurezza. Le identità fornite sono coerenti e attestate in fase di runtime per tutti i carichi di lavoro cloud native, dai servizi tradizionali ai più recenti sistemi Agentic AI, e garantiscono responsabilità e tracciabilità per ogni azione dei carichi di lavoro; inoltre costituiscono la base per le architetture Zero Trust nell'intero panorama applicativo. Zero Trust Workload Identity Manager richiede le sottoscrizioni OpenShift Platform Plus, Red Hat Advanced Cluster Security for Kubernetes o Red Hat Advanced Cluster Management, per abilitare la gestione delle identità dei carichi di lavoro nel cloud quando viene utilizzato su più cluster. 

Semplifica la gestione dei segreti con External Secrets Operator

In OpenShift 4.20 è disponibile l'operatore per i segreti esterni per Red Hat OpenShift (ESO), un servizio per l'intero cluster che semplifica la gestione del ciclo di vita dei segreti recuperati da sistemi di gestione dei segreti esterni. L'integrazione con tali sistemi, come AWS Secrets Manager, HashiCorp Vault e Azure Key Vault permette a ESO di recuperare, aggiornare ed eseguire il provisioning dei segreti nel cluster, garantendo così un flusso più sicuro ed efficiente dei segreti sensibili senza interazione diretta con le applicazioni.

Elimina i rischi legati all'escalation dei privilegi dei container con gli spazi dei nomi utente

Con la disponibilità generale degli spazi dei nomi utente in OpenShift 4.20, Red Hat consente di eseguire i carichi di lavoro con un elevato livello di isolamento, mantenendo la flessibilità necessaria agli sviluppatori per creare applicazioni moderne. In OpenShift, gli spazi dei nomi utente migliorano notevolmente la sicurezza isolando gli utenti dei container dagli utenti degli host, riducendo il rischio di attacchi di escalation dei privilegi e consentendo l'esecuzione dei container come utenti non root sull'host, senza compromettere i privilegi root per le operazioni interne. Gli ambienti multitenant sono quindi più sicuri e la conformità agli standard di sicurezza aziendali è maggiore.

Service mesh senza sidecar con la modalità ambient di Istio

In OpenShift Service Mesh 3.2 è ora generalmente disponibile il supporto per la service mesh senza sidecar nella modalità ambient di Istio. Si tratta di un piano dati completamente nuovo per Istio che utilizza due livelli di proxy per abilitare le funzionalità della service mesh in base alle esigenze, con un utilizzo minimo di risorse aggiuntive. 

Il primo proxy è lo ztunnel a livello di nodo ("Z sta per Zero Trust"), che fornisce crittografia TLS reciproca di livello 4, telemetria e criteri di autorizzazione di base. Sebbene sia un proxy del nodo, reindirizza il traffico dall'interno dello spazio dei nomi di rete univoco di ciascun pod, garantendo l'isolamento e la crittografia del traffico a livello di pod. Il secondo è un proxy waypoint orientato all'applicazione, che può essere distribuito in modo facoltativo e che fornisce funzionalità mesh di livello 7, ad esempio la telemetria e criteri basati su specifiche dell'applicazione come i tipi di richiesta HTTP o le intestazioni. 

Questa architettura riduce in modo significativo i costi di esecuzione di una service mesh, in particolare per le funzionalità che richiedono solo il proxy ztunnel, come la crittografia mTLS da pod a pod. Per saperne di più, leggi Ottimizzare il traffico e l'osservabilità con OpenShift Service Mesh 3. 

Supporto BGP nativo in OpenShift Networking

Red Hat OpenShift Networking offre ora funzionalità native di routing BGP all'interno del proprio plug-in di rete predefinito, OVN-Kubernetes. Questo miglioramento estende notevolmente gli scenari di utilizzo della rete già supportati da MetalLB (bilanciamento del carico dei servizi esterni) e dall'operatore Cluster Network (infrastruttura di rete di livello 3, multihoming, ridondanza dei collegamenti e convergenza rapida). 

A partire da OpenShift 4.20, BGP consente di commercializzare le reti di pod e macchine virtuali (VM) personalizzate del cluster in una rete di provider compatibile con BGP, tramite il router BGP della rete esterna. È quindi possibile reimportare i percorsi appresi da BGP dalla rete del provider in OVN-Kubernetes, sia nella rete di pod predefinita sia in una specifica rete definita dall'utente (UDN). L'integrazione bidirezionale semplifica lo scambio dei percorsi tra OpenShift e le strutture di rete esterne. Il supporto è al momento disponibile per le piattaforme bare metal, mentre quello per le piattaforme cloud sarà disponibile in una versione successiva.

Per una migliore scalabilità, è possibile distribuire i route reflector tra il cluster e le reti esterne. Esempi capaci di illustrare la natura dinamica e i vantaggi della commercializzazione dei percorsi tramite BGP sono la migrazione di VM o un evento di failover. Una VM che esegue la migrazione a un altro nodo conserva il proprio indirizzo IP statico; la tabella BGP aggiorna in modo automatico e rapido il percorso commercializzato della rete della VM, garantendo la connettività continua con interruzioni minime.

Rileva i problemi prima di aggiornare il cluster

Due nuovi comandi in OpenShift 4.20 offrono agli utenti più visibilità sui potenziali problemi prima e durante gli aggiornamenti: sono i comandi oc adm upgrade recommend e oc adm upgrade status, ora disponibili. 

Prima di avviare un aggiornamento, il comando oc adm upgrade recommend analizza il cluster alla ricerca di avvisi noti, evidenziando quelli che indicano potenziali problemi, come eventuali limiti raggiunti da PodDisruptionBudget, operatori cluster non disponibili o il possibile rallentamento del drenaggio dei nodi. È possibile evidenziare le versioni disponibili nel canale di aggiornamento, eventuali problemi noti con tali versioni e, soprattutto, quali condizioni possono effettivamente incidere sul normale comportamento del cluster. 

$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION    ISSUES
4.18.32    no known issues relevant to this cluster
4.18.30    no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.

Dopo l'aggiornamento,oc adm upgrade status mostra agli utenti ciò che accade in tempo reale: l'avanzamento del piano di controllo e del nodo di lavoro, le percentuali di completamento, la stima delle tempistiche e eventuali avvisi di malfunzionamenti. Entrambi i comandi sono di sola lettura e non apportano modifiche al cluster OpenShift. Per saperne di più, leggi Aggiornare un cluster tramite la CLI.

Ottimizza i deployment all'edge con OpenShift a due nodi

Semplifica i deployment all'edge con OpenShift a due nodi con arbitraggio. Offre le stesse caratteristiche di alta disponibilità di un cluster OpenShift standard a tre nodi, ma richiede solo due server di dimensioni standard, integrati da un nodo di arbitraggio leggero per garantire il quorum minimo necessario. 

Il nodo di arbitraggio viene eseguito come terza istanza etcd per raggiungere il quorum con 2 sole vCPU e 8 GB di memoria. I due nodi standard gestiscono tutto il carico di lavoro effettivo, mentre le dimensioni inferiori del nodo di arbitraggio garantiscono che il cluster possa tollerare l'interruzione di un singolo nodo senza ridurre la disponibilità. Sono necessarie solo due sottoscrizioni bare metal e il nodo di arbitraggio non incide sui costi di licenza. Per saperne di più, leggi Un'efficiente infrastruttura edge a due nodi con Red Hat OpenShift e Portworx/Pure Storage.

Bilanciamento del carico compatibile e migrazione di VM più rapida con Red Hat OpenShift Virtualization 4.20

In Red Hat OpenShift Virtualization 4.20 è ora disponibile il bilanciamento del carico compatibile con la CPU, che migliora la distribuzione dei carichi di lavoro tra i nodi del cluster considerando in modo dinamico e in tempo reale l'utilizzo delle risorse dei nodi e la migrazione delle VM dai nodi sovrautilizzati a quelli con capacità disponibile.

OpenShift Virtualization semplifica inoltre la gestione delle VM con funzionalità multi-cluster e maggiore velocità di migrazione a OpenShift grazie al toolkit per la migrazione delle macchine virtuali che consente di sfruttare le funzionalità delle soluzioni dei principali fornitori di storage, alla migrazione in tempo reale a un nodo specifico e al supporto esteso per Arm. I miglioramenti alla rete, come il protocollo BGP per le reti L2 definite dall'utente, aumentano ulteriormente l'efficienza e la flessibilità dei carichi di lavoro virtualizzati.

Scalabilità dei carichi di lavoro di virtualizzazione in Oracle Cloud Infrastructure

Annunciamo la disponibilità generale di OpenShift Virtualization su istanze bare metal in Oracle Cloud Infrastructure. La soluzione offre ai nostri clienti comuni la flessibilità di eseguire i carichi di lavoro delle VM da qualsiasi posizione tramite il cloud distribuito di OCI. Per saperne di più, leggi Unlocking Virtualization at Scale: Red Hat OpenShift Virtualization Now Available on OCI.

Espandi OpenShift nei cloud sovrani Oracle

Infine, OpenShift estende il supporto per Oracle Cloud Infrastructure, una novità rivolta in particolare ai cloud sovrani come Oracle EU Sovereign Cloud, Oracle US Government Cloud, Oracle Cloud for UK Government & Defence, Oracle Cloud Isolated Regions e Oracle Alloy. Questo miglioramento garantisce maggiore flessibilità e possibilità di scelta per il deployment di OpenShift nei cloud progettati per soddisfare le esigenze critiche di sovranità dei dati, conformità normativa e sicurezza avanzata di ambienti cloud specializzati. Per saperne di più, leggi Supporto esteso per Oracle Cloud Infrastructure.

Prova subito Red Hat OpenShift 4.20

Inizia con Red Hat Hybrid Cloud Console e sfrutta le funzionalità e i miglioramenti più recenti di OpenShift. Per scoprire tutte le novità puoi consultare queste risorse:

• Video e presentazione sulle novità di Red Hat OpenShift
• Video sulle novità di Red Hat OpenShift 4.20
• Prova altre demo interattive di OpenShift 4.20
• Serie di video In the Clouds
• Canale YouTube di OpenShift
• Blog di OpenShift
• OpenShift Commons
• Blog degli sviluppatori Red Hat
• Portfolio Red Hat Architecture Center
• Modelli convalidati

Un elenco completo degli aggiornamenti di Red Hat OpenShift 4.20 è disponibile nelle Note di rilascio su OpenShift 4.20. Puoi inviarci commenti tramite i tuoi contatti Red Hat oppure creare un ticket su GitHub.