Red Hat lancia OpenShift 5 con operazioni agentiche per i cluster

Il 9 novembre 2026, in occasione di KubeCon + CloudNativeCon North America, Red Hat ha annunciato la disponibilità generale di OpenShift 5, introducendo la risoluzione agentica dei problemi e un’unica piattaforma operativa per carichi di lavoro IA, macchine virtuali e container. Questa versione basata su Kubernetes è disponibile per i clienti con abbonamenti esistenti tramite il Red Hat Customer Portal.

Red Hat affianca al rilascio un aggiornamento in-place da OpenShift 4.22 e un modello di supporto più lungo, affrontando due ostacoli operativi all’adozione di una nuova generazione della piattaforma. La panoramica tecnica evidenzia inoltre una distinzione importante: i flussi di lavoro agentici supervisionati fanno parte del rilascio, mentre la risoluzione autonoma dei problemi e un agente di aggiornamento sono ancora in anteprima tecnologica.

Operazioni agentiche con approvazione umana

OpenShift Lightspeed va oltre il suo precedente ruolo di assistente conversazionale: analizza gli avvisi e presenta in linguaggio naturale i risultati e le possibili procedure correttive. In modalità supervisionata, attende la conferma di un amministratore prima di apportare modifiche al cluster. La versione in anteprima autonoma può condurre indagini più approfondite per conto proprio, ma si ferma anch’essa per ottenere l’approvazione finale di una persona prima di eseguire le modifiche; nessuna delle due modalità, quindi, elimina il passaggio di approvazione dell’esecuzione.

Lo stesso modello operativo si applica anche alla manutenzione. Le indicazioni sugli aggiornamenti potenziate da Lightspeed mappano lo stato del cluster, i potenziali conflitti e l’ampiezza dell’impatto prima di una finestra di manutenzione, mentre i controlli preliminari valutano la compatibilità delle API e degli operatori facoltativi. Un pianificatore separato degli operatori riunisce le informazioni sullo stato del ciclo di vita, sulla compatibilità del cluster e sugli aggiornamenti disponibili. L’agente di aggiornamento in anteprima si spinge oltre, aiutando a pianificare ed eseguire i percorsi di aggiornamento.

Per collegare gli agenti ai servizi della piattaforma, il server OpenShift Model Context Protocol e il gateway MCP tramite Red Hat Connectivity Link sono generalmente disponibili. MCP offre un canale regolamentato attraverso il quale gli agenti possono accedere alle API e ai servizi della piattaforma. Gli amministratori possono anche generare dashboard di osservabilità Perses tramite una chat conversazionale, senza dover creare manualmente le query.

Sicurezza per l’IA e i cluster condivisi

OpenShift 5 integra diverse protezioni nelle impostazioni predefinite della piattaforma. La crittografia post-quantistica protegge le comunicazioni del piano di controllo, mentre la predisposizione al calcolo quantistico è integrata nelle immagini della piattaforma e nella configurazione TLS. Una policy TLS centralizzata e applicata in modo uniforme si estende a OpenShift Core e ai prodotti a più livelli; policy di rete personalizzate limitano inoltre il traffico in entrata e in uscita dai namespace degli operand del piano di controllo. La gestione automatizzata del ciclo di vita dei certificati e il supporto nativo per le distribuzioni disconnesse rispondono alle esigenze degli ambienti isolati, edge e regolamentati.

Per i carichi di lavoro IA, i container riservati crittografano i pesi dei modelli sia a riposo sia durante l’uso. La versione Red Hat di Agent Sandbox, anch’essa in anteprima tecnologica, usa i container in sandbox di OpenShift per eseguire i carichi di lavoro degli agenti all’interno di macchine virtuali, creando un perimetro concepito per impedire al codice non attendibile o autonomo di ottenere accesso senza restrizioni al resto del cluster. Questa protezione affronta il rischio che si crea quando gli agenti generano ed eseguono codice non verificato dagli amministratori.

Per gli ambienti eterogenei, OpenShift Virtualization 5 usa Lightspeed e l’integrazione MCP per il provisioning delle macchine virtuali in linguaggio naturale e l’automazione dei flussi di lavoro. Il backup incrementale indipendente dallo storage usa QEMU Change Block Tracking per copiare i blocchi modificati anziché le immagini complete dei dischi virtuali, mentre il bilanciamento del carico consapevole della memoria e lo swap nativo adeguano le allocazioni in base al consumo effettivo. Red Hat afferma inoltre che la suddivisione automatizzata delle risorse di calcolo GPU è progettata per migliorare l’utilizzo dell’hardware nei carichi di lavoro di inferenza IA e nelle applicazioni aziendali tradizionali.

Aggiornamenti in-place e cinque anni di supporto

Il percorso di aggiornamento non impone un cambiamento immediato del sistema operativo. I cluster aggiornati da OpenShift 4.22 restano su Red Hat Enterprise Linux CoreOS 9, mentre i nuovi cluster OpenShift 5.0 creati da zero usano per impostazione predefinita CoreOS 10. Red Hat prevede di consentire, in una versione futura, la coesistenza di nodi CoreOS 9 e CoreOS 10 nello stesso cluster: questa possibilità non è inclusa in OpenShift 5.0.

Red Hat sta definendo una cadenza triennale per le versioni principali, a circa un anno di distanza dalle versioni principali di Red Hat Enterprise Linux. Il supporto incluso dura 24 mesi, suddivisi in un anno di supporto completo e un anno di supporto per la manutenzione.

Red Hat prevede un rilascio con ciclo di vita esteso ogni anno, con cinque anni interi di supporto enterprise, grazie a un’estensione di tre anni oltre i periodi inclusi. Il ciclo di vita quinquennale copre anche operatori opzionali, tra cui Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines e OpenShift GitOps.

L’importanza immediata di OpenShift 5 sta nell’unire questo percorso di aggiornamento a un controllo operativo più rigoroso: i cluster OpenShift 4.22 possono essere aggiornati in-place, ma le funzioni più autonome della piattaforma richiedono ancora un’approvazione e restano in anteprima. Il rilascio porta quindi l’assistenza agentica nella gestione dei cluster di produzione senza rendere predefinita l’esecuzione autonoma, mentre il ciclo di vita più lungo offre ai team infrastrutturali maggiore margine per coordinare le operazioni relative a IA, macchine virtuali e container.