Trafic entrant pour votre réseau maillé

Un maillage de services facilite les communications entre les services exécutés dans le réseau maillé. Mais comment recevoir du trafic dans votre réseau maillé ? Cette opération, qui consiste à diriger le trafic de l'extérieur vers l'intérieur de votre réseau maillé via un point d'entrée, peut être effectuée à l'aide d'une passerelle.

Ce document explique comment utiliser Cloud Load Balancing comme passerelle pour recevoir du trafic dans votre réseau maillé.

Présentation

Lorsque vous concevez votre maillage de services, vous devez prendre en compte le trafic provenant de ces sources :

  • Trafic provenant de l'intérieur de votre réseau maillé
  • Trafic provenant de l'extérieur de votre réseau maillé

Le trafic provenant de l'intérieur de votre réseau maillé parcourt le plan de données du maillage de services pour atteindre un backend ou un point de terminaison associé au service de destination. Cependant le trafic provenant de l'extérieur de votre réseau maillé doit d'abord atteindre le plan de données du maillage de services.

Dans l'exemple suivant de trafic provenant de l'intérieur de votre réseau maillé, Traffic Director configure vos proxys side-car. Ces proxys side-car constituent le plan de données de votre maillage de services. Si le service A souhaite communiquer avec le service B :

  1. Le service A envoie une requête au service B par nom.
  2. Cette requête est interceptée et redirigée vers le proxy side-car du service A.
  3. Le proxy side-car envoie ensuite la requête à un point de terminaison associé au service B.
Trafic interne au maillage de services géré par le plan de données du maillage de services (cliquez pour agrandir)
Le trafic interne au maillage de services est géré par le plan de données du maillage de services (cliquez pour agrandir).

Dans l'exemple suivant, le trafic provient de l'extérieur de votre maillage de services et ne parcourt pas le plan de données du maillage de services.

Le trafic externe au maillage de services n'est pas géré par le plan de données du maillage de services (cliquez pour agrandir)
Le trafic externe au maillage de services n'est pas géré par le plan de données du maillage de services (cliquez pour agrandir)

Dans cet exemple, le client se trouve en dehors de votre maillage de services. Comme il ne participe pas directement au maillage, le client ignore quels points de terminaison appartiennent aux services au sein du réseau maillé. En d'autres termes, comme le client n'envoie pas de requêtes sortantes à l'aide d'un proxy configuré par Traffic Director, il ne sait pas quelles paires adresse-port IP utiliser lors de l'envoi de trafic au service A ou au service B. Sans ces informations, le client ne peut accéder aux services de votre réseau maillé.

Les modèles de passerelle décrits dans le présent document vous permettent de résoudre ce problème : comment recevoir du trafic dans votre réseau maillé ?

Ce document aborde les questions suivantes :

  • Considérations générales concernant votre passerelle.
  • Présentation des options disponibles lors de la sélection d'une passerelle pour votre réseau maillé.
  • Recommandations d'architecture applicables à la topologie de votre passerelle.

Considérations générales concernant votre passerelle

Cette section présente les aspects à prendre en compte lorsque vous choisissez une passerelle :

  • Comment les clients peuvent-ils accéder à ma passerelle ?
  • Quelles règles dois-je appliquer au trafic qui atteint ma passerelle ?
  • Comment ma passerelle distribue-t-elle le trafic aux services de mon réseau maillé ?

Permettre aux clients d'accéder à la passerelle d'accès vers votre réseau maillé

Les clients ont besoin d'un moyen d'atteindre les services au sein de votre réseau maillé, que ce soit sur l'Internet public, dans votre environnement sur site ou dans Google Cloud. Pour ce faire, vous utilisez généralement une adresse IP et un port routables en mode public ou privé, associés à une passerelle. Les clients extérieurs à votre réseau maillé utilisent cette adresse IP et ce port pour envoyer des requêtes aux services de votre réseau maillé, via votre passerelle.

