v0.20 release

Published on: 2021-01-20 , Revised on: 2023-08-03

Announcing Knative v0.20 Release¶

A new version of Knative is now available across multiple components. Follow the instructions in the documentation Installing Knative for the respective component.

Table of Contents¶

Serving v0.20
Eventing v0.20
Eventing Extensions
- Eventing Kafka Broker v0.20
CLI v0.20
Operator v0.20
Thank you contributors v0.20

Highlights¶

Serving continues to polish DomainMapping.
Gradual traffic rollout featured is introduced.
Propagation of delivery spec down to subscription is now added in Eventing.
Eventing Kafka Broker enhanced with multiple observability related to metrics and tracing.
The kn CLI introduces a new experimental offline mode (--target) for kn service create that allows creating Knative services locally in resource files.

Serving v0.20¶

🚨 Breaking¶

Validate DomainMapping name if it is fully qualified. (#10379)
Remove the GC feature flag and v1 GC/Labeler (#10084)
Removes webhook name from code and set webhook name in webhook deployment yaml using key WEBHOOK_NAME (#10205)

💫 New Features & Changes¶

A feature flag is now available to enable hostAliases for Knative Services. See config-features for details. (#10301)
Add AutoTLS support for DomainMapping (#10467)
DomainMappings now support arbitrary target references, rather than only Knative Services. The target must conform to the Addressable contract (including Kubernetes Services), and the resolved URI must be of the form {name}.{namespace}.svc.{cluster-suffix}. (#10210)
Introduce serving.knative.dev/domainmapping label for Ingress generated by DomainMapping. (#10370)
Leader election transition improvements (#10131)
Profiling port is now configurable via the env var PROFILING_PORT (knative/pkg#1950)
Gradual traffic rollout of the configuration targets is now available in Knative. Right now it is driven by the rolloutDuration entry in the config-network configmap. When positive this setting will move the traffic gradually from the previous to the current revision over this period of time. It can handle several rollouts at the same time in three dimensions:
- different tags can be rolled out independently if they are pointing at different configs
- different percentages for the same configuration target will roll out at different speeds (but will finish around the same deadline)
- if new revisions were created while previous rollouts have not yet finished, the system will drain them and move everything to the newest revision.

🐞 Bug Fixes¶

Changes how ClusterDomainClaims are cleaned up when DomainMappings are removed. (#10503)
Enables connection reuse between activator probe and proxy to improve first request performance after cold starts (#10228)
Webhooks won't remove namespace selectors added by other components (knative/pkg#1949)

Eventing v0.20¶

💫 New Features & Changes¶

Now setting the channel spec delivery field defaults every subscription to that particular delivery spec (#4652)

🐞 Bug Fixes¶

Allow scaling the in-memory Channel dispatcher without disabling high availability. (#4675)

🧹 Clean up¶

Webhook no longer has Cluster-wide Secret permissions. Now the Webhook's Secret permissions are restricted to the knative-eventing namespace. (#4684)
bump the name of the broker on each test iteration (#4716)
Message receiver supports customized liveness and readiness check (#4707)
You need to run the storage migration tool after the upgrade to migrate from v1beta1 to v1 apiserversources.sources.knative.dev resources. (#4655)
You need to run the storage migration tool after the upgrade to migrate from v1beta1 to v1 containersources.sources.knative.dev resources. (#4657)
You need to run the storage migration tool after the upgrade to migrate from v1beta1 to v1 sinkbindings.sources.knative.dev resources. (#4658)

Eventing Extensions¶

Eventing Kafka Broker v0.20¶

Release Notes for eventing-kafka-broker

💫 New Features & Changes¶

kafka-broker-receiver, kafka-broker-dispatcher, and kafka-sink-receiver expose Kafka client metrics. (#435)
kafka-broker-receiver, kafka-broker-dispatcher, and kafka-sink-receiver expose JVM metrics (disabled by default) (#435)
Data plane pods produce distributed tracing spans. (#421)
Receivers now specify anti-affinity so that replicas will not be colocated (#483)

🐞 Bug Fixes¶

Controllers resync state when managed resources change. (#420)
Leader election transition improvements (#449)

🧹 Clean up¶

The data plane is completely non-blocking. (#438)
Skip ConfigMap update when there are no changes (#511)
Change release labels from eventing.knative.dev to kafka.eventing.knative.dev. (#480)

Client v0.20¶

kn v0.20.0 introduces a new experimental offline mode (--target) for kn service create that allows creating Knative services locally in resource files and without the need to be connected to a cluster. In addition, the usual bug fixes and some smaller features have been added.

💫 New Features & Changes¶

Offline mode

A new experimental offline mode has been added to kn service create. You enable it by using the option --target which can point to an existing directory or a filename. When provided kn will create a resource file that can be used with kn service create -f, kn service apply -f or even directly with kubectl. If the argument to --target is a filename or a non-existing path then a single file will be created. The file format (YAML or JSON) is determined by the file extension. If the argument to --target is a directory then the resource file is created within this directory by creating subdirectories for the namespace and type, using the service name as the filename's basename.

Examples:

# Create a YAML resource file "myservice.yml" with the custom resource definition of
# the specified Knative service
kn service create myservice --image quay.io/myuser/myservice:latest --target ./myservice.yml

# Create a YAML resource file with the service definition in "service-dir/default/ksvc/myservice.yml"
# The directory "service-dir/" must already exist
kn service create myservice --image gcr.io/myproject/myservice:latest --target service-dir/

Scale option

The --scale option for kn service create and kn service update allows now also ranges as values: - --scale 1..5 : Scale down to a minimal 1 replica and up to 5 replicas - --scale 1.. : Set scale-min to to 1 but leave scale-max untouched (when used for a service update) - --scale ..5 : Set scale-max to 5 but leave scale-min untouched (when used for a service update) - --scale 5..5 : Set scale-min and scale-max both to 5 (same as --scale 5)

Support for new architectures

linux/s390x and linux/ppc64le has been added to the list of supported architectures, which is contains now the following platforms: darwin/amd64, linux/amd64, linux/arm64, linux/ppc64le, linux/s390x and windows/amd64.

🧹 Clean up¶

Fixes for the help and error message have been applied.

Other CLI Features¶

-o url is now supported in kn broker describe and kn channel describe.
Machine-readable output (e.g. -o json) has been added to the commands where it has been missing.

Operator v0.20¶

The new operator can now deploy the new version v0.20 of serving and eventing components.

🐞 Bug Fixes¶

Preserve the values of the environment variables for the pingsource-mt-adapter deploy resource, (#394)
Implement the additional manifests for customized yamls. (#374

🧹 Clean up¶

Update attributes to describe which files are generated and/or vendored. (#423)
Enable code autogen for config generation (#417)
Add a tool to automatically fetch releases and stage them in kodata. (#360)

Thank you contributors v0.20¶

Learn more¶

Knative is an open source project that anyone in the community can use, improve, and enjoy. We'd love you to join us!