Présentation de Red Hat OpenShift Service Mesh 3.4

Red Hat OpenShift Service Mesh 3.4 est disponible avec Red Hat OpenShift et Red Hat OpenShift Platform Plus. Basée sur les projets Istio, Envoy et Kiali, cette version met à jour Istio vers la version 1.30 et Kiali vers la version 2.27. Cette version inclut plusieurs mises à jour du mode Ambient sans sidecar d'Istio, et bien plus encore. Kiali introduit une nouvelle page d'aperçu pour mieux gérer les maillages de services à grande échelle, tout en proposant des fonctionnalités basées sur l'IA avec Red Hat OpenShift Lightspeed en version d'essai (Technology Preview) pour vous aider à diagnostiquer et à résoudre les problèmes plus rapidement. Cet article propose également un aperçu des nouveautés à venir plus tard cette année.

Notez que la version 2.6 d'OpenShift Service Mesh a atteint sa fin de vie le 30/06/2026. Si vous utilisez encore la version 2.6 sans extension d'assistance approuvée, consultez les notes à la fin de cet article pour savoir comment procéder.

Nouvelle page d'aperçu de Kiali compatible avec les clusters multiples

OpenShift Service Mesh au Red Hat Summit

Le Red Hat Summit 2026 s'est tenu en mai à Atlanta, en Géorgie. Au cas où vous l'auriez manqué, OpenShift Service Mesh a occupé une place importante dans la présentation produit Red Hat OpenShift. Deux clients y ont présenté leur expérience avec le service mesh, et une démonstration a mis en avant l'utilisation du service mesh avec OpenShift Virtualization ainsi qu'une démonstration prospective utilisant le service mesh pour le dépannage par IA agentique.

Basée sur Istio 1.30 et Kiali 2.27

Cette version saute deux versions mineures d'Istio par rapport à OpenShift Service Mesh 3.3, intégrant les changements d'Istio 1.29 et 1.30. Ces deux versions incluent des mises à jour majeures du mode Ambient d'Istio, en particulier pour les clusters multiples. Kiali passe à la version 2.27, qui inclut des mises à jour majeures des pages d'aperçu et de détails. Nous soulignons ici certains des changements les plus notables, mais la liste complète des mises à jour est disponible dans les notes de version d'Istio 1.29 et 1.30 ainsi que dans les notes de version de Kiali. Pour plus de détails sur l'assistance produit, veuillez consulter les tableaux de prise en charge des fonctionnalités d'OpenShift Service Mesh 3.4.

Mises à jour du mode Ambient

Cette version propose plusieurs mises à jour du mode Ambient sans sidecar d'Istio, qui continue de progresser vers la parité fonctionnelle avec le mode sidecar traditionnel d'Istio.

Conseils de coexistence et de migration depuis le mode sidecar

Cette version introduit une assistance et des conseils officiels pour la coexistence des charges de travail en mode Ambient et en mode sidecar au sein d'un même maillage de services, ainsi que des conseils sur la migration des charges de travail du mode sidecar vers le mode Ambient. Les deux procédures signalent plusieurs limitations actuelles concernant la coexistence et la migration des charges de travail entre les modes Ambient et sidecar. La migration se veut progressive et réversible, les charges de travail Ambient et sidecar pouvant coexister pendant une période prolongée.

Les clusters multiples en mode Ambient continuent de mûrir (Technology Preview)

Cette version inclut de nombreuses mises à jour de l'ensemble de fonctionnalités multiréseau multiprincipal (clusters multiples) du mode Ambient d'Istio, y compris une documentation mise à jour dans OpenShift Service Mesh pour l'installation d'un maillage multiréseau multiprincipal en mode Ambient.

Pour rappel, les topologies clusters multiples d'Istio étendent la portée d'un maillage unique à plusieurs clusters, offrant un point unique pour observer le trafic et gérer les politiques à travers plusieurs clusters, zones de disponibilité et régions. Elles sont particulièrement utiles pour créer des applications hautement disponibles, l'équilibrage de charge basé sur la localisation d'Istio permettant d'acheminer le trafic en fonction de l'emplacement physique ou géographique. Pour le mode sidecar, il s'agit d'une fonctionnalité généralement disponible dans OpenShift Service Mesh.

Cette version inclut des améliorations significatives et des corrections de bogues qui rapprochent les clusters multiples en mode Ambient d'un état prêt pour la production. Cela inclut la correction d'un bogue où les passerelles d'entrée n'acheminaient pas les requêtes vers les backends distants exposés. Ce correctif est activable via l'indicateur de fonctionnalité AMBIENT_ENABLE_MULTI_NETWORK_INGRESS, qui est défini sur « false » par défaut.