Cloud Load Balancing fournit diverses options d'équilibrage de charge que vous pouvez utiliser en tant que passerelle vers votre réseau maillé. Voici les principales questions que vous devez vous poser lorsque vous choisissez un équilibreur de charge Google Cloud comme passerelle :

  • Mes clients sont-ils sur l'Internet public, dans un environnement sur site ou font-ils partie de mon réseau cloud privé virtuel (VPC) ?
  • Quels protocoles de communication mes clients utilisent-ils ?

L'option Choisir une passerelle pour votre réseau maillé donne un aperçu des fonctionnalités de Cloud Load Balancing, en fonction de l'emplacement du client et du protocole de communication.

Gérer le trafic au niveau de la passerelle

Comme votre passerelle se trouve à la périphérie de votre réseau maillé, entre les clients externes à celui-ci et les services situés à l'intérieur, celle-ci est l'emplacement adéquat pour appliquer des règles lorsque le trafic entre dans votre réseau maillé. Ces règles incluent les éléments suivants :

  • Gestion du trafic (par exemple, routage, redirections et transformation des requêtes)
  • Sécurité (par exemple, terminaison TLS et protection DDoS de Google Cloud Armor)
  • Mise en cache Cloud CDN

La section Choisir une passerelle pour votre réseau maillé met en évidence les règles pertinentes à appliquer à la périphérie de votre réseau maillé.

Envoyer du trafic depuis la passerelle vers un service de votre réseau maillé

Dès que les règles applicables au trafic entrant sont définies sur la passerelle, celle-ci décide où envoyer ce trafic. Pour ce faire, vous devez configurer des règles de gestion du trafic et d'équilibrage de charge. La passerelle peut, par exemple, inspecter l'en-tête de requête pour identifier le service maillé qui doit recevoir le trafic. Une fois que la passerelle a identifié le service, elle répartit le trafic vers un backend spécifique en fonction d'une règle d'équilibrage de charge.

La section Choisir une passerelle pour votre réseau maillé décrit les backends vers lesquels une passerelle peut envoyer du trafic.

Choisir une passerelle pour votre réseau maillé

Google Cloud propose une large gamme d'équilibreurs de charge pouvant servir de passerelle vers votre réseau maillé. Cette section explique comment choisir une passerelle, en comparant les options suivantes en fonction des dimensions pertinentes pour le modèle de passerelle :

Dans cette section, nous faisons référence aux passerelles de premier et de deuxième niveau. Ces termes sont utilisés pour décrire l'utilisation d'une ou de deux passerelles pour gérer le trafic entrant vers votre réseau maillé.

Vous n'aurez peut-être besoin que d'un seul niveau, un équilibreur de charge unique servant de passerelle vers le réseau maillé. Cependant, avoir plusieurs passerelles est parfois judicieux. Dans ces configurations, une passerelle gère le trafic entrant dans Google Cloud et une passerelle distincte de deuxième niveau gère le trafic au moment où il entre dans le réseau maillé. Par exemple, vous pouvez appliquer des règles de sécurité Google Cloud Armor au trafic entrant dans Google Cloud et des règles de gestion avancée au trafic entrant dans le réseau maillé. Le modèle d'utilisation d'une deuxième passerelle configurée par Traffic Director est décrit dans la section Déployer une passerelle de deuxième niveau à la périphérie du réseau maillé.

Le tableau suivant compare les fonctionnalités disponibles en fonction de l'option de passerelle sélectionnée :

Passerelle Emplacement du client Protocole Règles Backends/points de terminaison
Équilibrage de charge HTTP(S) interne Clients Google Cloud dans la même région que l'équilibreur de charge

Clients sur site dont les requêtes arrivent dans la même région Google Cloud (par exemple, via Cloud VPN ou Cloud Interconnect)
  • HTTP/1.1
  • HTTP/2
  • HTTPS
Gestion avancée du trafic
Terminaison TLS à l'aide de certificats autogérés
Backends dans la même région Google Cloud que l'équilibreur de charge, exécuté sur :

Backends de machines virtuelles sur Compute Engine

