Events for Cloud Run for Anthos >= Knative Eventing on Kubernetes


Introduction

We recently announced a new feature, Events for Cloud Run for Anthos, to build event driven systems on Google Kubernetes Engine (GKE). In the announcement, we also stated that the solution is based on open-source Knative.

In this blog post, I want to further explain the relationship between this new feature and Knative. I also want to convince you that our solution is an easier way to deploy Knative compliant event consuming services on Google Cloud.

TLDR: Events for Cloud Run for Anthos is Knative Eventing packaged and simplified for Google Cloud.

Sure, you can still create a GKE cluster, install Istio, install Knative on top, and deploy services reading events with Knative Eventing on your own. However, it will take you much longer to set everything up, not to mention the maintenance nightmare to keep track of all versions and dependencies.

Let’s dive into details by going through an example. Imagine you want to deploy a service to read events from a Google Cloud Storage bucket. What does it take to set this up in Knative vs. Cloud Run for Anthos?

Knative Eventing

Create an eventing enabled cluster

To read Google Cloud Storage events with Knative eventing, first, you need a Knative enabled cluster and you need to install event sources to read Google Cloud events. These are roughly the steps:

  1. Create a GKE cluster.
  2. Install Istio.
  3. Install Knative Serving.
  4. Install Knative Eventing.
  5. Install and configure Knative with GCP components.

I actually try to maintain a setup script in my Knative Tutorial to do all this and it’s a lot of work to update this script every time there’s a new version of Knative.

Deploy a service and connect to events

Once you have the cluster, you need to:

  1. Create a CloudStorageSource to read Cloud Storage events into the cluster.
  2. Inject a Broker in the namespace to receive events.
  3. Deploy a Knative Service to consume events.
  4. Create a Trigger to filter and pass Cloud Storage events from Broker to the Knative Service.

I won’t bore you with the details, I have a Cloud Storage triggered service sample in my Knative Tutorial with detailed instructions that involves multiple yaml files, deployments etc. Definitely not a quick & easy process.

Events for Cloud Run for Anthos

Now, let’s create the same sample with Cloud Run for Anthos.

Create an eventing enabled cluster

Like before, we need an eventing enabled GKE cluster. This is a 2 step process:

Create a GKE cluster with CloudRun add-on on rapid channel:

gcloud beta container clusters create ${CLUSTER_NAME} \
  --addons=HttpLoadBalancing,HorizontalPodAutoscaling,CloudRun \
  --machine-type=n1-standard-4 \
  --enable-autoscaling --min-nodes=3 --max-nodes=10 \
  --no-issue-client-certificate --num-nodes=3 --image-type=cos \
  --enable-stackdriver-kubernetes \
  --scopes=cloud-platform,logging-write,monitoring-write,pubsub \
  --zone ${CLUSTER_ZONE} \
  --release-channel=rapid

Initialize the cluster with eventing components:

gcloud beta events init

At this point, you will have an eventing enabled cluster with all the setup done for you. No Istio install, no Knative installation, no Knative-GCP installation and configuration!

Deploy a service and connect to events

This is a similar but slightly simplified process to Knative Eventing, involving Broker, Trigger etc.

First, inject a Broker in the namespace:

gcloud beta events brokers create default --namespace default

Deploy a Cloud Run service as event consumer:

gcloud run deploy event-display \
   --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display@sha256:8da2440b62a5c077d9882ed50397730e84d07037b1c8a3e40ff6b89c37332b27

Create a Trigger to filter and pass Cloud Storage events from Broker to the Cloud Run Service:

gcloud beta events triggers create trigger-storage \
  --target-service event-display \
  --type=google.cloud.storage.object.v1.finalized \
  --parameters bucket=bucket-name

Note that we didn’t have to create a CloudStorageSource manually, the Trigger created it for us. We didn’t have to deal with yaml files, instead relied on gcloud commands to do the right thing for us. Best of all, we don’t have to upgrade Knative Eventing manually going forward, GKE operator can do that for us!


Hopefully, this post clarified the relationship between Knative Eventing and Events for Cloud Run for Anthos.

To learn more:


Feel free to reach out to me on Twitter @meteatamel or read my previous posts on medium/@meteatamel.


See also