Route traffic from Cloud Service Mesh workloads to Compute Engine VM

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Note: This guide only supports Cloud Service Mesh with Istio APIs and doesnot support Google Cloud APIs. For more information see,Cloud Service Mesh overview.

This page shows you how to securely route network traffic fromCloud Service Mesh workloads on GKE to Compute Engine VM fronted by a BackendService.

Note that when routing traffic from GKE to a Compute Engine VM, itis not required to have the Compute Engine VM or BackendService join theCloud Service Mesh. However, the Compute Engine VM and BackendService must be inthe same project as the Cloud Service Mesh GKE cluster. Thislimitation exists while this feature is available in public preview. MTLS isn't supported for Compute Engine VMs

Before you begin

The following sections assume that you have:

  1. A GKE cluster with Cloud Service Mesh enabled.
  2. Deployed a Compute Engine VM that is fronted by a BackendService.

Alternatively, you can run the following commands to deploy a sampleCompute Engine VM fronted by a BackendService.

  1. Deploy a sample Compute Engine VM and BackendService:

    gcloudcomputeinstance-templatescreatetd-httpd-vm-template\--scopes=https://www.googleapis.com/auth/cloud-platform\--tags=http-td-server\--image-family=debian-11\--image-project=debian-cloud\--metadata=startup-script="#! /bin/bashsudo apt-get update -ysudo apt-get install apache2 -ysudo service apache2 restartecho '<!doctype <html><body><h1>'\`$(/bin/hostname)\`'</h1></body></html>' | sudo tee /var/www/html/index.html"gcloudcomputeinstance-groupsmanagedcreatehttp-td-mig-us-east1\--zone=VM_ZONE\--size=2\--template=td-httpd-vm-templategcloudcomputehealth-checkscreatehttphttp-helloworld-health-checkgcloudcomputefirewall-rulescreatehttp-vm-allow-health-checks\--network=default\--action=ALLOW\--direction=INGRESS\--source-ranges=0.0.0.0/0\--target-tags=http-td-server\--rules=tcp:80gcloudcomputebackend-servicescreatehelloworld\--global\--load-balancing-scheme=INTERNAL_SELF_MANAGED\--protocol=HTTP\--health-checkshttp-helloworld-health-checkgcloudcomputebackend-servicesadd-backendhelloworld\--instance-group=http-td-mig-us-east1\--instance-group-zone=VM_ZONE\--global

    Where:

    • VM_ZONE is the zone where you want your Compute Engine VM to be deployed.

Configure a Compute Engine VM as a GCPBackend

In this section, you expose the Compute Engine VM to the GKEworkloads using GCPBackend. The GCPBackend consists of:

  1. Frontend information - specifically, the hostname and port thatGKE Workloads would use to call this GCPBackend.
  2. Backend information - the BackendService details such as servicename, location, and project number.

The GCPBackend contains the hostname and port details as well as the BackendService details (service name, location, and project number). TheGKE workloads should use the GCPBackend hostname and port intheir HTTP requests to access the Compute Engine VM.

To make the hostname DNS resolvable within the cluster (by default it isn'tresolvable), you must configure Google Cloud DNS to resolves all hosts undera chosen hostname to an arbitrary IP address. Until you configure this DNS entry,the request fails. The Google Cloud DNS configuration is a one-time setup percustom domain.

  1. Create a managed-zone:

    gclouddnsmanaged-zonescreateprod\--description="zone for gcpbackend"\--dns-name=gcpbackend\--visibility=private\--networks=default

    In this example the DNS Name isgcpbackend and theVPC Network isdefault.

  2. Set up the record to make the domain resolvable:

    gcloudbetadnsrecord-setscreate*.gcpbackend\--ttl=3600--type=A--zone=prod\--rrdatas=10.0.0.1

  3. Create the GCPBackend with a hostname under the previous domain:

    cat<<EOF >gcp-backend.yamlapiVersion:networking.gke.io/v1kind:GCPBackendmetadata:name:vm-gcp-backendnamespace:NAMESPACEspec:type:"BackendService"hostname:hello-world.gcpbackendbackendservice:name:helloworldlocation:globalEOFkubectlapply-fgcp-backend.yaml

    In this exampleGCP_BACKEND_NAME isvm-gcp-backend.

  4. Create a testing Pod to verify GKE to Compute Engine VMconnectivity:

    cat<<EOF|kubectlapply-f-apiVersion:v1kind:Podmetadata:name:testcurlnamespace:defaultspec:containers:-name:curlimage:curlimages/curlcommand:["sleep","3000"]EOFkubectlexectestcurl-ccurl--curlhttp://hello-world.gcpbackend:80

    Now, your GKE workloads may access the Compute Engine VM bysending HTTP requests tohello-world.gcpbackend:80.

You should use distinct names for GCPBackend to avoid conflicting with existingKubernetes services or Istio Service Entries. If it does conflict, theprecedence order (high to low) is Kubernetes Service, istio ServiceEntry, andGCPBackend.

Note that the Virtual Service and the GCPBackend must be in the same namespaceand the Compute Engine VM must be in the same project as theCloud Service Mesh GKE cluster.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.