Présentation d'OpenShift Service Mesh 3.1

Red Hat OpenShift Service Mesh 3.1 est désormais disponible. Cette solution est incluse dans Red Hat OpenShift Container Platform et Red Hat OpenShift Platform Plus. Cette version est basée sur les projets Istio, Envoy et Kiali et met à jour Istio vers la version 1.26. et Kiali vers la version 2.11. Elle est également compatible avec OpenShift Container Platform 4.16 et les versions ultérieures.

Il s'agit de la première version mineure après Red Hat OpenShift Service Mesh 3.0, une mise à jour majeure visant à rapprocher le produit du projet communautaire Istio, dont l'installation et la gestion se font à l'aide de l'opérateur Sail. Ce changement permet de s'assurer qu'OpenShift Service Mesh offre les dernières fonctionnalités stables d'Istio avec la prise en charge de Red Hat.

Mise à niveau vers OpenShift Service Mesh 3.1

Si vous utilisez OpenShift Service Mesh 2.6 ou une version antérieure, vous devez effectuer une mise à niveau vers OpenShift Service Mesh 3.0 avant de procéder à la mise à niveau vers la version 3.1. Nous vous recommandons de migrer vers OpenShift Service Mesh 3.0 dans les meilleurs délais, la version 2.6 arrivant en fin de vie le 12 mars 2026. Vous trouverez un guide de migration détaillé dans la documentation OpenShift Service Mesh 3.0., qui comprend une analyse des différences entre OpenShift Service Mesh 2.6 et 3.0.  

Nous avons également publié récemment un article qui explique comment utiliser la console Kiali pour migrer entre OpenShift Service Mesh 2.6 et 3.0.

Pour découvrir un exemple d'OpenShift Service Mesh 3.0 en action, avec des indicateurs de mesure entièrement configurés et la console Kiali, consultez le modèle de solution.

Prise en charge de l'API Gateway Kubernetes dans OCP 4.19+

L'API Gateway Kubernetes constitue la nouvelle génération d'API Kubernetes Ingress, d'équilibrage de charge et de Service Mesh. Istio prévoit d'en faire l'ensemble d'API par défaut pour la création et la gestion du trafic à l'aide d'un Service Mesh, et son utilisation est nécessaire pour le mode ambiant d'Istio. Notez qu'il n'est pas prévu de supprimer les API Istio stables, telles que VirtualService, DestinationRule, etc. Il peut parfois s'avérer nécessaire d'utiliser ces API pour tirer parti de fonctions qui n'ont pas encore été ajoutées à l'API Gateway Kubernetes.

Alors qu'OpenShift Service Mesh 3.0 incluait la prise en charge de l'API Gateway Kubernetes, les utilisateurs devaient installer des définitions de ressources personnalisées (CRD) non prises en charge pour en tirer parti. Ce point a évolué depuis OpenShift Container Platform 4.19 et les versions ultérieures, avec les CRD requis désormais disponibles par défaut dans OpenShift. Vous n'avez plus besoin d'installer ces définitions de ressources personnalisées séparément. Red Hat prend entièrement en charge les définitions de ressources personnalisées de l'API Gateway incluses dans OpenShift.

Dans le but de fournir une prise en charge optimisée pour les charges de travail et les modèles de trafic d'IA générative, nous avons inclus la prise en charge de la préversion technologique pour l' API Gateway Inference Extension en rétroportant cette fonction sur OpenShift Service Mesh 3.1.

Prise en charge en disponibilité générale de la double pile pour les clusters x86

Cette version assure la prise en charge des charges de travail IPv4 et IPv6 à double pile avec OpenShift Service Mesh, en disponibilité générale pour les clusters OpenShift fonctionnant sur du matériel x86. Pour activer la prise en charge de la double pile dans OpenShift Service Mesh, vous devez régler l'indicateur ISTIO_DUAL_STACK sur « true » dans votre ressource client Istio. Cette information est démontrée dans la documentation sail-operator en amont concernant la double pile., ainsi que la documentation Istio de la communauté sur la double pile, avec la documentation du produit OpenShift Service Mesh à suivre.

Passage aux microconteneurs UBI

Cette version déplace la plupart des conteneurs, y compris les conteneurs istiod et proxy (Envoy), pour utiliser les images de base UBI Micro. UBI Micro est la plus petite image de base universelle (UBI) de Red Hat Enterprise Linux, obtenue en excluant un gestionnaire de paquetages et toutes ses dépendances, qui sont normalement inclus dans une image de conteneur. L'adoption d'UBI Micro permet de minimiser la surface d'attaque des images de conteneur fournies dans le cadre d'OpenShift Service Mesh.

