Knative v0.16.0 update

I finally got around to updating my Knative Tutorial from Knative v0.14.0 to the latest Knative v0.16.0 release. Since I skipped v0.15.0, I’m not sure which changes are due to v0.15.0 vs. v0.16.0. Regardless, there have been some notable changes that I want to outline in this blog post. This is not meant to be an exhaustive list. Feel free to let me know in the comments if there are other notable changes that I should be aware of.

Sugar Controller

Once I updated to v0.16.0, I realized the Broker injection into the default namespace did not work. Turns out, there’s a new Sugar Controller you need to install to have Broker injection. Installing Knative page has more details and my setup scripts have been updated to install this controller. This is how you install it:

kubectl apply -f \
  https://github.com/knative/eventing/releases/download/v0.16.0/eventing-sugar-controller.yaml

This allows you to:

When a Namespace is labeled with eventing.knative.dev/injection=enabled, the controller will create a default Broker in that namespace.
When a Trigger is annotated with eventing.knative.dev/injection=enabled, the controller will create a Broker named by that Trigger in the Trigger’s namespace.

Namespace label for Broker injection

If you were careful, you already realized that the namespace label for Broker injection used to be:

knative-eventing-injection

Now, it changed to:

eventing.knative.dev/injection

You have to label your namespace as follows now for Broker injection into that namespace (default in this case):

kubectl label ns default eventing.knative.dev/injection=enabled

Default Broker URL

Once the Broker is up and running, you’ll also realize that the default Broker URL also changed. If the Broker is injected into the default namespace, the URL used to be this:

http://default-broker.default.svc.cluster.local

Now, the new URL is:

http://broker-ingress.knative-eventing.svc.cluster.local/default/default

It’s good to remember if you need to send messages to the Broker.

Knative-GCP API version

As you might know, Knative-GCP project is useful to read Google Cloud events into Knative cluster. It also has a v0.16.0 release. With that, you can now move from v1alpha1 to v1beta1 API. This affects when you define a source, for example CloudStorageSource. You can use the newer API:

apiVersion: events.cloud.google.com/v1beta1
kind: CloudStorageSource
...

Google CloudEvents

Another notable change in v0.16.0 is that Knative-GCP now uses new CloudEvent attributes and data schemas and all sources now emit these CloudEvents. You can see the list of CloudEvents in google-cloudevents repository.

As an example, if you wanted to listen for file updates in a storage bucket in Cloud Storage, you’d create a trigger with com.google.cloud.storage.object.finalize filter:

apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
spec:
  filter:
    attributes:
      type: com.google.cloud.storage.object.finalize

Now, you need to use the new CloudEvents listed in google-cloudevents. The same trigger needs to filter on google.cloud.storage.object.v1.finalized instead:

apiVersion: eventing.knative.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
spec:
  filter:
    attributes:
      type: google.cloud.storage.object.v1.finalized

CloudSchedulerSource changes

Last but not least, I’ve realized that the CloudSchedulerSource events changed slightly. For example, take a look at the following CloudSchedulerSource:

apiVersion: events.cloud.google.com/v1beta1
kind: CloudSchedulerSource
metadata:
  name: schedulersource-cy
spec:
  location: "europe-west1"
  data: "Cyprus"
  schedule: "0 17 * * *"
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1beta1
      kind: Broker
      name: default

In the past, you’d get a CloudEvents with Cyprus in its Data field. In v0.16.0, you’d get a Data field with the value {"custom_data":"Q3lwcnVz"}. This is basically Cyprus Base64 encoded and saved under custom_data. You need to take this into account as you’re parsing the CloudEvent in your code.

These are the changes to look out for in v0.16.0. Did I miss anything? If so, let me know in the comments or reach out to me on Twitter (@meteatamel).