Red Hat OpenShift Service Mesh 3 : mise à jour de la version préliminaire pour les développeurs

Cette année, nous avons annoncé un nouvel opérateur pour Istio sur Red Hat OpenShift disponible en tant que version préliminaire pour les développeurs pour la prochaine génération d'OpenShift Service Mesh, version 3. Cet article fournit des renseignements importants sur les changements apportés à OpenShift Service Mesh en 2024. Nous avons continué à développer Sail Operator tout en assurant l'assistance sur OpenShift Service Mesh 2 et en recueillant des commentaires sur nos projets pour Service Mesh 3. Même si ce nouvel opérateur est encore en version préliminaire pour les développeurs, cet article fait le point, aborde les projets à venir et donne quelques conseils de préparation pour la migration vers OpenShift Service Mesh 3.

Mises à jour de Service Mesh 3.0

L'opérateur Kubernetes Service Mesh 3 est en cours de développement sous le nom « Sail Operator » et est disponible en tant qu'opérateur Kubernetes communautaire sur la plateforme Operator Hub d'OpenShift. L'opérateur Sail Kubernetes est mis à jour tous les soirs. Il s'agit donc d'un travail en cours susceptible d'être modifié. Il peut évoluer et différer de la description faite dans cet article de blog. Nous vous invitons donc à ne l'utiliser qu'à titre expérimental pour le moment. Consultez le fichier README inclus pour obtenir les informations les plus récentes sur cet opérateur Kubernetes.

Nous prévoyons de déplacer cet opérateur Kubernetes communautaire vers l'organisation istio-ecosystem en amont pour renforcer la collaboration, tout en apportant des améliorations au projet Istio principal afin d'améliorer la compatibilité d'Istio sur OpenShift. Les artéfacts de produit en aval d'OpenShift Service Mesh 3 résideront dans la nouvelle organisation openshift-service-mesh, tandis que l'organisation maistra continuera à être utilisée pour Service Mesh 2.

Un opérateur Kubernetes uniquement pour Istio

Comme indiqué dans un autre article de blog, OpenShift Service Mesh 3 sera basé sur un nouvel opérateur Kubernetes pour Istio. Contrairement à l'opérateur Kubernetes OpenShift Service Mesh 2 actuel, ce nouvel opérateur ne gère que les ressources Istio et ne tente pas de configurer des intégrations Istio comme Kiali. Les composants complémentaires, tels que Kiali, les indicateurs de mesure, le suivi et d'autres éléments seront gérés par des opérateurs Kubernetes de produits pris en charge de manière indépendante.

À la sortie de Sail Operator, la ressource personnalisée pour l'installation du plan de contrôle Istio s'appelait IstioHelmInstall. Cette ressource a été renommée « Istio » pour indiquer qu'elle est responsable de la création et de la gestion d'une seule instance Istio (un plan de contrôle et un plan de données).

Contrairement à la ressource personnalisée ServiceMeshControlPlane utilisée dans OpenShift Service Mesh 2, la ressource Istio utilise les valeurs Helm d'Istio en amont pour définir la configuration d'Istio. Les utilisateurs peuvent ainsi convertir plus facilement les exemples de configuration de la communauté pour OpenShift Service Mesh 3. Ce modèle permet également de s'assurer que la communauté Istio contribue à l'amélioration de la configuration. Nous n'avons pas exclu une convergence future avec l'API communautaire Istio Operator, qui est utilisée avec le processus d'installation d'istioctl et l'installation déconseillée de l'opérateur Istio en amont.

Nous allons notamment affiner l'organisation de la configuration et des améliorations pour mieux prendre en charge des fonctions telles que les révisions d'Istio, les mises à niveau de type canary et l'architecture multi-client. Veuillez consulter le fichier README de l'opérateur Kubernetes pour obtenir des informations plus récentes.

Sélection des versions

Lorsque nous avons lancé Sail Operator, il déployait la dernière version d'Istio, à savoir la branche Master d'Istio en cours de développement. Bien que cette méthode soit pratique pour tester les dernières nouveautés de la communauté Istio, les utilisateurs doivent utiliser une version officielle d'Istio pour garantir la stabilité et la compatibilité avec istioctl et les intégrations telles que Kiali.

Par défaut, nous utilisons désormais la dernière version d'Istio, à savoir la 1.20. Configurez ce paramètre avec le champ version dans la CRD Istio. Lors de la création d'une instance avec la console OpenShift, il est possible de sélectionner l'une des versions d'Istio disponibles dans un menu déroulant. Ces versions sont définies dans le fichier versions.yaml, qui sera mis à jour pour chaque nouvelle version d'Istio disponible.

Menu déroulant du sélecteur de version d'Istio

Le futur opérateur Kubernetes OpenShift Service Mesh 3, basé sur Sail Operator, gérera les versions d'OpenShift Service Mesh de la même manière. Ce champ version est similaire au champ version de la ressource ServiceMeshControlPlane dans Service Mesh 2.x, avec une nette différence : les utilisateurs peuvent spécifier une version jusqu'au niveau de la version de « correctif » Z (par exemple, 3.1.1). Nous ne prendrons en charge que les dernières versions de correctif d'OpenShift Service Mesh, mais cette fonctionnalité permettra d'associer une version de correctif « Z » particulière ou d'y revenir, avec à la clé davantage de contrôle et de flexibilité pour la gestion des mises à jour des correctifs.

Validation de la configuration

La configuration d'Istio avec la nouvelle CRD s'effectue principalement dans le champ values. Ce champ essentiel permet aux utilisateurs de faire référence directement aux valeurs de configuration d'Istio Helm. Nous avons ajouté une validation à ce champ pour détecter les valeurs de configuration inexistantes et d'autres erreurs de configuration, sur la base des  validations protobuf d'Istio en amont.

Ces validations permettent également de gérer le champ values comme suit :

$ oc explain istio.spec.values 
KIND:     Istio 
VERSION:  operator.istio.io/v1alpha1 
RESOURCE: values <Object> 
DESCRIPTION: 
    Values defines the values to be passed to the Helm chart when installing 
    Istio. 
FIELDS: 
  base <Object> 
  cni <Object> 
  defaultRevision <string> 
  global <Object> 
  istio_cni <Object> 
  istiodRemote <Object> 
  meshConfig <> 
  ownerName <string> 
  pilot <Object> 
  revision <string> 
  revisionTags <[]string> 
  sidecarInjectorWebhook <Object> 
  telemetry <Object> 
  ztunnel <>

Dans la mesure où il peut être souhaitable d'ignorer ces validations (par exemple, pour accéder à une configuration expérimentale qui ne fait pas encore partie du schéma protobuf d'Istio), nous avons également inclus un champ rawValues, identique à values, mais qui n'est pas validé.

Veuillez noter que les champs resource, values et rawValues d'Istio sont expérimentaux et susceptibles d'être modifiés. Reportez-vous au fichier README du projet pour obtenir les informations les plus récentes.

État et configuration d'Istio

Vous devez valider l'état de votre plan de contrôle une fois que vous avez appliqué la configuration d'Istio. Pour ce faire, vous pouvez utiliser la commande suivante :

$ kubectl get istioundefinedundefinedundefined

NAME         READY  STATUS VERSION AGE

istio-sample True  Healthy v1.20.0 62sundefinedundefined

Vous pouvez également utiliser le champ status :

Définition de ressources personnalisées Istio

Une fois la configuration développée, vous pouvez utiliser le champ status.appliedValues pour vérifier que tout s'est déroulé comme prévu à l'aide du champ spec.values.

Istio sur OpenShift