Instances de conteneur sur :
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Équilibrage de charge HTTP(S) Clients sur l'Internet public
  • HTTP/1.1
  • HTTP/2
  • HTTPS
  • Gestion du trafic
  • Cloud CDN (y compris backends de bucket Cloud Storage)
  • Terminaison TLS à l'aide de certificats Google ou autogérés
  • Règles SSL
  • Google Cloud Armor pour la protection contre les attaques DDoS et Web
  • Compatibilité IAP pour l'authentification des utilisateurs
Backends dans n'importe quelle région Google Cloud, exécutés sur :

Machines virtuelles sur Compute Engine

Instances de conteneur sur :
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Équilibrage de charge TCP/UDP interne Clients Google Cloud dans n'importe quelle région. Nécessite un accès mondial si les clients se trouvent dans une région différente de l'équilibreur de charge.

Clients sur site dont les requêtes arrivent dans n'importe quelle région Google Cloud (par exemple, via Cloud VPN ou Cloud Interconnect)
TCP Backends dans la même région Google Cloud que l'équilibreur de charge, s'exécutant sur :

Machines virtuelles sur Compute Engine
Équilibrage de charge au niveau du réseau Clients sur l'Internet public TCP ou UDP Backends dans la même région Google Cloud que l'équilibreur de charge, s'exécutant sur :

Machines virtuelles sur Compute Engine
Équilibrage de charge de proxy SSL et équilibrage de charge de proxy TCP Clients sur l'Internet public SSL ou TCP Terminaison TLS utilisant des certificats Google ou autogérés (proxy SSL uniquement)

Règles SSL (proxy SSL uniquement)
Backends dans n'importe quelle région Google Cloud, exécutés sur :

Machines virtuelles sur Compute Engine

Instances de conteneur sur :
  • Google Kubernetes Engine (GKE)
  • Kubernetes
Proxy de périphérie (sur les instances de VM ou de conteneur) configuré par Traffic Director Les clients doivent se trouver à un emplacement où l'une des conditions suivantes s'applique :
  • Ils peuvent envoyer une requête à un équilibreur de charge géré par Google Cloud, qui envoie ensuite la requête au proxy de périphérie. Pour plus d'informations, consultez la section Déployer une passerelle de deuxième niveau à la périphérie de votre réseau maillé du présent document.
  • Ils peuvent envoyer une requête via un proxy (par exemple, un proxy side-car) configuré par Traffic Director.
  • Ils peuvent envoyer une requête directement à l'adresse IP et au port d'une VM ou d'une instance de conteneur qui exécute le proxy de périphérie.
  • HTTP/1.1
  • HTTP/2
Gestion avancée du trafic (y compris la compatibilité avec les expressions régulières) Backends dans n'importe quelle région Google Cloud, exécutés sur :

Machines virtuelles sur Compute Engine

Instances de conteneur sur :
  • Google Kubernetes Engine (GKE)
  • Kubernetes

La page Fonctionnalités de l'équilibreur de charge présente une comparaison détaillée par fonctionnalité. Les pages Fonctionnalités de Traffic Director présentent en détail les fonctionnalités de Traffic Director.

Déployer et configurer des passerelles

Le dernier élément à prendre en compte lors de la sélection de votre passerelle est l'expérience que vous souhaitez fournir aux développeurs ainsi que les outils que vous souhaitez utiliser. Google Cloud propose plusieurs approches pour créer et gérer votre passerelle.

Outil de ligne de commande gcloud et API Compute Engine

L'outil de ligne de commande gcloud et les API Compute Engine vous permettent de configurer les produits d'équilibrage de charge gérés de Google Cloud, ainsi que Traffic Director. La CLI et les API offrent des mécanismes permettant de déployer et de configurer vos ressources Google Cloud de manière impérative. Vous pouvez créer des scripts pour automatiser les tâches répétitives.

Google Cloud Console

L'interface graphique de Google Cloud Console vous permet de configurer Traffic Director et les équilibreurs de charge gérés de Google Cloud. Pour configurer votre modèle de passerelle, vous aurez probablement besoin des interfaces utilisateur de Cloud Load Balancing et de Traffic Director.

