Présentation d'OpenShift Service Mesh 3.2 avec intégration du mode ambiant d'Istio

Nous sommes ravis d'annoncer la disponibilité générale de Red Hat OpenShift Service Mesh 3.2. Cette version introduit le mode ambiant d'Istio, une nouvelle méthode de déploiement d'un Service Mesh sans sidecar qui réduit considérablement les coûts liés aux ressources nécessaires à son utilisation. Cette solution allège aussi les coûts de mise en réseau Zero Trust grâce au chiffrement mTLS léger de pod à pod et à des politiques d'autorisation basées sur l'identité des charges de travail. Elle peut par ailleurs être complétée par d'autres fonctions avancées selon les besoins.

Basée sur les projets Istio, Envoy et Kiali, cette version fait passer à Istio 1.27 et Kiali 2.17. Elle est compatible avec Red Hat OpenShift 4.18 et les versions ultérieures. 

Mise à niveau vers OpenShift Service Mesh 3.2

Si vous exécutez OpenShift Service Mesh 2.6 ou une version antérieure, vous devez d'abord faire la mise à niveau vers OpenShift Service Mesh 3.0, puis 3.1 et ensuite 3.2. Nous vous recommandons de ne pas tarder, car la version 2.6 atteindra sa fin de vie le 30 juin 2026 (anciennement le 12 mars 2026). Vous trouverez un guide de migration détaillé dans la documentation d'OpenShift Service Mesh 3.0, qui comprend une analyse des différences entre OpenShift Service Mesh 2.6 et 3.0. Cet article de blog explique comment utiliser la console Kiali pour migrer depuis OpenShift Service Mesh 2.6 vers la version 3.0.

Pour comprendre le fonctionnement d'OpenShift Service Mesh 3.0 à l'aide d'un exemple, avec des indicateurs de mesure entièrement configurés et la console Kiali, consultez ce schéma de solution.

Mode ambiant d'Istio : un Service Mesh sans sidecar

Cette version d'OpenShift Service Mesh inclut la prise en charge du mode ambiant d'Istio en disponibilité générale, qui permet d'activer les fonctions du Service Mesh sur les charges de travail sans recourir aux proxies sidecar.

Dans l'architecture de plan de données traditionnelle d'Istio, appelée « mode sidecar », chaque pod d'application nécessite un conteneur de proxy sidecar pour activer les fonctions du Service Mesh. La simplicité de cette architecture entraîne toutefois un surcoût, puisqu'un conteneur proxy doit être créé pour chaque conteneur de charge de travail d'application. Cet aspect complique aussi l'adoption du Service Mesh, car les proxies sidecar doivent être ajoutés et mis à jour dans le cadre du cycle de vie de l'application et du Service Mesh. Ce processus nécessite de redémarrer les applications lors du déploiement et des mises à jour du Service Mesh.

Dans l'architecture du mode ambiant d'Istio, le plan de données est divisé en deux niveaux de proxy ayant des rôles spécifiques : les « zTunnels » et les « waypoints ». 

Proxy zTunnel

