Cloud Service Mesh avec des groupes de points de terminaison du réseau de connectivité hybride

Cloud Service Mesh est compatible avec des environnements qui vont au-delà de Google Cloud, y compris les centres de données sur site et d'autres clouds publics accessibles via une connectivité hybride.

Vous pouvez configurer Cloud Service Mesh de manière à ce que votre maillage de services puisse envoyer du trafic vers des points de terminaison en dehors de Google Cloud. Ces points de terminaison incluent les éléments suivants :

  • Équilibreurs de charge sur site.
  • Des applications de serveur sur une instance de machine virtuelle (VM) dans un autre cloud.
  • Toute autre destination accessible avec une connectivité hybride et accessible via une adresse IP et un port.

Vous ajoutez l'adresse IP et le port de chaque point de terminaison à un groupe de points de terminaison du réseau (NEG) de connectivité hybride. Les NEG de connectivité hybride sont de type NON_GCP_PRIVATE_IP_PORT.

La compatibilité de Cloud Service Mesh pour les services sur site et multicloud vous permet d'effectuer les opérations suivantes:

  • Router le trafic à l'échelle mondiale, y compris vers les points de terminaison des services sur site et multicloud.
  • Apporter les avantages de Cloud Service Mesh et du maillage de services, y compris des fonctionnalités telles que la détection de services et la gestion avancée du trafic, aux services exécutés sur votre infrastructure existante en dehors de Google Cloud.
  • Associer les capacités de Cloud Service Mesh à Cloud Load Balancing pour mettre en œuvre des services de mise en réseau de Google Cloud vers plusieurs environnements.

Les NEG de connectivité hybride (NEG NON_GCP_PRIVATE_IP_PORT) ne sont pas compatibles avec les clients gRPC sans proxy.

Cas d'utilisation

Cloud Service Mesh peut configurer la mise en réseau entre des services basés sur des VM et des conteneurs dans plusieurs environnements, y compris:

  • Google Cloud
  • Centres de données sur site
  • Autres clouds publics

Router le trafic du réseau maillé vers un emplacement sur site ou un autre cloud

Le cas d'utilisation le plus simple pour cette fonctionnalité est le routage du trafic. Votre application exécute un proxy Envoy Cloud Service Mesh . Cloud Service Mesh informe le client de vos services et des points de terminaison de chaque service.

Router le trafic du réseau maillé vers un emplacement sur site ou un autre cloud
Routage du trafic du réseau maillé vers un emplacement sur site ou un autre cloud (cliquez pour agrandir)

Dans le schéma précédent, lorsque votre application envoie une requête au service on-prem, le client Cloud Service Mesh inspecte la requête sortante et met à jour sa destination. La destination est définie sur un point de terminaison associé au service on-prem (dans ce cas, 10.2.0.1). La requête est acheminée via Cloud VPN ou Cloud Interconnect vers la destination souhaitée.

Si vous devez ajouter d'autres points de terminaison, mettez à jour Cloud Service Mesh pour les ajouter à votre service. Vous n'avez pas besoin de modifier votre code d'application.

Migrer un service sur site existant vers Google Cloud

L'envoi de trafic vers un point de terminaison autre que Google Cloud vous permet d'acheminer le trafic vers d'autres environnements. Vous pouvez combiner cette fonctionnalité avec la gestion avancée du trafic pour migrer des services entre les environnements.

Migrer depuis un emplacement sur site vers Google Cloud
Migration d'un emplacement sur site vers Google Cloud (cliquez pour agrandir)

Le schéma précédent étend le modèle précédent. Au lieu de configurer Cloud Service Mesh pour envoyer tout le trafic vers le service on-prem, configurez Cloud Service Mesh de manière à répartir le trafic entre deux services à l'aide de la répartition du trafic en fonction du poids.

La répartition du trafic vous permet de commencer par envoyer 0 % du trafic au service cloud et 100 % au service on-prem. Vous pouvez ensuite augmenter progressivement la proportion du trafic envoyé au service cloud. Vous finirez par envoyer 100 % du trafic vers le service cloud et vous pourrez supprimer le service on-prem.

Services de périphérie du réseau Google Cloud pour les déploiements sur site et multicloud

Enfin, vous pouvez combiner cette fonctionnalité avec les solutions réseau existantes de Google Cloud. Google Cloud propose une vaste gamme de services réseau, tels que l'équilibrage de charge externe global avec Google Cloud Armor pour la protection contre les attaques DDoS, que vous pouvez utiliser avec Cloud Service Mesh pour intégrer de nouvelles fonctionnalités à vos services sur site ou multicloud. Mieux encore, vous n'avez pas besoin d'exposer ces services sur site ou multicloud à l'Internet public.

Déploiements couvrant plusieurs environnements.
Déploiements couvrant plusieurs environnements (cliquez pour agrandir)

