2.7. Gestion du trafic

Vous pouvez utiliser une passerelle pour gérer le trafic entrant et sortant de votre maillage afin de spécifier le trafic que vous souhaitez voir entrer ou sortir du maillage. Les configurations de passerelle sont appliquées aux proxys Envoy autonomes qui s'exécutent à la périphérie du maillage, plutôt qu'aux proxys Envoy sidecar qui s'exécutent aux côtés de vos charges de travail de service.

Contrairement à d'autres mécanismes de contrôle du trafic entrant dans vos systèmes, tels que les API Kubernetes Ingress, les passerelles Red Hat OpenShift Service Mesh utilisent toute la puissance et la flexibilité du routage du trafic.

La ressource de passerelle Red Hat OpenShift Service Mesh peut utiliser les propriétés d'équilibrage de charge de la couche 4-6, telles que les ports, pour exposer et configurer les paramètres TLS de Red Hat OpenShift Service Mesh. Au lieu d'ajouter le routage du trafic de la couche application (L7) à la même ressource API, vous pouvez lier un service virtuel Red Hat OpenShift Service Mesh ordinaire à la passerelle et gérer le trafic de la passerelle comme tout autre trafic de plan de données dans un maillage de services.

Les passerelles sont principalement utilisées pour gérer le trafic entrant, mais vous pouvez également configurer des passerelles de sortie. Une passerelle de sortie vous permet de configurer un nœud de sortie dédié pour le trafic quittant le maillage. Cela vous permet de limiter les services qui ont accès aux réseaux externes, ce qui ajoute un contrôle de sécurité à votre maillage de services. Vous pouvez également utiliser une passerelle pour configurer un proxy purement interne.

L'exemple suivant montre un exemple de configuration de passerelle pour le trafic HTTPS externe entrant :

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

Cette configuration de passerelle permet au trafic HTTPS provenant de ext-host.example.com d'entrer dans le maillage sur le port 443, mais ne spécifie aucun routage pour le trafic.

Pour spécifier le routage et pour que la passerelle fonctionne comme prévu, vous devez également lier la passerelle à un service virtuel. Pour ce faire, vous utilisez le champ Passerelles du service virtuel, comme le montre l'exemple suivant :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

Vous pouvez ensuite configurer le service virtuel avec des règles de routage pour le trafic externe.

Une passerelle d'entrée est un équilibreur de charge fonctionnant à la périphérie du réseau maillé et recevant des connexions HTTP/TCP entrantes. Elle configure les ports et les protocoles exposés, mais n'inclut aucune configuration d'acheminement du trafic. Le routage du trafic entrant est plutôt configuré avec des règles de routage, de la même manière que pour les demandes de services internes.

Les étapes suivantes montrent comment créer une passerelle et configurer un site VirtualService pour exposer un service de l'application d'exemple Bookinfo au trafic extérieur pour les chemins /productpage et /login.

Dans Red Hat OpenShift Service Mesh, la passerelle d'entrée permet aux fonctionnalités telles que la surveillance, la sécurité et les règles de routage de s'appliquer au trafic qui entre dans le cluster. Utilisez une passerelle Service Mesh pour exposer un service en dehors du service mesh.

$ oc get svc istio-ingressgateway -n istio-system

$ export INGRESS_HOST=$(oc -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

Les routes OpenShift pour les passerelles Istio sont automatiquement gérées dans Red Hat OpenShift Service Mesh. Chaque fois qu'une passerelle Istio est créée, mise à jour ou supprimée dans le service mesh, une route OpenShift est créée, mise à jour ou supprimée.

spec:
  istio:
    gateways:
     istio-egressgateway:
       autoscaleEnabled: false
       autoscaleMin: 1
       autoscaleMax: 5
     istio-ingressgateway:
       autoscaleEnabled: false
       autoscaleMin: 1
       autoscaleMax: 5
       ior_enabled: true

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway1
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.info.com
    - info.example.com

oc -n <control_plane_namespace> get routes

NAME           HOST/PORT             PATH  SERVICES               PORT  TERMINATION   WILDCARD
gateway1-lvlfn info.example.com        istio-ingressgateway   <all>               None
gateway1-scqhv www.info.com            istio-ingressgateway   <all>               None

Une entrée de service ajoute une entrée au registre de service que Red Hat OpenShift Service Mesh maintient en interne. Après avoir ajouté l'entrée de service, les proxys Envoy envoient du trafic au service comme s'il s'agissait d'un service dans votre maillage. Les entrées de service vous permettent d'effectuer les opérations suivantes :

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

Spécifiez la ressource externe à l'aide du champ hosts. Vous pouvez le qualifier complètement ou utiliser un nom de domaine préfixé par un joker.

Vous pouvez configurer des services virtuels et des règles de destination pour contrôler le trafic vers une entrée de service de la même manière que vous configurez le trafic pour tout autre service dans le maillage. Par exemple, la règle de destination suivante configure la route du trafic pour utiliser TLS mutuel afin de sécuriser la connexion au service externe ext-svc.example.com qui est configuré à l'aide de l'entrée de service :

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

Vous pouvez acheminer des requêtes dynamiquement vers plusieurs versions d'un microservice via Red Hat OpenShift Service Mesh avec un service virtuel. Avec les services virtuels, vous pouvez :

spec:
  hosts:

spec:
  http:
  - match:

spec:
  http:
  - match:
    - destination:

Les règles de destination sont appliquées après l'évaluation des règles de routage des services virtuels, de sorte qu'elles s'appliquent à la destination réelle du trafic. Les services virtuels acheminent le trafic vers une destination. Les règles de destination configurent ce qu'il advient du trafic à cette destination.

Par défaut, Red Hat OpenShift Service Mesh utilise une politique d'équilibrage de charge des moindres demandes, où l'instance de service dans le pool avec le plus petit nombre de connexions actives reçoit la demande. Red Hat OpenShift Service Mesh prend également en charge les modèles suivants, que vous pouvez spécifier dans les règles de destination pour les requêtes vers un service ou un sous-ensemble de services particulier.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3
    labels:
      version: v3

Ce guide fait référence à l'application Bookinfo pour fournir des exemples de routage dans une application d'exemple. Installez l'application Bookinfo pour découvrir comment fonctionnent ces exemples de routage.

L'exemple d'application Service Mesh Bookinfo se compose de quatre microservices distincts, chacun ayant plusieurs versions. Après l'installation de l'exemple d'application Bookinfo, trois versions différentes du microservice reviews s'exécutent simultanément.

Lorsque vous accédez à la page de l'application Bookinfo /product dans un navigateur et que vous la rafraîchissez plusieurs fois, il arrive que la critique de livre contienne des étoiles et d'autres fois non. Sans version de service explicite par défaut, Service Mesh achemine les requêtes vers toutes les versions disponibles, l'une après l'autre.

Ce tutoriel vous aide à appliquer des règles qui acheminent tout le trafic vers v1 (version 1) des microservices. Par la suite, vous pourrez appliquer une règle pour acheminer le trafic en fonction de la valeur d'un en-tête de requête HTTP.