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.

Knative Client release v0.20.0

kn 0.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.

Meta

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

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. They 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.

Misc

• -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.
• Fixes for the help and error message have been applied.

---

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

Knative Client release v0.18.4

This update contains back-ports of a bug fix and an additional kn s390x build.
See the CHANGELOG for full details.

• Fix a race condition when using Kubernetes watches
• Add kn s390x binary to the release

Knative Client release v0.19.1

This update contains back-ports of bug fixes and an additional kn s390x build.
See the CHANGELOG for full details.

• Fix a race condition when using Kubernetes watches
• Embed the namespace in request body while creating channels
• Add kn s390x binary to the release

Knative Client release v0.18.3

This minor update contains a back-port of a bug fix.
See the CHANGELOG for full details.

• Embed the namespace in request body while creating channels

Knative Client release v0.17.4

This minor update contains a back-port of a bug fix.
See the CHANGELOG for full details.

• Embed the namespace in request body while creating channels

Knative Client release v0.19.0

kn 0.19.0 introduces two new commands (kn service apply and kn service import) and removes some deprecated options, in addition to bug fixes and some other goodies described below.

Meta

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

Removed deprecated options

The following deprecated options have been removed:

• --async for all CRUD commands. Use --no-wait instead
• --requests-cpu, --request-memory, --limits-cpu and --limits-memory when managing services. The replacement is to use --limit memory=.. and --limit cpu=... (same for --request). Both options can be combined as in --limit memory=256Mi,cpu=500m

kn service apply

A new kn service apply command has been added to allow a declarative management for your Knative service.
This new command is especially useful in can CI/CD context to allow for idempotent operations when creating or updating services.
It works much like kubectl apply and used a client-side 3-way merge algorithm to update service. The kubectl merge algorithm is directly reused here.
As apply operates on Knative's custom resource types, it suffers the same limitation as the client-side merge algorithm in kubectl apply when dealing with CRDs.
I.e. arrays can't be merged but are just overwritten by an update.
This limitation affects all containers specific parameters.

For the future, we plan to add a better merge algorithm that supports a full strategic 3-way merge like the support of kubectl apply has for intrinsic K8s resources.

It is important to note that kn service apply is fundamentally different to kn service update as with kn service apply the full configuration needs to be provided as command-line options or within a declaration file when used with --filename.
With kn service update you only specify the parts to be updated and don't touch any other service configuration.
This characteristic of apply also implies that you always have to provide the image as the only mandatory parameter with kn service apply.

For example:

# Initially apply a service with the given image and env var
kn service apply random --image rhuss/random:1.0 --env foo=bar

# Update the service to add a ying=yang env var to the already existing one
kn service update random --env ying=yang

# Apply a full new configuration. Note that foo=bar will be removed
# because it is not specified here.
kn service apply random --image rhuss/random:1.0 --env ying=yang

kn service import

kn service import is the counterpart to kn service export and allows you to import a Service and all active revision that has been exported.
Active revisions are revisions that are referenced in a traffic-split.

This command is still marked experimental, and there are some known issues in the import how the generation of revision are created.
Please gives us feedback on how we can improve the support for this feature.

Other

The following other features have been added, too:

• An arm64 flavour has been added to the released artefacts, as well as a checksum.txt which caries the sha256sum of all artefacts.
• A channel: prefix has been added for --sink parameters, so that channels can be directly addressed by name.
• Aliases are now appearing correctly in the help messages
• The Client API as a new list filter WithLabel() which can be used when listing services.

---

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

Knative Client release v0.17.3

This minor update contains a back-port of an essential feature addition.
See the CHANGELOG for full details.

• Add channel sink prefix: A channel prefix is now supported with sink flag, for example: --sink channel:NAME.