Dans le cadre de notre initiative de convergence avec la version communautaire d'Istio, nous continuons à contribuer au projet en amont pour améliorer la compatibilité d'Istio sur OpenShift. Nous le faisons pour notre propre intérêt (pour simplifier la mise en production d'Istio) ainsi que pour celui de la communauté, des clients et des partenaires. Nos contributions facilitent le fonctionnement de la version communautaire d'Istio sur OpenShift tout en offrant un processus d'intégration simple pour la version d'OpenShift Service Mesh prise en charge.

Ce projet a notamment pour but de supprimer la nécessité d'accorder le privilège SCC (Security Context Constraint) anyuid  aux composants du plan de contrôle et du plan de données Istio, comme récemment mis en évidence dans Istio 1.20. Nous apporterons régulièrement des contributions similaires. La plus importante consistera à faire fonctionner Ambient Mesh d'Istio sur OpenShift.

Meilleures pratiques en matière de passerelle

Dès le départ, cet opérateur Kubernetes a automatiquement installé des passerelles du même type que le profil de configuration d'installation par défaut d'Istio. Cette pratique est cohérente avec OpenShift Service Mesh 2.x, qui crée une passerelle d'entrée et de sortie par défaut, respectivement istio-ingressgateway et istio-egressgateway.

Bien que ces passerelles créées automatiquement soient pratiques pour commencer, elles n'offrent pas le niveau de configuration nécessaire pour les environnements de production. Nous pensons également qu'il est préférable de créer et gérer les passerelles avec leurs applications dans le plan de données, plutôt que dans le plan de contrôle. Du point de vue de la sécurité, il est recommandé de créer et gérer les passerelles avec leurs applications, afin de limiter le champ d'application d'une passerelle à un ensemble plus restreint d'applications et de lui permettre d'adopter le cycle de vie de ses applications plutôt que celui du plan de contrôle.

Nous avons donc décidé de supprimer ces passerelles de plan de contrôle pour aider les utilisateurs à créer des passerelles avec leurs applications à l'aide de l'injection de passerelles ou de l'API Gateway de Kubernetes. Les passerelles istio-ingressgateway et istio-egressgateway, telles que spécifiées dans ServiceMeshControlPlane d'OpenShift Service Mesh 2.x, ne seront pas incluses dans Service Mesh 3.0. Nous les remplacerons par des exemples de configuration de passerelles pour l'application Bookinfo à l'aide de l'injection de passerelles et de l'API Gateway de Kubernetes.

Avec l'injection de passerelle, les passerelles sont créées et gérées comme n'importe quelle autre charge de travail sur Kubernetes ou OpenShift, grâce à une ressource de déploiement injectée avec un proxy Envoy. Cette approche confère un contrôle complet de la passerelle au propriétaire de l'application. Il s'agit de la méthode recommandée pour créer et gérer des passerelles dans OpenShift Service Mesh 2.3 et versions ultérieures.

Avec l'API Gateway, une instance de déploiement de passerelle est créée et configurée avec chaque instance de passerelle à partir de la version préliminaire d'OpenShift Service Mesh 2.4.

Ces options permettent de créer et gérer des passerelles avec des applications, idéalement dans le cadre d'un workflow GitOps.

API Gateway de Kubernetes

 L'API Gateway de Kubernetes représente la prochaine génération d'API pour la modélisation de la mise en réseau dans Kubernetes. Par rapport à l'API Ingress actuelle de Kubernetes, elle offre nettement plus de flexibilité et d'extensibilité pour la gestion de la mise en réseau d'une grande entreprise. Initialement conçue pour gérer le trafic nord-sud des clients situés à l'extérieur du cluster, elle s'est ensuite développée pour inclure le trafic est-ouest, notamment Service Mesh. L'initiative GAMMA a été créée pour définir la manière dont l'API Gateway peut couvrir les cas d'utilisation de Service Mesh. Istio inclut maintenant les exemples de configuration de l'API Gateway pour la plupart des tâches documentées, comme la gestion du trafic.

L'API Gateway reste une fonction de version préliminaire dans OpenShift Service Mesh 2.4 et doit être activée avec un feature flag, mais elle est désormais disponible dans la communauté. La version 1.0 de cette API est disponible dans Istio 1.20 (qui sera inclus dans OpenShift Service Mesh 2.6 et versions ultérieures). Istio prévoit de faire de l'API Gateway l'API par défaut pour l'ensemble de la gestion du trafic, tout en continuant à prendre en charge les API Istio (Gateway, VirtualService, DestinationRule, etc.) dans un avenir proche.

Le projet de l'API Gateway pourrait fournir une norme commune pour les réseaux Kubernetes, bien au-delà de Service Mesh.

Nous développons une version d'OpenShift Ingress basée sur l'API Gateway que les utilisateurs peuvent déployer indépendamment d'un Service Mesh via l'opérateur Ingress de l'API Gateway. Pour en savoir plus sur ce projet et sur l'API Gateway, consultez cet article de blog et la dernière mise à jour.

En parallèle, l'équipe à l'origine de la solution 3Scale API Management travaille sur le projet Kuadrant.io qui utilisera l'API Gateway pour traiter des cas d'utilisation liés à l'entrée du trafic externe dans des passerelles Ingress, comme la connectivité multicluster, l'équilibrage de charge global, la limitation du débit et les autorisations. Vous trouverez davantage d'informations sur ce projet dans un prochain article de blog.

Premiers pas avec les modules complémentaires Istio, comme Kiali

Changement notable dans OpenShift Service Mesh 3.0 : l'opérateur Kubernetes gère uniquement Istio. Les intégrations telles que Kiali, le traçage distribué et les indicateurs de mesure seront installées et gérées de façon indépendante. Bien que cette méthode rallonge la prise en main de ces composants, nous pensons que la modularité et la flexibilité accrues de leur configuration en valent la peine.

Pour aider les utilisateurs à être rapidement opérationnels, nous avons ajouté des instructions au fichier README de l'opérateur Kubernetes pour configurer Istio avec Istioctl, des passerelles de test, Prometheus, Jaeger et Kiali. Ils disposent ainsi d'un environnement de démonstration/développement à peu près équivalent à ce que propose actuellement la version prête à l'emploi d'OpenShift Service Mesh 2.x. Cet environnement offre également un aperçu du workflow d'installation que nous prévoyons de fournir dans OpenShift Service Mesh 3, où Istio sera installé seul et où les modules complémentaires seront installés de manière indépendante. Bien entendu, la version prise en charge de Service Mesh 3.0 utilisera des opérateurs Kubernetes de produits pris en charge pour chaque module complémentaire Istio, avec une distribution d'Istioctl prise en charge. Ces configurations de modules complémentaires Istio communautaires sont uniquement destinées à des fins de démonstration et de développement, et ne doivent pas être utilisées dans des environnements de production.

Préparation pour Service Mesh 3.0

Les utilisateurs d'OpenShift Service Mesh 2 peuvent d'ores et déjà se préparer à l'adoption de Service Mesh 3.0.

OpenShift Service Mesh 3 continuera de se baser sur Istio et les API stables d'Istio susceptibles d'être utilisées par les utilisateurs finaux ne changeront pas. Les ressources de configuration du plan de contrôle, telles que ServiceMeshControlPlane, ServiceMeshMemberRoll et ServiceMeshMemberRoll, changent dans OpenShift Service Mesh 3 et devront être migrées. Ces ressources sont généralement gérées par les administrateurs ou les équipes chargées de la plateforme plutôt que par les propriétaires des applications. Nous continuerons d'explorer différentes méthodes pour permettre aux administrateurs de migrer leurs configurations de plan de contrôle vers des configurations Service Mesh 3.

Aucune modification n'est apportée à la configuration propre aux applications (les ressources Istio telles que VirtualServices, DestinationRules et même PeerAuthentication). Ainsi, les utilisateurs pourront commencer ou étendre leur utilisation d'OpenShift Service Mesh 2 sans avoir à migrer des configurations propres aux applications ou aux services lors de la migration vers OpenShift Service Mesh 3.

Certaines mesures peuvent dès maintenant faciliter la migration vers OpenShift Service Mesh 3.0. En plus d'utiliser la dernière version d'OpenShift Service Mesh (2.4 et versions ultérieures), les utilisateurs peuvent effectuer ce qui suit :

• Adopter l'injection de passerelle ou migrer vers celle-ci pour créer et gérer des passerelles Istio avec leurs applications plutôt qu'avec le plan de contrôle Istio (c'est le cas par défaut dans Service Mesh 2.0). Comme décrit ci-dessus, le plan de contrôle de la version 3.0 ne créera pas de passerelles.
• Utiliser le mode à l'échelle du cluster si un seul plan de contrôle suffit. Dans ce mode, la ressource Istiod s'exécute au niveau du cluster. Il s'agira du mode par défaut dans Service Mesh 3.0, avec la possibilité de créer plusieurs plans de contrôle à l'aide de la future fonction de plan de contrôle multiple.
• Configurer Service Mesh afin d'utiliser la surveillance de la charge de travail des utilisateurs d'OpenShift ou l'observabilité de Red Hat Advanced Cluster Management pour la capture des indicateurs de mesure. Ceux-ci fourniront une pile de surveillance avec alertes adaptée à la production qui sera beaucoup plus configurable et extensible que la pile d'indicateurs installée avec OpenShift Service Mesh 2.x (et qui sera supprimée dans Service Mesh 3).
• Utiliser des ressources Kiali et Jaeger configurées en externe plutôt que de les configurer directement dans la ressource ServiceMeshControlPlane. En plus d'offrir une gestion flexible de Kiali et Jaeger, ces ressources seront configurées indépendamment dans Service Mesh 3.

Nous publierons prochainement un article de blog plus approfondi sur chacun de ces sujets.

Quel avenir pour OpenShift Service Mesh ?

Le lancement de notre prochaine version, OpenShift Service Mesh 2.5 (basée sur Istio 1.18), est prévu pour le début de l'année 2024. Nous avons également décidé de lancer une version 2.6 basée sur Istio 1.20 (ou une version ultérieure) en 2024 pour nous assurer que les clients bénéficient d'au moins un an d'assistance simultanée pour passer de la version 2 à la version 3 d'OpenShift Service Mesh. La version 2.6 nous laissera également plus de temps pour recueillir l'avis des utilisateurs sur la version préliminaire d'OpenShift Service Mesh 3.

Pour OpenShift Service Mesh 3, nous continuons à améliorer le nouvel opérateur Kubernetes, notamment en modifiant les définitions de ressources personnalisées pour mieux gérer la configuration d'Istio et en ajoutant des fonctions pour mieux prendre en charge les mises à niveau de type canary des plans de contrôle Istio. Nous visons la fin du 1er trimestre 2024 pour la version préliminaire et une disponibilité générale au cours du second semestre 2024. Bien entendu, ces objectifs sont susceptibles d'évoluer. L'assistance client sera toujours assurée sur OpenShift Service Mesh 2.x, jusqu'à ce que nous soyons en mesure de mettre à disposition une version satisfaisante d'OpenShift Service Mesh 3.

Consultez cette page pour en savoir plus sur Red Hat OpenShift Service Mesh.