Knative Client release v1.0.0

Meta

The compile dependencies have been updated to Knative Serving v1.0.0, Knative Eventing v1.0.0 (Go module versions are v0.27.0).

Deprecated options cleanup

Approaching the Knative 1.0.0 milestone several deprecated options were removed.

• --limits-cpu
• --limits-cpu
• --request-memory
• --request-cpu
• --min-scale
• --max-scale
• --lookup-path

Released plugins

The kn-plugin-quickstart plugin is now included since this release.

The plugins that are released in parallel and aligned with Knative v1.0.0 are:

• kn-plugin-admin for managing Knative installations that are running on Kubernetes | download
• kn-plugin-quickstart to quickly set up a local Knative environment from the command line. | download
• kn-plugin-source-kafka for managing a Kafka Source that has been installed via eventing-kafka on the backend | download
• kn-plugin-source-kamelet for managing Kamelet Sources that has been installed via Camel-K on the backend | download

All those plugins are released separately and are technically not part of this knative/client release, they are aligned however to share the same Knative dependencies and can be targeted for inlining.

---

You can find the complete list of changes in the CHANGELOG.

Knative Client release v0.26.0

Meta

The compile dependencies have been updated to Knative Serving 0.26.0, Knative Eventing 0.26.0.

Environment variables from file

There's a new flag --env-file that accepts provided file to populate environment variables. It simplify and shorten the resulting command for multiple environment variables entries at once. Accepted format of the file is KEY=VALUE pair per line.

Released plugins

The kn-plugin-source-kamelet plugin is now included since this release.

The plugins that are released in parallel and aligned with Knative 0.26 are:

• kn-plugin-admin for managing Knative installations that are running on Kubernetes | download
• kn-plugin-source-kafka for managing a Kafka Source that has been installed via eventing-kafka on the backend | download
• kn-plugin-source-kamelet for managing Kamelet Sources that has been installed via Camel-K on the backend | download

All those plugins are released separately and are technically not part of this knative/client release, they are aligned however to share the same Knative dependencies and can be targeted for inlining.

---

You can find the complete list of changes in the CHANGELOG.

Knative Client release v0.25.1

Meta

The compile dependencies have been updated to Knative Serving 0.25.0, Knative Eventing 0.25.0 and Go version to 1.16.

Default plugin lookup in $PATH

The plugin lookup in $PATH has been enabled by default. This changes should improve local plugin development and testing. Furthermore the end user installation experience of plugins though package managers like Homebrew.

As a follow-up configuration property plugin.path-lookup has been deprecated.

Darwin/arm64 support

The native support for Apple's ARM64 chips has been added. All the future release will be published with the corresponding native binary.

Multicontainer support (experimental)

There's been added a new command kn container add to create Container snippets. The add command reuses all existing options flags manipulating Container know from kn service create.

In addition there's a new flag --extra-containers available for kn service create|update|apply that accepts YAML or JSON Containers to pass them to a Knative Service.

The command is marked as experimental and may change in the future releases.

Example

  The 'container add' represents utility command that prints YAML container spec to standard output. It's useful for
  multi-container use cases to create definition with help of standard 'kn' option flags. It accepts all container related
  flag available for 'service create'. The command can be chained through Unix pipes to create multiple containers at once.

  # Add a container 'sidecar' from image 'docker.io/example/sidecar' and print it to standard output
  kn container add sidecar --image docker.io/example/sidecar

  # Add command can be chained by standard Unix pipe symbol '|' and passed to 'service create|update|apply' commands
  kn container add sidecar --image docker.io/example/sidecar:first | \
  kn container add second --image docker.io/example/sidecar:second | \
  kn service create myksvc --image docker.io/example/my-app:latest --extra-containers -

---

You can find the complete list of changes in the CHANGELOG.

Knative Client release v0.25.0

Meta

The compile dependencies have been updated to Knative Serving 0.25.0, Knative Eventing 0.25.0 and Go version to 1.16.

