Knative Client release v0.16.0

Release 0.16.0 brings some minor improvements and bug fixes. See the CHANGELOG for full details.

Meta

The compile dependencies have been updated to Knative Serving 0.16.0 and Knative Eventing 0.16.0.
This version of kn is working with Knative Serving backends >= 0.13.0 and Knative Eventing >= 0.14.0.

Incompatible change in Eventing support

For our experimental eventing support, we introduced a mapping syntax for specifying sinks for sources and triggers. This mapping can also be customised in the ~/.config/kn/config.yaml configuration. It turned out that this mapping was to redundant. E.g. a Knative service could be specified with an svc: or a service: prefix or when given without any prefix. To allow users to, e.g. add a Kubernetes service to this mapping, the following change has been introduced in 0.16:

• A Knative service can be specified with ksvc: or when not providing any prefix
• The prefixes svc: and service: have been removed so that a user can use those prefixes in their configuration file.
• Other mappings (broker:, http: and https:) have been left untouched.

New Features

• The list of plugins has been integrated to the help message that you get with kn --help. The name of the plugins and their file path is shown. If you use --help on a deeper level, then you will see nested plugins in the help text. E.g. a plugin kn-service-log is shown in kn service --help.
• kn service describe now supports a -o url option, which allows to print out only the service URL. This additional output format can be quite convenient when used in a scripting context like with curl $(kn service describe mysvc -o url)
• A new option --scale has been introduced for setting --min-scale and --max-scale to the same value. E.g. --scale 1 will set the number of replicas to exactly one (min and max scale are both set to one). Except for the syntax for the scale value to be expanded for more flexibility, see #822 for the discussion about syntax enhancements.
• kn service create and kn service update now support a flag --filename (or -f) so that you can use a resource descriptor in YAML or JSON format to initialise your service. At the moment additional command-line options are ignored, but in a future version the will be merged with the content of the referenced file (#923)
• The new multi-tenant broker can be fully managed with kn broker CRUD commands.
• kn service export has now an own dedicated type Export (group client.knative.dev, version v1alpha1) which contains the service definition and potentially all active revision that service routes to.

---

As always you find the full list of changes in the CHANGELOG.

Knative Client release v0.15.2

Minor bug fix release with

• Return error message when using --untag with nonexistent tag #880

• Update go.mod to enforce go 1.14 #866

Knative Client release v0.15.1

Let's welcome release 0.15.1, which comes with some minor improvements and bug fixes. See the CHANGELOG for full details.

Meta

The compile dependencies have been updated to Knative Serving 0.15.0 and Knative Eventing 0.15.0.
This version of kn is working with Knative Serving backends >= 0.12.0 and Knative Eventing >= 0.13.0, except for the ApiServerSource support which has a breaking change in 0.14.0

Major Changes

• All eventing sources now support the --ce-override for setting override extensions in any Source.
• --request and --limit can be used now for setting arbitrary requests/limits like nvidia.com/gpu for requesting GPU support. The old style --request-memory, --requests-cpu, --limits-memory and --limits-cpu is deprecated now. Use e.g. --limit memory=250M instead of --limits-memory 250M.
• You can delete now all services in a namespace with kn service delete --all
• Plugins can also extend already existing command groups (like service), but the can't override existing commands
• The CLI convention document has been improved. These conventions are also normative for supported plugins.
• A new mode --with-revisions for kn export allows to export also revisions directly.

---

As always you find the full list of changes in the CHANGELOG.

Knative Client release v0.14.0

Release 0.14.0 is an incremental release with many bug-fixes that also has been back-ported to 0.13.2 and are described in the 0.13.2 release notes.

Meta

The compile dependencies have been updated to Knative Serving 0.14.0 and Knative Eventing 0.14.1.
This version of kn is working with Knative Serving backends >= 0.11.0 and Knative Eventing >= 0.12.0, except for the ApiServerSource support.

Eventing

The support for the ApiServerSource has been upgraded from v1alpha1 to v1alpha2 which includes some backwards-incompatible changes.
This update implies that kn source apiserver commands require a Knative Eventing backend >= 0.14.0

In detail, this version includes the following changes compared to kn 0.13:

• The --resource option in kn source apiserver create and kn source apiserver update takes a different value:
  • The controller flag has been removed
  • Instead, a label selector to restrict the objects for which events are delivered can be added
• For the --mode option, the value Ref for specifying that only references to objects should be delivered as part of the cloudevent payload has been changed to Reference.

So, instead of using:

# kn 0.13 usage
kn source apiserver create myapisource --reference Pod:v1:true --mode Ref --sink broker:default

the new usage pattern is

# kn 0.14 usage, selecting only events from Pods with a label 'app=myapp' with a reference
# to those Pods in the CE payload
kn source apiserver create myapisource --reference Pod:v1:app=myapp --mode Reference --sink broker:default

---

As always you find the full list of changes in the CHANGELOG.

Knative Client release v0.13.2

This patch release fixes the following bugs:

• Make wait, no-wait and async flags per bool var CLI convention #802
• Fix resource listing with -oname flag #775
• Fix showing repetitive revisions in service describe #790
• Add concurrency-utilization option for service create and update #788
• Refactor e2e common code into lib/test #765
• Fix plugin lookup with file ext on Windows #774
• Correct error message when updating service #778

Knative Client release v0.13.1

This patch release fixes the following bugs:

• Fix filter delete for trigger update command #746
• Fix trigger create --filter flag to be optional #745
• Fix plugin execution for Windows #738
• Fix default config path on Windows #752

Knative Client release v0.13.0

The central theme in v0.13.0 was to adapt to the changes happening in Knative eventing and adding more features to Knative serving. The eventing support is still experimental (aka alpha) and can change anytime, like the change from kn source cronjob to kn source ping in this release. We merged 28 user-facing PRs (compared to 14 in v0.12.0) which show the momentum that kn is gaining. You can expect much more feature and improved user experience in the forthcoming releases.

We also added a first kn service export command, which is also experimental but allows to export Knative services in a JSON or YAML description file.

Again, feedback for the experimental eventing support is highly appreciated! (Please open issues for feedback)

Meta

Compile-time dependencies on Knative serving and Knative eventing have been updated to v0.13.0 and v0.13.1, respectively. The API versions to for talking to the server has been updated to:

• serving.knative.dev/v1 for Knative serving
• eventing.knative.dev/v1alpha1 for Knative eventing
• source.knative.dev/v1alpha1 for ApiServerSource
• source.knative.dev/v1alpha2 for PingSource
• source.knative.dev/v1alpha2 for SinkBinding

This API selection also means that for serving kn is supposed to work down to Knative Serving 0.10.0. For Knative Eventing we have now backwards guarantees, so kn works for Knative eventing 0.13.0 and newer only.

Eventing Update

This kn release updates it dependency to Knative eventing v0.13.1 which introduces many (also incompatible) changes concerning v0.12.0.
kn incorporates these changes, which implies also the usage of different API endpoints:

• All sources are moved to the API group source.knative.dev
• CronJobSource has been renamed to PingSource (and is implemented differently on the server-side)

For kn this also implies changes in the user interface:
The command kn source cronjob has been renamed to kn source ping.
Besides the renaming, a PingSource doesn't have a mandatory schedule (the default schedule is every minute), and it has some fewer properties (no service account and no resource limits).
kn source ping has been adapted to these changes.

IMPORTANT : These changes imply that you can't manage eventing source on Knative eventing clusters with Knative eventing <= v0.12.0. Please use kn 0.12.0 for those older clusters. As mentioned, Knative eventing is still experimental (as Knative eventing itself), so there can be always incompatible API change in the next release (but we don't hope so). Also note, that the support for Knative serving is stable kn 0.13.0 support Knative serving down to v0.10.0 (always four releases backwards).

kn service export

This experimental feature is meant for exporting an interactive created service, possibly with the configured traffic split.
The primary use case is that you then can check in those service into your versioning system like GitHub and reuse it, e.g. within CI/CD pipelines, supporting the "GitOps" operational model.

It can be used just with

kn service export myservice -o yaml

And it will print out the service definition of myservice (without any server added information like status fields). The option --with-revisions allows you also to export all revisions which are referenced in a traffic declaration. A file created with

kn service export myservice -o yaml > myservice-service.yml

can then be applied with

kubectl apply myservice-service.yml

As mentioned, this is an experimental feature and can still change in a subsequent version (especially the export format of --with-revisions will differ).

Please give us any feedback on this new feature as well let us know what we can improve here.

Other features

There have been tons of other new features and fixes:

• Introduction of a sync operation for kn service delete and hardening of wait handling for kn service create/update
• kn trigger create --inject broker for creating a broker implicitely, with the proper security setup.
• --user allows to specify the user under which a service's pod is running
• Conifugable sink prefixes for kn source ... --sink
• Better error reporting
• Support for private services added via kn service create/update --cluster-local
• kn version can provide JSON or YAML output

The full list can be found in the Changelog.

The next release v0.14.0 is scheduled for April 21, 2020.

Knative Client release v0.12.0

