Red Hat OpenShift 4.20 accélère la virtualisation et l'innovation dans le domaine de l'IA pour les entreprises

Red Hat OpenShift 4.20 est maintenant disponible. Cette version est basée sur Kubernetes 1.33 et CRI-O 1.33. Associée à Red Hat OpenShift Platform Plus, elle souligne notre volonté de fournir une plateforme d'applications fiable, complète et cohérente. Sur OpenShift, les charges de travail d'IA, les conteneurs et les systèmes virtualisés coexistent en harmonie, ce qui permet aux entreprises d'innover plus rapidement dans le cloud hybride, sans compromettre la sécurité.

Disponible sous forme de service cloud autogéré ou entièrement géré, la plateforme d'applications OpenShift comprend une gamme complète d'outils et de services intégrés pour les charges de travail cloud-native, virtuelles, traditionnelles et d'IA. Cet article présente les dernières innovations d'OpenShift 4.20 ainsi que ses principales améliorations. Pour une liste complète des mises à jour, consultez les notes de version d'OpenShift 4.20.

Cette nouvelle version améliore le fonctionnement des charges de travail d'IA sur la plateforme grâce à la disponibilité générale de l'opérateur LeaderWorkerSet, du projet Gateway API Inference Extension et de la source de volume d'image OCI (Open Container Initiative). Elle renforce les fonctionnalités de base avec des ajouts essentiels, tels que la possibilité d'utiliser son propre fournisseur d'identité externe, l'opérateur Zero Trust Workload Identity Manager, un espace de noms d'utilisateurs, l'opérateur External Secrets Operator pour Red Hat OpenShift et le protocole de routage BGP (Border Gateway Protocol). OpenShift 4.20 inclut également d'importantes avancées en matière de virtualisation, comme le rééquilibrage en fonction de la charge du processeur et l'accélération de la migration à chaud. La plateforme est ainsi plus robuste et s'adapte à divers besoins informatiques.

Dans la continuité de nos efforts pour prendre en charge la cryptographie post-quantique, OpenShift 4.20 est désormais compatible avec le mécanisme d'échange de clés hybrides X25519MLKEM768 avec la version 1.24 de Go. Cette technologie améliore les communications TLS entre les principaux composants du plan de contrôle Kubernetes (serveur d'API, kubelet, ordonnanceur, controller-manager, etc.) et contribue à les protéger contre les attaques quantiques.

Nos récentes versions 1.3 de Trusted Artifact Signer et 2.2 de Trusted Profile Analyzer offrent une puissante combinaison de fonctionnalités de signature cryptographique et d'analyse avancée de la chaîne d'approvisionnement.

Distribution et mise à l'échelle des charges de travail d'IA/AA avec LeaderWorkerSet et JobSet

La version 4.20 d'OpenShift simplifie le déploiement des charges de travail d'IA distribuées complexes. Avec la disponibilité générale de LeaderWorkerSet, les équipes chargées de la plateforme peuvent distribuer et mettre à l'échelle efficacement les modèles d'IA qui dépassent la capacité d'un seul pod, en utilisant un pod principal pour orchestrer en toute simplicité la communication entre les pods de calcul. De plus, l'opérateur JobSet (disponible en version préliminaire), qui regroupe et gère les tâches distribuées avec un ordonnancement flexible et une tolérance aux pannes, permet aux équipes de tirer parti des processus GitOps habituels, du contrôle d'accès basé sur les rôles et de modèles de surveillance pour tous les workflows d'apprentissage automatique (AA), même les plus exigeants. Ensemble, ces outils aident à orchestrer de bout en bout les charges de travail d'entraînement (JobSet) et d'inférence (LeaderWorkerSet) à grande échelle, pour assurer une gestion robuste, efficace et évolutive du cycle de vie d'IA/AA sur OpenShift.

Routage d'IA natif avec Red Hat OpenShift AI 3

