Red Hat lance OpenShift 5 et ses opérations de cluster agentiques

Red Hat a annoncé la disponibilité générale d’OpenShift 5 le 9 novembre 2026, à l’occasion de KubeCon + CloudNativeCon North America. Cette version apporte le dépannage agentique et une plateforme opérationnelle unifiée pour les charges de travail d’IA, les machines virtuelles et les conteneurs. Cette version basée sur Kubernetes est accessible aux clients disposant d’abonnements actifs depuis le Red Hat Customer Portal.

Red Hat accompagne cette version d’une mise à niveau sur place depuis OpenShift 4.22 et d’un modèle de support plus long, répondant ainsi à deux obstacles opérationnels à l’adoption d’une nouvelle génération de plateforme. Son aperçu technique souligne également une distinction importante : les flux de travail agentiques supervisés font partie de la version, tandis que le dépannage autonome et un agent de mise à niveau restent en préversion technologique.

Opérations agentiques avec approbation humaine

OpenShift Lightspeed dépasse son rôle précédent d’assistant conversationnel : il enquête sur les alertes et présente en langage naturel ses conclusions ainsi que des pistes de remédiation. En mode supervisé, il attend la confirmation d’un administrateur avant de modifier le cluster. La préversion autonome peut mener des investigations plus approfondies de manière indépendante, mais elle s’arrête également pour obtenir l’approbation finale d’un humain avant d’appliquer des changements ; aucun des deux modes ne supprime donc cette étape de validation avant exécution.

Le même modèle opérationnel s’étend à la maintenance. Les recommandations de mise à niveau enrichies par Lightspeed dressent un état des lieux du cluster, des conflits potentiels et du rayon d’impact avant une fenêtre de maintenance, tandis que les vérifications préalables évaluent la compatibilité des API et des opérateurs facultatifs. Un planificateur d’opérateurs distinct regroupe l’état du cycle de vie, la compatibilité du cluster et les mises à niveau disponibles. L’agent de mise à niveau en préversion va plus loin en aidant à planifier et à exécuter les parcours de mise à niveau.

Pour connecter les agents aux services de la plateforme, le serveur OpenShift Model Context Protocol et la passerelle MCP via Red Hat Connectivity Link sont disponibles de manière générale. MCP fournit un canal gouverné permettant aux agents d’accéder aux API et aux services de la plateforme. Les administrateurs peuvent également générer des tableaux de bord d’observabilité Perses par le biais d’un dialogue conversationnel, sans avoir à rédiger manuellement des requêtes.

Sécurité pour l’IA et les clusters partagés

OpenShift 5 intègre plusieurs protections par défaut à la plateforme. La cryptographie post-quantique protège les communications du plan de contrôle, tandis que la préparation à l’informatique quantique est intégrée aux images de la plateforme et à la configuration TLS. Une politique TLS centralisée et appliquée à l’ensemble d’OpenShift et des produits complémentaires, ainsi que des politiques réseau adaptées, restreignent le trafic entrant et sortant des espaces de noms des opérandes du plan de contrôle. La gestion automatisée du cycle de vie des certificats et la prise en charge native des déploiements en environnement déconnecté répondent aux besoins des environnements isolés, de la périphérie et des secteurs réglementés.

Pour les charges de travail d’IA, les conteneurs confidentiels chiffrent les poids des modèles au repos et en cours d’utilisation. La version Red Hat d’Agent Sandbox, également en préversion technologique, s’appuie sur les conteneurs sandboxés d’OpenShift pour exécuter les charges de travail des agents à l’intérieur de machines virtuelles. Elle crée ainsi une limite destinée à empêcher le code non fiable ou autonome d’obtenir un accès sans restriction au reste du cluster. Cette protection répond au risque lié à la génération et à l’exécution par les agents de code que les administrateurs n’ont pas examiné.

Pour les environnements hétérogènes, OpenShift Virtualization 5 s’appuie sur Lightspeed et l’intégration MCP pour provisionner des machines virtuelles en langage naturel et automatiser les flux de travail. La sauvegarde incrémentielle indépendante du stockage utilise QEMU Change Block Tracking pour copier les blocs modifiés plutôt que des images complètes de disques virtuels, tandis que l’équilibrage de charge tenant compte de la mémoire et le swap natif ajustent les allocations en fonction de la consommation réelle. Red Hat indique également que son découpage automatisé des ressources de calcul des GPU vise à améliorer l’utilisation du matériel pour l’inférence en IA comme pour les charges de travail d’entreprise traditionnelles.

Mises à niveau sur place et support de cinq ans

Le parcours de mise à niveau n’impose pas de changer immédiatement de système d’exploitation. Les clusters mis à niveau depuis OpenShift 4.22 restent sous Red Hat Enterprise Linux CoreOS 9, tandis que les nouveaux clusters OpenShift 5.0 utilisent CoreOS 10 par défaut. Red Hat prévoit de permettre aux nœuds CoreOS 9 et CoreOS 10 de coexister au sein d’un même cluster dans une version ultérieure ; cette possibilité ne fait pas partie des fonctionnalités d’OpenShift 5.0.

Red Hat met en place une cadence de versions majeures tous les trois ans, environ un an après les versions majeures de Red Hat Enterprise Linux. Le support inclus dure 24 mois, répartis entre un an de support complet et un an de support de maintenance.

Red Hat prévoit une version à cycle de vie prolongé par an, bénéficiant de cinq années complètes de support entreprise grâce à une extension de trois ans au-delà des périodes incluses. Ce cycle de vie de cinq ans couvre également des opérateurs facultatifs, notamment Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines et OpenShift GitOps.

L’importance immédiate d’OpenShift 5 tient à l’association de ce parcours de mise à niveau et d’un contrôle opérationnel renforcé : les clusters OpenShift 4.22 peuvent être mis à niveau sur place, mais les fonctions les plus autonomes de la plateforme nécessitent toujours une approbation et restent en préversion. La version intègre donc une assistance agentique à la gestion des clusters de production sans faire de l’exécution autonome le comportement par défaut, tandis que le cycle de vie prolongé donne aux équipes d’infrastructure davantage de latitude pour coordonner les opérations liées à l’IA, aux machines virtuelles et aux conteneurs.