Vers un Service Mesh sans sidecar : le mode ambiant d'Istio

OpenShift Service Mesh 3.1 est basé sur Istio 1.26 et comprend principalement des mises à jour progressives par rapport à OpenShift Service Mesh 3.0, qui était basé sur Istio 1.24. Cela s'explique par le fait que la communauté Istio et Red Hat se concentrent sur la prochaine génération de plan de données de Service Mesh, à savoir le mode ambiant d'Istio.

Nous avons constaté une croissance constante de l'utilisation du Service Mesh ces dernières années. Cependant, la nécessité de recourir à des proxies sidecar constitue souvent un obstacle à son adoption en raison des ressources supplémentaires (mémoire et processeur, principalement) requises pour exécuter les conteneurs sidecar en parallèle de chaque conteneur d'application. Ce point complique l'adoption du maillage de services, car les proxies sidecar doivent être ajoutés et mis à jour dans le cadre du cycle de vie du pod. Ceci implique que les applications doivent être redémarrées pour introduire une mise à jour du maillage de services.

Le mode ambiant d'Istio vise à résoudre ces problèmes en supprimant la nécessité de recourir à des proxies sidecar et en divisant le plan de données Istio en deux couches distinctes. Les propriétaires d'applications peuvent ainsi adopter progressivement les fonctionnalités de Service Mesh, sans trop de complexité.

Cette architecture divisée se traduit par un nombre nettement moins élevé de proxies déployés pour activer le Service Mesh, ce qui réduit sensiblement les ressources requises pour exécuter un Service Mesh. Étant donné que le mode ambiant d'Istio ne nécessite pas de proxy de type sidecar, des applications peuvent être intégrées au maillage et en être retirées sans qu'il soit nécessaire de modifier ou de redémarrer les pods d'application.

Le mode ambiant d'Istio comprend deux couches distinctes :

• Ztunnel : Un proxy léger au niveau du nœud de couche 4 (exécuté en tant que Daemonset dans Kubernetes) qui crée une socket d'écoute à l'intérieur de l'espace de noms réseau du pod d'application pour mettre à niveau de manière transparente le trafic au niveau du pod avec le chiffrement mTLS. Ztunnel s'occupe également de la gestion des certificats et des identités pour les pods sur le nœud (et uniquement pour ceux-ci). En utilisant Ztunnel seul, vous pouvez mettre en œuvre le chiffrement mTLS automatique, la télémétrie de couche 4 et la gestion des politiques.
• Waypoint : Un proxy Envoy facultatif, comparable à une passerelle, déployé pour un ensemble d'applications (par défaut, limité à l'espace de noms) afin d'offrir des fonctionnalités de maillage de couche 7. Celles-ci incluent les politiques de sécurité et de trafic au niveau de l'application, la télémétrie au niveau de l'application et les fonctionnalités de résilience du maillage. Contrairement aux sidecars, les proxies de points de passage peuvent être ajoutés selon les besoins et mis à l'échelle indépendamment des conteneurs d'applications.

Pour plus d'informations sur l'architecture du mode ambiant d'Istio et les compromis à faire, lisez l'article Try Istio ambient mode on Red Hat OpenShift.

OpenShift Service Mesh 3.1 fait passer le mode ambiant d'Istio au statut de préversion technologique. Il inclut un proxy Ztunnel, entièrement pris en charge par Red Hat, qui utilise OpenSSL pour le chiffrement afin de garantir sa conformité avec les normes FIPS. OpenShift Service Mesh 3.1 inclut de la documentation pour prendre en main le mode ambiant d'Istio sur OpenShift, dans le cadre du guide d'installation. Cette documentation sera enrichie dans les mois à venir, en vue d'une disponibilité générale.

Notez que le mode ambiant d’Istio nécessite l’API Gateway Kubernetes. Utilisez-le donc sur OpenShift Container Platform 4.19 ou version ultérieure, qui inclut les définitions de ressources personnalisées (CRD) d’API Gateway prises en charge, installées par défaut. Si vous souhaitez expérimenter le mode ambiant d’Istio sur des versions antérieures d’OpenShift, vous devez installer les définitions de ressources personnalisées de l’API Gateway Kubernetes non prises en charge, comme décrit dans la documentation Istio de la communauté. Notez que la mise à niveau vers les CRD de l'API Gateway Kubernetes prises en charge dans OCP 4.19 peut entraîner des temps d'arrêt.

