Releases: knative/client
Knative Client release v0.17.0
Release 0.17.0 continues the journey to full Eventing support and adds some additional goodies.
Meta
The compile dependencies have been updated to Knative Serving 0.17.0 and Knative Eventing 0.17.0.
Eventing support
This release adds full support for managing Channel
resources. It allows you to specify the channel type during creation and also to add some mappings of GVK coordinates to symbolic names in your configuration.
Plugin Inline Support
It is possible now to create custom variations of kn
that can inline golang based plugins into a single binary. See the plugin README for a brief explanation about the mechanics. More documentation and examples pending.
It is important to note, that kn
as released from this repository will not inline any plugins. It just provides the hooks for enabling plugin inlining.
New features
Additionally the following features and fixes have been added:
kn source list
use now an own list type for heterogeneous lists- Client side volume name generation has been fixed
NAMESPACE
header column has been added tokn source list -A
- Add support to combine
kn service create --filename
with other options - List only built-in sources if access to CRDs is restricted
You can find the full list of changes in the CHANGELOG
Knative Client release v0.16.1
This minor update contains backports of essential fix and some minor feature additions.
See the CHANGELOG for full details.
Fixes:
- Fix missing NAMESPACE column header for 'kn source list -A
- Fix exit code for
kn service delete
andkn revision delete
failures - Fix client side volume name generation
kn source list
output now has client custom GVK set as{Group: client.knative.dev, Version: v1alpha1, Kind: SourceList}
- fix(kn source list): list inbuilt sources if crd access is restricted
- fix(tekton e2e): Refer tasks from new tekton catalog task structure
- Add support for internal plugins
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:
andservice:
have been removed so that a user can use those prefixes in their configuration file. - Other mappings (
broker:
,http:
andhttps:
) 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 pluginkn-service-log
is shown inkn 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 withcurl $(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
andkn 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 typeExport
(groupclient.knative.dev
, versionv1alpha1
) 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
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 likenvidia.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
forkn 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 inkn source apiserver create
andkn 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 valueRef
for specifying that only references to objects should be delivered as part of the cloudevent payload has been changed toReference
.
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
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 servingeventing.knative.dev/v1alpha1
for Knative eventingsource.knative.dev/v1alpha1
forApiServerSource
source.knative.dev/v1alpha2
forPingSource
source.knative.dev/v1alpha2
forSinkBinding
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 toPingSource
(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 forkn 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 forkn 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.