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é. Comment recevoir du trafic dans votre réseau maillé ? Vous pouvez utiliser une passerelle pour acheminer le trafic provenant de l'extérieur de votre réseau maillé vers votre réseau maillé via un point d'entrée.

Ce document décrit comment utiliser Cloud Load Balancing comme passerelle pour recevoir du trafic dans votre réseau maillé. Il comprend les éléments suivants :

  • 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.

Ce document s'applique aux API de routage de service Traffic Director. Une fois les étapes de configuration préliminaires terminées, consultez la section Configurer Traffic Director pour une passerelle d'entrée, qui contient des instructions de déploiement avec une passerelle d'entrée.

Lorsque vous concevez votre maillage de services, tenez compte du trafic provenant des sources suivantes :

  • 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. Toutefois, 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, voici ce qui se produit :

  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.
Le plan de données du réseau maillé gère le trafic interne au maillage de services.
Le plan de données du réseau maillé gère le trafic interne au maillage de services (cliquez pour agrandir)


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

Le plan de données du maillage de services ne gère pas le trafic externe au maillage de services.
Le plan de données du maillage de services ne gère pas le trafic externe au 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'utilise pas de proxy configuré par Traffic Director pour envoyer des requêtes sortantes, il ne sait pas quelles paires adresse IP-port 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é.

Considérations générales concernant votre passerelle

Cette section fournit une présentation des problèmes à prendre en compte lorsque vous sélectionnez une passerelle, y compris les éléments suivants :

  • 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 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. L'accès à un service de votre réseau maillé s'effectue généralement à l'aide d'une adresse IP et d'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 ?

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

Gérer le trafic au niveau de la passerelle

Étant donné que votre passerelle est située à la périphérie de votre réseau maillé, entre les clients externes à celui-ci et les services situés à l'intérieur, vous pouvez utiliser une passerelle pour appliquer des règles lorsque le trafic entre dans votre réseau maillé. Ces règles incluent les suivantes :

  • Gestion du trafic (par exemple, routage, redirections et transformation des requêtes)
  • Sécurité (par exemple, terminaison TLS et protection contre les dénis de service distribués, ou 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 configurer cela, vous devez utiliser 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 auxquels 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 first-level et de first-level. 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 Gérer le trafic entrant à l'aide d'une passerelle de deuxième niveau à la périphérie de votre 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
Équilibreur de charge d'application interne

Clients basés sur 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 que l'équilibreur de charge, par exemple à l'aide de Cloud VPN ou de Cloud Interconnect

HTTP/1.1

HTTP/2

HTTPS

Gestion avancée du trafic

Terminaison TLS à l'aide de certificats autogérés

Backends de la même région Google Cloud que l'équilibreur de charge, s'exécutant sur :

  • Backends d'instances de machine virtuelle (VM) sur Compute Engine
  • Instances de conteneur sur Google Kubernetes Engine (GKE) et Kubernetes
Équilibreur de charge d'application externe 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é avec Identity-Aware Proxy (IAP) pour l'authentification des utilisateurs

Backends dans n'importe quelle région Google Cloud s'exécutant sur :

  • VM sur Compute Engine
  • Instances de conteneurs sur GKE et Kubernetes
Équilibreur de charge réseau passthrough 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 de la même région Google Cloud que l'équilibreur de charge s'exécutant sur des VM sur Compute Engine
Équilibreur de charge réseau passthrough externe Clients sur l'Internet public TCP ou UDP Backends de la même région Google Cloud que l'équilibreur de charge s'exécutant sur des VM sur Compute Engine
Équilibreur de charge réseau proxy externe Clients sur l'Internet public SSL ou TCP

Terminaison TLS utilisant des certificats autogérés ou gérés par Google (proxy SSL uniquement)

Règles SSL (proxy SSL uniquement)

Backends dans n'importe quelle région Google Cloud s'exécutant sur :

  • VM sur Compute Engine
  • Instances de conteneurs sur GKE et Kubernetes
Proxy de périphérie
(sur les instances de VM ou de conteneur) configuré par Traffic Director
Les clients doivent se trouver dans un emplacement où l'un des cas suivants s'applique:

HTTP/1.1

HTTP/2

Gestion avancée du trafic (y compris la compatibilité avec les expressions régulières regex)

Backends dans n'importe quelle région Google Cloud s'exécutant sur :

  • VM sur Compute Engine
  • Instances de conteneurs sur GKE et Kubernetes

Pour une comparaison détaillée par fonctionnalité, consultez la page Fonctionnalités de l'équilibreur de charge. Pour une présentation détaillée des fonctionnalités de Traffic Director, consultez la page 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.

Google Cloud CLI et API Compute Engine

Pour configurer les produits d'équilibrage de charge gérés de Google Cloud et Traffic Director, vous pouvez utiliser la CLI Google Cloud et les API Compute Engine. gcloud CLI et les API offrent des mécanismes permettant de déployer et de configurer vos ressources Google Cloud de manière impérative. Pour automatiser les tâches répétitives, vous pouvez créer des scripts.

console Google Cloud

Pour configurer Traffic Director et les équilibreurs de charge gérés de Google Cloud, vous pouvez utiliser Google Cloud Console.

Pour configurer votre modèle de passerelle, vous aurez probablement besoin des pages Traffic Director et équilibrage de charge.

GKE et Ingress multicluster

Les contrôleurs de réseau GKE et GKE Enterprise sont également compatibles avec le déploiement de Cloud Load Balancing pour une intégration intégrée à la 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.

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 permet d'effectuer les opérations suivantes :

    • 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é.

    • Permet d'appliquer des règles qui peuvent ne pas être 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 dans les sections suivantes.

Activer le trafic entrant depuis Internet

Si vos clients ne font pas partie de Google Cloud et qu'ils doivent accéder à Google Cloud via l'Internet public, vous pouvez utiliser l'un des équilibreurs de charge suivants comme passerelle :

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é
Trafic entrant provenant de clients de 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 un équilibreur de charge d'application externe 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

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

Activer le trafic entrant depuis des clients du VPC et des réseaux sur site connectés

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 :

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é
Trafic entrant provenant de clients sur un réseau VPC vers des services d'un réseau maillé à l'aide d'un équilibreur de charge (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 un équilibreur de charge d'application interne comme passerelle pour 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

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

Gérer le trafic entrant à l'aide d'une passerelle de deuxième niveau à la périphérie de votre 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é
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 (groupe d'instances géré) 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 un équilibreur de charge d'application externe.

  • 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é.

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 qui hébergent les passerelles configurées par Traffic Director.

Utiliser les API de routage de service pour le trafic entrant

Les API de routage de services fournissent la ressource Gateway pour configurer la gestion du trafic et la sécurité des proxys Envoy agissant en tant que passerelles d'entrée, ce qui permet aux clients externes de se connecter au maillage de services (Nord-Sud). Pour plus d'informations, consultez les sections Présentation du routage de services et Configurer une passerelle d'entrée.

Étapes suivantes