Default plugin lookup in $PATH

The plugin lookup in $PATH has been enabled by default. This changes should improve local plugin development and testing. Furthermore the end user installation experience of plugins though package managers like Homebrew.

As a follow-up configuration property plugin.path-lookup has been deprecated.

Multicontainer support (experimental)

There's been added a new command kn container add to create Container snippets. The add command reuses all existing options flags manipulating Container know from kn service create.

In addition there's a new flag --extra-containers available for kn service create|update|apply that accepts YAML or JSON Containers to pass them to a Knative Service.

The command is marked as experimental and may change in the future releases.

Example

  The 'container add' represents utility command that prints YAML container spec to standard output. It's useful for
  multi-container use cases to create definition with help of standard 'kn' option flags. It accepts all container related
  flag available for 'service create'. The command can be chained through Unix pipes to create multiple containers at once.

  # Add a container 'sidecar' from image 'docker.io/example/sidecar' and print it to standard output
  kn container add sidecar --image docker.io/example/sidecar

  # Add command can be chained by standard Unix pipe symbol '|' and passed to 'service create|update|apply' commands
  kn container add sidecar --image docker.io/example/sidecar:first | \
  kn container add second --image docker.io/example/sidecar:second | \
  kn service create myksvc --image docker.io/example/my-app:latest --extra-containers -

---

You can find the complete list of changes in the CHANGELOG.

Knative Client release v0.23.2

kn 0.23.0 comes with bug fixes and API updates only.

Meta

The compile dependencies have been updated to Knative Serving 0.23.0 and Knative Eventing 0.23.0. There are no changes in the used API version for communicating with the backend. Eventing Sources APIServerSource, ContainerSource and SinkBinding are now accessed with their v1 API version (which implies, that you can manage those sources only for Knative installations that offer these sources in a v1 version, for older clusters you need to use kn <= 0.22). PingSource API access has been updated to v1beta2.

---

You can find the complete list of changes in the CHANGELOG

Knative Client release v0.24.0

Meta

The compile dependencies have been updated to Knative Serving 0.24.0 and Knative Eventing 0.24.0.

Improvement for configuring environment variables

A new option --env-value-from option has been added to kn service create and kn service update to allow referencing values from secrets and config maps. The order of environment variables are now kept according to the order --env related options are provided on the command line.

---

You can find the complete list of changes in the CHANGELOG

Knative Client release v0.23.1

kn 0.23.0 comes with bug fixes and API updates only.

Meta

The compile dependencies have been updated to Knative Serving 0.23.0 and Knative Eventing 0.23.0. There are no changes in the used API version for communicating with the backend. Eventing Sources APIServerSource, ContainerSource and SinkBinding are now accessed with their v1 API version (which implies, that you can manage those sources only for Knative installations that offer these sources in a v1 version, for older clusters you need to use kn <= 0.22). PingSource API access has been updated to v1beta2.

---

You can find the complete list of changes in the CHANGELOG

Knative Client release v0.23.0

kn 0.23.0 comes with bug fixes and API updates only.

Meta

The compile dependencies have been updated to Knative Serving 0.23.0 and Knative Eventing 0.23.0. There are no changes in the used API version for communicating with the backend. Eventing Sources APIServerSource, ContainerSource and SinkBinding are now accessed with their v1 API version (which implies, that you can manage those sources only for Knative installations that offer these sources in a v1 version, for older clusters you need to use kn <= 0.22). PingSource API access has been updated to v1beta2.

---

You can find the complete list of changes in the CHANGELOG

Knative Client release v0.22.0

kn 0.22.0 comes with some bug fixes and minor feature enhancements. It's mostly a polishing release. If you are using the client API, there is a breaking change that was needed to align with Kubernetes client API's

Meta

The compile dependencies have been updated to Knative Serving 0.22.0 and Knative Eventing 0.22.0. There are no changes in the used API version for communicating with the backend.

Managing custom domain mappings