Nous vous recommandons également de tester le mode ambiant d'Istio sur les clusters sur lesquels OpenShift Service Mesh n'est pas encore installé, afin de réduire la probabilité d'interférer avec les déploiements de Service Mesh existants. Nous fournirons prochainement de la documentation sur l'exécution d'un plan de données en mode ambiant en parallèle d'un plan de données en mode sidecar, ainsi que des conseils sur la migration des applications du mode sidecar vers le mode ambiant.

Notez qu'à partir d'Istio 1.26, les fonctionnalités du mode sidecar ne sont pas toutes prises en charge, certaines restant « Alpha » dans Istio en amont. Il se peut que le mode ambiant ne convienne pas pour tous les cas d’utilisation de Service Mesh. Les lacunes les plus notables concernent les configurations multi-réseaux et multi-clusters, ainsi que l'interopérabilité entre les plans de données en mode ambiant et en mode sidecar. Ces fonctionnalités et d'autres sont en cours de développement au sein de la communauté Istio.

Mises à jour Kiali

Kiali est la console d'Istio Service Mesh fournie avec OpenShift Service Mesh. Cette version met à jour Kiali vers la version 2.11, qui inclut de nombreuses mises à jour et améliorations (telles que le mode ambiant d'Istio).

Mises à jour de la page Mesh

La page de maillage continue à recevoir des améliorations en tant que tableau de bord principal permettant de surveiller l’état de l’infrastructure d’Istio, couvrant le plan de contrôle Istio lui-même, les composants du plan de données et les modules complémentaires d’observabilité tels que Prometheus et Tempo. Cette version comprend plusieurs mises à jour, notamment les passerelles Istio et les composants du plan de données en mode ambiant : Ztunnel et Waypoint. À partir de la page Mesh, vous pouvez examiner les composants pour révéler des informations d’état clés, notamment des mesures et des vidages de configuration relatifs à chaque composant.

Performances et évolutivité avec des maillages étendus

Le nombre croissant de charges de travail au sein du maillage de services suscite fréquemment des préoccupations en matière de performances de Kiali. Par le passé, Kiali aurait eu des difficultés à rester réactif avec des maillages de services très étendus. La FAQ du projet Kiali inclut désormais une nouvelle section dédiée aux performances, qui offre des conseils pour utiliser Kiali avec des déploiements de maillage étendus. Cette version comprend des mises à jour visant à améliorer les performances, notamment des améliorations pour une gestion plus efficace des maillages étendus.

Par exemple, Kiali tente par défaut de générer une page immédiatement et met automatiquement à jour la plupart des pages en fonction du réglage dans la liste déroulante Refresh Interval. Pour les maillages de grande envergure, même le rendu initial peut être lent, ce qui retarde l'utilisation de la console. Kiali propose désormais un mode Actualisation manuelle qui n’actualise une page que lorsque l’on clique sur le bouton Refresh. Cette option peut être configurée via spec.kiali_feature_flags.ui_defaults.refresh_interval sur la valeur « manual » dans la définition de ressource personnalisée (CRD) Kiali. 

Il est également possible de désactiver les validations afin d'améliorer les performances et la réactivité avec des maillages étendus. Pour ce faire, définissez la configuration de l'opérateur Kiali spec.external_services.istio.validation_reconcile_interval à 0.

Démarrer avec OpenShift Service Mesh

Si vous découvrez OpenShift Service Mesh, commencez par consulter l'introduction à OpenShift Service Mesh et nos instructions d'installation initiale. Pour un exemple fonctionnel complet, consultez le modèle de solution « Optimizing Traffic and Observability with OpenShift Service Mesh 3 ».

Si vous utilisez OpenShift Service Mesh 3.0, consultez la documentation de mise à niveau pour connaître les différentes approches de mise à jour de l'opérateur OpenShift Service Mesh 3, des plans de contrôle Istio, de la ressource CNI d'Istio et des proxies qui constituent le plan de données.

Si vous utilisez OpenShift Service Mesh 2.6 ou une version antérieure, consultez la documentation sur les différences de migration entre OpenShift Service Mesh 2 et 3, ainsi que notre documentation complète sur la migration. Un article de blog décrit également la procédure à l'aide de Kiali.