Traffic Director avec groupes de points de terminaison du réseau Internet

Vous pouvez configurer Traffic Director de sorte qu'il utilise des groupes de points de terminaison du réseau (NEG) Internet de type INTERNET_FQDN_PORT. Le service externe est représenté par son nom de domaine complet (FQDN) et son numéro de port dans le NEG. Le NEG ne peut contenir qu'une seule paire FQDN:Port et le service de backend ne peut contenir qu'un seul NEG de ce type. Le nom de domaine complet est résolu à l'aide de l'ordre de résolution des noms du réseau cloud privé virtuel (VPC) sous-jacent.

Développer le maillage de services Traffic Director à l'aide des backend FQDN

Le maillage de services Traffic Director peut acheminer le trafic vers des services privés accessibles via une connectivité hybride, y compris des services sur site, multi-cloud et Internet. Le service distant est référencé par son nom de domaine complet.

Étendre le maillage de services Traffic Director à des emplacements sur site ou multicloud à l'aide de backends FQDN via une connectivité hybride
Étendre le maillage de services Traffic Director à des emplacements sur site ou multicloud à l'aide de backends FQDN via une connectivité hybride (cliquez sur l'image pour l'agrandir)

Vous pouvez également acheminer le trafic vers des services accessibles via l'Internet public.

Étendre le maillage de services Traffic Director à un service Internet à l'aide de backends FQDN
Étendre le maillage de services Traffic Director à un service Internet à l'aide de backends FQDN (cliquez pour agrandir)

Ressources et architecture Google Cloud

Cette section décrit les ressources et l'architecture permettant de configurer Traffic Director avec un NEG Internet.

INTERNET_FQDN_PORT groupe de points de terminaison du réseau

Pour acheminer le trafic vers un service externe référencé par son nom de domaine complet, utilisez le NEG Internet global de type INTERNET_FQDN_PORT. Le NEG contient le nom de domaine complet de votre service et son numéro de port. Traffic Director programme le nom de domaine complet dans les proxys Envoy à l'aide de la configuration xDS.

Traffic Director lui-même ne garantit pas la résolution de noms ni la joignabilité des points de terminaison distants. Le nom de domaine complet doit pouvoir être résolu par l'ordre de résolution des noms du réseau VPC auquel les proxys Envoy sont associés. Les points de terminaison résolus doivent être accessibles à partir des proxys Envoy.

Vérifications d'état

Le comportement de vérification d'état pour les points de terminaison du réseau de type INTERNET_FQDN_PORT diffère du comportement de vérification d'état des autres types de points de terminaison de réseau utilisés avec Cloud Load Balancing et Traffic Director. Alors que la plupart des autres types de points de terminaison du réseau utilisent le système de vérification d'état centralisé de Google Cloud, les NEG utilisés pour les points de terminaison dans les environnements multicloud (INTERNET_FQDN_PORT et NON_GCP_PRIVATE_IP_PORT) utilisent le mécanisme de vérification de l'état distribué d'Envoy.

Envoy est compatible avec les protocoles suivants pour la vérification de l'état :

  • HTTP
  • HTTPS
  • HTTP/2
  • TCP

Vous pouvez configurer les vérifications d'état à l'aide des API Compute Engine.

Considérations DNS

Deux considérations distinctes concernent le DNS :

  • Le serveur DNS qui héberge les enregistrements de ressources de votre service externe.
  • Mode avec lequel le proxy Envoy est configuré pour utiliser DNS pour la gestion des connexions.

Serveur Cloud DNS

Vous pouvez créer une zone privée gérée Cloud DNS pour héberger les enregistrements DNS dans votre projet Google Cloud. Vous pouvez également utiliser d'autres fonctionnalités de Cloud DNS, telles que les zones de transfert, pour extraire des enregistrements d'un serveur DNS sur site.

Mode DNS Envoy

Le mode DNS Envoy, également appelé détection de services, spécifie la manière dont le proxy Envoy utilise des enregistrements DNS pour gérer les connexions sortantes. Traffic Director configure Envoy de manière à utiliser le mode DNS strict. Le mode DNS strict permet l'équilibrage de charge à tous les points de terminaison résolus. Il respecte l'état des vérifications d'état et draine les connexions aux points de terminaison qui ne sont plus opérationnels ou qui ne sont plus résolus à l'aide d'un DNS. Vous ne pouvez pas modifier ce mode.

Pour plus d'informations sur la détection de services, consultez la documentation Envoy.

Connectivité et routage

Si vous acheminez le trafic vers un service privé, les exigences suivantes sont requises pour la connectivité réseau sous-jacente :

  • La connectivité hybride entre le réseau VPC et le centre de données sur site ou le cloud public tiers est établie à l'aide de Cloud VPN ou de Cloud Interconnect.
  • Les règles de pare-feu VPC et les routes sont correctement configurées pour établir la joignabilité bidirectionnelle entre Envoy et vos points de terminaison de service privés et, le cas échéant, vers le serveur DNS sur site.
  • Pour que le basculement haute disponibilité régional soit réussi, le routage dynamique mondial doit être activé. Pour plus d'informations, consultez la documentation sur le Mode de routage dynamique.

Si vous acheminez le trafic vers un service externe accessible sur Internet, procédez comme suit :

  • Les instances de machines virtuelles (VM) clientes du réseau VPC doivent disposer d'une adresse IP externe ou de Cloud NAT.
  • La route par défaut doit être présente pour le trafic sortant vers Internet.

Dans les deux cas précédents, le trafic utilise le routage du réseau VPC.

Sécurité

Les backends FQDN sont compatibles avec les API et fonctionnalités de sécurité de Traffic Director. Pour les connexions sortantes vers votre service externe, vous pouvez configurer le nom de domaine complet de l'en-tête SNI à l'aide des règles TLS côté client.

Limites et points à noter

  • Les NEG Internet de type INTERNET_IP_PORT ne sont pas compatibles avec Traffic Director.
  • La version 1.15.0 ou ultérieure d'Envoy est requise avec les backends FQDN.
  • Utilisez Google Cloud CLI ou les API REST pour configurer Traffic Director. La configuration de bout en bout n'est pas disponible avec Google Cloud Console.
  • Les backend FQDN ne sont compatibles qu'avec Envoy. Le protocole gRPC sans proxy n'est pas compatible.

  • Lorsque vous utilisez le type de NEG INTERNET_FQDN_PORT avec Traffic Director, les vérifications de l'état des points de terminaison distants sont effectuées à l'aide du mécanisme de vérification d'état distribué d'Envoy. Chaque fois qu'un nouveau point de terminaison distant est ajouté, tous les proxys Envoy commencent à le vérifier indépendamment.

    De même, lorsqu'un nouveau proxy Envoy est ajouté au maillage, il commence à vérifier tous les points de terminaison distants. Par conséquent, en fonction du nombre de proxys Envoy et de points de terminaison distants dans votre déploiement, le maillage de vérifications d'état résultant peut entraîner un trafic réseau important et une charge excessive sur les points de terminaison distants. Vous pouvez choisir de ne pas configurer les vérifications d'état.

  • L'état de la vérification d'état n'est pas visible dans la console Google Cloud pour les backends FQDN.

  • La vérification d'état qui utilise les protocoles UDP, SSL et gRPC n'est pas prise en charge.

  • Les options de vérification d'état suivantes ne sont pas compatibles :

    • Vérification d'état HTTP/HTTP2/HTTPS
      • --proxy-header
      • --response
    • Vérification d'état TCP
      • --proxy-header
      • --request
      • --response

Étapes suivantes