Les charges de travail d'IA et d'AA posent des défis uniques qui compliquent les stratégies d'équilibrage de charge traditionnelles, telles que le « round-robin ». Red Hat OpenShift AI 3 résout ces problèmes grâce à l'inférence distribuée basée sur llm-d et le projet Kubernetes Gateway API Inference Extensions (GIE). OpenShift 4.20 inclut GIE et s'appuie sur l'API Kubernetes Gateway afin de fournir des fonctionnalités spécialisées de routage et de gestion du trafic pour les charges de travail d'IA/AA. Si vous utilisez déjà cette API pour vos applications, vous pouvez désormais appliquer la même approche déclarative à la mise à disposition des modèles d'IA.

GIE s'active automatiquement dans OpenShift 4.20 à la création d'une ressource InferencePool, qui rassemble des pods d'inférence d'IA ou d'AA ainsi qu'un outil de sélection de point de terminaison suivant une logique de routage spécialisée. Composant de Red Hat OpenShift AI 3, l'ordonnanceur d'inférence llm-d permet d'effectuer cette sélection. Il capture les données de télémétrie qu'expose vLLM à l'aide du protocole de serveur de modèles et aide ainsi à établir un routage intelligent en fonction de la meilleure instance de modèle disponible à un moment donné.

La mise en œuvre de GIE passe par celle de la passerelle d'Istio qui s'appuie sur le proxy Envoy via OpenShift Service Mesh 3.2. Actuellement, il n'est possible de l'utiliser qu'avec Red Hat OpenShift AI 3. GIE vous permet de gérer les charges de travail d'IA à l'aide des mêmes pipelines GitOps et politiques de contrôle d'accès basé sur les rôles. Que ce soit pour mettre à disposition un seul modèle ou orchestrer un pipeline d'inférence complexe à plusieurs modèles, avec GIE votre l'infrastructure d'IA devient une simple route au sein du cluster.

Mise à jour des modèles d'IA sans toucher aux pods

Souvent, les LLM et les modèles d'AA dépassent les 10 Go, ce qui ralentit le réassemblement des conteneurs et augmente les besoins de stockage. Désormais, vous n'avez plus à recréer les conteneurs à chaque mise à jour de votre modèle d'IA. Dans OpenShift 4.20, vous pouvez charger les pondérations de modèle directement à partir de votre registre de conteneurs, sous la forme de volumes. Ainsi, les data scientists peuvent envoyer de nouvelles versions du modèle au registre sans modifier les conteneurs de mise à disposition des modèles. Il vous suffit d'ajouter l'image OCI dans la spécification de votre pod. OpenShift gère le reste. Les modèles deviennent alors des artéfacts versionnables, distincts du code. Ils sont extraits à la demande à l'aide des mécanismes habituels d'authentification au registre, mis en cache localement pour améliorer les performances et mis à jour sans toucher aux déploiements.

Communication en langage naturel avec les clusters OpenShift ou Kubernetes

Nous avons le plaisir d'annoncer la version préliminaire pour les développeurs du serveur Kubernetes Model Context Protocol (MCP) pour OpenShift et Kubernetes, qui révolutionne la gestion de l'infrastructure en reliant les assistants d'IA, tels que VS Code, Microsoft Copilot et Cursor, aux environnements OpenShift et Kubernetes. Avec des tâches CRUD complètes, une gestion avancée des pods, une intégration Helm et un déploiement sur plusieurs plateformes, le serveur Kubernetes MCP transforme la gestion des clusters et la résolution des problèmes par le biais de requêtes en langage naturel.

Nous avons aussi intégré la détection des incidents à OpenShift Lightspeed avec MCP. Ainsi, l'analyse des incidents s'effectue directement dans l'interface conversationnelle, ce qui change la façon dont vous appréhendez et résolvez les problèmes de cluster.

Accélération des charges de travail d'IA avec les DPU NVIDIA Bluefield

Disponibles ensemble en version préliminaire, Red Hat OpenShift et les unités de traitement de données (DPU) NVIDIA Bluefield offrent une approche simplifiée du déploiement des solutions de sécurité, de routage et de stockage pour les charges de travail d'IA, de télécommunications et d'entreprise. Cette solution cible l'accélération du matériel et l'isolation sécurisée pour les charges de travail de l'infrastructure et des applications, ce qui optimise l'utilisation des ressources et la capacité du serveur. Les DPU Bluefield font partie intégrante de Spectrum-X et des conceptions AI Factory de NVIDIA, dont le déploiement et l'orchestration devraient être facilités par les futures versions d'OpenShift.