Dans le diagramme précédent, le trafic des clients sur le réseau Internet public accède au réseau Google Cloud depuis un équilibreur de charge Google Cloud, tel que notre équilibreur de charge d'application externe global. Lorsque le trafic atteint l'équilibreur de charge, vous pouvez appliquer des services de périphérie du réseau tels que la protection DDoS de Google Cloud Armor ou l'authentification des utilisateurs Identity-Aware Proxy (IAP). Pour plus d'informations, consultez la section Services de périphérie du réseau pour les déploiements multi-environnements.

Une fois ces services appliqués, le trafic s'arrête brièvement dans Google Cloud, où une application ou un proxy autonome (configuré par Cloud Service Mesh) transfère le trafic sur Cloud VPN ou Cloud Interconnect vers votre service sur site.

Ressources et architecture Google Cloud

Cette section fournit des informations générales sur les ressources Google Cloud que vous pouvez utiliser pour fournir un maillage de services géré par Cloud Service Mesh pour des environnements sur site et multicloud.

Le schéma suivant présente les ressources Google Cloud qui permettent l'utilisation de services sur site et multicloud pour Cloud Service Mesh. La ressource clé est le NEG accompagné de ses points de terminaison du réseau. Les autres ressources sont celles que vous configurez dans le cadre d'une configuration standard de Cloud Service Mesh. Pour plus de simplicité, le schéma n'affiche pas d'options telles que plusieurs services de backend globaux.

Ressources Compute Engine pour les services sur site et multicloud.
Ressources Compute Engine pour les services sur site et multicloud (cliquez pour agrandir)

Lorsque vous configurez Cloud Service Mesh, vous devez utiliser la ressource API globale des services de backend pour créer des services. Un service est une construction logique qui combine les éléments suivants :

  1. Des règles à appliquer lorsqu'un client tente d'envoyer du trafic au service.
  2. Un ou plusieurs backends ou points de terminaison qui gèrent le trafic destiné au service.

Les services sur site et multicloud sont comme tous les autres services configurés par Cloud Service Mesh. La principale différence est que vous utilisez un NEG de connectivité hybride pour configurer les points de terminaison de ces services. Le type de point de terminaison du réseau est défini sur NON_GCP_PRIVATE_IP_PORT pour ces NEG. Les points de terminaison que vous ajoutez à des NEG de connectivité hybride doivent être des combinaisons IP:port valides que vos clients peuvent atteindre, par exemple, via une connectivité hybride telle que Cloud VPN ou Cloud Interconnect.

Chaque NEG dispose d'un type de point de terminaison du réseau et ne peut contenir que des points de terminaison réseau du même type. Ce type détermine :

  • La destination vers laquelle vos services peuvent envoyer du trafic.
  • Le comportement de la vérification d'état.

Lorsque vous créez votre NEG, configurez-le comme suit pour pouvoir envoyer du trafic vers une destination sur site ou multicloud.

  • Définissez le type de point de terminaison du réseau sur NON_GCP_PRIVATE_IP_PORT. Cette option représente une adresse IP accessible. Si cette adresse IP est sur site ou chez un autre fournisseur cloud, elle doit être accessible depuis Google Cloud via une connectivité hybride, telle que la connectivité fournie par Cloud VPN ou Cloud Interconnect.
  • Spécifiez une zone Google Cloud qui réduit la distance géographique entre Google Cloud et votre environnement sur site ou multicloud. Par exemple, si vous hébergez un service dans un environnement sur site à Francfort, en Allemagne, vous pouvez spécifier la zone Google Cloud europe-west3-a lorsque vous créez le NEG.

Le comportement de vérification d'état pour les points de terminaison du réseau de ce type diffère du comportement de vérification d'état des autres types de points de terminaison du réseau. Alors que d'autres types de points de terminaison du réseau utilisent le système de vérification d'état centralisé de Google Cloud, les points de terminaison du réseau NON_GCP_PRIVATE_IP_PORT utilisent le mécanisme de vérification d'état distribué d'Envoy. Pour en savoir plus, consultez la section Limites et autres considérations.

Considérations sur la connectivité et la mise en réseau

Vos clients Cloud Service Mesh, tels que les proxys Envoy, doivent pouvoir se connecter à Cloud Service Mesh à l'adresse trafficdirector.googleapis.com:443. Voici ce qui se produit si vous perdez la connectivité au plan de contrôle Cloud Service Mesh:

  • Les clients Cloud Service Mesh existants ne peuvent pas recevoir les mises à jour de configuration de Cloud Service Mesh. Ils continuent de fonctionner selon leur configuration actuelle.
  • Les nouveaux clients Cloud Service Mesh ne peuvent pas se connecter à Cloud Service Mesh. Ils ne peuvent pas utiliser le maillage de services tant que la connectivité n'est pas rétablie.

Si vous souhaitez envoyer du trafic entre Google Cloud et des environnements sur site ou multicloud, ceux-ci doivent être connectés via une connectivité hybride. Nous vous recommandons d'utiliser une connexion à haute disponibilité activée par Cloud VPN ou Cloud Interconnect.

Les adresses IP de sous-réseau Google Cloud et les plages d'adresses IP sur site et d'autres clouds ne doivent pas se chevaucher.

Limites et autres considérations

