serving

Meta

More regular releases

0.3 is the first release of our new schedule of releasing every 6 weeks.
This release is a smaller delta than 0.2 because of this shorter development cycle.

Kubernetes 1.11 is now required

We now use the Kubernetes /status sub-resource support, which went Beta in K8s 1.11.

Autoscaling

More aggressive scale to zero

We will now scale Revisions down to zero pods after only 30 seconds of inactivity.

Support for HPA-class autoscaler (Kubecon Demo)

You may now opt to use the Kubernetes HPA for autoscaling Revisions, if you want to scale on CPU instead of request rate. HPA-class Revisions will not scale to zero.

Support target and window annotations for KPA-class autoscaler

You may now tune the default Knative autoscaler (KPA) with revision-level concurrency targets and different windows over which to calculate average concurrency.

Support mutable PodAutoscalers

You may now mutate PodAutoscaler specs in-place to adjust the scale bounds and other parameters. The changes will be picked up dynamically by KPA and HPA-class autoscalers.

Core API

Support of “resources” block (thanks @jszroberto)

You may now specify the resources section of a container spec to include reservations and limits on the resources your service may use. This also lets your Service gain access to GPUs, if available on your cluster.

Elide Builds for config-only changes

We will now skip the Build step of a deployment if only the configuration of a Revision changes (e.g. env var).

Revisions can now specify TimeoutSeconds

Requests that show no activity within the allotted timeout will be cancelled and respond with a 503.

Inactive isn’t failed!

Fixed an issue in 0.2 where Services, Configurations, and Revisions that were scaled to zero would appear to have failed. The “Active” condition is now treated as a purely informational condition.

A Container Port can now be specified for incoming traffic

You may now specify a single 'containerPort' to customize which port will receive request traffic. If unspecified, the default port (8080) will be assumed. As with previous releases, this value is available to the container through the environment variable '$PORT'.

More Global Resyncs

Editing the Serving ConfigMaps will now immediately trigger all existing resources to reconcile, and reflect any newly configured settings. This avoids the (up to 10 hour) delay that would otherwise exist waiting for the normal resync.

Networking

Use the default gateway istio-ingressgateway by default (@lichuqiang)

We have deprecated the Knative copy of the Istio ingress gateway.
Routes can be exposed to additional Gateways.

Routes without external domain are exposed only to local Gateways

Route that only have svc.cluster.local domain suffix will not be exposed to Istio ingress gateway by default.
Users can set the label
serving.knative.dev/visibility=cluster-local on a Route or Service to achieve the same effect.

Reconcile ClusterIngress' based on Ingress class annotation (@greghaynes)

ClusterIngress class annotation is taken into account when reconciling. The default ClusterIngress reconciler only reconcile when the type is Istio.

Bug fixes:

https://github.com/knative/serving/issues/2359 (@lichuqiang) Conflict between Routes having the same names causing issue.
https://github.com/knative/serving/issues/2582 (@markusthoemmes) Correct Revision Timeout meaning.

Monitoring

Metrics improvements

New metrics are added for Knative reconciler
Metric labels were renamed to be consistent across all Knative components
Knative control plane (reconciler, autoscaler & activator) metrics can now be exported to Stackdriver backend

Logging improvements

Commit id of the running build is added to the logs generated by Knative components

Cherry Picks

See: https://github.com/knative/serving/projects/6

Meta

Pluggability:

We have made significant progress “under the hood” encapsulating the major subsystems of knative/serving in an effort to support pluggability (e.g. replace Istio). Our core resources now configure these subsystems: Networking, Autoscaling, and Caching via new internal APIs.

Looser Coupling:

We have spent considerable effort working to ensure that all knative components are usable in isolation, and splitting out our release artifacts into the smallest units we can. For instance, you can now install and use knative/serving without knative/build, and even plug in alternative Build CRDs!

Our release now consists of:

• serving.yaml: just the knative/serving components.
• build.yaml: just knative/build’s 0.2.0 release
• monitoring*.yaml: a number of different configurations of our monitoring stack.
• istio*.yaml: two configurations of our Istio stack, one with sidecar injection and one without.
• release*.yaml: similar bundles to last release

Autoscaling

New shared autoscaler (special thanks to @glyn @markusthoemmes)

We have replaced the previous per-Revision autoscalers with a single shared autoscaler. This 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.

Introduced the ContainerConcurrency 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 (e.g. limited thread pools).

• 1 is the new Single.
• 0 is the new Multi (no limit).

Example:

spec:
  containerConcurrency: 1
  container:
    image: docker.io/{username}/helloworld-go

ContainerConcurrency is now used to determine the autoscaler target concurrency.

Core API

Decoupled Build (special thanks to @imikushin)

Build is no longer required to run Serving, unless you plan to use it. The old style of expressing builds inline is still supported when Build is installed, but deprecated in favor of:

spec:
  build:
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    spec:
      # What was previously directly under "build:"

In addition, alternative Build implementations may be plugged in, the only requirement is that those Build resources indicate completion via:

status:
  conditions:
  - type: Succeeded
    status: True | False | Unknown

