Maillage de services Cloud avec groupes de points de terminaison du réseau Internet
Vous pouvez configurer Cloud Service Mesh pour utiliser
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 Cloud Service Mesh à l'aide de backends de nom de domaine complet
Le maillage de services Cloud Service Mesh peut acheminer le trafic vers des services privés sont accessibles à l'aide d'une connectivité hybride, y compris sur site, multicloud et Internet. Le service distant est référencé par son nom de domaine complet.
<ph type="x-smartling-placeholder">Vous pouvez également acheminer le trafic vers des services accessibles via l'Internet public.
<ph type="x-smartling-placeholder">Ressources et architecture Google Cloud
Cette section décrit les ressources et l'architecture permettant de configurer Cloud Service Mesh 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. Cloud Service Mesh programme
Nom de domaine complet dans les proxys Envoy à l'aide de la configuration xDS.
Cloud Service Mesh lui-même ne garantit pas la résolution des 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
Comportement de la vérification de l'état pour les points de terminaison du réseau de type INTERNET_FQDN_PORT
diffère de la vérification de l'état pour les autres types de points de terminaison du réseau utilisés
avec Cloud Load Balancing et Cloud Service Mesh. 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 de l'é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. Cloud Service Mesh configure Envoy pour qu'il utilise 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 Fonctionnalités de sécurité de Cloud Service Mesh et des API. 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 Cloud Service Mesh. - La version 1.15.0 ou ultérieure d'Envoy est requise avec les backends FQDN.
- Utilisez la Google Cloud CLI ou les API REST pour configurer Cloud Service Mesh. 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 Cloud Service Mesh, l'état les vérifications des points de terminaison distants sont effectuées à l'aide du système le mécanisme de vérification. 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
- Vérification d'état HTTP/HTTP2/HTTPS
Étape suivante
- Pour configurer Cloud Service Mesh avec des NEG Internet, consultez Configurez des backends externes.
- Pour en savoir plus sur les NEG de connectivité hybride, consultez Cloud Service Mesh avec des NEG de connectivité hybride.