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

Knative Client release v0.9.0

This release focusses on improving support for Knative serving with its latest release 0.9.0. It enhances the kn service command group so that ~ 90% of all Knative Serving provided features are supported.

Meta

• Updated compile dependencies to Knative Serving 0.9.0, kn uses the v1alpha1 version for accessing the Knative serving API, as defined in knative-serving 0.9.0.

Service

The following Service related commands have been enhanced:

• kn service create & kn service update:

  • --traffic for specifying traffics splits
  • --tag for tagging revisions used in a traffic distribution
  • --annotation for setting annotations
  • --label for setting labels
  • --revision-name allows setting the revision name for a service update
  • --generate-revision-name lets the client create the revision (on by default)
  • --service-account for setting the Service's service account
  • Improved output when creating/updating services synchronously, containing now a progress indication.

• kn service describe:

  • Switched to human-readable output instead of plain YAML
  • Information about the URL, labels, annotations, environment variables, request and limit resources, concurrency options and more have been added.
  • Include information about active revisions and the traffic distributions among them.
  • All Status conditions
  • --verbose output possible

Example output:

Name:       random
Namespace:  default
Age:        2m
URL:        http://random.default.example.com
Address:    http://random.default.svc.cluster.local

Revisions:
   10%  @latest (random-mrznh-2) [2] (1m)
        Image:  rhuss/random:2.0 (pinned to d922f5)
   90%  random-mtbxz-1 #v1 [1] (2m)
        Image:  rhuss/random:1.0 (pinned to 946b7c)

Conditions:
  OK TYPE                   AGE REASON
  ++ Ready                   3s
  ++ ConfigurationsReady     1m
  ++ RoutesReady             3s

• kn service list:
  • --no-headers for omitting the column headers in the output
  • Adding the latest revision to the list output

Plugins

Support for plugins has been added. This support works similar to kubectl plugins as it will execute external plugin command based on the command given. E.g. a kn pipeline create would call an external command kn-pipeline-create. This executable can be looked up from the execution path or from within a dedicated plugin directory (~/.kn/plugins by default).

All accessible plugins can be listed with kn plugin list.

Misc

• Updated kn version to include the supported API version
• Changed boolean flags to the --foo and --no-foo format
• --log-output option added for helping to debug
• --all-namespaces(-A) for listing resources in all namespaces
• Removed zsh completion as upstream support is broken for now
• Documentation improvements

---

For all features and fixes included in this release, please refer to the Changelog.

Knative Client release v0.2.0

Please refer to the Changelog for what is new in v0.2.0.

Knative Client release v0.1.0

Initial release!

Support for creating and updating services against Knative 5.x.