Des améliorations ont été apportées à l'implémentation de la télémétrie, comblant les lacunes liées à l'échange de métadonnées entre pairs et de télémétrie à travers les limites du réseau lorsque des points de passage (waypoints) sont utilisés. Ces fonctionnalités peuvent nécessiter l'activation de l'indicateur de fonctionnalité AMBIENT_ENABLE_BAGGAGE. Le projet Istio propose désormais un guide détaillé pour la configuration du mode Ambient multiréseau avec Kiali.

La prise en charge du multiréseau multiprincipal (clusters multiples) avec le mode Ambient d'Istio est une fonctionnalité en version d'essai (Technology Preview) dans OpenShift Service Mesh 3.4. Bien que nous ne recommandions pas encore cette fonctionnalité pour une utilisation en production, nous encourageons les utilisateurs d'OpenShift Service Mesh à commencer le développement et l'expérimentation, et à nous faire part de leurs commentaires.

Prise en charge des listes de révocation de certificats (CRL) dans ztunnel

Cette version ajoute la prise en charge des listes de révocation de certificats (CRL) à ztunnel, permettant au mode Ambient de valider et de rejeter les certificats révoqués lors de l'utilisation d'autorités de certification externes. Comme pour le mode sidecar, vous pouvez configurer cela à l'aide d'un fichier ca-crl.pem fourni avec vos fichiers de CA intégrés dans ClientTLSSettings. Le plan de contrôle Istio (Istiod) distribuera automatiquement ces CRL à tous les espaces de noms participants du cluster.

Prise en charge native de nftables pour RHEL 10 et versions ultérieures

Cette version offre une prise en charge native de nftables pour les modes sidecar et Ambient. Cette fonctionnalité a été fournie par Red Hat pour préparer Istio aux futures versions de Red Hat Enterprise Linux (RHEL) et d'OpenShift. Nftables constitue une alternative aux iptables traditionnels pour la gestion des règles réseau, ce qui sera nécessaire lors de l'utilisation de Service Mesh avec RHEL 10 et versions ultérieures.

Politiques réseau pour les composants clés d'Istio

Pour améliorer la sécurité des composants clés d'Istio (istiod, istio-cni et ztunnel), Red Hat a introduit un ensemble facultatif de politiques réseau qui limitent ces composants au strict minimum de ports d'entrée nécessaires. Ces politiques peuvent être activées en définissant global.networkPolicy.enabled=true dans la configuration des valeurs de votre ressource Istio. 

Dans OpenShift Service Mesh 3.4, celles-ci seront désactivées par défaut, mais elles seront activées par défaut dans une future version mineure d'OpenShift Service Mesh.

Améliorations de l'API Kubernetes Gateway

La prise en charge de l'API Kubernetes Gateway dans Istio continue d'évoluer. Cette version de Service Mesh inclut des mises à jour majeures avec la prise en charge de l'API Kubernetes Gateway 1.5. Notez que la prise en charge de l'API Gateway sur OpenShift nécessite l'installation de définitions de ressources personnalisées (CRD), et la version prise en charge de ces CRD dépend actuellement de la version de la plateforme OpenShift.

Cette version ajoute la prise en charge complète de la terminaison TLSRoute et du mode mixte, ainsi que du transfert TLS (passthrough) pour les passerelles est-ouest, une fonctionnalité clé pour prendre en charge le trafic intercluster chiffré dans le mode Ambient d'Istio. 

La ressource Gateway inclut désormais l'option de spécifier des suites de chiffrement personnalisées à l'aide de l'annotation gateway.istio.io/tls-cipher-suites. Le rapport d'état de la ressource Gateway a été amélioré pour inclure le nombre de ListenerSets rattachés, tandis que le rapport d'état de ListenerSet inclut désormais le nombre de Routes rattachées.

Enfin, si vous utilisez uniquement l'API Kubernetes Gateway pour configurer votre maillage de services (GAMMA), ou si vous utilisez Istio uniquement comme contrôleur d'entrée (pour le trafic nord-sud uniquement), vous n'aurez peut-être pas besoin de l'ensemble des ressources et fonctionnalités incluses par défaut dans Istio. La nouvelle variable d'environnement PILOT_IGNORE_RESOURCES peut être utilisée pour optimiser Istio en ignorant les ressources inutiles pour vos cas d'utilisation. Cela peut réduire l'empreinte d'Istio, économisant ainsi de la mémoire et du temps de réconciliation de la configuration.

Prise en charge des espaces de noms utilisateur Kubernetes

Cette version ajoute la prise en charge de l'injection de sidecars aux pods utilisant les espaces de noms utilisateur Kubernetes (hostUsers: false) lors de l'exécution avec Istio CNI.

Les espaces de noms utilisateur Kubernetes renforcent la sécurité des clusters en isolant l'utilisateur root d'un conteneur de l'utilisateur root du nœud hôte. Cela garantit que même si un processus conteneurisé s'échappe vers l'hôte, il ne détient aucun privilège.

