INTERNET_FQDN_PORT 类型的网络端点的健康检查行为与用于 Cloud Load Balancing 和 Cloud Service Mesh 的其他类型网络端点的健康检查行为不同。大多数其他网络端点类型都使用 Google Cloud的集中式健康检查系统，但用于多云端环境中的端点（INTERNET_FQDN_PORT 和 NON_GCP_PRIVATE_IP_PORT）的 NEG 使用 Envoy 的分布式健康检查机制。
Envoy 支持以下健康检查协议：
HTTP
HTTPS
HTTP/2
TCP
您可以使用 Compute Engine API 配置健康检查。
DNS 注意事项
关于 DNS，有两类不同的注意事项：
用于托管外部服务资源记录的 DNS 服务器。
Envoy 代理配置为使用 DNS 进行连接管理的模式。
Cloud DNS 服务器
您可以创建 Cloud DNS 托管式专用区域，以在 Google Cloud 项目中托管 DNS 记录。您还可以使用 Cloud DNS 的其他功能（例如转发区域）从本地 DNS 服务器提取记录。
Envoy DNS 模式
Envoy DNS 模式（也称为服务发现）指定 Envoy 代理如何使用 DNS 记录来管理出站连接。Cloud Service Mesh 将 Envoy 配置为使用严格 DNS 模式。严格 DNS 模式支持负载均衡到所有已解析端点。它遵循健康检查状态，并排空与不健康或不再使用 DNS 进行解析的端点的连接。您无法更改此模式。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-14。"],[],[],null,["# Cloud Service Mesh with internet network endpoint groups\n========================================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Google Cloud APIs and does not support Istio APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nYou can configure Cloud Service Mesh to use\n[internet network endpoint groups (NEGs)](/load-balancing/docs/negs/internet-neg-concepts)\nof the type `INTERNET_FQDN_PORT`. The external service is represented by its\nfully qualified domain name (FQDN) and port number in the NEG. The NEG can\ncontain only one `FQDN:Port` pair, and the backend service can contain only one\nNEG of this type. The FQDN is resolved by using the underlying\nVirtual Private Cloud (VPC) network's\n[name resolution order](/dns/docs/vpc-name-res-order).\n\nExpand the Cloud Service Mesh service mesh using FQDN backends\n--------------------------------------------------------------\n\nThe Cloud Service Mesh service mesh can route traffic to private services that\nare reachable by using hybrid connectivity, including named on-premises,\nmulti-cloud, and internet services. The remote service is referenced by its FQDN.\n[](/static/service-mesh/docs/images/internet-neg-example-setup.svg) Extending the Cloud Service Mesh service mesh to on-premises or multi-cloud locations using FQDN backends over hybrid connectivity (click to enlarge)\n\nYou can also route traffic to services that are reachable over the public\ninternet.\n[](/static/service-mesh/docs/images/td-internet-service.svg) Extending the Cloud Service Mesh service mesh to an internet service using FQDN backends (click to enlarge)\n\nGoogle Cloud resources and architecture\n---------------------------------------\n\nThis section describes the resources and architecture for configuring\nCloud Service Mesh with an internet NEG.\n\n`INTERNET_FQDN_PORT` network endpoint group\n-------------------------------------------\n\nTo route traffic to an external service referenced by its FQDN, use the global\ninternet NEG of the type `INTERNET_FQDN_PORT`. The NEG contains\nthe FQDN of your service and its port number. Cloud Service Mesh programs the\nFQDN into Envoy proxies by using xDS configuration.\n\nCloud Service Mesh itself does not guarantee name resolution and reachability\nof the remote endpoints. The FQDN must be resolvable by the name resolution\norder of the VPC network to which the Envoy proxies are attached,\nand the resolved endpoints must be reachable from the Envoy proxies.\n\nHealth checks\n-------------\n\nHealth checking behavior for network endpoints of the type `INTERNET_FQDN_PORT`\ndiffers from health checking behavior for other types of network endpoints used\nwith Cloud Load Balancing and Cloud Service Mesh. While most other network\nendpoint types use Google Cloud's centralized health checking system, the\nNEGs used for endpoints in multi-cloud environments (`INTERNET_FQDN_PORT`\nand `NON_GCP_PRIVATE_IP_PORT`) use Envoy's distributed health checking\nmechanism.\n\nEnvoy supports the following protocols for health checking:\n\n- HTTP\n- HTTPS\n- HTTP/2\n- TCP\n\nYou configure health checks by using the Compute Engine APIs.\n\nDNS considerations\n------------------\n\nThere are two distinct considerations regarding DNS:\n\n- The DNS server that hosts the resource records of your external service.\n- The mode with which the Envoy proxy is configured to use DNS for connection management.\n\n### Cloud DNS server\n\nYou can create a Cloud DNS\n[managed private zone](/dns/docs/zones#create-private-zone) to host the DNS\nrecords in your Google Cloud project. You can also use other features of\nCloud DNS, such as\n[forwarding zones](/dns/docs/zones#creating-forwarding-zones), to fetch records\nfrom an on-premises DNS server.\n\n### Envoy DNS mode\n\nEnvoy DNS mode, which is also called *service discovery* , specifies how the Envoy\nproxy uses DNS records for managing outbound connections. Cloud Service Mesh\nconfigures Envoy to use [strict DNS mode](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#strict-dns).\nStrict DNS mode enables load balancing to all resolved endpoints. It honors\nhealth check status and drains connections to endpoints that are unhealthy or\nno longer resolved by using DNS. You cannot change this mode.\n\nFor more information about service discovery, see the Envoy documentation.\n\nConnectivity and routing\n------------------------\n\nIf you are routing traffic to a private service, the following are the\nrequirements for the underlying network connectivity:\n\n- Hybrid connectivity between the VPC network and the on-premises data center or third-party public cloud is established by using Cloud VPN or Cloud Interconnect.\n- VPC firewall rules and routes are correctly configured to establish bi-directional reachability from Envoy to your private service endpoints and, if applicable, to the on-premises DNS server.\n- For successful regional high-availability failover, global dynamic routing must be enabled. For more details, see [dynamic routing mode](/network-connectivity/docs/router/concepts/learned-routes#dynamic-routing-mode-effects-on-learned-routes).\n\nIf you are routing traffic to an external service that is\nreachable on the internet, the following are the requirements:\n\n- The client virtual machine (VM) instances in the VPC network must have an external IP address or Cloud NAT.\n- The [default route](/vpc/docs/routes#routingpacketsinternet) must be present to egress traffic to the internet.\n\nIn both of the preceding cases, traffic uses the VPC network's\nrouting.\n\nSecurity\n--------\n\nFQDN backends are compatible with\n[Cloud Service Mesh's security features](/service-mesh/docs/service-routing/security-overview#securing_service-to-service_communications)\nand APIs. On the outbound connections to your external service, you can\nconfigure FQDN in the SNI header by using\n[client TLS policies](/service-mesh/legacy/load-balancing-apis/set-up-internet-neg#unauth-https).\n\nLimitations and considerations\n------------------------------\n\n- Internet NEGs of the type `INTERNET_IP_PORT` are not supported with Cloud Service Mesh.\n- Envoy version 1.15.0 or later is required with FQDN backends.\n- Use the Google Cloud CLI or REST APIs to configure Cloud Service Mesh. End-to-end configuration using the Google Cloud console is not supported.\n- FQDN backends are only supported with Envoy. Proxyless gRPC is not supported.\n- When you use the NEG type `INTERNET_FQDN_PORT` with Cloud Service Mesh, health\n checks of the remote endpoints are done using Envoy's distributed health\n checking mechanism. Whenever a new remote endpoint is added, all Envoy proxies\n start health checking it independently.\n\n Similarly, when a new Envoy proxy is added to the mesh, it starts checking\n all the remote endpoints. Therefore,\n depending on the number of Envoy proxies and remote endpoints in your\n deployment, the resulting health check mesh might cause significant network\n traffic and an undue load on the remote endpoints. You can choose not to\n configure health checks.\n- Health check status is not visible in the Google Cloud console for FQDN\n backends.\n\n- Health checking that uses the UDP, SSL, and gRPC protocols is not supported.\n\n- The following health check options are not supported:\n\n - HTTP/HTTP2/HTTPS health check\n - `--proxy-header`\n - `--response`\n - TCP health check\n - `--proxy-header`\n - `--request`\n - `--response`\n\nWhat's next\n-----------\n\n- To set up Cloud Service Mesh with internet NEGS, see [Set up external backends](/service-mesh/legacy/load-balancing-apis/set-up-internet-neg).\n- To learn about hybrid connectivity NEGs, see [Cloud Service Mesh with hybrid connectivity NEGs](/service-mesh/docs/service-routing/multi-environment-overview)."]]
