Route traffic from Cloud Service Mesh workloads to Cloud Run Services

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.

This page shows you how to securely route network traffic fromCloud Service Mesh workloads on GKE to Cloud RunServices.

Note that when routing traffic from GKE to Cloud Run, itis not required to have Cloud Run Service join theCloud Service Mesh. However, the Cloud Run Service must be inthe same project as the Cloud Service Mesh GKE cluster. Thislimitation exists while this feature is available in public preview.

Before you begin

The following sections assume that you have:

1. A GKE cluster with Cloud Service Mesh enabled.
2. Deployed a Cloud Run service.

Alternatively, you can run the following commands to deploy a sampleCloud Run service.

1. Generate a kubeconfig context for your cluster:

   gcloudcontainerclustersget-credentialsCLUSTER_NAME--project=PROJECT_ID--location=CLUSTER_LOCATION

   Where:

   • CLUSTER_NAME is the name of the your cluster.
   • PROJECT_ID is the project ID of your project.
   • CLUSTER_LOCATION is the region or zone of your cluster.

2. Deploy a sample Cloud Run service:

   gcloudrundeployhello-world\--image=us-docker.pkg.dev/cloudrun/container/hello\--no-allow-unauthenticated\--port=8080\--service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com\--region=us-central1\--project=PROJECT_ID

   Where:

   • PROJECT_NUMBER is the project number of the your project.
   • PROJECT_ID is the project ID of your project.

Configure IAM

To invoke Cloud Run services, Cloud RunIdentity and Access Management (IAM) checks must pass. You must granttheCloud Run Invoker roleto the Google Service Account. You must also configure the GKEKubernetes Service Account (KSA) to impersonate the Google Service Account.

Perform the following steps to allow a Kubernetes Service Account to impersonatea Google Service Account.

1. Add an IAM policy binding to an IAM serviceaccount:

   gcloudiamservice-accountsadd-iam-policy-bindingPROJECT_NUMBER-compute@developer.gserviceaccount.com\--roleroles/iam.workloadIdentityUser\--member"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"

   Where:

   • NAMESPACE is the namespace name. For the purposes of this guide,you can use the namespacedefault.
   • KSA is the name of the Kubernetes Service Account. For thepurposes of this guide, you can use the KSAdefault.

2. Annotate the service account:

   kubectlannotateserviceaccountKSA\--namespaceNAMESPACE\iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

3. Grant the Cloud Run Invoker Role to the Google Service Account:

   gcloudrunservicesadd-iam-policy-bindinghello-world\--region=us-central1\--member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com"\--role="roles/run.invoker"

Configure a Cloud Run Service as a GCPBackend

In this section, you expose the Cloud Run service 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 Cloud Run Service details such as servicename, location, and project number.

The GCPBackend contains the hostname and port details as well as the CloudService details (service name, location, and project number). TheGKE workloads should use the GCPBackend hostname and port intheir HTTP requests to access the Cloud Run Service.

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:cr-gcp-backendnamespace:NAMESPACEspec:hostname:hello-world.gcpbackendtype:CloudRuncloudrun:service:hello-worldregions:[us-central1]EOFkubectlapply-fgcp-backend.yaml

   In this exampleGCP_BACKEND_NAME iscr-gcp-backend.

4. Create a testing Pod to verify GKE to Cloud Runconnectivity:

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

   Now, your GKE workloads may access the Cloud Run Service bysending HTTP requests tohello-world.gcpbackend/hello.

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 Cloud Run Service must be in the same project as theCloud Service Mesh GKE cluster.

(Optional) Use Cloud Run's hostname instead of Cloud DNS

Every Cloud Run Service is assigned a hostname (for example,hello-world.us-central1.run.app) and is DNS resolvable globally. You can usethis hostname directly in the GCPBackend hostname and skip the Cloud DNSconfiguration.

cat<<EOF|kubectlapply-f-apiVersion:networking.gke.io/v1kind:GCPBackendmetadata:name:cr-gcp-backendnamespace:NAMESPACEspec:hostname:hello-world.us-central1.run.apptype:CloudRuncloudrun:service:hello-worldregion:[us-central1]EOF

Now, your GKE workloads may access the Cloud Run Service bysending HTTP requests tohello-world.us-central1.run.app.

(Optional) Configure Istio Virtual Service and or Destination Rule

You can configure Istio Virtual Service or Istio Destination Rule for theGCPBackend Hostname to set consumer or client policies for requests to theGCPBackend.

The following example injects a delay of 5s to 50% of the requests and abort(503 http status) to 10% of the requests going to the GCPBackend.

cat<<EOF|kubectlapply-f-apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:cr-virtual-servicenamespace:NAMESPACEspec:hosts:-hello-world.us-central1.run.appgateways:-meshhttp:-fault:delay:percentage:value:50# Delay 50% of requestsfixedDelay:5sabort:percentage:value:10# Abort 10% of requestshttpStatus:503-route:-destination:host:hello-world.us-central1.run.appEOF

In this exampleVIRTUAL_SERVICE_NAME iscr-virtual-service.

Troubleshooting

This section shows you how to troubleshoot common errors withCloud Service Mesh and Cloud Run.

Cloud Run Sidecar Logs

Envoy errors are logged in Cloud Logging.

For example an error such as the following will be logged if theCloud Run service account is not given the trafficdirector client rolein the mesh project:

StreamAggregatedResourcesgRPCconfigstreamtotrafficdirector.googleapis.com:443closed:7,Permission'trafficdirector.networks.getConfigs'deniedonresource'//trafficdirector.googleapis.com/projects/525300120045/networks/mesh:test-mesh/nodes/003fb3e0c8927482de85f052444d5e1cd4b3956e82b00f255fbea1e114e1c0208dbd6a19cc41694d2a271d1ab04b63ce7439492672de4499a92bb979853935b03d0ad0'(oritmaynotexist).

CSDS

The trafficdirector client state can be retrieved using CSDS:

gcloudalphacontainerfleetmeshdebugproxy-status--membership=<CLUSTER_MEMBERSHIP>--location=<CLUSTER_LOCATION>ExternalClients:....

What's next

• Route traffic from Cloud Run Services to Cloud Service Mesh workloads on GKE