Pour utiliser cette fonctionnalité, vous devez configurer explicitement les plages d'identifiants utilisateur (UID) et de groupe (GID) par défaut sur l'objet de l'espace de noms cible à l'aide des annotations openshift.io/sa.scc.uid-range et openshift.io/sa.scc.supplemental-groups pour permettre la correspondance des espaces de noms utilisateur. La longueur de ces plages d'ID allouées doit être de 65 535 ou moins, car le dépassement de cette limite entraînera l'échec de la création du pod.

Prise en charge du gestionnaire d'identités de charge de travail Zero Trust (Technology Preview)

Cette version fait passer la prise en charge par OpenShift Service Mesh du gestionnaire d'identités de charge de travail Zero Trust de Red Hat (basé sur SPIRE) en version d'essai (Technology Preview). Bien qu'OpenShift Service Mesh inclue l'identification et la création de charges de travail prêtes à l'emploi via le protocole SPIFFE, le gestionnaire d'identités de charge de travail Zero Trust, disponible avec Red Hat OpenShift Platform Plus, offre une attestation d'identité multifacteur plus robuste, appuyée par une vérification matérielle ou de l'environnement cloud. Cela apporte une assurance supplémentaire quant à la légitimité de l'identité revendiquée par une charge de travail.

Le gestionnaire d'identités de charge de travail Zero Trust inclut également une fonctionnalité puissante appelée fédération, qui permet aux charges de travail appartenant à différents domaines de confiance de s'authentifier et de communiquer entre elles de manière sécurisée. L'association de cette solution au maillage de services simplifie et renforce la sécurité du partage de la confiance, que ces charges de travail se trouvent dans différents maillages de services, clusters ou environnements autonomes tels que des machines virtuelles (VM).

Cette intégration a été détaillée dans une série d'articles de blog, incluant l'extension du cas d'utilisation à une machine virtuelle externe.

Nouvelle API TrafficExtension (Technology Preview)

Cette version introduit également une nouvelle API pour étendre Istio : l'API TrafficExtension. Bien qu'Istio soit riche en fonctionnalités, nous constatons que de nombreux clients ont des cas d'utilisation spécialisés nécessitant l'extension des fonctionnalités d'Istio, soit via l'API EnvoyFilter (une API de bas niveau présentant un risque important de rupture lors des mises à jour), soit via des plug-ins WebAssembly (efficaces pour les cas complexes, mais parfois lourds à créer et à distribuer). 

L'API TrafficExtension vise à fournir une interface unique, unifiée et améliorée pour étendre les fonctionnalités d'Istio. Elle intègre les fonctionnalités de l'API WasmPlugin (qu'elle vise à remplacer), tout en ajoutant la prise en charge de scripts Lua directement intégrés dans la ressource, sans nécessiter de distribution de module. Cela offre une méthode plus légère pour étendre Istio, tout en visant une plus grande sécurité qu'un EnvoyFilter. Comme les autres ressources Istio, les TrafficExtensions peuvent être configurées et gérées à l'aide de Kiali. Pour plus d'informations, consultez la section sur l'extension des proxys Envoy.

Nouvelles pages d'aperçu et de détails de Kiali avec une prise en charge clusters multiples améliorée

La console Kiali et son plug-in associé OpenShift Service Mesh Console offrent un emplacement centralisé pour observer, gérer et protéger à la fois Istio et les services qui composent votre maillage de services.

Cette version inclut une page d'aperçu entièrement repensée dans Kiali (illustrée dans la capture d'écran ci-dessus). Ceci a été fait pour améliorer la lisibilité et les performances des grands déploiements de maillages de services de clusters multiples pouvant comporter plusieurs centaines d'espaces de noms. La nouvelle architecture réduit l'utilisation de la mémoire et le temps de rendu, tandis que la mise en page mise à jour est compatible avec les clusters multiples, mettant l'accent sur l'état de santé global avec des aperçus instantanés des applications. Des mises à jour similaires ont été apportées à la page d'aperçu du plug-in de la console OpenShift Service Mesh.

Une page d'espaces de noms mise à jour offre une meilleure prise en charge des maillages de clusters multiples de grande taille, avec un filtrage et un tri avancés, ainsi que l'état mTLS pour chaque espace de noms. 

Page d'espaces de noms de Kiali compatible avec les clusters multiples

L'examen d'un espace de noms particulier fournit une vue résumée et graphique mise à jour de cet espace de noms. L'exploration d'une charge de travail spécifique offre une vue résumée similaire avec un graphique affichant ses dépendances.

Page de détails de l'espace de noms mise à jour dans Kiali

Page de détails de la charge de travail mise à jour dans Kiali