Le zTunnel est un proxy léger, partagé au niveau du nœud, qui intercepte le trafic de la couche 4 et assure la sécurité (la lettre z correspond à l'initiale de Zero trust) via le chiffrement mTLS (mutual Transport Layer Security), l'authentification, la télémétrie et des politiques d'autorisation de la couche 4 simples, basées sur l'identité des applications. Il fournit également des journaux et des indicateurs de mesure de base pour la couche 4 (par exemple, TCP), accessibles depuis la console Kiali.

Codé en Rust et conçu pour cet usage spécifique, le zTunnel offre d'excellentes performances avec un faible coût en ressources. 

Bien qu'exécuté au niveau du nœud en tant que ressource Kubernetes DaemonSet, le proxy zTunnel applique la redirection du trafic dans l'espace de noms réseau de chaque pod. La redirection et le chiffrement du trafic s'effectuent au sein même du pod, ce qui permet de préserver l'isolation et le chiffrement du trafic de pod à pod. Pour en savoir plus sur ce point ainsi que sur la façon dont l'agent Istio CNI configure cette redirection du trafic, consultez la documentation d'Istio sur la redirection du trafic zTunnel.

Grâce au mode ambiant d'Istio, si vous avez uniquement besoin des fonctions du zTunnel, vous n'avez pas d'autre proxy à exécuter. Et vous bénéficiez ainsi d'un Service Mesh hautement performant.

Proxy waypoint

Pour utiliser les fonctions du Service Mesh au niveau des applications (couche 7), comme la télémétrie HTTP ou gRPC, la gestion du trafic et les politiques d'autorisation, il est possible d'ajouter d'autres proxies appelés « waypoints ». Ceux-ci sont généralement déployés par espace de noms, avec un groupe de charges de travail d'applications étroitement liées. 

En plus de celles déjà fournies par le zTunnel, un proxy waypoint ajoute les fonctions suivantes :

• Routage HTTP, équilibrage de charge, nouvelles tentatives, délais d'expiration, interruption du routage, limites de débit et injection de fautes
• Politiques d'autorisation complexes basées sur les éléments de la couche 7, telles que le type de requête ou l'en-tête HTTP
• Indicateurs de mesure HTTP, journalisation des accès et suivi

La gestion des proxies waypoint est similaire à celles des passerelles Ingress, comme des proxys Envoy autonomes. De même, leur cycle de vie suit celui des charges de travail d'applications, plutôt que celui du plan de contrôle du Service Mesh ou du zTunnel présent sur chaque nœud.

Le mode ambiant d'Istio convient-il à votre entreprise ? Quels sont ses avantages et compromis ? 

Le mode ambiant d'Istio n'a pas fini d'évoluer. À l'heure actuelle, il est particulièrement adapté aux nouvelles installations de Service Mesh puisque la migration ou son association avec le mode sidecar présente des limites (plus de détails ci-dessous).  

Nous vous recommandons d'utiliser la solution Red Hat OpenShift 4.19 (ou une version ultérieure) pour bénéficier des définitions de ressources personnalisées (CRD) de l'API Kubernetes Gateway. Ces dernières sont conseillées pour configurer les passerelles Ingress et obligatoires pour configurer les proxies waypoint du mode ambiant. OpenShift Service Mesh 4.18 et les versions antérieures n'incluent pas ou ne prennent pas en charge ces CRD.

Voici quelques avantages et compromis liés à l'adoption du mode ambiant :

Réduction importante des coûts liés aux ressources

Parce qu'il élimine le besoin d'utiliser des proxies sidecar, le mode ambiant d'Istio réduit considérablement la quantité de ressources de mémoire et de processeur nécessaires pour adopter les fonctions du Service Mesh, telles que le chiffrement mTLS. Nous avons constaté une réduction de plus de 90 % de l'utilisation de la mémoire et de plus de 50 % du processeur par rapport au mode sidecar, avec une réduction encore plus marquée lorsque le zTunnel est utilisé seul. 

Mise en réseau Zero Trust allégée

Nous sommes convaincus que le principal avantage du mode ambiant d'Istio est le chiffrement mTLS léger de pod à pod. Alors que la mise en réseau Zero Trust devient une question prioritaire, de plus en plus de clients exigent que le Service Mesh applique le chiffrement mTLS à un grand nombre d'applications. C'est l'une des possibilités qu'offre le mode ambiant d'Istio avec le zTunnel seul, avec la gestion des identités et des certificats. De plus, il mobilise moins de ressources et a des effets limités sur les charges de travail en cours d'exécution. Et lorsque les besoins évoluent, il est possible d'ajouter des waypoints pour appliquer des politiques et une télémétrie au niveau des applications, notamment en fonction des types de requêtes HTTP (par exemple, /GET) ou des en-têtes. 

Amélioration de l'évolutivité 

Parce que l'empreinte et le nombre de proxies à gérer sont réduits, le potentiel d'évolutivité du mode ambiant d'Istio est nettement plus élevé que celui du mode sidecar traditionnel. Même si certains de nos clients ont mis à l'échelle des Service Mesh pour exécuter des milliers de charges de travail à l'aide des fonctions de définition et de mise à l'échelle d'Istio, l'architecture du mode ambiant permet d'exécuter des dizaines, voire des centaines de milliers de charges de travail avec moins de paramètres d'optimisation. 

Caractéristiques de performances potentielles

Si les premières mesures de performances réalisées par la communauté Istio sont prometteuses, nous sommes toujours en train d'évaluer le mode ambiant d'Istio dans une configuration d'entreprise comparable à celle de nos clients. Jusqu'à présent, nous avons constaté des performances comparables à celles du mode sidecar, avec de potentielles améliorations dans les prochaines versions. Les caractéristiques de performances diffèrent entre l'utilisation du zTunnel seul et du zTunnel associé à un waypoint, car ce dernier consomme plus de ressources en fonction de la configuration. Nous avons également détecté un goulet d'étranglement qui limitait la mise à l'échelle verticale du zTunnel, et dont la résolution prendra un certain temps. Nous sommes néanmoins convaincus que les prochaines versions du mode ambiant d'Istio pourront apporter des améliorations des performances.

Adoption plus simple

Le mode ambiant d'Istio facilite l'adoption du Service Mesh, puisque les charges de travail n'ont plus besoin d'être modifiées pour ajouter des conteneurs sidecar. Il n'est même pas nécessaire de les redémarrer pour les ajouter au Service Mesh ou lors de la mise à niveau de ce dernier. L'architecture à deux niveaux permet également d'adopter progressivement les fonctions d'Istio, sans les coûts en ressources associés à l'utilisation de proxies non nécessaires dans la couche 7. 

Niveau de prise en charge des fonctions

Le mode ambiant peut prendre en charge moins de fonctions d'Istio que le mode sidecar traditionnel. Pour connaître les fonctions prises en charge, consultez le tableau des fonctions d'OpenShift Service Mesh. Les fonctions avancées, telles que les clusters multiples et le multimesh, sont encore en cours de développement. L'association des modes sidecar et ambiant pour les charges de travail présente des limites, en particulier pour les proxys waypoint utilisés avec des sidecars. Pour connaître le point de vue de la communauté Istio concernant les modes ambiant et sidecar, consultez cette page. 

À savoir avant de faire la mise à niveau

Le mode ambiant d'Istio permet de mettre à jour le plan de données sans redémarrer les pods des charges de travail, ce qui est impossible avec des proxies sidecar. En contrepartie, les proxies zTunnel sont partagés au niveau du nœud et font partie du chemin de données de plusieurs applications. La mise à niveau du zTunnel doit donc être effectuée avec précaution, pendant une période de maintenance ou de trafic faible par exemple, car les connexions TCP à longue durée de vie seront réinitialisées sur ce nœud. À ce jour, les mises à niveau à partir de révisions (canary) ne sont pas encore prises en charge, mais elles sont à l'étude pour les prochaines versions.

Débuter avec le mode ambiant d'Istio

Pour commencer à utiliser le mode ambiant d'Istio, OpenShift Service Mesh fournit la ressource « zTunnel » qui permet d'installer et de gérer le zTunnel en tant que ressource DaemonSet. Elle est installée en parallèle des ressources « Istio » et « IstioCNI », qui doivent être configurées avec le profil « Ambient », même si certaines charges de travail ont des sidecars. 

Comme pour le mode sidecar traditionnel, il est également important de configurer les « sélecteurs de découverte » d'Istio pour que le plan de contrôle surveille uniquement les espaces de noms qui doivent faire partie du Service Mesh. Dans le mode ambiant, l'étiquette « istio.io/dataplane-mode=ambient » indique qu'une charge de travail ou un espace de noms doit être inclus dans le Service Mesh. Pour savoir comment ajouter des charges de travail, consultez la documentation de la communauté Istio.

Lorsqu'une nouvelle charge de travail est ajoutée au Service Mesh, l'agent Istio CNI collabore avec le proxy zTunnel du nœud pour configurer la redirection du trafic. Ce dernier est alors intercepté et mis à niveau pour utiliser le chiffrement mTLS à l'aide du protocole de tunnellisation HBONE d'Istio. Le zTunnel gère également la récupération et la gestion des certificats pour tous les pods d'un même nœud.

Les proxies waypoint sont ajoutés de la même façon que les passerelles Ingress ou Egress à l'aide de la ressource « Gateway » de l'API Kubernetes Gateway, incluse dans la solution OpenShift 4.19 (et les versions ultérieures). Pour en savoir plus sur l'installation des waypoints, consultez cette page, et pour en savoir plus sur leur utilisation avec des fonctions de la couche 7, consultez cette page.

Pour savoir comment commencer à utiliser le mode ambiant d'Istio, consultez la documentation sur OpenShift Service Mesh.

J'utilise déjà un Service Mesh. Est-ce que je peux passer au mode ambiant ?

Même si le mode ambiant est idéal pour les utilisateurs d'un nouveau Service Mesh, vous pouvez tout de même l'ajouter à un déploiement existant et l'associer à des charges de travail en mode sidecar. Cependant, certaines précautions s'imposent. Nous sommes aussi convaincus que le mode sidecar restera le cas d'utilisation privilégié pour les clients qui ont besoin de l'ensemble complet des fonctions d'un proxy Envoy dédié par pod. 

Pour introduire le mode ambiant dans un Service Mesh existant (Istio et Istio CNI), ce dernier doit être mis à jour avec le profil « Ambient », et toutes les charges de travail avec sidecars doivent être redémarrées afin de communiquer avec le zTunnel à l'aide du protocole de tunnellisation HBONE. 

Il faut cependant noter que dans ce cadre, le trafic entre les proxies sidecar et les charges de travail en mode ambiant contourne généralement les proxies waypoint. Les politiques de la couche 7 ne sont donc pas appliquées à ces charges de travail.

Compte tenu de ces limites, nous recommandons d'utiliser uniquement le mode ambiant ou le mode sidecar pour les espaces de noms et les groupes d'applications, et de ne pas combiner les deux modes au sein des charges de travail d'applications étroitement couplées. Il faut également faire attention à ne pas mélanger les étiquettes de pod en mode sidecar et ambiant.

Kiali avec le mode ambiant d'Istio

Kiali est la console pour Istio incluse dans OpenShift Service Mesh. Elle offre de nombreuses fonctions permettant de configurer, visualiser et valider le mode ambiant d'Istio. Face aux différents états possibles des charges de travail (mesh avec zTunnel, mesh avec waypoints, mode sidecar ou exclues du Service Mesh), la technologie Kiali devient d'autant plus utile pour comprendre l'état du Service Mesh et dépanner les applications distribuées qui ne se comportent pas comme prévu.

À chaque niveau, Kiali fournit des confirmations précises pour valider la bonne configuration du mode ambiant. Tout commence par le plan de contrôle d'Istio qui s'exécute avec le profil ambiant activé, et les charges de travail et espaces de noms qui ont été étiquetés. Ainsi, le trafic des charges de travail est capturé par le zTunnel et/ou le waypoint, comme prévu. Enfin, au niveau des pods, vous pouvez vérifier la sécurité du trafic à l'aide du protocole HBONE d'Istio, au lieu du protocole TCP non chiffré.

Kiali fournit également des journaux corrélés entre le zTunnel et le waypoint pour vous aider à comprendre et résoudre les problèmes liés au trafic entre la charge de travail et chaque proxy.

Les waypoints sont similaires aux autres proxies, à la différence que Kiali dispose d'un onglet spécifique qui indique les charges de travail et services enregistrés. 

Enfin, les graphiques de topologie du mode ambiant sont différents de ceux du mode sidecar. Comme il existe désormais deux niveaux de proxy, chaque charge de travail peut présenter deux ensembles indépendants de télémétrie : les indicateurs de mesure de la couche 4 (TCP) s'affichent en bleu depuis les zTunnels, et les indicateurs de mesure de la couche 7 (HTTP) s'affichent en vert lorsqu'un waypoint est configuré. Kiali permet de sélectionner le type de trafic à afficher.

Puisque les proxies waypoint représentent souvent des groupes de charges de travail étroitement couplées (qui constituent éventuellement une application distribuée commune), l'affichage du waypoint offrira une vue d'ensemble plus détaillée des Service Mesh de très grande envergure.

Pour plus d'informations sur toutes les fonctions de Kiali pour le mode ambiant, consultez la documentation de la communauté Kiali.

Mises à jour d'Istio 1.27

Cette version inclut toutes les mises à jour indiquées dans les notes de version d'Istio 1.27. Voici les principales nouveautés.

Gateway API Inference Extensions (GIE)

Cette version inclut la prise en charge des Gateway API Inference Extensions. Pour mieux servir les clients qui utilisent Red Hat OpenShift AI 3, nous avons rétroporté la mise en œuvre de l'API (version 1.0) dans cette version. Notez que cette fonction est uniquement prise en charge par Red Hat OpenShift AI 3, et qu'elle est considérée comme une version préliminaire pour OpenShift Service Mesh 3.2. 

Clusters multiples avec mode ambiant

Cette version introduit une première prise en charge du mode ambiant d'Istio dans une topologie à clusters multiples primaires. Parce qu'elle est encore en cours de développement, cette fonction est disponible en « version préliminaire pour les développeurs » dans OpenShift Service Mesh 3.2. 

Prise en charge native du système nftables en mode sidecar

En prévision du lancement de Red Hat Enterprise Linux (RHEL) 10, Red Hat a contribué à la prise en charge de nftables pour le projet Istio, avec l'intégration du mode sidecar dans Istio 1.27. Le framework nftables est le remplaçant moderne de la fonction Linux iptables, qui est utilisée par Istio pour configurer les règles de redirection du réseau. Il offre de meilleures performances, une maintenance simplifiée et une gestion plus flexible des règles pour la redirection du trafic vers et depuis le sidecar Envoy. À partir de RHEL 10, le framework nftables sera l'outil par défaut pour la gestion des règles de mise en réseau. La prise en charge pour RHEL 10 sera ajoutée dans une prochaine version d'OpenShift.

Disponibilité générale de l'agent Istio-CSR cert-manager

Le service cert-manager Operator est pris en charge par OpenShift Service Mesh, mais il a besoin de l'agent istio-csr pour signer, délivrer et renouveler des certificats pour les charges de travail. Avec le lancement de la version 1.18 de cert-manager Operator, cet agent est en disponibilité générale et peut être utilisé avec toutes les versions prises en charge d'OpenShift Service Mesh. Pour en savoir plus sur le fonctionnement de cert-manager avec OpenShift Service Mesh pour l'application du modèle Zero Trust, consultez cet article de blog. Consultez la documentation pour savoir comment utiliser cert-manager avec OpenShift Service Mesh.

Débuter avec OpenShift Service Mesh

Pour en savoir plus sur Red Hat OpenShift Service Mesh, lisez cet article de blog ainsi que cet article sur le Service Mesh à clusters multiples. 

Pour utiliser un Service Mesh, vous devez d'abord installer Red Hat OpenShift Service Mesh 3 Operator. S'il s'agit de votre premier Service Mesh, nous vous conseillons d'utiliser le mode ambiant d'Istio, qui est nettement plus économe en ressources que le mode sidecar traditionnel. Pour en savoir plus sur le mode ambiant d'Istio, lisez la documentation. 

Pour découvrir un exemple complet de l'utilisation d'OpenShift Service Mesh avec la surveillance de la charge de travail utilisateur, le traçage distribué et Kiali, consultez ce schéma de solution.