Revision GC (special thanks to @greghaynes)

A Configuration will now reclaim unroutable Revisions based on a few criteria:

• Time since its creation
• Time since it was last observed to be routable (via serving.knative.dev/lastPinned annotation heartbeat)
• Age (e.g. keep the last N)
• Is it the LatestReadyRevision of the Configuration?
• These knobs can be configured in config/config-gc.yaml.

Misc Features

• Service now supports the release and manual modes.
• Short names for Knative resources
• Custom columns in kubectl output (K8s 1.11+ only)
• Longer "resync" periods, with global resyncs on (some) configmap changes
• We now create caching.internal.knative.dev/Image resources to signal the images that are important to cache. Operators must install an extension to leverage these hints.

Networking

ClusterIngress abstraction (special thanks to @lichuqiang)

Route no longer depends directly on VirtualService, but an intermediate resource ClusterIngress which could be reconciled differently for different network platforms.

Istio Updates

• Moved to Istio 1.0.2.
• Hacks & workarounds needed due to 0.8.0 bugs are removed.
• Cluster-local access to Route (through route.ns.svc.cluster.local name) no longer requires the istio sidecar.

Bug fixes

• #2276 Route status incorrect for named traffic targets having the same revision #2234 Activator headers getting forwarded prevent scaling from 0 (@trisberg, @scothis)
• #2046 Activator can activate the wrong Service (@markusthoemmes)
• #2043 Activator leaks metrics publicly (@scothis, @tanzeeb)
• #1931 Queue-proxy does not work with custom cluster domain (@cizixs,@arvtiwar)
• #1907 Activator retries its own requests (@markusthoemmes).
• #1637 Placeholder k8s service reconciliation doesn't take defaulter into account #1229 Activator should retry with backoff (@markusthoemmes).
• #837 Activator deal with multiple ports (@markusthoemmes).

Monitoring

The monitoring namespace has changed to knative-monitoring

Bug fixes:

• #2255 Zipkin install without Elasticsearch
• #2201 Add service label to revisions (@pivotal-nader-ziada)
• #1474 Switch the fluentd configmap to one-per-Revision

Cherry Picks

See: https://github.com/knative/serving/projects/6

Meta

Pluggability:

We have made significant progress “under the hood” encapsulating the major subsystems of knative/serving in an effort to support pluggability (e.g. replace Istio). Our core resources now configure these subsystems: Networking, Autoscaling, and Caching via new internal APIs.

Looser Coupling:

We have spent considerable effort working to ensure that all knative components are usable in isolation, and splitting out our release artifacts into the smallest units we can. For instance, you can now install and use knative/serving without knative/build, and even plug in alternative Build CRDs!

Our release now consists of:

• serving.yaml: just the knative/serving components.
• build.yaml: just knative/build’s 0.2.0 release
• monitoring*.yaml: a number of different configurations of our monitoring stack.
• istio*.yaml: two configurations of our Istio stack, one with sidecar injection and one without.
• release*.yaml: similar bundles to last release

Autoscaling

New shared autoscaler (special thanks to @glyn @markusthoemmes)

We have replaced the previous per-Revision autoscalers with a single shared autoscaler. This 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.

Introduced the ContainerConcurrency 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 (e.g. limited thread pools).

• 1 is the new Single.
• 0 is the new Multi (no limit).

Example:

spec:
  containerConcurrency: 1
  container:
    image: docker.io/{username}/helloworld-go

ContainerConcurrency is now used to determine the autoscaler target concurrency.

Core API

Decoupled Build (special thanks to @imikushin)

Build is no longer required to run Serving, unless you plan to use it. The old style of expressing builds inline is still supported when Build is installed, but deprecated in favor of:

spec:
  build:
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    spec:
      # What was previously directly under "build:"

In addition, alternative Build implementations may be plugged in, the only requirement is that those Build resources indicate completion via:

status:
  conditions:
  - type: Succeeded
    status: True | False | Unknown

Revision GC (special thanks to @greghaynes)

A Configuration will now reclaim unroutable Revisions based on a few criteria:

• Time since its creation
• Time since it was last observed to be routable (via serving.knative.dev/lastPinned annotation heartbeat)
• Age (e.g. keep the last N)
• Is it the LatestReadyRevision of the Configuration?
• These knobs can be configured in config/config-gc.yaml.

Misc Features

• Service now supports the release and manual modes.
• Short names for Knative resources
• Custom columns in kubectl output (K8s 1.11+ only)
• Longer "resync" periods, with global resyncs on (some) configmap changes
• We now create caching.internal.knative.dev/Image resources to signal the images that are important to cache. Operators must install an extension to leverage these hints.

Networking

ClusterIngress abstraction (special thanks to @lichuqiang)

Route no longer depends directly on VirtualService, but an intermediate resource ClusterIngress which could be reconciled differently for different network platforms.

Istio Updates

• Moved to Istio 1.0.2.
• Hacks & workarounds needed due to 0.8.0 bugs are removed.
• Cluster-local access to Route (through route.ns.svc.cluster.local name) no longer requires the istio sidecar.

Bug fixes

