A quick summary of some key changes you’ll see in this release.

As of last week, IBM Cloud Kubernetes Service now supports Knative version 0.6. In this blog post, I’ll provide a quick summary of some key changes you’ll see in this release and then dive into one particular that I’m pretty excited about.

Knative Build: Asserting its independence

As I’m sure most everyone knows, Knative is made up of three main components: Serving, Eventing, and Build. Well, Knative Build has decided it wants its independence and is running away from home. Sort of.

A while ago, the Knative community realized that the features of Knative Build are not really specific to just Knative. The idea of defining a list of steps to execute where one possible outcome might be a new container image and deploying it to Knative Serving isn’t unique to Knative. Nor should these tasks that people define really be scoped to just Knative.

Perhaps they are more about other aspects of the CI/CD pipeline. With that, the ideas from Knative Build were used to seed a new project called Tekton. I’m not going to go into Tekton or the new foundation that was established around CD tooling, but instead just give a heads up that while Knative Build is still part of the Knative source and install, you should expect it to be removed in the near future as the work is shifted from Knative Build to Tekton.

I should also note that while Tekton is just one option for building images and defining build processes, it is not the only one. This is another reason for pulling Knative Build out of the Knative project—it allows for a looser coupling between the projects and doesn’t favor one particular choice over another.

Knative Eventing

Within the Knative Eventing, space I wanted to highlight just a few key things. First is a new resource type within the model called an “EventType.” As events are flowing through the Brokers, each time a new type of Event is seen (as defined by its “source” and “type” CloudEvents properties) a new EventType instance will be created and stored in an Event Registry.

The intent is that the Registry can then be used to determine what possible events can be subscribed to—avoiding the need for people to query the various Event Producers directly. To be honest, I’m still trying to see how useful this Registry is used going forward—so, we’ll see.

While there are new Knative Event Sources being developed all the time, I wanted to mention one in particular that’s important to IBM—the Kafka Event Source. With this, you can now retrieve events from any Kafka provider, including IBM Event Streams. This will allow for an even broader integration of Knative with other IBM managed services.

Knative Serving: Major overhaul

There have been some pretty significant developments within the Knative Serving space.

First, Istio is now optional. As useful as it is, there are some environments where a service mesh just isn’t needed, or there are other service meshes (aside from Istio) that people want to use. So, with that in mind, you can now choose to not install Istio at all for your Knative environment.

You’ll probably still need to install something to handle some of the basic networking infrastructure, like Ingress. You don’t need to worry about this within the IBM Cloud Kubernetes Service, though. Istio is still installed for you so all of the networking magic that we’ve worked hard to manage for you is still there—nothing from your side required.

Second, while you may not need this within IBM Cloud Kubernetes Service, for vanilla Knative installs, there’s now an auto-tls feature. This builds on cert-manager to create certificates automatically for you. You can use a variety of cert-managers (such as Let’s Encrypt) as needed. It’s worth noting that to use this, you’ll need Istio.

There has also been a ton of work within the performance side of Knative Serving. I won’t go into them here, but they’ve been working really hard to improve things like cold-start timings and how Services are scaled to zero, which should allow for even more optimizations in the future.

New Knative Service v1beta1 API

Now, let’s talk about a really big change—the new Knative Service v1beta1 API. If you’ve played with Knative, I’m sure you’re used to creating Services with yaml files that look like this:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: duglin/helloworld

And while this is manageable, it’s really verbose. If you then wanted to do some kind of A/B testing (or traffic splitting), you would then need to switch from a “runLatest” type of a Service to a “release” one:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld
spec:
  release:
    revisions: [ "@latest", "helloworld-as9ds" ]
    rolloutPercent: 10
    configuration:
      revisionTemplate:
        spec:
          container:
            image: duglin/helloworld

You’d then need to specify a “rolloutPercent” to control how much traffic would be routed to each of the two versions of your Service. This was ok, but it was kind of limiting since if you had more than two versions, you would need to leave the Service definition and have to manage the underlying Routes directly.

The new and improved Service API

In v0.6 there’s a new way to do this. First, let’s look at the simple case—just a single versioned Service:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld
spec:
 template:
    spec:
      containers:
        - image: duglin/helloworld

 You’ll notice that it’s not really that different from the previous way we would specify things. It is, however, a lot less verbose (which is always a good thing). Now, let’s look at what it would look like if we had more than one version of the Service:

apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
  name: helloworld
spec:
  template:
    metadata:
      name: helloworld-wip
    spec:
      containers:
      - image: duglin/helloworld
  traffic:
  - tag: current
    revisionName: helloworld-v1
    percent: 50
  - tag: candidate
    revisionName: helloworld-v2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0 

There are a couple of things to note here:

• There’s a still a “template” section that allows for you to specify what the latest version of your Service should look like, it was just renamed from “revisionTemplate.”
• The “spec.template.metadata.name” field is now used to allow you to provide a name for each revision. In the past, the system would generate a random name for you (and it still will if you don’t provide one) but this allows for you to give one that’s meaningful to you.
• Keep in mind that names are static and cannot move—so once you give a new revision a name, you cannot rename it, and you’ll need to change the “spec.template.metadata.name” each time you change the Service definition, otherwise you’ll get an error about the name already being used. You could also just remove it and let the system generate a name for you.

Sometime traffic is a good thing

The “traffic” section is new and really exciting. This allows for you, from within the Service definition, to control how much traffic goes to each version of your Service. In this particular example, I have three versions, where 50% goes to v1, 50% goes to v2, and nothing is automatically routed to the latest version. Notice that each item in the traffic block has a “tag” —this allows you to specify the name used in each version’s URL when you send a request directly to that version and bypass the traffic splitting logic entirely.

So, if you look at what I wrote above, by default, no traffic will go to the “latest” version of the Service. However, if I direct my request to “helloworld-latest-default.DOMAIN,” it’ll go to it. That’s really quite powerful and much more user-friendly than what was available in previous releases of Knative Serving.

One final thing—this new API does not allow you to specify a “build” section. This is done because, as I mentioned above, Knative Build is going away, and this modification is reflective of that change.

Get started with the new Service API

Anyway, that’s a very quick overview of the new Service API—there are more aspects to it which you can read in their docs, but I wanted to showcase some of the key aspects in here. Give it a try on IBM Cloud Kubernetes Service and let me know what you think!

For general questions, engage our team via Slack by registering here and join the discussion in the #managed_istio_knative channel on our public IBM Cloud Kubernetes Service Slack.

References

• Knative
• Knative 101
• IBM Kubernetes Service
• Kubernetes: A Complete Guide

• Knative: A Complete Guide