[[["易于理解","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-09-04。"],[],[],null,["Route traffic from Cloud Service Mesh workloads to Compute Engine VM\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/docs/overview).\n\nThis page shows you how to securely route network traffic from\nCloud Service Mesh workloads on GKE to Compute Engine VM fronted by a BackendService.\n\nNote that when routing traffic from GKE to a Compute Engine VM, it\nis not required to have the Compute Engine VM or BackendService join the\nCloud Service Mesh. However, the Compute Engine VM and BackendService must be in\nthe same project as the Cloud Service Mesh GKE cluster. This\nlimitation exists while this feature is available in public preview. MTLS isn't supported for Compute Engine VMs\n\nBefore you begin\n\nThe following sections assume that you have:\n\n1. [A GKE cluster with Cloud Service Mesh enabled](/service-mesh/docs/onboarding/provision-control-plane).\n2. [Deployed a Compute Engine VM that is fronted by a BackendService](/service-mesh/docs/service-routing/set-up-envoy-http-mesh#config-server).\n\nAlternatively, you can run the following commands to deploy a sample\nCompute Engine VM fronted by a BackendService.\n\n1. Deploy a sample Compute Engine VM and BackendService:\n\n gcloud compute instance-templates create td-httpd-vm-template \\\n --scopes=https://www.googleapis.com/auth/cloud-platform \\\n --tags=http-td-server \\\n --image-family=debian-11 \\\n --image-project=debian-cloud \\\n --metadata=startup-script=\"#! /bin/bash\n sudo apt-get update -y\n sudo apt-get install apache2 -y\n sudo service apache2 restart\n echo '\u003c!doctype \u003chtml\u003e\u003cbody\u003e\u003ch1\u003e'\\`$(/bin/hostname)\\`'\u003c/h1\u003e\u003c/body\u003e\u003c/html\u003e' | sudo tee /var/www/html/index.html\"\n\n gcloud compute instance-groups managed create http-td-mig-us-east1 \\\n --zone=\u003cvar translate=\"no\"\u003eVM_ZONE\u003c/var\u003e \\\n --size=2 \\\n --template=td-httpd-vm-template\n\n gcloud compute health-checks create http http-helloworld-health-check\n\n gcloud compute firewall-rules create http-vm-allow-health-checks \\\n --network=default \\\n --action=ALLOW \\\n --direction=INGRESS \\\n --source-ranges=0.0.0.0/0 \\\n --target-tags=http-td-server \\\n --rules=tcp:80\n\n gcloud compute backend-services create helloworld \\\n --global \\\n --load-balancing-scheme=INTERNAL_SELF_MANAGED \\\n --protocol=HTTP \\\n --health-checks http-helloworld-health-check\n\n gcloud compute backend-services add-backend helloworld \\\n --instance-group=http-td-mig-us-east1 \\\n --instance-group-zone=\u003cvar translate=\"no\"\u003eVM_ZONE\u003c/var\u003e \\\n --global\n\n Where:\n - \u003cvar translate=\"no\"\u003eVM_ZONE\u003c/var\u003e is the zone where you want your Compute Engine VM to be deployed.\n\nConfigure a Compute Engine VM as a GCPBackend\n\nIn this section, you expose the Compute Engine VM to the GKE\nworkloads using GCPBackend. The GCPBackend consists of:\n\n1. Frontend information - specifically, the hostname and port that GKE Workloads would use to call this GCPBackend.\n2. Backend information - the BackendService details such as service name, location, and project number.\n\nThe GCPBackend contains the hostname and port details as well as the BackendService details (service name, location, and project number). The\nGKE workloads should use the GCPBackend hostname and port in\ntheir HTTP requests to access the Compute Engine VM.\n\nTo make the hostname DNS resolvable within the cluster (by default it isn't\nresolvable), you must configure Google Cloud DNS to resolves all hosts under\na chosen hostname to an arbitrary IP address. Until you configure this DNS entry,\nthe request fails. The Google Cloud DNS configuration is a one-time setup per\ncustom domain.\n\n1. Create a managed-zone:\n\n gcloud dns managed-zones create prod \\\n --description=\"zone for gcpbackend\" \\\n --dns-name=\u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e \\\n --visibility=private \\\n --networks=\u003cvar translate=\"no\"\u003edefault\u003c/var\u003e\n\n In this example the DNS Name is \u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e and the\n VPC Network is \u003cvar translate=\"no\"\u003edefault\u003c/var\u003e.\n2. Set up the record to make the domain resolvable:\n\n gcloud beta dns record-sets create *.\u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e \\\n --ttl=3600 --type=A --zone=prod \\\n --rrdatas=10.0.0.1\n\n3. Create the GCPBackend with a hostname under the previous domain:\n\n cat \u003c\u003cEOF \u003e gcp-backend.yaml\n apiVersion: networking.gke.io/v1\n kind: GCPBackend\n metadata:\n name: \u003cvar translate=\"no\"\u003evm-gcp-backend\u003c/var\u003e\n namespace: \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e\n spec:\n type: \"BackendService\"\n hostname: \u003cvar translate=\"no\"\u003ehello-world\u003c/var\u003e.\u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e\n backendservice:\n name: helloworld\n location: global\n EOF\n kubectl apply -f gcp-backend.yaml\n\n In this example \u003cvar translate=\"no\"\u003eGCP_BACKEND_NAME\u003c/var\u003e is `vm-gcp-backend`.\n4. Create a testing Pod to verify GKE to Compute Engine VM\n connectivity:\n\n cat \u003c\u003cEOF | kubectl apply -f -\n apiVersion: v1\n kind: Pod\n metadata:\n name: testcurl\n namespace: default\n spec:\n containers:\n - name: curl\n image: curlimages/curl\n command: [\"sleep\", \"3000\"]\n EOF\n\n kubectl exec testcurl -c curl -- curl http://\u003cvar translate=\"no\"\u003ehello-world\u003c/var\u003e.\u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e:80\n\n Now, your GKE workloads may access the Compute Engine VM by\n sending HTTP requests to **\u003cvar translate=\"no\"\u003ehello-world\u003c/var\u003e.\u003cvar translate=\"no\"\u003egcpbackend\u003c/var\u003e:80**.\n\nYou should use distinct names for GCPBackend to avoid conflicting with existing\nKubernetes services or Istio Service Entries. If it does conflict, the\nprecedence order (high to low) is Kubernetes Service, istio ServiceEntry, and\nGCPBackend.\n\nNote that the Virtual Service and the GCPBackend must be in the same namespace\nand the Compute Engine VM must be in the same project as the\nCloud Service Mesh GKE cluster."]]