• #2276 Route status incorrect for named traffic targets having the same revision #2234 Activator headers getting forwarded prevent scaling from 0 (@trisberg, @scothis)
• #2046 Activator can activate the wrong Service (@markusthoemmes)
• #2043 Activator leaks metrics publicly (@scothis, @tanzeeb)
• #1931 Queue-proxy does not work with custom cluster domain (@cizixs,@arvtiwar)
• #1907 Activator retries its own requests (@markusthoemmes).
• #1637 Placeholder k8s service reconciliation doesn't take defaulter into account #1229 Activator should retry with backoff (@markusthoemmes).
• #837 Activator deal with multiple ports (@markusthoemmes).

Monitoring

The monitoring namespace has changed to knative-monitoring

Bug fixes:

• #2255 Zipkin install without Elasticsearch
• #2201 Add service label to revisions (@pivotal-nader-ziada)
• #1474 Switch the fluentd configmap to one-per-Revision

Meta

Pluggability:

We have made significant progress “under the hood” encapsulating the major subsystems of knative/serving in an effort to support pluggability (e.g. replace Istio). Our core resources now configure these subsystems: Networking, Autoscaling, and Caching via new internal APIs.

Looser Coupling:

We have spent considerable effort working to ensure that all knative components are usable in isolation, and splitting out our release artifacts into the smallest units we can. For instance, you can now install and use knative/serving without knative/build, and even plug in alternative Build CRDs!

Our release now consists of:

• serving.yaml: just the knative/serving components.
• build.yaml: just knative/build’s 0.2.0 release
• monitoring*.yaml: a number of different configurations of our monitoring stack.
• istio*.yaml: two configurations of our Istio stack, one with sidecar injection and one without.
• release*.yaml: similar bundles to last release

Autoscaling

New shared autoscaler (special thanks to @glyn @markusthoemmes)

We have replaced the previous per-Revision autoscalers with a single shared autoscaler. This 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.

Introduced the ContainerConcurrency 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 (e.g. limited thread pools).

• 1 is the new Single.
• 0 is the new Multi (no limit).

Example:

spec:
  containerConcurrency: 1
  container:
    image: docker.io/{username}/helloworld-go

ContainerConcurrency is now used to determine the autoscaler target concurrency.

Core API

Decoupled Build (special thanks to @imikushin)

Build is no longer required to run Serving, unless you plan to use it. The old style of expressing builds inline is still supported when Build is installed, but deprecated in favor of:

spec:
  build:
    apiVersion: build.knative.dev/v1alpha1
    kind: Build
    spec:
      # What was previously directly under "build:"

In addition, alternative Build implementations may be plugged in, the only requirement is that those Build resources indicate completion via:

status:
  conditions:
  - type: Succeeded
    status: True | False | Unknown

Revision GC (special thanks to @greghaynes)

A Configuration will now reclaim unroutable Revisions based on a few criteria:

• Time since its creation
• Time since it was last observed to be routable (via serving.knative.dev/lastPinned annotation heartbeat)
• Age (e.g. keep the last N)
• Is it the LatestReadyRevision of the Configuration?
• These knobs can be configured in config/config-gc.yaml.

Misc Features

• Service now supports the release and manual modes.
• Short names for Knative resources
• Custom columns in kubectl output (K8s 1.11+ only)
• Longer "resync" periods, with global resyncs on (some) configmap changes
• We now create caching.internal.knative.dev/Image resources to signal the images that are important to cache. Operators must install an extension to leverage these hints.

Networking

ClusterIngress abstraction (special thanks to @lichuqiang)

Route no longer depends directly on VirtualService, but an intermediate resource ClusterIngress which could be reconciled differently for different network platforms.

Istio Updates

• Moved to Istio 1.0.2.
• Hacks & workarounds needed due to 0.8.0 bugs are removed.
• Cluster-local access to Route (through route.ns.svc.cluster.local name) no longer requires the istio sidecar.

Bug fixes

• #2276 Route status incorrect for named traffic targets having the same revision #2234 Activator headers getting forwarded prevent scaling from 0 (@trisberg, @scothis)
• #2046 Activator can activate the wrong Service (@markusthoemmes)
• #2043 Activator leaks metrics publicly (@scothis, @tanzeeb)
• #1931 Queue-proxy does not work with custom cluster domain (@cizixs,@arvtiwar)
• #1907 Activator retries its own requests (@markusthoemmes).
• #1637 Placeholder k8s service reconciliation doesn't take defaulter into account #1229 Activator should retry with backoff (@markusthoemmes).
• #837 Activator deal with multiple ports (@markusthoemmes).

Monitoring

The monitoring namespace has changed to knative-monitoring

Bug fixes:

• #2255 Zipkin install without Elasticsearch
• #2201 Add service label to revisions (@pivotal-nader-ziada)
• #1474 Switch the fluentd configmap to one-per-Revision

Fixes:

• Lowercase header names to fix validation with Istio 1.0.
• Update shared gateway TLS setting to work with Istio 1.0 validation.
• Update to Build v0.1.1 so that things work with containerd.

First Knative Serving Alpha Release!