v0.2 release

Published on: 2021-10-06

Improved pluggability, autoscaling, stability, and performance

Announcing Knative v0.2 Release

Improved pluggability, autoscaling, stability, and performance

We are excited to announce a new release of Knative, the set of middleware components for building modern applications on Kubernetes. The 0.2 release of Knative is the first significant update since the project’s launch in July. It represents months of hard work by the entire Knative community to address our learnings from the growing number of Knative deployments.

The most exciting aspect of the 0.2 release is the inclusion of eventing. The Eventing component complements the other two foundational blocks already defined by Knative: Serving and Build. We look forward to the new types of events and innovative solutions the community will develop using this new capability.

Serving made significant improvements “under the hood,” encapsulating key areas of Knative into subsystems with new internal APIs to enable support for pluggable networking, autoscaling, and caching.

The complete release notes are available in Knative Serving, Build, and Eventing repositories. Here are a few highlights:

New Eventing Resource Model
The eventing repo went through a significant rework of the resource model, resulting in migration of sources into Custom Resource Definitions (CRDs). Now, eventing includes a sophisticated use of standard Kubernetes concepts, resulting in better validation, cleaner interfaces, and RBAC support. The new architecture uses a simpler object model that is centered around channels and subscriptions.

Looser Coupling
One of the pieces of positive feedback we received on v0.1 was the “tasteful” choices defining Knative building blocks. In v0.2, Knative leans into this even further to enable operators to install the Build, Serving, and Eventing components independent of one another. The contract that enables these loose couplings between Knative components will also enable third party integrations over time, such as using a non-Knative Build with Serving, or delivering events to non-Serving deployments. We are excited to see what direction the community takes this.

Pluggable Subsystems
We also got a lot of feedback about wanting to customize Knative. The goal was always to support some measure of pluggability, so customization was significantly improved in v0.2. We introduced 3 new internal APIs in v0.2 to separate our core resource model from the subsystems that implement them: Networking, Autoscaling, and Caching. Networking enables developers to replace our Istio dependency with alternative ingress implementations. Autoscaling enables developers to replace our “cheap and cheerful” autoscaler with one of their own designs. Caching enables developers to employ image caching strategies to preload container images across their cluster (no implementation bundled, so this is a pure extension-point).

Improved Cold-Starts
Two of the dominant factors in cold-start performance are side-car injection and image pull latency. With their 1.0.2 release, Istio has made progress on reducing the Envoy programming time. In addition, we’ve made it possible to install Knative with side-car injection disabled. To enable folks to combat image pull latency, we have exposed a new extension point called an “Image” resource (part of knative/caching), which contains all the information needed for a controller to pre-load user images across a cluster. Caching is another feature we are excited to see the community build upon.

Autoscaling
We have replaced the previous per-Revision autoscalers with a single shared autoscaler. The new autoscaler is based on the same logic as the previous autoscaler, but has evolved to be purely metrics driven (including 0->1->0), eliminating the unnecessary Revision servingState field. We have replaced ConcurrencyModel (Single or Multi) with an integer ContainerConcurrency field. This allows limiting concurrency to values other than 1 for certain use cases (for example, limited thread pools).

Build
Knative Build added many incremental improvements, including the new ClusterBuildTemplate resource. Operators are now able to install a set of BuildTemplates one time instead of once per-Namespace. Build template parameters can now also apply to build step image names. New features of the Build spec allow users to specify a build-wide timeout, node selectors, and affinity. Last but not least, build status has been extended to report per-step build progress and build pending times.

Knative at KubeCon

Come and talk to us! There are a number of Knative sessions at the upcoming KubeCon conferences, both in Shanghai and Seattle.

Shanghai

Botless: A Serverless Chatbot Framework

Seattle