Traffic Director avec des groupes de points de terminaison du réseau de connectivité hybride
Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director à 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
Traffic Director 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 Traffic Director . Traffic Director informe le client de vos services et de leurs points de terminaison.
Dans le schéma précédent, lorsque votre application envoie une requête au service on-prem, le client Traffic Director 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 Traffic Director 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.
Le schéma précédent étend le modèle précédent. Au lieu de configurer Traffic Director pour envoyer tout le trafic vers le service on-prem, configurez Traffic Director 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 par déni de service distribué (DDoS), que vous pouvez utiliser avec Traffic Director pour apporter 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.
Dans le schéma précédent, le trafic des clients sur l'Internet public entre dans le réseau Google Cloud à partir d'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 Traffic Director) 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 Traffic Director pour des environnements sur site et multi-cloud.
Le schéma suivant présente les ressources Google Cloud qui permettent l'utilisation de services sur site et multicloud pour Traffic Director. 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 Traffic Director. Pour plus de simplicité, le schéma n'affiche pas d'options telles que plusieurs services de backend globaux.
Lorsque vous configurez Traffic Director, 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 :
- Des règles à appliquer lorsqu'un client tente d'envoyer du trafic au service.
- 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 Traffic Director. 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-alorsque 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 Traffic Director, tels que les proxys Envoy, doivent pouvoir se connecter à Traffic Director à l'adresse trafficdirector.googleapis.com:443. Voici ce qui se produit si vous perdez votre connectivité au plan de contrôle Traffic Director:
- Les clients Traffic Director existants ne peuvent pas recevoir les mises à jour de configuration de Traffic Director. Ils continuent de fonctionner selon leur configuration actuelle.
- Les nouveaux clients Traffic Director ne peuvent pas se connecter à Traffic Director. 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, Traffic Director 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 Traffic Director 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 Traffic Director 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 Traffic Director existants peuvent commencer à vérifier 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 Traffic Director), 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 Traffic Director reçoivent la configuration de Traffic Director 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 Traffic Director.
Étapes suivantes
- Pour configurer Traffic Director pour les déploiements sur site et multicloud, consultez la page Services de mise en réseau réseau pour les déploiements multi-environnements.
- Pour en savoir plus sur Traffic Director, consultez la présentation de Traffic Director.
- Pour en savoir plus sur les NEG Internet, consultez la page Traffic Director avec des groupes de points de terminaison du réseau Internet.