GKE et Ingress multicluster

Les contrôleurs de réseau GKE et Anthos sont également compatibles avec le déploiement de Cloud Load Balancing pour l'intégration native avec mise en réseau de conteneurs. Ils fournissent une interface déclarative de style Kubernetes pour le déploiement et la configuration de passerelles. Les contrôleurs GKE Ingress et Anthos Ingress gèrent les équilibreurs de charge internes et externes pour envoyer du trafic vers un seul cluster ou sur plusieurs clusters GKE. La ressource Ingress peut également être paramétrée pour pointer vers des services configurés par Traffic Director qui sont déployés dans des clusters GKE.

Modèles d'architecture de passerelle

Cette section décrit des modèles de haut niveau et fournit des schémas d'architecture pour votre passerelle.

Modèles

Le modèle le plus courant implique l'utilisation d'un équilibreur de charge géré par Google Cloud comme passerelle :

  1. Les clients envoient du trafic à un équilibreur de charge géré par Google Cloud qui fait office de passerelle.
    • La passerelle applique des règles.
  2. La passerelle envoie le trafic à un service dans votre réseau maillé.

Un modèle plus avancé implique l'utilisation de passerelles à deux niveaux. Les passerelles fonctionnent comme suit :

  1. Les clients envoient du trafic à un équilibreur de charge géré par Google Cloud qui sert de passerelle de premier niveau.
    • La passerelle applique des règles.
  2. La passerelle envoie le trafic à un proxy de périphérie (ou à un pool de proxys de périphérie) configuré par Traffic Director.
    • Ce proxy de périphérie sert de passerelle de deuxième niveau. Ce niveau :
      1. Fournit une séparation claire des responsabilités. Par exemple, une équipe peut être chargée du trafic entrant dans Google Cloud, tandis qu'une autre est chargée du trafic entrant dans son propre réseau maillé.
      2. Permet d'appliquer des règles qui ne sont peut-être pas compatibles avec l'équilibreur de charge géré par Google Cloud.
  3. La passerelle de deuxième niveau envoie le trafic à un service dans votre réseau maillé.

Le modèle d'entrée prend fin une fois que le trafic atteint un service intégré au réseau maillé. Le cas courant et des modèles plus avancés sont décrits ci-dessous.

Activer le trafic entrant depuis Internet

Si vos clients se trouvent en dehors de Google Cloud et doivent y accéder via l'Internet public, vous pouvez utiliser l'un des équilibreurs de charge suivants comme passerelle.

Pour en savoir plus sur le choix d'une passerelle adaptée, consultez la section Choisir une passerelle pour votre réseau maillé.

Trafic entrant provenant de clients sur l'Internet public et passant par un équilibreur de charge pour atteindre les services d'un réseau maillé (cliquez pour agrandir)
Trafic entrant provenant de clients sur l'Internet public et passant par un équilibreur de charge pour atteindre les services d'un réseau maillé (cliquez pour agrandir)

Dans ce modèle, l'équilibreur de charge géré par Google Cloud sert de passerelle. La passerelle gère le trafic entrant avant de le transférer vers un service de votre réseau maillé.

Par exemple, vous pouvez choisir l'équilibrage de charge HTTP(S) comme passerelle pour utiliser les éléments suivants :

  • Une adresse IP mondiale Anycast pouvant être routée en mode public, ce qui minimise la latence et les coûts liés au balayage du réseau
  • Google Cloud Armor et une terminaison TLS destinée à sécuriser le trafic vers votre réseau maillé
  • Cloud CDN pour diffuser des contenus Web et vidéo
  • Fonctionnalités de gestion du trafic telles que le routage basé sur l'hôte ou sur le chemin d'accès

Activer le trafic entrant provenant de clients du cloud privé virtuel et de réseaux connectés sur site