Assistance au maillage de services basée sur l'IA (Technology Preview)

La complexité d'Istio et la richesse des informations accessibles par Kiali (notamment les métriques, les journaux et les traces) en font un lieu idéal pour l'assistance par l'IA. Dans la console Kiali, cela peut être utilisé en configurant le propre chatbot de Kiali. Cette version ajoute l'analyse de l'utilisation des jetons pour vous aider à surveiller et à contrôler les coûts. L'invite système a également été renforcée contre les attaques par injection afin d'empêcher les entrées malveillantes de divulguer des configurations de maillage ou des identifiants sensibles.

Pour encore plus de puissance et d'intégration, utilisez le Model Connect Protocol (MCP) en combinaison avec OpenShift Lightspeed pour vous assister avec le maillage de services et le reste de la plateforme OpenShift. Le serveur OpenShift Model Connect Protocol (MCP) est récemment passé en version d'essai (Technology Preview) et inclut des outils spécifiques pour Kiali et OpenShift Service Mesh. 

Ceux-ci peuvent être utilisés en combinaison avec la console Kiali ou le plug-in de console OpenShift Service Mesh pour surveiller votre maillage pendant que vous interagissez avec lui via Lightspeed ou votre environnement agentique de choix utilisant MCP.

OpenShift Lightspeed avec le plug-in de console OpenShift Service Mesh

Nous avons déjà constaté que cette combinaison aide à abaisser les barrières pour les cas d'utilisation courants du maillage de services, tels que la répartition du trafic (illustrée ci-dessus et en démonstration ici), l'analyse de télémétrie, l'identification d'erreurs de configuration jusqu'aux scénarios de dépannage complexes (démo ici), et d'autres tâches qui nécessitaient auparavant une expertise approfondie d'Istio (ou beaucoup de temps passé dans la documentation).

Amélioration de l’architecture multi-client des espaces de noms dans Kiali

Kiali a ajouté une nouvelle option de configuration, KialiFeatureFlags.Authz.RequireNamespaceGet, permettant aux administrateurs de restreindre la visibilité des espaces de noms aux seuls espaces pour lesquels les utilisateurs disposent de permissions « get » explicites (et pas seulement « list »). Ceci est utile dans les environnements multi-client à maillage unique où les utilisateurs ne doivent voir que leurs propres espaces de noms, et non l'inventaire complet du cluster.

Prochaines étapes

Bien que cette version propose une gamme de mises à jour pour Istio et Kiali, plusieurs autres fonctionnalités majeures sont attendues plus tard cette année. Nous travaillons à la mise en disponibilité générale de la topologie multiréseau multiprincipal (clusters multiples) du mode Ambient. Nous prévoyons d'étendre notre prise en charge des VM pour inclure les charges de travail sur des réseaux séparés, y compris celles ne faisant pas partie d'un cluster OpenShift. La prise en charge de l'intégration des VM RHEL est une fonctionnalité en version d'essai pour les développeurs (Developer Preview). Nous étudions également des extensions pour Red Hat Advanced Cluster Management for Kubernetes afin d'améliorer la configuration et la gestion du maillage de services à travers un parc de clusters.

Fin de vie d'OpenShift Service Mesh 2.6

OpenShift Service Mesh 2.6 a atteint sa fin de vie le 30/06/2026. Bien que nous continuions d'aider nos clients à migrer vers une version prise en charge d'OpenShift Service Mesh 3, nous ne fournissons plus de correctifs de bogues ni de sécurité pour OpenShift Service Mesh 2.6.

Si vous utilisez encore OpenShift Service Mesh 2.6, veuillez contacter votre représentant commercial Red Hat pour discuter d'une extension d'assistance et d'un calendrier de migration. Des informations détaillées sur les différences entre OpenShift Service Mesh 2.6 et 3.0 sont disponibles ici, avec un guide de migration approfondi détaillant une procédure sans interruption de service couvrant diverses configurations de production. Nous sommes à votre disposition pour discuter de situations ou de défis particuliers.

Premiers pas ou mise à niveau vers OpenShift Service Mesh 3.4

Si vous découvrez le maillage de services, le guide d'installation détaille l'installation d'Istio avec l'opérateur OpenShift Service Mesh 3. L'opérateur gère l'installation et les mises à niveau d'Istio, y compris plusieurs maillages de services sur un seul cluster (mode sidecar uniquement) ou plusieurs clusters au sein d'un maillage de services.

Pour ceux effectuant une mise à niveau depuis OpenShift Service Mesh 3.3, consultez les notes de version pour obtenir la liste des changements importants à connaître avant de procéder. Suivez la documentation de mise à jour d'OpenShift Service Mesh pour connaître la procédure de mise à niveau détaillée.

En savoir plus sur Red Hat OpenShift Service Mesh.