Les limites suivantes s'appliquent à l'utilisation de NEG de connectivité hybride.

Configurer proxyBind

Vous ne pouvez définir la valeur de proxyBind que lorsque vous créez un targetHttpProxy. Vous ne pouvez pas mettre à jour un proxy targetHttpProxy existant.

Connectivité et perturbation de la connectivité

Pour en savoir plus sur les exigences et les limites de la connectivité, consultez la section Considérations relatives à la connectivité et à la mise en réseau.

Types de backends mixtes

Un service de backend peut comporter des backends de VM ou de NEG. Si un service de backend comporte des backends de type NEG, tous les NEG doivent contenir le même type de point de terminaison du réseau. Vous ne pouvez pas avoir un service de backend avec plusieurs NEG, chacun avec des types de points de terminaison différents.

Un mappage d'URL peut avoir des règles d'hôte qui correspondent à différents services de backend. Vous pouvez disposer d'un service de backend ne contenant que des NEG de connectivité hybride (avec des points de terminaison sur site) et un service de backend avec des NEG autonomes (avec points de terminaison GKE). Le mappage d'URL peut contenir des règles, telles que la répartition du trafic en fonction du poids, qui divisent le trafic entre chacun de ces services de backend.

Utiliser un NEG avec des points de terminaison de type NON_GCP_PRIVATE_IP_PORT avec des backends Google Cloud

Il est possible de créer un service de backend avec un NEG de connectivité hybride pointant vers les backends dans Google Cloud. Cependant, nous vous déconseillons d'utiliser ce modèle, car les NEG de connectivité hybride ne bénéficient pas de la vérification d'état centralisée. Pour plus d'informations sur la vérification de l'état centralisée et la vérification d'état distribuée, consultez la section Vérification d'état.

Enregistrement des points de terminaison

Si vous souhaitez ajouter un point de terminaison à un NEG, vous devez mettre à jour le NEG. Cette opération peut être effectuée manuellement ou à l'aide des API REST du NEG Google Cloud ou de Google Cloud CLI.

Lorsqu'une nouvelle instance d'un service démarre, vous pouvez utiliser l'API Google Cloud pour enregistrer l'instance avec le NEG que vous avez configuré. Lorsque vous utilisez des groupes d'instances gérés (MIG) Compute Engine ou GKE (dans Google Cloud), le contrôleur MIG ou NEG gère automatiquement l'enregistrement des points de terminaison, respectivement.

Vérification de l'état

Lorsque vous utilisez des NEG de connectivité hybride, le comportement de vérification de l'état diffère du comportement standard de la vérification d'état :

  • Pour les points de terminaison du réseau de type NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh configure ses clients afin qu'ils utilisent le plan de données pour gérer la vérification de l'état. Pour éviter d'envoyer des requêtes aux backends défectueux, les instances Envoy effectuent leurs propres vérifications d'état et utilisent leurs propres mécanismes.
  • Étant donné que votre plan de données gère les vérifications d'état, vous ne pouvez pas utiliser Google Cloud Console, l'API ou Google Cloud CLI pour récupérer l'état de la vérification d'état.

En pratique, l'utilisation de NON_GCP_PRIVATE_IP_PORT signifie ce qui suit :

  • Comme les clients Cloud Service Mesh gèrent chacun une vérification de l'état de manière distribuée, vous constaterez peut-être une augmentation du trafic réseau à cause de la vérification de l'état. L'augmentation dépend du nombre de clients Cloud Service Mesh et du nombre de points de terminaison dont un client doit vérifier l'état. Exemple :
    • Lorsque vous ajoutez un point de terminaison à un NEG de connectivité hybride, les clients Cloud Service Mesh existants peuvent commencer à vérification de l'état des points de terminaison dans les NEG de la connectivité hybride.
    • Lorsque vous ajoutez une instance à votre maillage de services (par exemple, une instance de VM qui exécute le code de votre application et un client Cloud Service Mesh), la nouvelle instance peut commencer à vérifier l'état des points de terminaison dans les NEG de la connectivité hybride.
    • Le trafic réseau en raison de vérifications de l'état augmente à un taux quadratique (O(n^2)).

Réseau VPC

Un maillage de services est identifié de manière unique par le nom de son réseau de cloud privé virtuel (VPC). Les clients de Cloud Service Mesh reçoivent la configuration de Cloud Service Mesh en fonction du réseau VPC spécifié dans la configuration d'amorçage. Par conséquent, même si votre maillage est entièrement extérieur à un centre de données Google Cloud, vous devez indiquer un nom de réseau VPC valide dans la configuration d'amorçage.

Compte de service

Dans Google Cloud, l'amorçage Envoy par défaut est configuré pour lire les informations de compte de service à partir des environnements de déploiement Compute Engine ou GKE. Lorsque vous exécutez une exécution en dehors de Google Cloud, vous devez explicitement spécifier un compte de service, un nom de réseau et un numéro de projet dans votre amorçage Envoy. Ce compte de service doit disposer des autorisations suffisantes pour se connecter à l'API Cloud Service Mesh.

Étape suivante