Configurer des backends externes avec des groupes de points de terminaison du réseau Internet

Ce document fournit des instructions de configuration des backends externes pour Cloud Service Mesh à l'aide de groupes de points de terminaison de réseau (NEG) Internet, qui nécessitent un nom de domaine complet. Ce document est destiné aux utilisateurs qui connaissent bien ou très bien les éléments suivants:

Ce guide de configuration fournit des instructions de base pour les opérations suivantes :

  • Configurer Cloud Service Mesh de manière à utiliser un NEG Internet et un TLS non authentifié pour le trafic sortant
  • Acheminer le trafic vers un service Cloud Run à partir de votre maillage de services

Avant de commencer

Consultez la présentation de Cloud Service Mesh avec des groupes de points de terminaison du réseau Internet.

 Pour les besoins de ce guide, les exemples de configurations supposent les éléments suivants :

  • Toutes les ressources Compute Engine pertinentes, telles que les proxys intermédiaires, les ressources Cloud Service Mesh, les zones Cloud DNS et la connectivité hybride, sont associées au réseau cloud privé virtuel (VPC) par défaut.
  • Le service example.com:443 est en cours d'exécution dans votre infrastructure sur site. Le domaine example.com est desservi par trois points de terminaison, 10.0.0.100, 10.0.0.101 et 10.0.0.102. Des routes permettent d'assurer la connectivité des proxys Envoy vers ces points de terminaison distants.

Le déploiement obtenu ressemble à ce qui suit.

Exemple de configuration avec un NEG Internet.
Exemple de configuration avec un NEG Internet (cliquez pour agrandir)

Routage du trafic avec un NEG Internet et TLS avec SNI

Une fois que vous avez configuré Cloud Service Mesh avec un NEG Internet à l'aide du nom de domaine complet et du protocole TLS pour le trafic sortant, l'exemple de déploiement se comporte comme indiqué dans le schéma et la description suivants du trafic.

Exemple de routage du trafic dans l'exemple
Routage du trafic dans l'exemple (cliquez pour agrandir)

Étapes de la légende suivante correspondant à la numérotation dans le schéma précédent.

Étape Description
0 Envoy reçoit la configuration du backend FQDN de Cloud Service Mesh via xDS.
0 Envoy, qui s'exécute sur la VM, interroge en permanence le DNS pour récupérer le nom de domaine complet configuré.
1 L'application utilisateur lance une requête.
2 Paramètres de la requête.
3 Le proxy Envoy intercepte la requête. L'exemple suppose que vous utilisez 0.0.0.0 comme adresse IP virtuelle (IPV) de la règle de transfert. Lorsque 0.0.0.0 est l'adresse IP virtuelle, Envoy intercepte toutes les requêtes. Le routage des requêtes est basé uniquement sur les paramètres de couche 7, quelle que soit l'adresse IP de destination dans la requête d'origine générée par l'application.
4 Envoy sélectionne un point de terminaison distant opérationnel et effectue un handshake TLS avec l'extension SNI obtenue de la règle TLS du client.
5 Envoy transfère la requête vers le point de terminaison distant.

Elle n'est pas illustrée dans le schéma, mais si les vérifications d'état sont configurées, Envoy vérifie en permanence l'état des points de terminaison distants et achemine les requêtes uniquement vers les points de terminaison opérationnels.

Configurer une connectivité hybride

Ce document suppose également que la connectivité hybride est déjà établie :

  • Une connectivité hybride entre le réseau VPC et les services sur site, ou un cloud public tiers, est établie avec Cloud VPN ou Cloud Interconnect.
  • Les règles et routes de pare-feu VPC sont correctement configurées pour établir la joignabilité bidirectionnelle entre Envoy vers des points de terminaison de service privés et, éventuellement, vers un serveur DNS sur site.
  • Pour un scénario de basculement régional à haute disponibilité réussi, le routage dynamique global est activé. Pour en savoir plus, consultez la documentation sur le Mode de routage dynamique.

Définir la configuration de Cloud DNS

Utilisez les commandes suivantes pour configurer une zone privée Cloud DNS pour le domaine (FQDN) example.com qui contient les enregistrements A pointant vers des points de terminaison 10.0.0.100, 10.0.0.101, 10.0.0.102 et 10.0.0.103.

gcloud

  1. Créez une zone gérée privée DNS et associez-la au réseau par défaut :
    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
  1. Ajoutez des enregistrements DNS à la zone privée :
    gcloud dns record-sets transaction start \
        --zone=example-zone

    gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
        --name=example.com \
        --ttl=300 \
        --type=A \
        --zone=example-zone

    gcloud dns record-sets transaction execute \
        --zone=example-zone

Configurer Cloud Service Mesh avec un NEG FQDN Internet

Dans cette section, vous allez configurer Cloud Service Mesh avec un NEG FQDN Internet.

Créer le service NEG, la vérification d'état et le service de backend

gcloud

  1. Créez le NEG Internet :
    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
        --global \
        --network-endpoint-type INTERNET_FQDN_PORT
  1. Ajoutez le point de terminaison FQDN:Port au NEG Internet :
    gcloud compute network-endpoint-groups update on-prem-service-a-neg \
        --global \
        --add-endpoint=fqdn=example.com,port=443
  1. Créez une vérification d'état globale :
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. Créez un service de backend global appelé on-prem-service-a et associez-lui la vérification d'état :
    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
  1. Ajoutez le NEG appelé on-prem-service-a-neg en tant que backend du service de backend :
    gcloud compute backend-services add-backend on-prem-service-a \
        --global \
        --global-network-endpoint-group \
        --network-endpoint-group on-prem-service-a-neg

Créer une carte des règles de routage

Le mappage d'URL, le proxy HTTP cible et la règle de transfert constituent une règle de routage qui fournit des informations de routage pour le trafic au sein de votre réseau maillé.

Ce mappage d'URL contient une règle qui achemine tout le trafic HTTP vers on-prem-service-a.

gcloud

  1. Créez le mappage d'URL :
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. Créez le proxy HTTP cible et associez le mappage d'URL au proxy cible:
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. Créez la règle de transfert globale à l'aide de l'adresse IP 0.0.0.0. Il s'agit d'une adresse IP spéciale qui oblige votre plan de données à ignorer l'adresse IP de destination et à acheminer les requêtes uniquement en fonction des paramètres HTTP de la requête.
    gcloud compute forwarding-rules create td-forwarding-rule \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --address=0.0.0.0 \
        --target-http-proxy=td-proxy \
        --ports=443 \
        --network=default

Configurer les protocoles TLS et HTTPS non authentifiés

Si vous souhaitez configurer le protocole HTTPS non authentifié entre vos proxys Envoy et vos services sur site, suivez les instructions ci-dessous. Ces instructions montrent également comment configurer l'extension SNI dans le handshake TLS.

Une règle TLS client spécifie l'identité et le mécanisme d'authentification du client lorsqu'un client envoie des requêtes sortantes à un service particulier. Une règle TLS du client est associée à une ressource de service de backend à l'aide du champ securitySettings.

gcloud

  1. Créez et importez la règle TLS du client, puis définissez le SNI sur le nom de domaine complet que vous avez configuré dans le NEG :
    cat << EOF > client_unauthenticated_tls_policy.yaml
    name: "client_unauthenticated_tls_policy"
    sni: "example.com"
    EOF

    gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
        --source=client_unauthenticated_tls_policy.yaml \
        --location=global
  1. Si vous avez configuré une vérification d'état HTTP avec le service de backend dans la section précédente, détachez la vérification d'état du service de backend :
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. Créez une vérification d'état HTTPS :
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. Associez la règle TLS du client au service de backend que vous avez créé précédemment. Cela applique le protocole HTTPS non authentifié sur toutes les requêtes sortantes du client vers ce service de backend :
    gcloud compute backend-services export on-prem-service-a \
        --global \
        --destination=on-prem-service-a.yaml

    cat << EOF >> on-prem-service-a.yaml
    securitySettings:
      clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
    healthChecks:
      - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
    EOF

    gcloud compute backend-services import on-prem-service-a \
        --global \
        --source=on-prem-service-a.yaml

Vous pouvez utiliser des NEG FQDN Internet pour acheminer le trafic vers tout service accessible via le FQDN, par exemple, des services externes et internes pouvant être résolus par DNS ou des services Cloud Run.

Migrer d'un NEG IP:Port vers un NEG FQDN:Port

Le NEG NON_GCP_PRIVATE_IP_PORT nécessite de programmer les points de terminaison de service dans le NEG en tant que paires IP:PORT statiques, tandis que INTERNET_FQDN_NEG permet de résoudre les points de terminaison de manière dynamique à l'aide du DNS. Vous pouvez migrer vers le NEG Internet en configurant des enregistrements DNS pour vos points de terminaison de service sur site, puis en configurant Cloud Service Mesh comme suit:

  1. Configurez les enregistrements DNS de votre nom de domaine complet.
  2. Créez un nouveau NEG Internet avec le nom de domaine complet.
  3. Créez un service de backend avec le NEG Internet que vous avez créé à l'étape 2 en tant que backend. Associez la vérification d'état que vous avez utilisée au service de backend du NEG de connectivité hybride au nouveau service de backend. Vérifiez que les nouveaux points de terminaison distants sont opérationnels.
  4. Mettez à jour la carte des règles de routage pour référencer le nouveau service de backend en remplaçant l'ancien backend incluant le NEG de connectivité hybride.
  5. Si vous souhaitez atteindre des temps d'arrêt nuls lors de la migration à chaud pour un déploiement en production, vous pouvez utiliser le trafic basé sur le poids. Au départ, configurez votre nouveau service de backend de sorte qu'il ne reçoive qu'un faible pourcentage de trafic, par exemple 5 %. Suivez les instructions de configuration de la répartition du trafic.
    1. Vérifiez que les nouveaux points de terminaison distants diffusent correctement le trafic.
  6. Si vous utilisez la répartition du trafic en fonction d'une pondération, configurez le nouveau service de backend pour qu'il reçoive la totalité du trafic. Cette étape draine l'ancien service de backend.
  7. Après avoir vérifié que les nouveaux backend diffusent du trafic sans problème, supprimez l'ancien service de backend.

Dépannage

Pour résoudre les problèmes de déploiement, suivez les instructions de cette section. Si vos problèmes ne sont pas résolus avec ces informations, consultez la section Dépanner les déploiements qui utilisent Envoy.

Un point de terminaison sur site ne reçoit pas de trafic

Si un point de terminaison ne reçoit pas de trafic, assurez-vous qu'il passe les vérifications d'état et les requêtes DNS du client Envoy renvoient son adresse IP de manière cohérente.

Envoy utilise le mode strict_dns pour gérer les connexions. Il équilibre la charge du trafic sur tous les points de terminaison résolus qui sont opérationnels. L'ordre dans lequel les points de terminaison sont résolus n'a pas d'importance en mode strict_dns, mais Envoy draine le trafic vers un point de terminaison qui ne figure plus dans la liste des adresses IP renvoyées.

L'en-tête d'hôte HTTP ne correspond pas au nom de domaine complet lorsque la requête atteint mon serveur sur site

Prenons un exemple dans lequel le domaine example.com est résolu en 10.0.0.1, qui est l'adresse IP de la règle de transfert, et le domaine altostrat.com est résolu en 10.0.0.100, qui est votre point de terminaison de service local. Vous souhaitez envoyer du trafic vers le domaine altostrat.com, qui est configuré dans votre NEG.

Il est possible que l'application dans Compute Engine ou GKE définisse l'en-tête HTTP Host sur example.com (Host: example.com) qui est transféré au point de terminaison sur site. Si vous utilisez HTTPS, Envoy définit l'extension SNI sur altostrat.com lors du handshake TLS. Envoy obtient le SNI à partir de la ressource de la règle TLS du client.

Si ce conflit entraîne des problèmes lors du traitement ou du routage de la requête lorsqu'elle atteint le point de terminaison sur site, en tant que solution, vous pouvez réécrire l'en-tête Host en altostrat.com (Host: altostrat.com). Cela peut être effectué dans Cloud Service Mesh à l'aide de la réécriture d'URL ou sur le point de terminaison distant si celui-ci dispose de la fonctionnalité de réécriture d'en-têtes.

Une autre solution plus complexe consiste à définir l'en-tête Host sur altostrat.com (Host: altostrat.com) et à utiliser l'adresse spéciale 0.0.0.0 comme adresse IP de la règle de transfert.

Envoy renvoie de nombreuses erreurs 5xx

Si Envy renvoie un nombre excessif d'erreurs 5xx, procédez comme suit :

  • Consultez les journaux Envoy pour déterminer si la réponse provient du backend (sur site) et la raison de l'erreur 5xx.
  • Assurez-vous que les requêtes DNS réussissent et qu'il n'y a pas d'erreurs SERVFAIL ou NXDOMAIN.
  • Assurez-vous que tous les points de terminaison distants réussissent les vérifications d'état.
  • Si les vérifications d'état ne sont pas configurées, assurez-vous que tous les points de terminaison sont accessibles depuis Envoy. Vérifiez vos règles de pare-feu et vos routes côté Google Cloud et côté site.

Impossible d'accéder aux services externes via l'Internet public depuis le maillage de services

Vous pouvez envoyer du trafic vers des services situés sur l'Internet public à l'aide de backends FQDN dans Cloud Service Mesh. Vous devez d'abord établir la connectivité Internet entre les clients Envoy et le service externe. Si vous obtenez une erreur 502 lors des connexions au service externe, procédez comme suit 

  • Assurez-vous que les routes sont correctes, en particulier la route par défaut 0.0.0.0/0 et les règles de pare-feu configurées.
  • Assurez-vous que les requêtes DNS réussissent et qu'il n'y a pas d'erreurs SERVFAIL ou NXDOMAIN.
  • Si le proxy Envoy s'exécute dans une VM Compute Engine qui ne possède pas d'adresse IP externe ou dans un cluster GKE privé, vous devez configurer Cloud NAT ou d'autres moyens pour établir une connectivité Internet sortante.

Si les erreurs persistent, ou si vous obtenez d'autres erreurs 5xx, consultez les journaux Envoy pour affiner la source des erreurs.

Impossible d'accéder aux services sans serveur à partir du maillage de services

Vous pouvez envoyer du trafic aux services sans serveur (Cloud Run, fonctions Cloud Run et App Engine) à l'aide de backends FQDN dans Cloud Service Mesh. Si le proxy Envoy s'exécute dans une VM Compute Engine qui ne possède pas d'adresse IP externe ou dans un cluster GKE privé, vous devez configurer l'accès privé à Google sur le sous-réseau pour pouvoir accéder aux API et services Google.

Étape suivante