In v0.12.0 the team worked on extending support for Knative eventing and include support for the sink bindings (kn source binding). The eventing support is still experimental (aka alpha) and can change anytime (e.g. the support for CronJoboSource might disappear when removed in Knative eventing). Also, some minor features have been added and existing features have been hardened.

Again, feedback for the experimental eventing support is highly appreciated! (Please open issues for feedback)

Meta

Compile-time dependencies on Knative serving and Knative eventing have been updated to v0.12.0, respectively.

Manage Sink Bindings

Sink binding can be used to connect a given eventing sink (like a Knative service that consumes CloudEvents) with a subject, which is a Kubernetes resource that embeds a Pod definition scheme at the top-level. Such a resource is also called a PodSpecable. Examples of those PodSpecables are the Kubernetes resources Deployment, Job, StatefulSet, DaemonSet. The binding will inject an environment variable K_SINK pointing to the sink's URL to the set of environment variables in the Pod specification of the subject

The sink can be specified as for any other supported source with a prefix like svc: or broker: or a plain URL. The subject argument follows the scheme <kind>:<apiVersion>:<name> if a subject is identified by name or <kind>:<apiVersion>:<labelKey1>=<labelValue1>,<labelKey2>=<labelValue2>,.. if a label selector is used to identify the subject resource. The latter approach is especially useful when targetting resources with generated names, like Jobs that have been created on behalf of a CronJob run.

Example

This example is based on the CronJob example from the sink binding example.

# Create an event display service
kn service create edisplay --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display

# Create a CronJob source with a job that honours the `K_SINK` environment variable and emits CloudEvents.
# You can use the example from kn service create edisplay --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display 
kubectl create -f cronjob.yml

# Create sink-binding "heartbeat:, which connects the Knative service "edisplay" 
# with the K8s Jobs created by the CronJob definition every minute
# The Job is selected by a label selector "app=heartbeat-cron"
kn source binding create heartbeat --sink svc:edisplay --subject job:batch/v1:app=heartbeat-cron

# List all sink binding
kn source binding list

# Show the details of a sink binding
kn source binding describe heartbeat

# Delete the sink binding
kn source binding delete heartbeat

Notes

