Announcing the Knative v0.3 release

Knative’s momentum continues! Once again, we are excited to announce a new release of Knative. After a series of architectural changes…

Announcing Knative v0.3 Release

Knative’s momentum continues! Once again, we are excited to announce a new release of Knative. After a series of architectural changes announced in the previous release, v0.3 implements many of the learnings from the growing number of Knative deployments, increases operational control, and improves stability.

As we move to a more predictable release schedule based on six week cadence, Knative releases will now be smaller and more frequent. We did this to enable a tighter feedback loop with our users and allow for smoother course corrections as we continue to learn from our growing number of users.

Starting with the v0.3 release, Knative now requires Kubernetes 1.11, due to the use of `/status` sub-resource support, which went Beta in Kubernetes 1.11 and fixes a long-standing Kubernetes CRD bug.

The complete set of Knative v0.3 release notes outlining the new features as well as bug fixes and architectural changes are available in the Serving, Build, and Eventing repositories. Here are a few highlights:

Serving API

With the v0.3 release, Knative now exposes a few additional parameters in its API. These include explicit Revision timeouts and the ability to specify the port for incoming traffic to the user container, which Knative previously exposed to the container using the “$PORT” environment variable.

An even bigger addition is support for the Kubernetes resources spec, which allows you to specify reservations and limits on the user container. Besides allowing the service to specify how much CPU and memory (RAM) it needs or limit how much it can use; this also allows developers to request access to hardware accelerators like GPU if their cluster includes nodes configured with that capability.

In v0.3, Knative is also more proactive about rolling out operator changes. Changes to serving ConfigMaps are now immediately reconciled and rolled out.

Autoscaling

Building on the new single shared autoscaler introduced in the previous release, v0.3 introduces a more aggressive scale-to-zero strategy, which will by default scale Revisions down to zero pods after only 30 seconds of inactivity. The default Knative Pod Autoscaler (KPA) now supports revision-level concurrency targets.

As shown in our Kubecon demo, Knative now offers Horizontal Pod Autoscaler (HPA). This is useful for those who need to opt-out of KPA and use CPU instead of request rate as a scaling metric. (Note: HPA-class Revisions will not scale to zero).

Lastly, you can now also mutate `PodAutoscaler` specs in-place to adjust the scale bounds and other parameters.

Networking

A frequently-requested feature is the ability to deploy services which are not exposed externally and can only be accessed by other services in the cluster. In v0.3, Routes configured to use the `svc.cluster.local` domain will only be exposed to the cluster-local Istio gateway. The cluster-local gateway will keep the deployed service inaccessible from outside the cluster. Developers can also use the `serving.knative.dev/visibility=cluster-local` label on their Route or Service to enable this behaviour.

Knative is also deprecating its dedicated Istio gateway. In v0.3 release, Knative will still expose public routes to both the deprecated gateway and the default Istio gateway. Starting with next release however, Knative will remove the deprecated gateway to further reduce overhead and avoid the additional cost of public IP. (Note, you may have to update the gateway IP in your DNS mappings).

Eventing

With the inclusion of Eventing in the previous release, there has been a significant focus on extending the number of and documenting available external event sources which can be installed in Knative as Kubernetes Custom Resource Definitions (CRDs). The complete list of currently supported event sources can be found here.

Build

The Knative Build component can now support both single `source` and multiple input `sources`. If multiple sources are requested, each will be fetched in declared order and placed into a directory under `/workspace` named after the source’s name field. The Build controller is also now subject to the PodSecurityPolicy which enables cluster operators to specify further limitations.

Monitoring

Metric labels should now be consistent across all of the Knative components. Also, in addition to the default Prometheus metric target, Knative control plane metrics (from Reconciler, Autoscaler, and Activator) can now be exported directly to Stackdriver.

Black lives matter.