Going Multicloud with Google Cloud Run and TriggerMesh Using Knative

Sebastien Goasguen
Sebastien Goasguen
May 22, 2019
Going Multicloud with Google Cloud Run and TriggerMesh Using Knative
Going Multicloud with Google Cloud Run and TriggerMesh Using Knative

At the last Google Next, Google announced a new serverless compute offering: Cloud Run. The service is currently beta and as stated in the product page:

Run stateless HTTP containers on a fully managed environment or in your own GKE cluster.

A very intriguing feature of Cloud Run is that you can run it on your Kubernetes cluster in GKE. This is possible because the technology used for Cloud Run is Knative, the same technology used for TriggerMesh cloud. Whether Knative internals are used in Cloud Run or only its API, can almost be seen as an implementation detail. The interesting part is that Knative is the common link between the two.

In this post, we will show you how you can deploy a service in Cloud Run and deploy the exact same service using the same API manifest to the TriggerMesh Cloud.

Take away: Knative gives you multicloud capability for your serverless workload.

Deploy A Cloud Run Service

First, let’s deploy the basic Hello World example of Cloud Run. You can do it through the Google console or through the gcloud CLI as shown below:

gcloud beta run deploy hello --image=gcr.io/cloudrun/hello --region=us-central1 --allow-unauthenticated
✓ Deploying new service... Done. 
✓ Creating Revision... 
✓ Routing traffic... 
✓ Setting IAM Policy... 
Done. 
Service [hello] revision [hello-9ee232e3-128b-4510-a8ea-c77959cf1bb8] has been deployed and is serving traffic at https://hello-tu4luqbmqq-uc.a.run.app

The pre-built container gets deployed, will scale to zero if the application is not used and you will only be charged per function calls.

You can access the application with your browser:

open https://hello-tu4luqbmqq-uc.a.run.app

Describe Your Service

With your sample Hello application running, you can now describe the API objects that corresponds to it. Again using the CLI, you can get the JSON manifest, massage it a bit with jq and get back the container image being used:

gcloud beta run services describe hello --region us-central1 --format json | \
jq -r .spec.runLatest.configuration.revisionTemplate.spec.container.image
gcr.io/cloudrun/hello

To save the full manifest, simply redirect it to a file hello.yaml like so:

gcloud beta run services describe hello --region us-central1 --format yaml > hello.yaml

If you peek into the file you will see that it is a Knative Service object:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
...
  name: hello
spec:
  runLatest:
    configuration:
      revisionTemplate:
        metadata:
          labels:
          ...
        spec:
          container:
            image: gcr.io/cloudrun/hello

Deploy a Cloud Run Service to TriggerMesh Cloud

If you register to TriggerMesh and download your configuration file you will be able to create Knative objects with the tm CLI and even with the Kubernetes CLI kubectl. Let’s try it with kubectl as shown below and our Cloud Run manifest obtained in the prior section:

kubectl -n sebgoa apply -f hello.yaml

We can now describe our TriggerMesh service and get the URL of our new application:

kubectl -n sebgoa get services.serving.knative.dev hello -o json | jq -r .status.domain
hello-sebgoa.k.triggermesh.io

Take your browser and open the equivalent of https://hello-sebgoa.k.triggermesh.io/ and you will enjoy the Cloud Run hello application on a different cloud!

Note that using the TriggerMesh client `tm` you could also deploy the same container as in Cloud Run with a similar CLI syntax:

tm deploy service hello --from-image gcr.io/cloudrun/hello

Related Posts

Join our newsletter

Subscribe to TriggerMesh newsletter. You'll get only the most important news about TriggerMesh