June 26, 2019 By Doug Davis 5 min read

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

More from Cloud

Sensors, signals and synergy: Enhancing Downer’s data exploration with IBM

3 min read - In the realm of urban transportation, precision is pivotal. Downer, a leading provider of integrated services in Australia and New Zealand, considers itself a guardian of the elaborate transportation matrix, and it continually seeks to enhance its operational efficiency. With over 200 trains and a multitude of sensors, Downer has accumulated a vast amount of data. While Downer regularly uncovers actionable insights from their data, their partnership with IBM® Client Engineering aimed to explore the additional potential of this vast dataset,…

Best practices for hybrid cloud banking applications secure and compliant deployment across IBM Cloud and Satellite

10 min read - Financial Services clients are increasingly looking to modernize their applications. This includes modernization of code development and maintenance (helping with scarce skills and allowing innovation and new technologies required by end users) as well as improvement of deployment and operations, using agile techniques and DevSecOps. As part of their modernization journey, clients want to have flexibility to determine what is the best “fit for purpose” deployment location for their applications. This may be in any of the environments that Hybrid…

Level up your Kafka applications with schemas

4 min read - Apache Kafka is a well-known open-source event store and stream processing platform and has grown to become the de facto standard for data streaming. In this article, developer Michael Burgess provides an insight into the concept of schemas and schema management as a way to add value to your event-driven applications on the fully managed Kafka service, IBM Event Streams on IBM Cloud®. What is a schema? A schema describes the structure of data. For example: A simple Java class…

SSD vs. NVMe: What’s the difference?

7 min read - Recent technological advancements in data storage have prompted businesses and consumers to move away from traditional hard disk drives (HDDs) towards faster, lower-latency solid-state drive (SSD) technology. In this post, we’re going to look at this new technology, as well as the fastest and most popular protocol available to connect it to a computer’s motherboard—non-volatile memory express (NVMe). While the terms SSD and NVMe are often used to describe two different types of drives, they are actually different data storage…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters