This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.Este contenido no está disponible en el idioma seleccionado.
Chapter 4. Knative CLI
4.1. Installing the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
The Knative (kn
) CLI does not have its own login mechanism. To log in to the cluster, you must install the OpenShift CLI (oc
) and use the oc login
command. Installation options for the CLIs may vary depending on your operating system.
For more information on installing the oc
CLI for your operating system and logging in with oc
, see the OpenShift CLI getting started documentation.
OpenShift Serverless cannot be installed using the Knative (kn
) CLI. A cluster administrator must install the OpenShift Serverless Operator and set up the Knative components, as described in the Installing the OpenShift Serverless Operator documentation.
If you try to use an older version of the Knative (kn
) CLI with a newer OpenShift Serverless release, the API is not found and an error occurs.
For example, if you use the 1.23.0 release of the Knative (kn
) CLI, which uses version 1.2, with the 1.24.0 OpenShift Serverless release, which uses the 1.3 versions of the Knative Serving and Knative Eventing APIs, the CLI does not work because it continues to look for the outdated 1.2 API versions.
Ensure that you are using the latest Knative (kn
) CLI version for your OpenShift Serverless release to avoid issues.
4.1.1. Installing the Knative CLI using the OpenShift Container Platform web console Copiar enlaceEnlace copiado en el portapapeles!
Using the OpenShift Container Platform web console provides a streamlined and intuitive user interface to install the Knative (kn
) CLI. After the OpenShift Serverless Operator is installed, you will see a link to download the Knative (kn
) CLI for Linux (amd64, s390x, ppc64le), macOS, or Windows from the Command Line Tools page in the OpenShift Container Platform web console.
Prerequisites
- You have logged in to the OpenShift Container Platform web console.
The OpenShift Serverless Operator and Knative Serving are installed on your OpenShift Container Platform cluster.
ImportantIf libc is not available, you might see the following error when you run CLI commands:
kn: No such file or directory
$ kn: No such file or directory
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
If you want to use the verification steps for this procedure, you must install the OpenShift (
oc
) CLI.
Procedure
-
Download the Knative (
kn
) CLI from the Command Line Tools page. You can access the Command Line Tools page by clicking theicon in the top right corner of the web console and selecting Command Line Tools in the list.
Unpack the archive:
tar -xf <file>
$ tar -xf <file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Move the
kn
binary to a directory on yourPATH
. To check your
PATH
, run:echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Run the following commands to check that the correct Knative CLI resources and route have been created:
oc get ConsoleCLIDownload
$ oc get ConsoleCLIDownload
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME DISPLAY NAME AGE kn kn - OpenShift Serverless Command Line Interface (CLI) 2022-09-20T08:41:18Z oc-cli-downloads oc - OpenShift Command Line Interface (CLI) 2022-09-20T08:00:20Z
NAME DISPLAY NAME AGE kn kn - OpenShift Serverless Command Line Interface (CLI) 2022-09-20T08:41:18Z oc-cli-downloads oc - OpenShift Command Line Interface (CLI) 2022-09-20T08:00:20Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get route -n openshift-serverless
$ oc get route -n openshift-serverless
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD kn kn-openshift-serverless.apps.example.com knative-openshift-metrics-3 http-cli edge/Redirect None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD kn kn-openshift-serverless.apps.example.com knative-openshift-metrics-3 http-cli edge/Redirect None
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.2. Installing the Knative CLI for Linux by using an RPM package manager Copiar enlaceEnlace copiado en el portapapeles!
For Red Hat Enterprise Linux (RHEL), you can install the Knative (kn
) CLI as an RPM by using a package manager, such as yum
or dnf
. This allows the Knative CLI version to be automatically managed by the system. For example, using a command like dnf upgrade
upgrades all packages, including kn
, if a new version is available.
Prerequisites
- You have an active OpenShift Container Platform subscription on your Red Hat account.
Procedure
Register with Red Hat Subscription Manager:
subscription-manager register
# subscription-manager register
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pull the latest subscription data:
subscription-manager refresh
# subscription-manager refresh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Attach the subscription to the registered system:
subscription-manager attach --pool=<pool_id>
# subscription-manager attach --pool=<pool_id>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Pool ID for an active OpenShift Container Platform subscription
Enable the repositories required by the Knative (
kn
) CLI:Linux (x86_64, amd64)
subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Linux on IBM Z and LinuxONE (s390x)
subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Linux on IBM Power (ppc64le)
subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
# subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Install the Knative (
kn
) CLI as an RPM by using a package manager:Example
yum
commandyum install openshift-serverless-clients
# yum install openshift-serverless-clients
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.3. Installing the Knative CLI for Linux Copiar enlaceEnlace copiado en el portapapeles!
If you are using a Linux distribution that does not have RPM or another package manager installed, you can install the Knative (kn
) CLI as a binary file. To do this, you must download and unpack a tar.gz
archive and add the binary to a directory on your PATH
.
Prerequisites
If you are not using RHEL or Fedora, ensure that libc is installed in a directory on your library path.
ImportantIf libc is not available, you might see the following error when you run CLI commands:
kn: No such file or directory
$ kn: No such file or directory
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
Download the relevant Knative (
kn
) CLItar.gz
archive:You can also download any version of
kn
by navigating to that version’s corresponding directory in the Serverless client download mirror.Unpack the archive:
tar -xf <filename>
$ tar -xf <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Move the
kn
binary to a directory on yourPATH
. To check your
PATH
, run:echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. Installing the Knative CLI for macOS Copiar enlaceEnlace copiado en el portapapeles!
If you are using macOS, you can install the Knative (kn
) CLI as a binary file. To do this, you must download and unpack a tar.gz
archive and add the binary to a directory on your PATH
.
Procedure
Download the Knative (
kn
) CLItar.gz
archive.You can also download any version of
kn
by navigating to that version’s corresponding directory in the Serverless client download mirror.- Unpack and extract the archive.
-
Move the
kn
binary to a directory on yourPATH
. To check your
PATH
, open a terminal window and run:echo $PATH
$ echo $PATH
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.5. Installing the Knative CLI for Windows Copiar enlaceEnlace copiado en el portapapeles!
If you are using Windows, you can install the Knative (kn
) CLI as a binary file. To do this, you must download and unpack a ZIP archive and add the binary to a directory on your PATH
.
Procedure
Download the Knative (
kn
) CLI ZIP archive.You can also download any version of
kn
by navigating to that version’s corresponding directory in the Serverless client download mirror.- Extract the archive with a ZIP program.
-
Move the
kn
binary to a directory on yourPATH
. To check your
PATH
, open the command prompt and run the command:path
C:\> path
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. Configuring the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can customize your Knative (kn
) CLI setup by creating a config.yaml
configuration file. You can provide this configuration by using the --config
flag, otherwise the configuration is picked up from a default location. The default configuration location conforms to the XDG Base Directory Specification, and is different for UNIX systems and Windows systems.
For UNIX systems:
-
If the
XDG_CONFIG_HOME
environment variable is set, the default configuration location that the Knative (kn
) CLI looks for is$XDG_CONFIG_HOME/kn
. -
If the
XDG_CONFIG_HOME
environment variable is not set, the Knative (kn
) CLI looks for the configuration in the home directory of the user at$HOME/.config/kn/config.yaml
.
For Windows systems, the default Knative (kn
) CLI configuration location is %APPDATA%\kn
.
Example configuration file
- 1
- Specifies whether the Knative (
kn
) CLI should look for plugins in thePATH
environment variable. This is a boolean configuration option. The default value isfalse
. - 2
- Specifies the directory where the Knative (
kn
) CLI looks for plugins. The default path depends on the operating system, as described previously. This can be any directory that is visible to the user. - 3
- The
sink-mappings
spec defines the Kubernetes addressable resource that is used when you use the--sink
flag with a Knative (kn
) CLI command. - 4
- The prefix you want to use to describe your sink.
svc
for a service,channel
, andbroker
are predefined prefixes for the Knative (kn
) CLI. - 5
- The API group of the Kubernetes resource.
- 6
- The version of the Kubernetes resource.
- 7
- The plural name of the Kubernetes resource type. For example,
services
orbrokers
.
4.3. Knative CLI plugins Copiar enlaceEnlace copiado en el portapapeles!
The Knative (kn
) CLI supports the use of plugins, which enable you to extend the functionality of your kn
installation by adding custom commands and other shared commands that are not part of the core distribution. Knative (kn
) CLI plugins are used in the same way as the main kn
functionality.
Currently, Red Hat supports the kn-source-kafka
plugin and the kn-event
plugin.
The kn-event
plugin is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.
4.3.1. Building events by using the kn-event plugin Copiar enlaceEnlace copiado en el portapapeles!
You can use the builder-like interface of the kn event build
command to build an event. You can then send that event at a later time or use it in another context.
Prerequisites
-
You have installed the Knative (
kn
) CLI.
Procedure
Build an event:
kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>
$ kn event build --field <field-name>=<value> --type <type-name> --id <id> --output <format>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow where:
-
The
--field
flag adds data to the event as a field-value pair. You can use it multiple times. -
The
--type
flag enables you to specify a string that designates the type of the event. -
The
--id
flag specifies the ID of the event. You can use the
json
oryaml
arguments with the--output
flag to change the output format of the event.All of these flags are optional.
Building a simple event
kn event build -o yaml
$ kn event build -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Resultant event in the YAML format
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Building a sample transaction event
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Resultant event in the JSON format
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
The
4.3.2. Sending events by using the kn-event plugin Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn event send
command to send an event. The events can be sent either to publicly available addresses or to addressable resources inside a cluster, such as Kubernetes services, as well as Knative services, brokers, and channels. The command uses the same builder-like interface as the kn event build
command.
Prerequisites
-
You have installed the Knative (
kn
) CLI.
Procedure
Send an event:
kn event send --field <field-name>=<value> --type <type-name> --id <id> --to-url <url> --to <cluster-resource> --namespace <namespace>
$ kn event send --field <field-name>=<value> --type <type-name> --id <id> --to-url <url> --to <cluster-resource> --namespace <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow where:
-
The
--field
flag adds data to the event as a field-value pair. You can use it multiple times. -
The
--type
flag enables you to specify a string that designates the type of the event. -
The
--id
flag specifies the ID of the event. -
If you are sending the event to a publicly accessible destination, specify the URL using the
--to-url
flag. If you are sending the event to an in-cluster Kubernetes resource, specify the destination using the
--to
flag.-
Specify the Kubernetes resource using the
<Kind>:<ApiVersion>:<name>
format.
-
Specify the Kubernetes resource using the
The
--namespace
flag specifies the namespace. If omitted, the namespace is taken from the current context.All of these flags are optional, except for the destination specification, for which you need to use either
--to-url
or--to
.The following example shows sending an event to a URL:
Example command
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The following example shows sending an event to an in-cluster resource:
Example command
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
The
4.4. Knative Serving CLI commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following Knative (kn
) CLI commands to complete Knative Serving tasks on the cluster.
4.4.1. kn service commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following commands to create and manage Knative services.
4.4.1.1. Creating serverless applications by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
Using the Knative (kn
) CLI to create serverless applications provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the kn service create
command to create a basic serverless application.
Prerequisites
- OpenShift Serverless Operator and Knative Serving are installed on your cluster.
-
You have installed the Knative (
kn
) CLI. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
Procedure
Create a Knative service:
kn service create <service-name> --image <image> --tag <tag-value>
$ kn service create <service-name> --image <image> --tag <tag-value>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
--image
is the URI of the image for the application. --tag
is an optional flag that can be used to add a tag to the initial revision that is created with the service.Example command
kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
4.4.1.2. Updating serverless applications by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn service update
command for interactive sessions on the command line as you build up a service incrementally. In contrast to the kn service apply
command, when using the kn service update
command you only have to specify the changes that you want to update, rather than the full configuration for the Knative service.
Example commands
Update a service by adding a new environment variable:
kn service update <service_name> --env <key>=<value>
$ kn service update <service_name> --env <key>=<value>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update a service by adding a new port:
kn service update <service_name> --port 80
$ kn service update <service_name> --port 80
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update a service by adding new request and limit parameters:
kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
$ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assign the
latest
tag to a revision:kn service update <service_name> --tag <revision_name>=latest
$ kn service update <service_name> --tag <revision_name>=latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update a tag from
testing
tostaging
for the latestREADY
revision of a service:kn service update <service_name> --untag testing --tag @latest=staging
$ kn service update <service_name> --untag testing --tag @latest=staging
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the
test
tag to a revision that receives 10% of traffic, and send the rest of the traffic to the latestREADY
revision of a service:kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
$ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.1.3. Applying service declarations Copiar enlaceEnlace copiado en el portapapeles!
You can declaratively configure a Knative service by using the kn service apply
command. If the service does not exist it is created, otherwise the existing service is updated with the options that have been changed.
The kn service apply
command is especially useful for shell scripts or in a continuous integration pipeline, where users typically want to fully specify the state of the service in a single command to declare the target state.
When using kn service apply
you must provide the full configuration for the Knative service. This is different from the kn service update
command, which only requires you to specify in the command the options that you want to update.
Example commands
Create a service:
kn service apply <service_name> --image <image>
$ kn service apply <service_name> --image <image>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add an environment variable to a service:
kn service apply <service_name> --image <image> --env <key>=<value>
$ kn service apply <service_name> --image <image> --env <key>=<value>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Read the service declaration from a JSON or YAML file:
kn service apply <service_name> -f <filename>
$ kn service apply <service_name> -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.1.4. Describing serverless applications by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can describe a Knative service by using the kn service describe
command.
Example commands
Describe a service:
kn service describe --verbose <service_name>
$ kn service describe --verbose <service_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
--verbose
flag is optional but can be included to provide a more detailed description. The difference between a regular and verbose output is shown in the following examples:Example output without
--verbose
flagCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example output with
--verbose
flagCopy to Clipboard Copied! Toggle word wrap Toggle overflow Describe a service in YAML format:
kn service describe <service_name> -o yaml
$ kn service describe <service_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Describe a service in JSON format:
kn service describe <service_name> -o json
$ kn service describe <service_name> -o json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Print the service URL only:
kn service describe <service_name> -o url
$ kn service describe <service_name> -o url
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2. About the Knative CLI offline mode Copiar enlaceEnlace copiado en el portapapeles!
When you execute kn service
commands, the changes immediately propagate to the cluster. However, as an alternative, you can execute kn service
commands in offline mode. When you create a service in offline mode, no changes happen on the cluster, and instead the service descriptor file is created on your local machine.
The offline mode of the Knative CLI is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.
After the descriptor file is created, you can manually modify it and track it in a version control system. You can also propagate changes to the cluster by using the kn service create -f
, kn service apply -f
, or oc apply -f
commands on the descriptor files.
The offline mode has several uses:
- You can manually modify the descriptor file before using it to make changes on the cluster.
- You can locally track the descriptor file of a service in a version control system. This enables you to reuse the descriptor file in places other than the target cluster, for example in continuous integration (CI) pipelines, development environments, or demos.
-
You can examine the created descriptor files to learn about Knative services. In particular, you can see how the resulting service is influenced by the different arguments passed to the
kn
command.
The offline mode has its advantages: it is fast, and does not require a connection to the cluster. However, offline mode lacks server-side validation. Consequently, you cannot, for example, verify that the service name is unique or that the specified image can be pulled.
4.4.2.1. Creating a service using offline mode Copiar enlaceEnlace copiado en el portapapeles!
You can execute kn service
commands in offline mode, so that no changes happen on the cluster, and instead the service descriptor file is created on your local machine. After the descriptor file is created, you can modify the file before propagating changes to the cluster.
The offline mode of the Knative CLI is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.
Prerequisites
- OpenShift Serverless Operator and Knative Serving are installed on your cluster.
-
You have installed the Knative (
kn
) CLI.
Procedure
In offline mode, create a local Knative service descriptor file:
kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \ --target ./ \ --namespace test
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \ --target ./ \ --namespace test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Service 'event-display' created in namespace 'test'.
Service 'event-display' created in namespace 'test'.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
--target ./
flag enables offline mode and specifies./
as the directory for storing the new directory tree.If you do not specify an existing directory, but use a filename, such as
--target my-service.yaml
, then no directory tree is created. Instead, only the service descriptor filemy-service.yaml
is created in the current directory.The filename can have the
.yaml
,.yml
, or.json
extension. Choosing.json
creates the service descriptor file in the JSON format.The
--namespace test
option places the new service in thetest
namespace.If you do not use
--namespace
, and you are logged in to an OpenShift Container Platform cluster, the descriptor file is created in the current namespace. Otherwise, the descriptor file is created in thedefault
namespace.
Examine the created directory structure:
tree ./
$ tree ./
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
The current
./
directory specified with--target
contains the newtest/
directory that is named after the specified namespace. -
The
test/
directory contains theksvc
directory, named after the resource type. -
The
ksvc
directory contains the descriptor fileevent-display.yaml
, named according to the specified service name.
-
The current
Examine the generated service descriptor file:
cat test/ksvc/event-display.yaml
$ cat test/ksvc/event-display.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow List information about the new service:
kn service describe event-display --target ./ --namespace test
$ kn service describe event-display --target ./ --namespace test
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
--target ./
option specifies the root directory for the directory structure containing namespace subdirectories.Alternatively, you can directly specify a YAML or JSON filename with the
--target
option. The accepted file extensions are.yaml
,.yml
, and.json
.The
--namespace
option specifies the namespace, which communicates tokn
the subdirectory that contains the necessary service descriptor file.If you do not use
--namespace
, and you are logged in to an OpenShift Container Platform cluster,kn
searches for the service in the subdirectory that is named after the current namespace. Otherwise,kn
searches in thedefault/
subdirectory.
Use the service descriptor file to create the service on the cluster:
kn service create -f test/ksvc/event-display.yaml
$ kn service create -f test/ksvc/event-display.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.3. kn container commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following commands to create and manage multiple containers in a Knative service spec.
4.4.3.1. Knative client multi-container support Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn container add
command to print YAML container spec to standard output. This command is useful for multi-container use cases because it can be used along with other standard kn
flags to create definitions.
The kn container add
command accepts all container-related flags that are supported for use with the kn service create
command. The kn container add
command can also be chained by using UNIX pipes (|
) to create multiple container definitions at once.
Example commands
Add a container from an image and print it to standard output:
kn container add <container_name> --image <image_uri>
$ kn container add <container_name> --image <image_uri>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn container add sidecar --image docker.io/example/sidecar
$ kn container add sidecar --image docker.io/example/sidecar
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
containers: - image: docker.io/example/sidecar name: sidecar resources: {}
containers: - image: docker.io/example/sidecar name: sidecar resources: {}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Chain two
kn container add
commands together, and then pass them to akn service create
command to create a Knative service with two containers:kn container add <first_container_name> --image <image_uri> | \ kn container add <second_container_name> --image <image_uri> | \ kn service create <service_name> --image <image_uri> --extra-containers -
$ kn container add <first_container_name> --image <image_uri> | \ kn container add <second_container_name> --image <image_uri> | \ kn service create <service_name> --image <image_uri> --extra-containers -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow --extra-containers -
specifies a special case wherekn
reads the pipe input instead of a YAML file.Example command
kn container add sidecar --image docker.io/example/sidecar:first | \ kn container add second --image docker.io/example/sidecar:second | \ kn service create my-service --image docker.io/example/my-app:latest --extra-containers -
$ kn container add sidecar --image docker.io/example/sidecar:first | \ kn container add second --image docker.io/example/sidecar:second | \ kn service create my-service --image docker.io/example/my-app:latest --extra-containers -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
--extra-containers
flag can also accept a path to a YAML file:kn service create <service_name> --image <image_uri> --extra-containers <filename>
$ kn service create <service_name> --image <image_uri> --extra-containers <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
$ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.4. kn domain commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following commands to create and manage domain mappings.
4.4.4.1. Creating a custom domain mapping by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. You can use the Knative (kn
) CLI to create a DomainMapping
custom resource (CR) that maps to an Addressable target CR, such as a Knative service or a Knative route.
Prerequisites
- The OpenShift Serverless Operator and Knative Serving are installed on your cluster.
You have created a Knative service or route, and control a custom domain that you want to map to that CR.
NoteYour custom domain must point to the DNS of the OpenShift Container Platform cluster.
-
You have installed the Knative (
kn
) CLI. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
Procedure
Map a domain to a CR in the current namespace:
kn domain create <domain_mapping_name> --ref <target_name>
$ kn domain create <domain_mapping_name> --ref <target_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn domain create example.com --ref example-service
$ kn domain create example.com --ref example-service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
--ref
flag specifies an Addressable target CR for domain mapping.If a prefix is not provided when using the
--ref
flag, it is assumed that the target is a Knative service in the current namespace.Map a domain to a Knative service in a specified namespace:
kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
$ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn domain create example.com --ref ksvc:example-service:example-namespace
$ kn domain create example.com --ref ksvc:example-service:example-namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Map a domain to a Knative route:
kn domain create <domain_mapping_name> --ref <kroute:route_name>
$ kn domain create <domain_mapping_name> --ref <kroute:route_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn domain create example.com --ref kroute:example-route
$ kn domain create example.com --ref kroute:example-route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.4.2. Managing custom domain mappings by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
After you have created a DomainMapping
custom resource (CR), you can list existing CRs, view information about an existing CR, update CRs, or delete CRs by using the Knative (kn
) CLI.
Prerequisites
- The OpenShift Serverless Operator and Knative Serving are installed on your cluster.
-
You have created at least one
DomainMapping
CR. -
You have installed the Knative (
kn
) CLI tool. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
Procedure
List existing
DomainMapping
CRs:kn domain list -n <domain_mapping_namespace>
$ kn domain list -n <domain_mapping_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow View details of an existing
DomainMapping
CR:kn domain describe <domain_mapping_name>
$ kn domain describe <domain_mapping_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Update a
DomainMapping
CR to point to a new target:kn domain update --ref <target>
$ kn domain update --ref <target>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Delete a
DomainMapping
CR:kn domain delete <domain_mapping_name>
$ kn domain delete <domain_mapping_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. Knative Eventing CLI commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following Knative (kn
) CLI commands to complete Knative Eventing tasks on the cluster.
4.5.1. kn source commands Copiar enlaceEnlace copiado en el portapapeles!
You can use the following commands to list, create, and manage Knative event sources.
4.5.1.1. Listing available event source types by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
Using the Knative (kn
) CLI provides a streamlined and intuitive user interface to view available event source types on your cluster. You can list event source types that can be created and used on your cluster by using the kn source list-types
CLI command.
Prerequisites
- The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
-
You have installed the Knative (
kn
) CLI.
Procedure
List the available event source types in the terminal:
kn source list-types
$ kn source list-types
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink PingSource pingsources.sources.knative.dev Periodically send ping events to a sink SinkBinding sinkbindings.sources.knative.dev Binding for connecting a PodSpecable to a sink
TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink PingSource pingsources.sources.knative.dev Periodically send ping events to a sink SinkBinding sinkbindings.sources.knative.dev Binding for connecting a PodSpecable to a sink
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Optional: You can also list the available event source types in YAML format:
kn source list-types -o yaml
$ kn source list-types -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.1.2. Knative CLI sink flag Copiar enlaceEnlace copiado en el portapapeles!
When you create an event source by using the Knative (kn
) CLI, you can specify a sink where events are sent to from that resource by using the --sink
flag. The sink can be any addressable or callable resource that can receive incoming events from other resources.
The following example creates a sink binding that uses a service, http://event-display.svc.cluster.local
, as the sink:
Example command using the sink flag
kn source binding create bind-heartbeat \ --namespace sinkbinding-example \ --subject "Job:batch/v1:app=heartbeat-cron" \ --sink http://event-display.svc.cluster.local \ --ce-override "sink=bound"
$ kn source binding create bind-heartbeat \
--namespace sinkbinding-example \
--subject "Job:batch/v1:app=heartbeat-cron" \
--sink http://event-display.svc.cluster.local \
--ce-override "sink=bound"
- 1
svc
inhttp://event-display.svc.cluster.local
determines that the sink is a Knative service. Other default sink prefixes includechannel
, andbroker
.
4.5.1.3. Creating and managing container sources by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn source container
commands to create and manage container sources by using the Knative (kn
) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly.
Create a container source
kn source container create <container_source_name> --image <image_uri> --sink <sink>
$ kn source container create <container_source_name> --image <image_uri> --sink <sink>
Delete a container source
kn source container delete <container_source_name>
$ kn source container delete <container_source_name>
Describe a container source
kn source container describe <container_source_name>
$ kn source container describe <container_source_name>
List existing container sources
kn source container list
$ kn source container list
List existing container sources in YAML format
kn source container list -o yaml
$ kn source container list -o yaml
Update a container source
This command updates the image URI for an existing container source:
kn source container update <container_source_name> --image <image_uri>
$ kn source container update <container_source_name> --image <image_uri>
4.5.1.4. Creating an API server source by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn source apiserver create
command to create an API server source by using the kn
CLI. Using the kn
CLI to create an API server source provides a more streamlined and intuitive user interface than modifying YAML files directly.
Prerequisites
- The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
- You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
-
You have installed the OpenShift CLI (
oc
). -
You have installed the Knative (
kn
) CLI.
If you want to re-use an existing service account, you can modify your existing ServiceAccount
resource to include the required permissions instead of creating a new resource.
Create a service account, role, and role binding for the event source as a YAML file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Apply the YAML file:
oc apply -f <filename>
$ oc apply -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create an API server source that has an event sink. In the following example, the sink is a broker:
kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
Copy to Clipboard Copied! Toggle word wrap Toggle overflow To check that the API server source is set up correctly, create a Knative service that dumps incoming messages to its log:
kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you used a broker as an event sink, create a trigger to filter events from the
default
broker to the service:kn trigger create <trigger_name> --sink ksvc:<service_name>
$ kn trigger create <trigger_name> --sink ksvc:<service_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create events by launching a pod in the default namespace:
oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
$ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check that the controller is mapped correctly by inspecting the output generated by the following command:
kn source apiserver describe <source_name>
$ kn source apiserver describe <source_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
You can verify that the Kubernetes events were sent to Knative by looking at the message dumper function logs.
Get the pods:
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow View the message dumper function logs for the pods:
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Deleting the API server source
Delete the trigger:
kn trigger delete <trigger_name>
$ kn trigger delete <trigger_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the event source:
kn source apiserver delete <source_name>
$ kn source apiserver delete <source_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the service account, cluster role, and cluster binding:
oc delete -f authentication.yaml
$ oc delete -f authentication.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.1.5. Creating a ping source by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn source ping create
command to create a ping source by using the Knative (kn
) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly.
Prerequisites
- The OpenShift Serverless Operator, Knative Serving and Knative Eventing are installed on the cluster.
-
You have installed the Knative (
kn
) CLI. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
-
Optional: If you want to use the verification steps for this procedure, install the OpenShift CLI (
oc
).
Procedure
To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service logs:
kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For each set of ping events that you want to request, create a ping source in the same namespace as the event consumer:
kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
$ kn source ping create test-ping-source \ --schedule "*/2 * * * *" \ --data '{"message": "Hello world!"}' \ --sink ksvc:event-display
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check that the controller is mapped correctly by entering the following command and inspecting the output:
kn source ping describe test-ping-source
$ kn source ping describe test-ping-source
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
You can verify that the Kubernetes events were sent to the Knative event sink by looking at the logs of the sink pod.
By default, Knative services terminate their pods if no traffic is received within a 60 second period. The example shown in this guide creates a ping source that sends a message every 2 minutes, so each message should be observed in a newly created pod.
Watch for new pods created:
watch oc get pods
$ watch oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cancel watching the pods using Ctrl+C, then look at the logs of the created pod:
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Deleting the ping source
Delete the ping source:
kn delete pingsources.sources.knative.dev <ping_source_name>
$ kn delete pingsources.sources.knative.dev <ping_source_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.1.6. Creating a Kafka event source by using the Knative CLI Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn source kafka create
command to create a Kafka source by using the Knative (kn
) CLI. Using the Knative CLI to create event sources provides a more streamlined and intuitive user interface than modifying YAML files directly.
Prerequisites
-
The OpenShift Serverless Operator, Knative Eventing, Knative Serving, and the
KnativeKafka
custom resource (CR) are installed on your cluster. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
- You have access to a Red Hat AMQ Streams (Kafka) cluster that produces the Kafka messages you want to import.
-
You have installed the Knative (
kn
) CLI. -
Optional: You have installed the OpenShift CLI (
oc
) if you want to use the verification steps in this procedure.
Procedure
To verify that the Kafka event source is working, create a Knative service that dumps incoming events into the service logs:
kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display
$ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a
KafkaSource
CR:kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
$ kn source kafka create <kafka_source_name> \ --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \ --topics <topic_name> --consumergroup my-consumer-group \ --sink event-display
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteReplace the placeholder values in this command with values for your source name, bootstrap servers, and topics.
The
--servers
,--topics
, and--consumergroup
options specify the connection parameters to the Kafka cluster. The--consumergroup
option is optional.Optional: View details about the
KafkaSource
CR you created:kn source kafka describe <kafka_source_name>
$ kn source kafka describe <kafka_source_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification steps
Trigger the Kafka instance to send a message to the topic:
oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
$ oc -n kafka run kafka-producer \ -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \ --restart=Never -- bin/kafka-console-producer.sh \ --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enter the message in the prompt. This command assumes that:
-
The Kafka cluster is installed in the
kafka
namespace. -
The
KafkaSource
object has been configured to use themy-topic
topic.
-
The Kafka cluster is installed in the
Verify that the message arrived by viewing the logs:
oc logs $(oc get pod -o name | grep event-display) -c user-container
$ oc logs $(oc get pod -o name | grep event-display) -c user-container
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6. Functions commands Copiar enlaceEnlace copiado en el portapapeles!
4.6.1. Creating functions Copiar enlaceEnlace copiado en el portapapeles!
Before you can build and deploy a function, you must create it by using the Knative (kn
) CLI. You can specify the path, runtime, template, and image registry as flags on the command line, or use the -c
flag to start the interactive experience in the terminal.
Prerequisites
- The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
-
You have installed the Knative (
kn
) CLI.
Procedure
Create a function project:
kn func create -r <repository> -l <runtime> -t <template> <path>
$ kn func create -r <repository> -l <runtime> -t <template> <path>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Accepted runtime values include
quarkus
,node
,typescript
,go
,python
,springboot
, andrust
. Accepted template values include
http
andcloudevents
.Example command
kn func create -l typescript -t cloudevents examplefunc
$ kn func create -l typescript -t cloudevents examplefunc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Created typescript function in /home/user/demo/examplefunc
Created typescript function in /home/user/demo/examplefunc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, you can specify a repository that contains a custom template.
Example command
kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc
$ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Created node function in /home/user/demo/examplefunc
Created node function in /home/user/demo/examplefunc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Accepted runtime values include
4.6.2. Running a function locally Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn func run
command to run a function locally in the current directory or in the directory specified by the --path
flag. If the function that you are running has never previously been built, or if the project files have been modified since the last time it was built, the kn func run
command builds the function before running it by default.
Example command to run a function in the current directory
kn func run
$ kn func run
Example command to run a function in a directory specified as a path
kn func run --path=<directory_path>
$ kn func run --path=<directory_path>
You can also force a rebuild of an existing image before running the function, even if there have been no changes to the project files, by using the --build
flag:
Example run command using the build flag
kn func run --build
$ kn func run --build
If you set the build
flag as false, this disables building of the image, and runs the function using the previously built image:
Example run command using the build flag
kn func run --build=false
$ kn func run --build=false
You can use the help command to learn more about kn func run
command options:
Build help command
kn func help run
$ kn func help run
4.6.3. Building functions Copiar enlaceEnlace copiado en el portapapeles!
Before you can run a function, you must build the function project. If you are using the kn func run
command, the function is built automatically. However, you can use the kn func build
command to build a function without running it, which can be useful for advanced users or debugging scenarios.
The kn func build
command creates an OCI container image that can be run locally on your computer or on an OpenShift Container Platform cluster. This command uses the function project name and the image registry name to construct a fully qualified image name for your function.
4.6.3.1. Image container types Copiar enlaceEnlace copiado en el portapapeles!
By default, kn func build
creates a container image by using Red Hat Source-to-Image (S2I) technology.
Example build command using Red Hat Source-to-Image (S2I)
kn func build
$ kn func build
4.6.3.2. Image registry types Copiar enlaceEnlace copiado en el portapapeles!
The OpenShift Container Registry is used by default as the image registry for storing function images.
Example build command using OpenShift Container Registry
kn func build
$ kn func build
Example output
Building function image Function image has been built, image: registry.redhat.io/example/example-function:latest
Building function image
Function image has been built, image: registry.redhat.io/example/example-function:latest
You can override using OpenShift Container Registry as the default image registry by using the --registry
flag:
Example build command overriding OpenShift Container Registry to use quay.io
kn func build --registry quay.io/username
$ kn func build --registry quay.io/username
Example output
Building function image Function image has been built, image: quay.io/username/example-function:latest
Building function image
Function image has been built, image: quay.io/username/example-function:latest
4.6.3.3. Push flag Copiar enlaceEnlace copiado en el portapapeles!
You can add the --push
flag to a kn func build
command to automatically push the function image after it is successfully built:
Example build command using OpenShift Container Registry
kn func build --push
$ kn func build --push
4.6.3.4. Help command Copiar enlaceEnlace copiado en el portapapeles!
You can use the help command to learn more about kn func build
command options:
Build help command
kn func help build
$ kn func help build
4.6.4. Deploying functions Copiar enlaceEnlace copiado en el portapapeles!
You can deploy a function to your cluster as a Knative service by using the kn func deploy
command. If the targeted function is already deployed, it is updated with a new container image that is pushed to a container image registry, and the Knative service is updated.
Prerequisites
- The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
-
You have installed the Knative (
kn
) CLI. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
- You must have already created and initialized the function that you want to deploy.
Procedure
Deploy a function:
kn func deploy [-n <namespace> -p <path> -i <image>]
$ kn func deploy [-n <namespace> -p <path> -i <image>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Function deployed at: http://func.example.com
Function deployed at: http://func.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
If no
namespace
is specified, the function is deployed in the current namespace. -
The function is deployed from the current directory, unless a
path
is specified. - The Knative service name is derived from the project name, and cannot be changed using this command.
-
If no
4.6.5. Listing existing functions Copiar enlaceEnlace copiado en el portapapeles!
You can list existing functions by using kn func list
. If you want to list functions that have been deployed as Knative services, you can also use kn service list
.
Procedure
List existing functions:
kn func list [-n <namespace> -p <path>]
$ kn func list [-n <namespace> -p <path>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME NAMESPACE RUNTIME URL READY example-function default node http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com True
NAME NAMESPACE RUNTIME URL READY example-function default node http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow List functions deployed as Knative services:
kn service list -n <namespace>
$ kn service list -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
NAME URL LATEST AGE CONDITIONS READY REASON example-function http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com example-function-gzl4c 16m 3 OK / 3 True
NAME URL LATEST AGE CONDITIONS READY REASON example-function http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com example-function-gzl4c 16m 3 OK / 3 True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.6. Describing a function Copiar enlaceEnlace copiado en el portapapeles!
The kn func info
command prints information about a deployed function, such as the function name, image, namespace, Knative service information, route information, and event subscriptions.
Procedure
Describe a function:
kn func info [-f <format> -n <namespace> -p <path>]
$ kn func info [-f <format> -n <namespace> -p <path>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example command
kn func info -p function/example-function
$ kn func info -p function/example-function
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.7. Invoking a deployed function with a test event Copiar enlaceEnlace copiado en el portapapeles!
You can use the kn func invoke
CLI command to send a test request to invoke a function either locally or on your OpenShift Container Platform cluster. You can use this command to test that a function is working and able to receive events correctly. Invoking a function locally is useful for a quick test during function development. Invoking a function on the cluster is useful for testing that is closer to the production environment.
Prerequisites
- The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
-
You have installed the Knative (
kn
) CLI. - You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
- You must have already deployed the function that you want to invoke.
Procedure
Invoke a function:
kn func invoke
$ kn func invoke
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
The
kn func invoke
command only works when there is either a local container image currently running, or when there is a function deployed in the cluster. -
The
kn func invoke
command executes on the local directory by default, and assumes that this directory is a function project.
-
The
4.6.7.1. kn func invoke optional parameters Copiar enlaceEnlace copiado en el portapapeles!
You can specify optional parameters for the request by using the following kn func invoke
CLI command flags.
Flags | Description |
---|---|
|
Specifies the target instance of the invoked function, for example, |
|
Specifies the format of the message, for example, |
| Specifies a unique string identifier for the request. |
| Specifies the namespace on the cluster. |
|
Specifies sender name for the request. This corresponds to the CloudEvent |
|
Specifies the type of request, for example, |
|
Specifies content for the request. For CloudEvent requests, this is the CloudEvent |
| Specifies path to a local file containing data to be sent. |
| Specifies the MIME content type for the request. |
| Specifies path to the project directory. |
| Enables prompting to interactively confirm all options. |
| Enables printing verbose output. |
|
Prints information on usage of |
4.6.7.1.1. Main parameters Copiar enlaceEnlace copiado en el portapapeles!
The following parameters define the main properties of the kn func invoke
command:
- Event target (
-t
,--target
) -
The target instance of the invoked function. Accepts the
local
value for a locally deployed function, theremote
value for a remotely deployed function, or a URL for a function deployed to an arbitrary endpoint. If a target is not specified, it defaults tolocal
. - Event message format (
-f
,--format
) -
The message format for the event, such as
http
orcloudevent
. This defaults to the format of the template that was used when creating the function. - Event type (
--type
) -
The type of event that is sent. You can find information about the
type
parameter that is set in the documentation for each event producer. For example, the API server source might set thetype
parameter of produced events asdev.knative.apiserver.resource.update
. - Event source (
--source
) -
The unique event source that produced the event. This might be a URI for the event source, for example
https://10.96.0.1/
, or the name of the event source. - Event ID (
--id
) - A random, unique ID that is created by the event producer.
- Event data (
--data
) Allows you to specify a
data
value for the event sent by thekn func invoke
command. For example, you can specify a--data
value such as"Hello World"
so that the event contains this data string. By default, no data is included in the events created bykn func invoke
.NoteFunctions that have been deployed to a cluster can respond to events from an existing event source that provides values for properties such as
source
andtype
. These events often have adata
value in JSON format, which captures the domain specific context of the event. By using the CLI flags noted in this document, developers can simulate those events for local testing.You can also send event data using the
--file
flag to provide a local file containing data for the event. In this case, specify the content type using--content-type
.- Data content type (
--content-type
) -
If you are using the
--data
flag to add data for events, you can use the--content-type
flag to specify what type of data is carried by the event. In the previous example, the data is plain text, so you might specifykn func invoke --data "Hello world!" --content-type "text/plain"
.
4.6.7.1.2. Example commands Copiar enlaceEnlace copiado en el portapapeles!
This is the general invocation of the kn func invoke
command:
kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>
$ kn func invoke --type <event_type> --source <event_source> --data <event_data> --content-type <content_type> --id <event_ID> --format <format> --namespace <namespace>
For example, to send a "Hello world!" event, you can run:
kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
$ kn func invoke --type ping --source example-ping --data "Hello world!" --content-type "text/plain" --id example-ID --format http --namespace my-ns
4.6.7.1.2.1. Specifying the file with data Copiar enlaceEnlace copiado en el portapapeles!
To specify the file on disk that contains the event data, use the --file
and --content-type
flags:
kn func invoke --file <path> --content-type <content-type>
$ kn func invoke --file <path> --content-type <content-type>
For example, to send JSON data stored in the test.json
file, use this command:
kn func invoke --file ./test.json --content-type application/json
$ kn func invoke --file ./test.json --content-type application/json
4.6.7.1.2.2. Specifying the function project Copiar enlaceEnlace copiado en el portapapeles!
You can specify a path to the function project by using the --path
flag:
kn func invoke --path <path_to_function>
$ kn func invoke --path <path_to_function>
For example, to use the function project located in the ./example/example-function
directory, use this command:
kn func invoke --path ./example/example-function
$ kn func invoke --path ./example/example-function
4.6.7.1.2.3. Specifying where the target function is deployed Copiar enlaceEnlace copiado en el portapapeles!
By default, kn func invoke
targets the local deployment of the function:
kn func invoke
$ kn func invoke
To use a different deployment, use the --target
flag:
kn func invoke --target <target>
$ kn func invoke --target <target>
For example, to use the function deployed on the cluster, use the --target remote
flag:
kn func invoke --target remote
$ kn func invoke --target remote
To use the function deployed at an arbitrary URL, use the --target <URL>
flag:
kn func invoke --target "https://my-event-broker.example.com"
$ kn func invoke --target "https://my-event-broker.example.com"
You can explicitly target the local deployment. In this case, if the function is not running locally, the command fails:
kn func invoke --target local
$ kn func invoke --target local
4.6.8. Deleting a function Copiar enlaceEnlace copiado en el portapapeles!
You can delete a function by using the kn func delete
command. This is useful when a function is no longer required, and can help to save resources on your cluster.
Procedure
Delete a function:
kn func delete [<function_name> -n <namespace> -p <path>]
$ kn func delete [<function_name> -n <namespace> -p <path>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
If the name or path of the function to delete is not specified, the current directory is searched for a
func.yaml
file that is used to determine the function to delete. -
If the namespace is not specified, it defaults to the
namespace
value in thefunc.yaml
file.
-
If the name or path of the function to delete is not specified, the current directory is searched for a