This release adds support for CRUD management of domain mappings. I.e. you can use kn domain along with its sub-commands create, update, describe, list and delete to fully manage DomainMapping resources for the installation of custom domains for Knative services.

# Create a domain mappings 'hello.example.com' for Knative service 'hello'
kn domain create hello.example.com --ref hello

# Update a domain mappings 'hello.example.com' for Knative service 'hello'
kn domain create hello.example.com --refFlags hello

# List all domain mappings
kn domain list

# Delete domain mappings 'hello.example.com'
kn domain delete hello.example.com

See kn domain help for more information.

Client API signature change

A context.Context object is added as the first argument to every Client API method to align with Kubernetes' client API signatures. This change does not affect any client's CLI usage, only if the client-specific Golang API is used for communicating with the Knative backend has changed. The migration is straight forward, either pass an already existing context down to the call or leverage one of the available standard contexts (like context.TODO()).

This change does not affect any CLI usage of the client.

Released plugins

The plugins that are released aligned with 0.22 are:

• kn-plugin-admin for managing Knative installations that are running on Kubernetes | download
• kn-plugin-source-kafka for managing a Kafka Source that has been installed via eventing-kafka on the backend | download

Minor updates

• Fix kn export uses the Export format as the default
• Added S column to specify built-in sources in kn source list-types
• Added support for namespaces for all commands that takes a --sink option

---

You can find the complete list of changes in the CHANGELOG.

Knative Client release v0.21.0

kn 0.21.0 comes with some bug fixes and minor feature enhancements. It's mostly a polishing release. It is also the first release that brings two kn plugins to the Knative release train.

Meta

The compile dependencies have been updated to Knative Serving 0.21.0 and Knative Eventing 0.21.0. There are no changes in the used API version for communicating with the backend.

Revision naming

In this version, kn changes the default of how revisions are named. Up to now, the name was selected by the client itself, leveraging the "bring-your-own" (BYO) revision name support of Knative serving.

However, it turned out that this mode has several severe drawbacks:

• If you create a service with client-side revision naming, you have to provide a new revision name on every update. This is especially tedious if using other clients than kn, like editing the resource directly in the cluster or you tools like the OpenShift Developer console. Assuming that kn is the only client to be used is a bit of a too bold attitude.
• SinkBinding do not work with BYO revision names
• kn service apply can't use client-generated revision names, so kn service apply ignore --revision-name option and always uses server-side generated revision names. The same is true if you want to use kubectl apply after you have created a service with BYO revision name mode with kn.
• Revision name's are random and do not reflect a certain generational order as for server-side generated revision names
• There are issues with new revision created when updated with the same image name again (see #398)

Please refer to issue #1144 (and issues referencing this issue) for more details about the reasoning for this breaking change.

ACTION REQUIRED

If you rely on client-side revision naming, you have to add --revision-name {{.Service}}-{{.Random 5}}-{{.Generation}} to kn service create to get back the previous default behaviour. However, in most of all cases, you shound not worry about whether the revision names are created by kn or by the Knative serving controller.

In case of issues with this change, please let us know and we will fix it asap. We are committed to supporting you with any issues caused by this change.

Plugins jump on the release train

With 0.21, Knative ships also it first set of kn plugins, that are aligned with respect to their dependencies, so that they can be easily inlined.

The plugins that are verified to work with kn in version 0.21 are:

• kn-plugin-admin for managing Knative installations that are running on Kubernetes | download
• kn-plugin-source-kafka for managing a Kafka Source that has been installed via eventing-kafka on the backend | download

To give those plugins a try, just download them and put the binary into your execution path. You then get help with kn admin --help and kn source kafka --help, respectively.

Minor updates

• Options --context and --cluster allow you to select the parameters for connecting to your Kubernetes cluster. Those options work the same as for kubectl.
• Some cleanup of cluster-specific runtime information when doing a kn export.

---

You can find the full list of changes in the CHANGELOG.