Comment les microservices communiquent-ils avec le monde extérieur ?

Une des problématiques phares dans la gestion du trafic dans Istio est d’assurer la communication entre services, notamment si ceux ci ne font pas partie du mesh. Comment faire pour qu’ils soient traités comme tout autre service d’Istio ? C’est dans ce cadre qu’interviennent les services entries. L’objectif de cet article sera alors de décortiquer toutes les facettes des services entries.

Principe

  Les Services Entries permettent d’ajouter des services supplémentaires au réseau de microservices d’Istio. Ceci permet aux services d’Istio d’accéder aux services spécifiés manuellement à l’aide des services entries. Ces services entries peuvent être  des services externes (par exemple, les API Web) ou des services internes au cluster kubernetes, c’est à dire  ne faisant pas partie du data plane de services d’Istio (par exemple les services dans Kubernetes).

Les principaux cas d’utilisation des services entries s’inscrivent dans les contextes ci-dessous:

  • Intégration des applications externes: communications avec des services qui ne sont pas déployés dans Kubernetes ou qui ne sont pas directement accessibles depuis le  data plane d’Istio.
  • Environnement multi-cluster : Assemblement de plusieurs services à partir de plusieurs clusters Kubernetes.
  • Extension du mesh au-delà du cluster Kubernetes : ajout de charges de travail déployées sur du matériel physique ou des machines virtuelles à un mesh existant.
  • Application de politiques de trafic sur les services externes: par exemple les retries, les circuit breakers, routage par pourcentage (plus d’informations ici https://www.beopenit.com/gestion-des-panne-dans-istio/ ), tracing, etc.

Caractéristiques

Un objet serviceEntry décrit les propriétés d’un service (nom DNS, VIP, ports, protocoles, endpoints). 

Dans cette section, nous allons voir plus en détails l’objet serviceEntry ainsi que ses composants à savoir le serviceEntry.endpoint, le serviceEntry.location et le serviceEntry.resolution .

ServiceEntry 

ServiceEntry permet d’ajouter des services supplémentaires dans le data plane  d’Istio.

  • Hosts: Ce champ définit les hôtes associés à un  ServiceEntry. Il peut s’agir d’un nom DNS avec un préfixe générique.

    1. Le champ hosts est utilisé pour sélectionner les hôtes correspondants dans les VirtualServices et DestinationRules.
    2. Pour le trafic HTTP, l’en-tête host / Authority HTTP sera mis en correspondance avec le champ hosts.
    3. Pour le trafic HTTP ou TLS contenant l’indication de nom de serveur (SNI), la valeur SNI sera comparée au champ hosts.

    Il est à noter que, lorsque la résolution est définie sur le type DNS et qu’aucun point de terminaison n’est spécifié, le champ host sera utilisé comme DNS du point de terminaison vers lequel sera acheminé le trafic.

  • Addresses: Il correspond aux adresses IP virtuelles associées au service. Si une ou plusieurs adresses IP sont spécifiées, le trafic entrant sera identifié comme appartenant à ce service si l’IP de destination correspond aux IP / CIDR spécifiées dans le champ des adresses. Si le champ Addresses est vide, le trafic sera identifié uniquement en fonction du port de destination. Dans de tels scénarios, le port sur lequel le service est accédé ne doit être partagé avec aucun autre service du maillage. En d’autres termes, le sidecar se comportera comme un simple proxy TCP, transmettant le trafic entrant sur un port spécifié au point de terminaison de destination / IP spécifié.
  • Ports: Ils correspondent aux ports associés au service externe.
  • Location: Ce champ permet de spécifier si le service doit être considéré comme externe au mesh ou faisant partie de celui-ci.
  • Resolution: Il définit le mode de découverte de service pour les hôtes. Des précautions doivent être prises lors de la définition du mode de résolution sur NONE pour un port TCP sans adresses IP associées. Dans de tels cas, le trafic vers n’importe quelle IP sur ledit port sera autorisé (c’est-à-dire 0.0.0.0:)
  • .

  • Endpoints: Un ou plusieurs points de terminaison associés au service.
  • Names: Une liste des namespaces vers lesquels ce service est exporté. L’exportation d’un service permet son utilisation par des side-cars, des passerelles et des services virtuels définis dans d’autres namespaces. Cette fonctionnalité fournit un mécanisme permettant aux propriétaires de services et aux administrateurs du mesh de contrôler la visibilité des services au-delà des limites de l’espace de noms. Si aucun namespace n’est spécifié, le service est exporté vers tous les namespaces par défaut.
  • SubjectAltName: Il correspond à une liste d’appellations autorisées pour les workloads qui implémentent ce service.
Copy to Clipboard

ServiceEntry.endpoint

 Le serviceEntry.endpoint définit une adresse réseau (IP ou nom d’hôte) associée au service mesh.

Ses différents attributs sont les suivants:

  • Address: Adresse associée au endpoint réseau sans le port. Les noms de domaine peuvent être utilisés si et seulement si la résolution est définie dans la configuration du DNS.
  • Port: Ensemble de ports associés au endpoint. Les ports doivent être associés à un nom de port déclaré comme faisant partie du service.
  • Network: Il permet à Istio de regrouper les endpoints se situant sur le même domaine / réseau L3. Tous les endpoints d’un même réseau sont supposés être directement accessibles les uns par les autres.
  • label: Une ou plusieurs étiquettes associées au endpoint.
  • Locality: La localité associée au endpoint. Une localité correspond à un domaine de défaillance (par exemple, pays / région / zone).
  • weight: Poids d’équilibrage de charge associé au endpoint. Les points de terminaison avec des poids plus élevés recevront un trafic proportionnellement plus élevé.

serviceEntry.location

Il spécifie si le service fait partie du mesh Istio ou est externe à celui-ci. Il détermine également le comportement de plusieurs fonctionnalités, telles que l’authentification mTLS de service à service, l’application des politiques, etc. Lors de la communication avec des services en dehors du service mesh, l’authentification mTLS d’Istio est désactivée et l’application des politiques est effectuée côté client.

Valeurs possibles:

         – Mesh internal: Signifie que le service fait partie du mesh. 

         – Mesh external: Signifie que le service est externe au mesh. Généralement utilisé pour indiquer les services externes consommés via les API.

serviceEntry.resolution

La résolution détermine la manière dont le proxy résoudra les adresses IP des endpoints réseau associés au service, afin qu’il puisse router vers l’un d’eux. 

Valeurs possibles:

  • NONE: Supposons que les connexions entrantes ont déjà été résolues (vers une adresse IP de destination spécifique). Après avoir effectué toutes les configurations liées au routage, le proxy transmet la connexion à l’adresse IP à laquelle la connexion était liée.
  • STATIC: Équivaut à utiliser les adresses IP statiques spécifiées dans les endpoints  comme instances de support associées au service.
  • DNS: Essayer de résoudre l’adresse IP en interrogeant le serveur DNS, lors du traitement de la demande. Si aucun noeud final n’est spécifié, le proxy résoudra l’adresse DNS spécifiée dans le champ hosts, si des caractères génériques ne sont pas utilisés. Si des points de terminaison sont spécifiés, les adresses DNS spécifiées dans les points de terminaison seront résolues pour déterminer l’adresse IP de destination.

Exemple

  • Scénario

Considérons un service externe hébergé par someprovider.com qui nécessite une authentification mutuelle. Une solution consiste à déployer des certificats pour chaque service déployé dans notre cluster Kubernetes qui utiliserait le service externe.

Cela pourrait poser des contraintes:

  • Il peut y avoir plusieurs services,
  • Chacun nécessitera des modifications potentiellement intrusives du code d’application pour prendre en charge du mTLS,
  • En plus de cela, nous devons distribuer et faire une rotation des clefs.

Ces contraintes peuvent être levées en configurant Istio pour agir en tant que proxy direct. Ce proxy va servir de terminaison SSL pour avoir une communication sécurisée entre les microservices.

Mise en oeuvre

Copy to Clipboard

Copy to Clipboard

Deux ressources ont été définies: une ServiceEntry et la DestinationRule correspondante. La première inscrit someprovider.com comme serviceEntry, le plaçant ainsi dans le champ d’action d’Istio.

La seconde spécifie le mode d’authentification, le  CA pour vérifier le fournisseur, la clé privée et le certificat pour authentifier le client. Pratique non ?!

 Un objet serviceEntry permet à un ou plusieurs services externes d’être traités comme tout autre service interne au mesh. Par ailleurs, il est important de faire la distinction avec l’egress proxy Envoy d’Istio. En effet celui-ci permet d’accéder à des services inconnus externes par défaut, tandis que les services entries seront gérés par Istio et profiteront alors des politiques de trafic. Toutefois, il est à reconnaître que les serviceEntries ne sont pas courants; vous pouvez déployer un système distribué complet dans Istio sans jamais toucher à ce concept et pourtant, il est classé parmi les principaux concepts d’Istio, il faudrait alors au moins être conscient de leur utilité !

Halima GAYE
Halima GAYEIngénieur Cloud & DevOps