Cloud Service Mesh avec groupes de points de terminaison du réseau à 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 configurez Cloud Service Mesh de sorte que votre maillage de services puisse envoyer du trafic de points de terminaison externes à 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.

Compatibilité de Cloud Service Mesh avec 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.
  • Profitez des avantages de Cloud Service Mesh et du maillage de services : comme la détection de services et la gestion avancée du trafic, pour des services s'exécutant sur votre infrastructure existante en dehors de Google Cloud.
  • Combinez les fonctionnalités de Cloud Service Mesh avec Cloud Load Balancing pour : d'intégrer les services de mise en réseau Google Cloud dans des environnements multi-environnements.

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

Cas d'utilisation

Cloud Service Mesh peut configurer la mise en réseau entre 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 l'application exécute un proxy Envoy Cloud Service Mesh . Cloud Service Mesh indique sur vos services et les 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 on-prem le client Cloud Service Mesh inspecte la requête sortante 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, vous devez mettre à 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, vous configurer Cloud Service Mesh afin de répartir le trafic en fonction du poids entre deux services.

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 un large éventail de services tels que l'équilibrage de charge externe global avec Google Cloud Armor la protection contre le déni de service distribué (DDoS), que vous pouvez utiliser Cloud Service Mesh pour apporter de nouvelles fonctionnalités à vos environnements sur site ou multicloud services. 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 schéma précédent, le trafic des clients sur l'Internet public entre au réseau Google Cloud à partir d'un équilibreur de charge Google Cloud, par exemple 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 que vous avez appliqué ces services, 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 à 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 illustre les ressources Google Cloud permettant Compatibilité des 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 les ressources 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 utilisez l'API des services de backend globaux ressource 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 semblables à tout autre service Cloud Service Mesh est configuré. 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. Si vous perdez au plan de contrôle Cloud Service Mesh, voici ce qui se produit:

  • Les clients Cloud Service Mesh existants ne peuvent pas recevoir de configuration à partir 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 pour utiliser 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 :

  • Étant donné que les clients Cloud Service Mesh gèrent chacun la vérification de l'état dans un de manière distribuée, vous constaterez peut-être une augmentation du trafic réseau les vérifications d'état. L'augmentation dépend du nombre de Cloud Service Mesh et le nombre de points de terminaison dont chaque client vérifier. Exemple :
    • Lorsque vous ajoutez un point de terminaison à un NEG de connectivité hybride, les clients Cloud Service Mesh existants peuvent commencer à vérifier l'état des points de terminaison dans les NEG de la connectivité hybride.
    • Lorsque vous ajoutez une autre instance à votre maillage de services (par exemple, une VM qui exécute le code de votre application client Cloud Service Mesh), la nouvelle instance peut commencer à fonctionner et vérifier les points de terminaison des NEG de 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 Cloud Service Mesh reçoivent la configuration de Cloud Service Mesh en fonction du réseau VPC spécifié dans le configuration. 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