Prise en charge native d'OIDC pour rationaliser la gestion des identités

OpenShift 4.20 permet désormais une intégration directe aux fournisseurs d'identité OIDC (OpenID Connect) externes afin d'émettre des jetons textuels pour l'authentification, ce qui améliore le niveau de contrôle sur les systèmes d'authentification. En intégrant directement un fournisseur OIDC externe, vous pouvez tirer parti des fonctionnalités avancées du fournisseur de votre choix au lieu de vous limiter à celle du serveur OAuth intégré. Votre entreprise peut gérer des utilisateurs et des groupes à partir d'une seule interface, tout en rationalisant l'authentification dans plusieurs clusters et dans les environnements hybrides.

Gestion des identités de charges de travail avec le modèle Zero Trust sur OpenShift

La disponibilité générale de Zero Trust Workload Identity Manager est prévue dans les semaines à venir pour OpenShift 4.20. Cet opérateur fournit des identités vérifiées au moment de l'exécution et vérifiables par chiffrement pour toutes les charges de travail. Basé sur SPIFFE/SPIRE, Zero Trust Workload Identity Manager inclut des fonctionnalités essentielles, telles que l'enregistrement automatique des charges de travail, la fédération de SPIRE à SPIRE pour établir la confiance dans les environnements hybrides et multicloud, la fédération OIDC pour l'intégration aux systèmes d'identités d'entreprise, ainsi que l'authentification sans secret grâce à l'intégration Hashicorp Vault.

L'opérateur Zero Trust Workload Identity Manager établit la confiance, élimine les secrets statiques et permet d'utiliser des identités vérifiables temporaires pour sécuriser la communication entre les charges de travail. Il fournit des identités cohérentes et vérifiées pendant l'exécution pour l'ensemble des charges de travail cloud-native, des services traditionnels aux nouveaux systèmes d'IA agentique, assurant ainsi la responsabilité et la traçabilité de chaque action qu'effectuent les charges de travail. Il est à la base des architectures Zero Trust dans tout l'environnement d'applications. Pour gérer les identités de charges de travail dans plusieurs clouds avec Zero Trust Workload Identity Manager, en cas d'utilisation avec plusieurs clusters, vous devez disposer d'une souscription pour OpenShift Platform Plus, Red Hat Advanced Cluster Security for Kubernetes ou Red Hat Advanced Cluster Management. 

Rationalisation de la gestion des secrets avec External Secrets Operator

L'opérateur External Secrets Operator (ESO) pour Red Hat OpenShift est désormais disponible dans OpenShift 4.20. Ce service à l'échelle du cluster offre un moyen de gérer le cycle de vie des secrets récupérés à partir de systèmes externes de gestion des secrets. En s'intégrant à des systèmes externes comme AWS Secrets Manager, HashiCorp Vault et Azure Key Vault, ESO est capable de récupérer, d'actualiser et de provisionner les secrets au sein du cluster. Ainsi, les secrets sensibles circulent de manière plus sûre et plus efficace entre les charges de travail, sans intervention directe des applications.

Suppression des risques d'augmentation des privilèges des conteneurs grâce aux espaces de noms d'utilisateurs

La disponibilité générale des espaces de noms d'utilisateurs dans OpenShift 4.20 permet d'exécuter les charges de travail en améliorant l'isolation et en conservant la flexibilité dont les équipes de développement ont besoin pour créer des applications modernes. Les espaces de noms d'utilisateurs dans OpenShift renforcent considérablement la sécurité en isolant les utilisateurs de conteneurs des utilisateurs hôtes, en réduisant le risque d'attaques liées à l'augmentation des privilèges et en exécutant les conteneurs comme utilisateurs non root sur l'hôte avec des privilèges root internes pour l'exploitation. Les environnements multiclients sont ainsi plus sécurisés et respectent davantage les normes de sécurité de l'entreprise.

Utilisation de Service Mesh sans sidecars avec le mode ambiant d'Istio

OpenShift Service Mesh 3.2 marque la disponibilité générale de Service Mesh sans sidecars grâce au mode ambiant d'Istio. Il s'agit d'un tout nouveau plan de données pour Istio qui utilise deux niveaux de proxy pour activer les fonctions de Service Mesh selon les besoins, avec très peu de ressources supplémentaires. 