Si vos clients se trouvent dans votre réseau VPC, ou s'ils sont sur site et peuvent accéder aux services Google Cloud via une méthode de connectivité privée (telle que Cloud VPN ou Cloud Interconnect), vous pouvez utiliser l'un des équilibreurs de charge suivants comme passerelle :

Pour en savoir plus sur le choix d'une passerelle adaptée, consultez la section Choisir une passerelle pour votre réseau maillé.

Trafic entrant provenant de clients sur un réseau VPC et passant par un équilibreur de charge pour atteindre les services d'un réseau maillé (cliquez pour agrandir)
Trafic entrant provenant de clients sur un réseau VPC et passant par un équilibreur de charge pour atteindre les services d'un réseau maillé (cliquez pour agrandir)

Dans ce modèle, l'équilibreur de charge géré par Google Cloud sert de passerelle. La passerelle gère le trafic entrant avant de le transférer vers un service de votre réseau maillé.

Par exemple, vous pouvez choisir l'équilibrage de charge HTTP(S) interne comme passerelle afin d'utiliser les fonctionnalités suivantes :

  • Adresse IP adressable en mode privé
  • Terminaison TLS pour sécuriser votre réseau maillé
  • Fonctionnalités de gestion avancée du trafic telles que la répartition du trafic en fonction d'une pondération
  • NEG en tant que backends

Gérer le trafic entrant à l'aide d'une passerelle de deuxième niveau à la périphérie du réseau maillé

En fonction de vos besoins, vous pouvez envisager un modèle plus avancé qui ajoute une passerelle supplémentaire.

Trafic entrant provenant de clients externes et passant par un équilibreur de charge et un proxy de périphérie pour atteindre les services d'un réseau maillé (cliquez pour agrandir)
Trafic entrant provenant de clients externes et passant par un équilibreur de charge et un proxy de périphérie pour atteindre les services d'un réseau maillé (cliquez pour agrandir)

Cette passerelle est un proxy de périphérie (ou un pool de proxys) configuré par Traffic Director et situé derrière l'équilibreur de charge géré par Google Cloud. Vous pouvez héberger cette passerelle de deuxième niveau dans votre projet à l'aide d'un pool de VM Compute Engine (MIG) ou de services GKE.

Bien que ce modèle soit plus avancé, il offre des avantages supplémentaires :

  • L'équilibreur de charge géré par Google Cloud applique un ensemble initial de règles (par exemple, la protection Google Cloud Armor, si vous utilisez l'équilibrage de charge HTTP(S)).

  • Le proxy de périphérie configuré par Traffic Director applique un deuxième ensemble de règles qui peuvent ne pas être disponibles dans l'équilibreur de charge géré par Google Cloud. Ces règles comprennent la gestion avancée du trafic à l'aide d'expressions régulières appliquées aux en-têtes HTTP, et la répartition du trafic en fonction d'une pondération.

Ce modèle peut être configuré pour refléter votre structure organisationnelle. Exemple :

  1. Une équipe peut être chargée du trafic entrant dans Google Cloud, tandis qu'une autre est chargée du trafic entrant dans son propre réseau maillé.

  2. Si plusieurs équipes proposent des services sur un VPC partagé, avec chaque équipe possédant son propre projet de service, ces équipes peuvent utiliser ce modèle pour gérer et appliquer des règles dans leurs propres réseaux maillés. Chaque équipe peut exposer une passerelle configurée par Traffic Director et accessible via une paire adresse IP/port unique. Une équipe peut alors définir et gérer indépendamment les règles appliquées au trafic entrant dans son réseau maillé.

Notez que ce modèle peut être mis en œuvre à l'aide de n'importe quel équilibreur de charge géré par Google Cloud, du moment que celui-ci peut envoyer du trafic aux backends hébergeant la ou les passerelle(s) configurées par Traffic Director. Consultez la section Choisir une passerelle pour votre réseau maillé pour en savoir plus sur les backends compatibles avec chaque équilibreur de charge. Pour en savoir plus sur l'utilisation de Traffic Director avec un VPC partagé, consultez la page Configurer Traffic Director avec un VPC partagé sur plusieurs clusters GKE.