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:
This links a Pub/Sub topic to a Kubernetes Service but it can be anything addressable like Knative Service, Channel, Broker, etc.