Le premier proxy, ztunnel (avec « z » pour « Zero Trust »), se trouve au niveau du nœud. Il fournit le chiffrement TLS mutuel de la couche 4, la télémétrie et les politiques d'autorisation de base. Même s'il s'agit d'un proxy de nœud, il redirige le trafic depuis l'espace de noms réseau unique de chaque pod, ce qui assure son isolement et son chiffrement au niveau du pod. L'autre proxy, waypoint, est orienté applications. Il est possible de le déployer pour bénéficier des fonctions de maillage de couche 7, telles que la télémétrie et les politiques basées sur certains éléments, comme les types ou les titres de requête HTTP. 

Cette architecture réduit considérablement les coûts des ressources associés à l'exécution de Service Mesh, en particulier pour les fonctions qui nécessitent uniquement le proxy ztunnel, comme le chiffrement mTLS de pod à pod. Pour en savoir plus, consultez la page sur l'optimisation du trafic et de l'observabilité avec OpenShift Service Mesh 3. 

Utilisation de BGP en natif dans OpenShift Networking

Red Hat OpenShift Networking fournit désormais des fonctionnalités natives de routage BGP avec son plug-in réseau par défaut, OVN-Kubernetes. Cette amélioration enrichit considérablement les cas d'utilisation réseau qu'offraient jusqu'ici MetalLB (équilibrage de charge de service externe) et l'opérateur de réseau en cluster (fabric réseau de couche 3, multihébergement, redondance des liens et convergence rapide). 

À partir d'OpenShift 4.20, BGP permet aux réseaux de pods et de machines virtuelles à l'échelle du cluster d'être directement présentés au réseau d'un opérateur compatible BGP via le routeur BGP du réseau externe. À l'inverse, les routes BGP propres au réseau de l'opérateur peuvent être réintégrées dans OVN-Kubernetes, soit dans le réseau de pods par défaut, soit dans un réseau UDN (User-Defined Network) spécifique. Cette intégration bidirectionnelle facilite le partage des routes entre les environnements OpenShift et les fabrics réseau externes. Dans un premier temps, seules les plateformes bare metal seront prises en charge. Les plateformes cloud seront ajoutées dans une version ultérieure.

Pour améliorer l'évolutivité, le cluster et les réseaux externes peuvent être reliés par des réflecteurs de route. La migration ou le basculement d'une machine virtuelle illustre bien la nature dynamique et les avantages de la présentation des routes selon le protocole BGP. Lorsqu'une machine virtuelle est transférée vers un autre nœud, elle conserve son adresse IP statique tandis que la table BGP met automatiquement et rapidement à jour la route présentée pour le réseau de cette machine virtuelle, ce qui assure la continuité de la connectivité en limitant les perturbations.

Détection des problèmes avant la mise à jour du cluster

Dans OpenShift 4.20, deux nouvelles commandes offrent une visibilité sur les problèmes potentiels avant et pendant les mises à jour. Les commandes oc adm upgrade recommend et oc adm upgrade status sont désormais disponibles. 

Avant le début d'une mise à jour, la commande oc adm upgrade recommend analyse le cluster à la recherche d'alertes connues. Elle affiche celles qui entraînent des problèmes : limites atteintes pour PodDisruptionBudgets, opérateurs de cluster indisponibles ou ralentissements de l'élimination des nœuds. Vous pourrez consulter les versions disponibles dans votre canal de mise à jour, les problèmes connus avec ces versions et, surtout, les conditions qui posent problème par rapport au comportement normal du 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'.

Après la mise à jour, la commande oc adm upgrade status indique ce qui se passe en temps réel : la progression du plan de contrôle et du nœud de calcul, les pourcentages d'achèvement, les estimations de durée et les éventuels blocages. Les deux commandes sont en lecture seule et ne modifient rien dans le cluster OpenShift. Pour en savoir plus, consultez la page d'instructions pour la mise à jour d'un cluster à l'aide d'une interface en ligne de commande.

Optimisation des déploiements d'edge computing avec OpenShift à deux nœuds

Rationalisez vos déploiements d'edge computing avec la topologie OpenShift à deux nœuds avec arbitre. Cette configuration fournit les mêmes caractéristiques de haute disponibilité qu'un cluster OpenShift standard à trois nœuds, mais ne nécessite que deux serveurs complets et un nœud arbitre léger pour assurer le quorum. 

Le nœud arbitre s'exécute comme une troisième instance etcd pour vérifier le quorum, avec seulement deux processeurs virtuels et 8 Go de mémoire. Dans cette topologie, les deux nœuds complets gèrent la charge de travail réelle, tandis que l'arbitre garantit que le cluster peut tolérer la panne d'un nœud sans perte de disponibilité. Seules deux souscriptions bare metal sont nécessaires et le nœud arbitre ne génère aucuns frais de licence. Pour en savoir plus, lisez l'article sur la création d'une infrastructure d'edge computing à deux nœuds efficace avec Red Hat OpenShift et Portworx/Pure Storage.

Rééquilibrage en fonction de la charge et accélération de la migration des machines virtuelles dans Red Hat OpenShift Virtualization 4.20

Le rééquilibrage en fonction de la charge du processeur dans Red Hat OpenShift Virtualization 4.20 est désormais disponible. Cette fonctionnalité améliore la distribution des charges de travail sur les nœuds du cluster. Elle tient compte de l'utilisation des ressources en temps réel par les nœuds et migre les machines virtuelles depuis les nœuds surutilisés vers d'autres plus disponibles.

OpenShift Virtualization simplifie également la gestion des machines virtuelles grâce à des fonctionnalités pour les clusters multiples, accélère la migration vers OpenShift grâce à la fonctionnalité d'allègement du stockage de la boîte à outils de migration pour la virtualisation (incluse dans les solutions des principaux fournisseurs de stockage), introduit la migration à chaud vers un nœud spécifique et étend la prise en charge de l'architecture ARM. Les améliorations apportées à la mise en réseau, telles que le protocole BGP pour les réseaux L2 définis par l'utilisateur, augmentent encore l'efficacité et la flexibilité des charges de travail virtualisées.

Mis à l'échelle des charges de travail de virtualisation dans Oracle Cloud Infrastructure

Le composant OpenShift Virtualization est désormais disponible sur les instances bare metal dans Oracle Cloud Infrastructure. Nos clients communs bénéficient ainsi de la flexibilité nécessaire pour exécuter leurs charges de travail de machines virtuelles où qu'ils se trouvent via le cloud distribué d'Oracle Cloud Infrastructure. Pour en savoir plus, consultez la page consacrée à la virtualisation à grande échelle sur Oracle Cloud Infrastructure.

OpenShift sur les clouds souverains Oracle

Enfin, OpenShift étend sa prise en charge à Oracle Cloud Infrastructure, en particulier aux clouds souverains comme Oracle EU Sovereign Cloud, Oracle US Government Cloud, Oracle Cloud for UK Government & Defence, Oracle Cloud Isolated Regions et Oracle Alloy. Cette amélioration offre plus de flexibilité et de choix pour déployer OpenShift dans des clouds qui respectent les impératifs en matière de souveraineté des données, de conformité réglementaire et de sécurité au sein d'environnements cloud spécialisés. Pour en savoir plus, lisez l'article sur la prise en charge étendue d'Oracle Cloud Infrastructure.

Essayez Red Hat OpenShift 4.20

Lancez-vous dès aujourd'hui avec Red Hat Hybrid Cloud Console et profitez des dernières fonctions et améliorations d'OpenShift. Pour en savoir plus, consultez les ressources suivantes :

• Nouveautés de Red Hat OpenShift
• What's New in Red Hat OpenShift 4.20 (vidéo)
• Démonstrations interactives d'OpenShift 4.20
• In the Clouds (vidéo)
• Chaîne YouTube d'OpenShift
• Articles de blog sur OpenShift
• OpenShift Commons
• Blog Red Hat Developer
• Centre d'architecture des produits Red Hat
• Modèles validés

Vous trouverez la liste complète des mises à jour de Red Hat OpenShift 4.20 dans les notes de version d'OpenShift 4.20. Faites part de vos commentaires à vos contacts Red Hat ou dans un dossier sur GitHub.