• sink and subject must be in the same namespace as the binding that is managed with kn. If you want to access sink across namespaces, use an URL for the sink specification.
• Please be very careful that you use the correct <kind>:<apiVersion> when creating the binding. If you misspell that or choose a non-podspecable resource, then you might hit this issue
• The format of the subject might change in the future (i.e. whether it's <kind>:<apiVersion> or <apiVersion>:<kind>)

New options for kn service create and kn service update

• --pull-secret for adding a secret to use when pulling images from a private registry
• --autoscale-window to specify the time window (in seconds) to consider for calculating the concurrency average on which a scaling decision is based. This value is also the amount of time to wait at least before your service scales to zero when it does not receive any requests.

Minor cosmetics

• Traffic and tag information is added to kn revision list
• Syntax of map-like options like --env has been consolidated:
  • --env a1=b1 --env a2=b2 adds both variables
  • --env a1 sets the variable to an empty string
  • --env a1- removes the variable (only useful for kn service update)
  • --env a1=b1 --env a1=b2 results in an error because the same key is used twice
• Better error message when the command is misspelled or missing
• Improved syntax check for kn trigger commands
• More end-to-end testing love

---

The full details can be found in the Changelog. A BIG BIG thank you to all contributors to this release. You are awesome!

Release v0.13.0 is scheduled for March 10, 2020.

Knative Client release v0.11.0

The main theme of v0.11.0 is the experimental support for Knative eventing sources and triggers. It already contains a substantial part of the kn support for Eventing: Sources & Triggers specification but not all features have been implemented yet. Also, the currently used CLI labels and layout can be different in a future version. Feedback for the experimental eventing support is highly appreciated ! (Please open issues for feedback)

Meta

Dependencies on Knative serving and Knative eventing have been updated to v0.11.0, respectively.

List available source types

You can easily list the kind of sources that are available at a connected cluster with:

kn source list-types
TYPE              NAME                                            DESCRIPTION
ApiServerSource   apiserversources.sources.eventing.knative.dev   Kubernetes API Server events source
ContainerSource   containersources.sources.eventing.knative.dev   Container events source
CronJobSource     cronjobsources.sources.eventing.knative.dev     CronJob events source
SinkBinding       sinkbindings.sources.eventing.knative.dev       Binding Pattern for ContainerSource

This will list all built-in source available at the cluster. Currently, only the ApiServerSource and CronJobSource have direct support by kn. They are described below.

ApiServer source

The ApiServer source that is included in a basic Knative Eventing installation can be fully managed with kn. Use kn source apiserver for a list of commands. I.e you can do the following management operations:

# Create an ApiServer source which connects to a service named "edisplay" and registers for `Pod` and `Deployment` events (service account "mysa" needs have the permissions to watch source resources)
$ kn source apiserver create myapisource --service-account mysa --register pod:v1 --register deployment:apps/v1 --sink svc:edisplay
ApiServer source 'myapisource' created in namespace 'default'.

# List all ApiServer sources for all namespaces
$ kn source apiserver list -A
NAMESPACE   NAME          RESOURCES                               SINK           CONDITIONS   READY   REASON
default     myapisource   pod:v1:false,deployment:apps/v1:false   svc:edisplay   5 OK / 5     True

# Describe a specific ApiServer source
$ kn source apiserver describe myapisource
Name:                myapisource
Namespace:           default
Annotations:         sources.eventing.knative.dev/creator=minikube-user, sources.eventing.knative.dev/la ...
Age:                 16m
ServiceAccountName:  apisa
Mode:                Ref

Sink:
  Name:       edisplay
  Namespace:  default
  Kind:       Service (serving.knative.dev/v1alpha1)

Resources:
  Kind:        pod (v1)
  Controller:  false
  Kind:        deployment (apps/v1)
  Controller:  false

Conditions:
  OK TYPE                     AGE REASON
  ++ Ready                     4m
  ++ Deployed                  4m
  ++ SinkProvided             16m
  ++ SufficientPermissions     4m
  ++ EventTypesProvided        4m

# Delete an ApiServer source
$ kn source apiserver delete myapisource
ApiServer source 'myapisource' deleted in namespace 'default'.

CronJob source

The CronJob source can be used similarly to the ApiServer source, with the same subcommands:

# Create a Knative service "edisplay" (only for demonstration purposes)
$ kn service create edisplay --image gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
....

# Create an  CronJon source which fires every minute and sends a fixed string to the service "edisplay"
$ kn source cronjob create mycronjobsource --schedule "* * * * *" --sink svc:edisplay
CronJob source 'mycronjobservice' created in namespace 'default'.

# List all CronJob sources for all namespaces
$ kn source cronjob list -A
NAMESPACE   NAME               SCHEDULE    SINK           CONDITIONS   READY   REASON
default     mycronjobsource     * * * * *   svc:edisplay   6 OK / 6     True

# Describe a specific CronJon source
$ kn source apiserver describe mycronjobsource
Name:         mycronjobsource
Namespace:    default
Annotations:  sources.eventing.knative.dev/creator=minikube-user, sources.eventing.knative.dev/la ...
Age:          15s
Schedule:     * * * * *
Data:

Sink:
  Name:       edisplay
  Namespace:  default
  Resource:   Service (serving.knative.dev/v1alpha1)

Conditions:
  OK TYPE                 AGE REASON
  ++ Ready                14s
  ++ Deployed             14s
  ++ SinkProvided         15s
  ++ ValidSchedule        15s
  ++ EventTypeProvided    15s
  ++ ResourcesCorrect     15s

# Delete a CronJob source
$ kn source cronjob delete mycronjobsource
CronJob source 'mycronjobsource' deleted in namespace 'default'.

Trigger

With this release initial support for manually managing triggers has been added. You can manage triggers like sources, by connection a subscription (or "sink") to a broker. In order to use triggers, a Broker must be enabled for the namespace the trigger is created in. This can be achieved in various ways. The easiest possibility is to label your namespace with kubectl with a specific trigger label (
kubectl label namespace default knative-eventing-injection=enabled). A future version of kn will allow you to manage brokers individually.

Here's an example how triggers can be managed:

# Create a trigger which connects the service "edisplay" to the default broker and filters on all events with the property "type=dev.knative.foo". The broker option could have been omitted as "default" is the default.
$ kn trigger create mytrigger --filter type=dev.knative.foo --sink svc:edisplay --broker default
Trigger 'mytrigger' successfully created in namespace 'default'.

# List all triggers in the current namespace
$ kn trigger list
NAME        BROKER    SUBSCRIBER_URI                              READY   REASON
mytrigger   default   http://edisplay.default.svc.cluster.local   True

# Update the trigger to add an additional filter
$ kn trigger update mytrigger --filter name=mysource
Trigger 'mytrigger' updated in namespace 'default'.

# Describe the trigger in a human readable layout
$ kn trigger describe mytrigger
Name:         mytrigger
Namespace:    default
Labels:       eventing.knative.dev/broker=default
Annotations:  eventing.knative.dev/creator=minikube-user, eventing.knative.dev/lastModifier=minik ...
Age:          2m
Broker:       default
Filter:
  name:       mysource
  type:       dev.knative.for

Sink:
  Name:       edisplay
  Namespace:  default
  Resource:   Service (serving.knative.dev/v1alpha1)

Conditions:
  OK TYPE                  AGE REASON
  ++ Ready                  2m
  ++ Broker                 2m
  ++ Dependency             2m
  ++ Subscribed             2m
  ++ SubscriberResolved     2m

# Delete a trigger
$ kn trigger delete mytrigger
Trigger 'mytrigger' deleted in namespace 'default'.

Misc

• The test suite has been extended to include E2E tests for eventing and for using kn within a Tekton pipeline
• Minor cosmetic tunings like the output of the cluster URL for service happens only in verbose mode or that polling fallback for waiting on service to become ready has been added.

Limitations

• For a source's sink and a trigger's subscription/sink only Knative service's can be specified by using a svc: prefix. Future versions will allow other sink types, so that you can alos use e.g. a broker as sink target or even a plain URL.
• kn source list-types all list known, built in source types and ignores yet plugins and more generic list types. Also the naming does not perfectly fit the command names that can be used for managing those sources.

---

The full details can be found in the Changelog.

Release v0.12.0 is scheduled for January 28, 2020.

Knative Client release v0.10.0

With v0.10.0 kn now finally jumps onto the Knative release train with six-week releases.

Meta

• This 0.10 release aligns the kn release cycles with Knative serving and Knative eventing. From now on, kn releases are timeboxed in 6-week intervals and happen one week after Knative serving and Knative eventing releases. The next release 0.11.0 is scheduled for December 17th.

Service

• kn revision describe has been updated to provide human-readable output like in

Name:         random-hmnjm-4
Namespace:    default
Age:          3h
Image:        rhuss/random:2.0 (pinned to d922f5)
Env:          DELAY=1000
Concurrency:
  Limit:      10
Service:      random

Conditions:
  OK TYPE                  AGE REASON
  ++ Ready                  3h
  ++ ContainerHealthy       3h
  ++ ResourcesAvailable     3h
   I Active                 3h NoTraffic

• --env-from and --mount has been added to kn service create and kn service update to allow exposing value from config-maps and secrets as environment variables and mounted files, respectively. See kn service create --help for more details on --env-from and --mount (and --volume for multi-mounts of config-maps/secrets

All details can be found in the Changelog