Présentée à KubeCon 2025, la version 4.20 d’OpenShift consolide la plateforme hybride de Red Hat autour de la cybersécurité, de la virtualisation et de l’IA. L’éditeur y voit une réponse à la montée des exigences réglementaires et à la nécessité d’un contrôle accru sur les données et les infrastructures cloud.
OpenShift est la plateforme d’orchestration de conteneurs développée par Red Hat, basée sur Kubernetes, qui permet de déployer, gérer et automatiser des applications sur des environnements hybrides et multicloud. Conçue pour les entreprises, elle unifie la gestion des conteneurs, des machines virtuelles et des workloads d’intelligence artificielle au sein d’une même infrastructure.
Sa force réside dans son intégration étroite avec Linux et RHEL, son outillage complet pour le DevOps (CI/CD, sécurité, observabilité) et son support commercial, ce qui en fait aujourd’hui une vraie référence du cloud hybride. Selon IDC et Gartner, Red Hat OpenShift occupe autour de 45 % du marché des plateformes Kubernetes d’entreprise, devant VMware Tanzu, Nutanix Kubernetes Platform et Google Anthos, et reste la solution la plus déployée dans les environnements réglementés ou souverains.
Autant dire que l’arrivée d’une mise à jour majeure intrigue et attire les regards.
Présentée à KubeCon 2025, OpenShift 4.20 vise à consolider la sécurité, à mieux encadrer les déploiements d’intelligence artificielle et à étendre la compatibilité avec les clouds dits souverains.
Dans un contexte où les DSI doivent conjuguer conformité, performance et souveraineté numérique, Red Hat met l’accent sur la cohérence entre datacenters privés, clouds publics et infrastructures en périphérie. L’objectif est d’offrir une base unifiée capable de supporter des workloads d’IA en production tout en garantissant un contrôle strict des identités, des flux et des secrets applicatifs.
La sécurité au cœur de la mise à jour
Ainsi, OpenShift 4.20 introduit la prise en charge préliminaire de la cryptographie post-quantique pour le chiffrement mTLS, anticipant les menaces à long terme sur les communications sensibles.
La version intègre également Red Hat Advanced Cluster Security 4.9, ainsi que de nouveaux outils dénommés Trusted Artifact Signer (signe et vérifie l’intégrité des composants logiciels pour garantir qu’ils proviennent de sources fiables avant leur déploiement) et Trusted Profile Analyzer (analyse et valide les profils de sécurité des systèmes et applications afin de détecter les écarts de conformité et renforcer la posture de cybersécurité) destinés à renforcer la vérification des composants logiciels et l’analyse de conformité.
Red Hat permet aux clients d’utiliser leur propre OpenID Connect pour mieux contrôler les identités, et réduit les coûts grâce à un mode Service Mesh « sidecar-less » qui évite la surcharge réseau du chiffrement entre pods.
Une option de déploiement en deux nœuds avec arbitre vise les sites contraints, en offrant de la haute disponibilité sans gonfler l’infrastructure.
De l’expérimentation à la production des workloads d’IA
Et parce que toute plateforme est destinée désormais à héberger de l’IA sous une forme ou sous une autre, OpenShift se muscle en la matière.
La nouvelle API LeaderWorkerSet simplifie l’orchestration de charges d’IA distribuées. Elle formalise le schéma « chef-orchestre / travailleurs » typique des entraînements et inférences distribués : la plateforme sait créer, surveiller et remplacer automatiquement le nœud leader, faire varier le nombre de workers en fonction de la charge et relancer proprement les tâches en cas de défaillance d’un pod ou d’un nœud. Cette gestion native réduit le code ad hoc dans les jobs d’IA, limite les erreurs de coordination et facilite l’observabilité, ce qui raccourcit le chemin entre un notebook et un run reproductible en cluster.
Autre nouveauté, la fonctionnalité Image Volume Source réduit le temps de déploiement des modèles. Au lieu de reconstruire une image de conteneur à chaque nouveau modèle, OpenShift peut monter un volume d’image pré-préparé contenant poids et artefacts, puis lancer les pods en quelques minutes. La latence de mise en production est ainsi réduite tout comme la charge sur les registres d’images et les temps de « cold start » lors des mises à l’échelle.
Combinées, ces capacités rendent les pipelines MLOps plus prévisibles et auditables, ce qui aide les DSI à basculer des POC vers des services d’IA industrialisés, tout en gardant le contrôle sur les coûts, la conformité et les performances.
Autre nouveauté, le désormais célèbre et incontournable protocole MCP envahit même une plateforme fondation comme OpenShift. Selon Red Hat, l’intégration du Model Context Protocol permet aussi aux développeurs d’administrer les clusters OpenShift directement depuis des environnements tels que Visual Studio Code, signalant une volonté d’aligner la plateforme sur les pratiques modernes du DevOps.
Virtualisation unifiée et contrôle de l’infrastructure
OpenShift 4.20 pousse un peu plus l’idée d’une couche d’infrastructure unique où machines virtuelles et conteneurs partagent le même plan de contrôle, le même réseau, les mêmes politiques et les mêmes chaînes CI/CD. OpenShift Virtualization, basé sur KubeVirt, permet d’orchestrer des VM comme des pods, d’appliquer les mêmes règles de sécurité et d’observabilité, et d’opérer des migrations progressives d’applications sans imposer une réécriture immédiate.
Un rééquilibrage automatique de la charge CPU fait son apparition afin de limiter les effets de voisinage bruyant et les pics imprévus. Le scheduler détecte les hôtes saturés, déplace ou redimensionne les workloads et s’appuie sur la migration à chaud des VM pour préserver les SLO sans interruption perceptible. À la clé, une utilisation plus homogène des sockets et des cœurs, une meilleure affinité NUMA et moins de dette opérationnelle lors des montées en charge.
La très attendue compatibilité ARM ouvre des scénarios où le ratio performance par watt et le coût à l’échelle priment. Télécoms, edge computing, retail ou IoT peuvent faire tourner des VM et des conteneurs sur des nœuds ARM tout en conservant les mêmes pipelines et la même gouvernance que sur x86. Les images multi-architecture et les opérateurs certifiés facilitent la portabilité entre sites et architectures.
Enfin, OpenShift 4.20 officialise aussi la prise en charge des déploiements bare metal dans Oracle Cloud avec un contrôle fin sur les ressources physiques. Au menu de ce support officiel, un accès direct aux cartes réseau haut débit, aux GPU et aux volumes NVMe, des latences prévisibles, moins de couches d’abstraction, et une meilleure maîtrise de la localisation des données. Pour les DSI adeptes d’OCI, cette combinaison VM plus conteneurs sur bare metal réduit le compromis entre performance, isolation et conformité, tout en gardant une expérience d’exploitation unifiée.
Toutes ces évolutions traduisent une volonté de faire d’OpenShift un pivot unique pour les environnements cloud hybrides, où cohabitent infrastructures historiques et workloads modernes alors que nombre de DSI remettent désormais en cause leur choix VMware.
Une réponse aux exigences de souveraineté numérique
En mettant l’accent sur la cryptographie post-quantique, la gestion des identités et la virtualisation souveraine, Red Hat tente de positionner OpenShift 4.20 comme une réponse technologique aux contraintes réglementaires croissantes. Pour être tout à fait honnêtes, la concurrence qu’il s’agisse de VMware by Broadcom, de Nutanix Cloud (NKP), de SUSE Rancher ou Google Distributed Cloud (ex Anthos) explore des voies similaires, mais Red Hat conserve un avantage historique grâce à ses parts de marché, la puissance d’IBM, sa maîtrise de l’open source et son écosystème communautaire.
Bref, Red Hat continue d’empiler les atouts au cœur de son OpenShift s’affranchissant des contraintes des releases officielles de Kubernetes (OpenShift 4.20 s’appuie sur Kubernetes 1.33 et sur le moteur d’exécution de containers de Red Hat « CRI-O » en version 1.33) pour mieux satisfaire les besoins de ses DSI clientes. Et jusqu’ici cela lui réussit bien…
puis