Mete Atamel
Sep 26 · 3 min read

Knative has been evolving pretty quickly. There’s a new release roughly every 6 weeks with significant changes in each release. Knative v0.7.0 was all about changes in Knative Serving (my post). Knative v0.8.0 was about deprecation of Knative Build in favor of Tekton Pipelines (my post).

Knative Serving v0.9.0 and Eventing v0.9.0 have been released a little over a week ago. In Serving, there’s a v1 API and a number of improvements on autoscaling and cold starts. In Eventing, the way events are read changed quite a bit. I want to outline some of these changes here.

ClusterChannelProvisioners ⇒ CRDs

Since v0.8.0, there has been a shift from ClusterChannelProvisioners to CRDs and this concluded in v0.9.0. The release notes give more details but this affects how Knative is setup to transport events. For example, in the previous release of Knative, in order to use Google Cloud Pub/Sub as the eventing transport, you’d create a Channel with the gcp-pubsub provisioner as explained in the docs.

In this release, there’s now a concrete CRD, channels.pubsub.cloud.run, that you create instead. It includes all the configuration parameters available for that transport. This makes it much easier to see available parameters and validate them.

Knative with GCP Project

Knative with GCP is a new project that aims to enable easy configuration and consumption of Google Cloud events. It’s now the preferred way of consuming Google Cloud events in Knative. It is installed separately on top of Knative (instructions) and allows reading Cloud Storage, Cloud Scheduler or Cloud Pub/Sub events.

Cloud Pub/Sub PullSubscription

In my Knative Tutorial, I read events from Cloud Pub/Sub into Knative. Knative with GCP Project has multiple ways of reading Pub/Sub messages into Knative. PullSubscription is one way of reading Cloud Pub/Sub messages directly into Knative.

This is done slightly different from the previous version of Knative. By default, Pub/Sub messages are not wrapped into CloudEvents anymore, so you don’t have to worry about unwrapping CloudEvents. Since you don’t have CloudEvents anymore, you also do not have to worry about Base64 decoding the data field of CloudEvents (If you still prefer the old behavior, there’s a mode config that you can set to PushCompatible).

All of these make the processing of Pub/Sub messages simpler than before. PullSubscription requires a Secret from a Pub/Sub enabled Service Account (instructions) and a yaml definition file that looks something like this:

apiVersion: pubsub.cloud.run/v1alpha1
kind: PullSubscription
metadata:
name: my-topic-source
spec:
topic: my-topic
sink:
apiVersion: v1
kind: Service
name: event-display

This links a Pub/Sub topic to a Kubernetes Service but it can be anything addressable like Knative Service, Channel, Broker, etc.


Hope this provides a little glimpse of changes to Knative in v.0.9.0. I already updated my Knative Tutorial to use Knative 0.9.0. Hello World Eventing goes through all the setup steps needed to read Pub/Sub messages in a simple Kubernetes service. Give it a try!

Google Cloud Platform - Community

A collection of technical articles published or curated by Google Cloud Platform Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Mete Atamel

Written by

Developer Advocate at Google

Google Cloud Platform - Community

A collection of technical articles published or curated by Google Cloud Platform Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade