Serverless

• OpenShift Serverless now uses Knative Serving 1.3.
• OpenShift Serverless now uses Knative Eventing 1.3.
• OpenShift Serverless now uses Kourier 1.3.
• OpenShift Serverless now uses Knative kn CLI 1.3.
• OpenShift Serverless now uses Knative Kafka 1.3.
• The kn func CLI plug-in now uses func 0.24.
• Init containers support for Knative services is now generally available (GA).
• OpenShift Serverless logic is now available as a Developer Preview. It enables defining declarative workflow models for managing serverless applications.
• You can now use the cost management service with OpenShift Serverless.

• Integrating OpenShift Serverless with Red Hat OpenShift Service Mesh causes the net-istio-controller pod to run out of memory on startup when too many secrets are present on the cluster.

  It is now possible to enable secret filtering, which causes net-istio-controller to consider only secrets with a networking.internal.knative.dev/certificate-uid label, thus reducing the amount of memory needed.

• The OpenShift Serverless Functions Technology Preview now uses Cloud Native Buildpacks by default to build container images.

• The Federal Information Processing Standards (FIPS) mode is disabled for Kafka broker, Kafka source, and Kafka sink.

• In OpenShift Serverless 1.23, support for KafkaBindings and the kafka-binding webhook were removed. However, an existing kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration might remain, pointing to the kafka-source-webhook service, which no longer exists.

  For certain specifications of KafkaBindings on the cluster, kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration might be configured to pass any create and update events to various resources, such as Deployments, Knative Services, or Jobs, through the webhook, which would then fail.

  To work around this issue, manually delete kafkabindings.webhook.kafka.sources.knative.dev MutatingWebhookConfiguration from the cluster after upgrading to OpenShift Serverless 1.23:

  $ oc delete mutatingwebhookconfiguration kafkabindings.webhook.kafka.sources.knative.dev

• OpenShift Serverless now uses Knative Serving 1.2.
• OpenShift Serverless now uses Knative Eventing 1.2.
• OpenShift Serverless now uses Kourier 1.2.
• OpenShift Serverless now uses Knative (kn) CLI 1.2.
• OpenShift Serverless now uses Knative Kafka 1.2.
• The kn func CLI plug-in now uses func 0.24.
• It is now possible to use the kafka.eventing.knative.dev/external.topic annotation with the Kafka broker. This annotation makes it possible to use an existing externally managed topic instead of the broker creating its own internal topic.
• The kafka-ch-controller and kafka-webhook Kafka components no longer exist. These components have been replaced by the kafka-webhook-eventing component.
• The OpenShift Serverless Functions Technology Preview now uses Source-to-Image (S2I) by default to build container images.

• The Federal Information Processing Standards (FIPS) mode is disabled for Kafka broker, Kafka source, and Kafka sink.
• If you delete a namespace that includes a Kafka broker, the namespace finalizer may fail to be removed if the broker’s auth.secret.ref.name secret is deleted before the broker.

• Running OpenShift Serverless with a large number of Knative services can cause Knative activator pods to run close to their default memory limits of 600MB. These pods might be restarted if memory consumption reaches this limit. Requests and limits for the activator deployment can be configured by modifying the KnativeServing custom resource:

  apiVersion: operator.knative.dev/v1alpha1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    deployments:
    - name: activator
      resources:
      - container: activator
        requests:
          cpu: 300m
          memory: 60Mi
        limits:
          cpu: 1000m
          memory: 1000Mi

• If you are using Cloud Native Buildpacks as the local build strategy for a function, kn func is unable to automatically start podman or use an SSH tunnel to a remote daemon. The workaround for these issues is to have a Docker or podman daemon already running on the local development computer before deploying a function.
• On-cluster function builds currently fail for Quarkus and Golang runtimes. They work correctly for Node, Typescript, Python, and Springboot runtimes.

• OpenShift Serverless now uses Knative Serving 1.1.
• OpenShift Serverless now uses Knative Eventing 1.1.
• OpenShift Serverless now uses Kourier 1.1.
• OpenShift Serverless now uses Knative (kn) CLI 1.1.
• OpenShift Serverless now uses Knative Kafka 1.1.
• The kn func CLI plug-in now uses func 0.23.
• Init containers support for Knative services is now available as a Technology Preview.
• Persistent volume claim (PVC) support for Knative services is now available as a Technology Preview.
• The knative-serving, knative-serving-ingress, knative-eventing and knative-kafka system namespaces now have the knative.openshift.io/part-of: "openshift-serverless" label by default.
• The Knative Eventing - Kafka Broker/Trigger dashboard has been added, which allows visualizing Kafka broker and trigger metrics in the web console.
• The Knative Eventing - KafkaSink dashboard has been added, which allows visualizing KafkaSink metrics in the web console.
• The Knative Eventing - Broker/Trigger dashboard is now called Knative Eventing - Channel-based Broker/Trigger.
• The knative.openshift.io/part-of: "openshift-serverless" label has substituted the knative.openshift.io/system-namespace label.
• Naming style in Knative Serving YAML configuration files changed from camel case (ExampleName) to hyphen style (example-name). Beginning with this release, use the hyphen style notation when creating or editing Knative Serving YAML configuration files.

• The Federal Information Processing Standards (FIPS) mode is disabled for Kafka broker, Kafka source, and Kafka sink.

• OpenShift Serverless now uses Knative Serving 1.0
• OpenShift Serverless now uses Knative Eventing 1.0.
• OpenShift Serverless now uses Kourier 1.0.
• OpenShift Serverless now uses Knative (kn) CLI 1.0.
• OpenShift Serverless now uses Knative Kafka 1.0.
• The kn func CLI plug-in now uses func 0.21.
• The Kafka sink is now available as a Technology Preview.
• The Knative open source project has begun to deprecate camel-cased configuration keys in favor of using kebab-cased keys consistently. As a result, the defaultExternalScheme key, previously mentioned in the OpenShift Serverless 1.18.0 release notes, is now deprecated and replaced by the default-external-scheme key. Usage instructions for the key remain the same.

• In OpenShift Serverless 1.20.0, there was an event delivery issue affecting the use of kn event send to send events to a service. This issue is now fixed.
• In OpenShift Serverless 1.20.0 (func 0.20), TypeScript functions created with the http template failed to deploy on the cluster. This issue is now fixed.
• In OpenShift Serverless 1.20.0 (func 0.20), deploying a function using the gcr.io registry failed with an error. This issue is now fixed.
• In OpenShift Serverless 1.20.0 (func 0.20), creating a Springboot function project directory with the kn func create command and then running the kn func build command failed with an error message. This issue is now fixed.
• In OpenShift Serverless 1.19.0 (func 0.19), some runtimes were unable to build a function by using podman. This issue is now fixed.

• Currently, the domain mapping controller cannot process the URI of a broker, which contains a path that is currently not supported.

  This means that, if you want to use a DomainMapping custom resource (CR) to map a custom domain to a broker, you must configure the DomainMapping CR with the broker’s ingress service, and append the exact path of the broker to the custom domain:

  Example DomainMapping CR

  apiVersion: serving.knative.dev/v1alpha1
  kind: DomainMapping
  metadata:
    name: <domain-name>
    namespace: knative-eventing
  spec:
    ref:
      name: broker-ingress
      kind: Service
      apiVersion: v1

  The URI for the broker is then <domain-name>/<broker-namespace>/<broker-name>.

• OpenShift Serverless now uses Knative Serving 0.26.
• OpenShift Serverless now uses Knative Eventing 0.26.
• OpenShift Serverless now uses Kourier 0.26.
• OpenShift Serverless now uses Knative (kn) CLI 0.26.
• OpenShift Serverless now uses Knative Kafka 0.26.
• The kn func CLI plug-in now uses func 0.20.

• The Kafka broker is now available as a Technology Preview.

  Important

  The Kafka broker, which is currently in Technology Preview, is not supported on FIPS.

• The kn event plug-in is now available as a Technology Preview.
• The --min-scale and --max-scale flags for the kn service create command have been deprecated. Use the --scale-min and --scale-max flags instead.

• OpenShift Serverless deploys Knative services with a default address that uses HTTPS. When sending an event to a resource inside the cluster, the sender does not have the cluster certificate authority (CA) configured. This causes event delivery to fail, unless the cluster uses globally accepted certificates.

  For example, an event delivery to a publicly accessible address works:

  $ kn event send --to-url https://ce-api.foo.example.com/

  On the other hand, this delivery fails if the service uses a public address with an HTTPS certificate issued by a custom CA:

  $ kn event send --to Service:serving.knative.dev/v1:event-display

  Sending an event to other addressable objects, such as brokers or channels, is not affected by this issue and works as expected.

• The Kafka broker currently does not work on a cluster with Federal Information Processing Standards (FIPS) mode enabled.

• If you create a Springboot function project directory with the kn func create command, subsequent running of the kn func build command fails with this error message:

  [analyzer] no stack metadata found at path ''
  [analyzer] ERROR: failed to : set API for buildpack 'paketo-buildpacks/ca-certificates@3.0.2': buildpack API version '0.7' is incompatible with the lifecycle

  As a workaround, you can change the builder property to gcr.io/paketo-buildpacks/builder:base in the function configuration file func.yaml.

• Deploying a function using the gcr.io registry fails with this error message:

  Error: failed to get credentials: failed to verify credentials: status code: 404

  As a workaround, use a different registry than gcr.io, such as quay.io or docker.io.

• TypeScript functions created with the http template fail to deploy on the cluster.

  As a workaround, in the func.yaml file, replace the following section:

  buildEnvs: []

  with this:

  buildEnvs:
  - name: BP_NODE_RUN_SCRIPTS
    value: build

• In func version 0.20, some runtimes might be unable to build a function by using podman. You might see an error message similar to the following:

  ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

  • The following workaround exists for this issue:

    1. Update the podman service by adding --time=0 to the service ExecStart definition:

       Example service configuration

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

    2. Restart the podman service by running the following commands:

       $ systemctl --user daemon-reload

       $ systemctl restart --user podman.socket

  • Alternatively, you can expose the podman API by using TCP:

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

• OpenShift Serverless now uses Knative Serving 0.25.
• OpenShift Serverless now uses Knative Eventing 0.25.
• OpenShift Serverless now uses Kourier 0.25.
• OpenShift Serverless now uses Knative (kn) CLI 0.25.
• OpenShift Serverless now uses Knative Kafka 0.25.
• The kn func CLI plug-in now uses func 0.19.
• The KafkaBinding API is deprecated in OpenShift Serverless 1.19.0 and will be removed in a future release.
• HTTPS redirection is now supported and can be configured either globally for a cluster or per each Knative service.

• In previous releases, the Kafka channel dispatcher waited only for the local commit to succeed before responding, which might have caused lost events in the case of an Apache Kafka node failure. The Kafka channel dispatcher now waits for all in-sync replicas to commit before responding.

• In func version 0.19, some runtimes might be unable to build a function by using podman. You might see an error message similar to the following:

  ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF

  • The following workaround exists for this issue:

    1. Update the podman service by adding --time=0 to the service ExecStart definition:

       Example service configuration

       ExecStart=/usr/bin/podman $LOGGING system service --time=0

    2. Restart the podman service by running the following commands:

       $ systemctl --user daemon-reload

       $ systemctl restart --user podman.socket

  • Alternatively, you can expose the podman API by using TCP:

    $ podman system service --time=0 tcp:127.0.0.1:5534 &
    export DOCKER_HOST=tcp://127.0.0.1:5534

• OpenShift Serverless now uses Knative Serving 0.24.0.
• OpenShift Serverless now uses Knative Eventing 0.24.0.
• OpenShift Serverless now uses Kourier 0.24.0.
• OpenShift Serverless now uses Knative (kn) CLI 0.24.0.
• OpenShift Serverless now uses Knative Kafka 0.24.7.
• The kn func CLI plug-in now uses func 0.18.0.

• In the upcoming OpenShift Serverless 1.19.0 release, the URL scheme of external routes will default to HTTPS for enhanced security.

  If you do not want this change to apply for your workloads, you can override the default setting before upgrading to 1.19.0, by adding the following YAML to your KnativeServing custom resource (CR):

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "http"
  ...

  If you want the change to apply in 1.18.0 already, add the following YAML:

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "https"
  ...

• In the upcoming OpenShift Serverless 1.19.0 release, the default service type by which the Kourier Gateway is exposed will be ClusterIP and not LoadBalancer.

  If you do not want this change to apply to your workloads, you can override the default setting before upgrading to 1.19.0, by adding the following YAML to your KnativeServing custom resource (CR):

  ...
  spec:
    ingress:
      kourier:
        service-type: LoadBalancer
  ...

• You can now use emptyDir volumes with OpenShift Serverless. See the OpenShift Serverless documentation about Knative Serving for details.
• Rust templates are now available when you create a function using kn func.

• The prior 1.4 version of Camel-K was not compatible with OpenShift Serverless 1.17.0. The issue in Camel-K has been fixed, and Camel-K version 1.4.1 can be used with OpenShift Serverless 1.17.0.

• Previously, if you created a new subscription for a Kafka channel, or a new Kafka source, a delay was possible in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reported a ready status.

  As a result, messages that were sent during the time when the data plane was not reporting a ready status, might not have been delivered to the subscriber or sink.

  In OpenShift Serverless 1.18.0, the issue is fixed and the initial messages are no longer lost. For more information about the issue, see Knowledgebase Article #6343981.

• Older versions of the Knative kn CLI might use older versions of the Knative Serving and Knative Eventing APIs. For example, version 0.23.2 of the kn CLI uses the v1alpha1 API version.

  On the other hand, newer releases of OpenShift Serverless might no longer support older API versions. For example, OpenShift Serverless 1.18.0 no longer supports version v1alpha1 of the kafkasources.sources.knative.dev API.

  Consequently, using an older version of the Knative kn CLI with a newer OpenShift Serverless might produce an error because the kn cannot find the outdated API. For example, version 0.23.2 of the kn CLI does not work with OpenShift Serverless 1.18.0.

  To avoid issues, use the latest kn CLI version available for your OpenShift Serverless release. For OpenShift Serverless 1.18.0, use Knative kn CLI 0.24.0.

• OpenShift Serverless now uses Knative Serving 0.23.0.
• OpenShift Serverless now uses Knative Eventing 0.23.0.
• OpenShift Serverless now uses Kourier 0.23.0.
• OpenShift Serverless now uses Knative kn CLI 0.23.0.
• OpenShift Serverless now uses Knative Kafka 0.23.0.
• The kn func CLI plug-in now uses func 0.17.0.

• In the upcoming OpenShift Serverless 1.19.0 release, the URL scheme of external routes will default to HTTPS for enhanced security.

  If you do not want this change to apply for your workloads, you can override the default setting before upgrading to 1.19.0, by adding the following YAML to your KnativeServing custom resource (CR):

  ...
  spec:
    config:
      network:
        defaultExternalScheme: "http"
  ...

• mTLS functionality is now Generally Available (GA).
• TypeScript templates are now available when you create a function using kn func.

• Changes to API versions in Knative Eventing 0.23.0:

  • The v1alpha1 version of the KafkaChannel API, which was deprecated in OpenShift Serverless version 1.14.0, has been removed. If the ChannelTemplateSpec parameters of your config maps contain references to this older version, you must update this part of the spec to use the correct API version.

• 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.16.0 release of the kn CLI, which uses version 0.22.0, with the 1.17.0 OpenShift Serverless release, which uses the 0.23.0 versions of the Knative Serving and Knative Eventing APIs, the CLI does not work because it continues to look for the outdated 0.22.0 API versions.

  Ensure that you are using the latest kn CLI version for your OpenShift Serverless release to avoid issues.

• Kafka channel metrics are not monitored or shown in the corresponding web console dashboard in this release. This is due to a breaking change in the Kafka dispatcher reconciling process.

• If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.

  As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.

  For more information about this issue and possible workarounds, see Knowledge Article #6343981.

• The Camel-K 1.4 release is not compatible with OpenShift Serverless version 1.17.0. This is because Camel-K 1.4 uses APIs that were removed in Knative version 0.23.0. There is currently no workaround available for this issue. If you need to use Camel-K 1.4 with OpenShift Serverless, do not upgrade to OpenShift Serverless version 1.17.0.

  Note

  The issue has been fixed, and Camel-K version 1.4.1 is compatible with OpenShift Serverless 1.17.0.

• OpenShift Serverless now uses Knative Serving 0.22.0.
• OpenShift Serverless now uses Knative Eventing 0.22.0.
• OpenShift Serverless now uses Kourier 0.22.0.
• OpenShift Serverless now uses Knative kn CLI 0.22.0.
• OpenShift Serverless now uses Knative Kafka 0.22.0.
• The kn func CLI plug-in now uses func 0.16.0.
• The kn func emit command has been added to the functions kn plug-in. You can use this command to send events to test locally deployed functions.

• You must upgrade OpenShift Container Platform to version 4.6.30, 4.7.11, or higher before upgrading to OpenShift Serverless 1.16.0.

• The AMQ Streams Operator might prevent the installation or upgrade of the OpenShift Serverless Operator. If this happens, the following error is thrown by Operator Lifecycle Manager (OLM):

  WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

  You can fix this issue by uninstalling the AMQ Streams Operator before installing or upgrading the OpenShift Serverless Operator. You can then reinstall the AMQ Streams Operator.

• If Service Mesh is enabled with mTLS, metrics for Knative Serving are disabled by default because Service Mesh prevents Prometheus from scraping metrics. For instructions on enabling Knative Serving metrics for use with Service Mesh and mTLS, see the "Integrating Service Mesh with OpenShift Serverless" section of the Serverless documentation.

• If you deploy Service Mesh CRs with the Istio ingress enabled, you might see the following warning in the istio-ingressgateway pod:

  2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

  Your Knative services might also not be accessible.

  You can use the following workaround to fix this issue by recreating the knative-local-gateway service:

  1. Delete the existing knative-local-gateway service in the istio-system namespace:

     $ oc delete services -n istio-system knative-local-gateway

  2. Create and apply a knative-local-gateway service that contains the following YAML:

     apiVersion: v1
     kind: Service
     metadata:
      name: knative-local-gateway
      namespace: istio-system
      labels:
        experimental.istio.io/disable-gateway-port-translation: "true"
     spec:
      type: ClusterIP
      selector:
        istio: ingressgateway
      ports:
        - name: http2
          port: 80
          targetPort: 8081

• If you have 1000 Knative services on a cluster, and then perform a reinstall or upgrade of Knative Serving, there is a delay when you create the first new service after the KnativeServing custom resource (CR) becomes Ready.

  The 3scale-kourier-control service reconciles all previously existing Knative services before processing the creation of a new service, which causes the new service to spend approximately 800 seconds in an IngressNotConfigured or Unknown state before the state updates to Ready.

• If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.

  As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.

  For more information about this issue and possible workarounds, see Knowledge Article #6343981.

• OpenShift Serverless now uses Knative Serving 0.21.0.
• OpenShift Serverless now uses Knative Eventing 0.21.0.
• OpenShift Serverless now uses Kourier 0.21.0.
• OpenShift Serverless now uses Knative kn CLI 0.21.0.
• OpenShift Serverless now uses Knative Kafka 0.21.1.
• OpenShift Serverless Functions is now available as a Technology Preview.

• If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.

  As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.

  For more information about this issue and possible workarounds, see Knowledge Article #6343981.

• OpenShift Serverless now uses Knative Serving 0.20.0.
• OpenShift Serverless uses Knative Eventing 0.20.0.
• OpenShift Serverless now uses Kourier 0.20.0.
• OpenShift Serverless now uses Knative kn CLI 0.20.0.
• OpenShift Serverless now uses Knative Kafka 0.20.0.

• Knative Kafka on OpenShift Serverless is now Generally Available (GA).

  Important

  Only the v1beta1 version of the APIs for KafkaChannel and KafkaSource objects on OpenShift Serverless are supported. Do not use the v1alpha1 version of these APIs, as this version is now deprecated.

• The Operator channel for installing and upgrading OpenShift Serverless has been updated to stable for OpenShift Container Platform 4.6 and newer versions.

• OpenShift Serverless is now supported on IBM Power Systems, IBM Z, and LinuxONE, except for the following features, which are not yet supported:

  • Knative Kafka functionality.
  • OpenShift Serverless Functions developer preview.

• Subscriptions for the Kafka channel sometimes fail to become marked as READY and remain in the SubscriptionNotMarkedReadyByChannel state. You can fix this by restarting the dispatcher for the Kafka channel.

• If you create a new subscription for a Kafka channel, or a new Kafka source, there might be a delay in the Kafka data plane becoming ready to dispatch messages after the newly created subscription or sink reports a ready status.

  As a result, messages that are sent during the time when the data plane is not reporting a ready status might not be delivered to the subscriber or sink.

  For more information about this issue and possible workarounds, see Knowledge Article #6343981.

• Rapidly deploying serverless containers.
• Automatically scaling pods.

• Channels and subscriptions, or
• Brokers and Triggers.

• Node.js
• Python
• Go
• Quarkus
• TypeScript

• Getting started with functions.

• Creating brokers

• No event persistence is available. If a pod goes down, events on that pod are lost.
• InMemoryChannel channels do not implement event ordering, so two events that are received in the channel at the same time can be delivered to a subscriber in any order.
• If a subscriber rejects an event, there are no re-delivery attempts by default. You can configure re-delivery attempts by modifying the delivery spec in the Subscription object.

• Create a channel.
• If you are a cluster administrator, you can configure default settings for channels. See Configuring channel defaults.

• OpenShift Serverless is supported for installation in a restricted network environment.
• OpenShift Serverless currently cannot be used in a multi-tenant configuration on a single cluster.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have logged in to the OpenShift Container Platform web console.

• After the OpenShift Serverless Operator is installed, you can install Knative Serving or install Knative Eventing.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have logged in to the OpenShift Container Platform web console.
• You have installed the OpenShift Serverless Operator.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have installed the OpenShift Serverless Operator.
• Install the OpenShift CLI (oc).

• If you want to use Knative event-driven architecture you can install Knative Eventing.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have logged in to the OpenShift Container Platform web console.
• You have installed the OpenShift Serverless Operator.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have installed the OpenShift Serverless Operator.
• Install the OpenShift CLI (oc).

• If you want to use Knative services you can install Knative Serving.

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• Install the OpenShift CLI (oc).

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• Install the OpenShift CLI (oc).

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• You have uninstalled Knative Serving and removed the OpenShift Serverless Operator.
• Install the OpenShift CLI (oc).

Procedure

• To delete the remaining OpenShift Serverless CRDs, enter the following command:

  $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

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.

  Important

  If libc is not available, you might see the following error when you run CLI commands:

  $ kn: No such file or directory

• If you want to use the verification steps for this procedure, you must install the OpenShift (oc) CLI.

Verification

• Run the following commands to check that the correct Knative CLI resources and route have been created:

  $ oc get ConsoleCLIDownload

  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

  $ oc get route -n openshift-serverless

  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

Prerequisites

• You have an active OpenShift Container Platform subscription on your Red Hat account.

Prerequisites

• If you are not using RHEL or Fedora, ensure that libc is installed in a directory on your library path.

  Important

  If libc is not available, you might see the following error when you run CLI commands:

  $ kn: No such file or directory

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>

  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 or yaml 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

    Resultant event in the YAML format

    data: {}
    datacontenttype: application/json
    id: 81a402a2-9c29-4c27-b8ed-246a253c9e58
    source: kn-event/v0.4.0
    specversion: "1.0"
    time: "2021-10-15T10:42:57.713226203Z"
    type: dev.knative.cli.plugin.event.generic

    Building a sample transaction event

    $ kn event build \
        --field operation.type=local-wire-transfer \
        --field operation.amount=2345.40 \
        --field operation.from=87656231 \
        --field operation.to=2344121 \
        --field automated=true \
        --field signature='FGzCPLvYWdEgsdpb3qXkaVp7Da0=' \
        --type org.example.bank.bar \
        --id $(head -c 10 < /dev/urandom | base64 -w 0) \
        --output json

    Resultant event in the JSON format

    {
      "specversion": "1.0",
      "id": "RjtL8UH66X+UJg==",
      "source": "kn-event/v0.4.0",
      "type": "org.example.bank.bar",
      "datacontenttype": "application/json",
      "time": "2021-10-15T10:43:23.113187943Z",
      "data": {
        "automated": true,
        "operation": {
          "amount": "2345.40",
          "from": 87656231,
          "to": 2344121,
          "type": "local-wire-transfer"
        },
        "signature": "FGzCPLvYWdEgsdpb3qXkaVp7Da0="
      }
    }

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>

  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.

  • 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

    $ kn event send \
        --field player.id=6354aa60-ddb1-452e-8c13-24893667de20 \
        --field player.game=2345 \
        --field points=456 \
        --type org.example.gaming.foo \
        --to-url http://ce-api.foo.example.com/

    The following example shows sending an event to an in-cluster resource:

    Example command

    $ kn event send \
        --type org.example.kn.ping \
        --id $(uuidgen) \
        --field event.type=test \
        --field event.data=98765 \
        --to Service:serving.knative.dev/v1:event-display

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

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>

  • Accepted runtime values include node, go, python, quarkus, and typescript.

  • Accepted template values include http and events.

    Example command

    $ kn func create -l typescript -t events examplefunc

    Example output

    Project path:  /home/user/demo/examplefunc
    Function name: examplefunc
    Runtime:       typescript
    Template:      events
    Writing events to /home/user/demo/examplefunc

  • 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

    Example output

    Project path:  /home/user/demo/examplefunc
    Function name: examplefunc
    Runtime:       node
    Template:      hello-world
    Writing events to /home/user/demo/examplefunc

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>]

  Example output

  Function deployed at: http://func.example.com

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

Procedure

• List existing functions:

  $ kn func list [-n <namespace> -p <path>]

  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

• List functions deployed as Knative services:

  $ kn service list -n <namespace>

  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

Procedure

• Describe a function:

  $ kn func info [-f <format> -n <namespace> -p <path>]

  Example command

  $ kn func info -p function/example-function

  Example output

  Function name:
    example-function
  Function is built in image:
    docker.io/user/example-function:latest
  Function is deployed as Knative Service:
    example-function
  Function is deployed in namespace:
    default
  Routes:
    http://example-function.default.apps.ci-ln-g9f36hb-d5d6b.origin-ci-int-aws.dev.rhcloud.com

Procedure

• Delete a function:

  $ kn func delete [<function_name> -n <namespace> -p <path>]

  • 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 the func.yaml file.

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>

  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

    Example output

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

Prerequisites

• OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• You have installed the Knative (kn) CLI.

Prerequisites

• OpenShift Serverless Operator and Knative Serving 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.
• Install the OpenShift CLI (oc).

Prerequisites

• OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• You have installed the oc CLI.
• You have created a Knative service.

Prerequisites

• Install the OpenShift CLI (oc).

Prerequisites

• OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• Install the OpenShift CLI (oc).
• You have created a Knative service.

Prerequisites

• Install the OpenShift CLI (oc).
• OpenShift Serverless Operator and Knative Serving are installed on your cluster.

Prerequisites

• OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• Before you can use init containers for Knative services, an administrator must add the kubernetes.podspec-init-containers flag to the KnativeServing custom resource (CR). See the OpenShift Serverless "Global configuration" documentation for more information.

Procedure

• Add the initContainers spec to a Knative Service object:

  Example service spec

  apiVersion: serving.knative.dev/v1
  kind: Service
  ...
  spec:
    template:
      spec:
        initContainers:
          - imagePullPolicy: IfNotPresent 1
            image: <image_uri> 2
            volumeMounts: 3
              - name: data
                mountPath: /data
  ...

  1

  The image pull policy when the image is downloaded.

  2

  The URI for the init container image.

  3

  The location where volumes are mounted within the container file system.

• A soft limit is a targeted requests limit, rather than a strictly enforced bound. For example, if there is a sudden burst of traffic, the soft limit target can be exceeded.

• A hard limit is a strictly enforced upper bound requests limit. If concurrency reaches the hard limit, surplus requests are buffered and must wait until there is enough free capacity to execute the requests.

  Important

  Using a hard limit configuration is only recommended if there is a clear use case for it with your application. Having a low, hard limit specified may have a negative impact on the throughput and latency of an application, and might cause cold starts.

Prerequisites

• The OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• You have installed the Knative (kn) CLI.
• You have created a Knative service.

Procedure

• Specify the revision of your service and what percentage of traffic you want to route to it by using the --traffic tag with a standard kn service update command:

  Example command

  $ kn service update <service_name> --traffic <revision>=<percentage>

  Where:

  • <service_name> is the name of the Knative service that you are configuring traffic routing for.
  • <revision> is the revision that you want to configure to receive a percentage of traffic. You can either specify the name of the revision, or a tag that you assigned to the revision by using the --tag flag.
  • <percentage> is the percentage of traffic that you want to send to the specified revision.

• Optional: The --traffic flag can be specified multiple times in one command. For example, if you have a revision tagged as @latest and a revision named stable, you can specify the percentage of traffic that you want to split to each revision as follows:

  Example command

  $ kn service update example-service --traffic @latest=20,stable=80

  If you have multiple revisions and do not specify the percentage of traffic that should be split to the last revision, the --traffic flag can calculate this automatically. For example, if you have a third revision named example, and you use the following command:

  Example command

  $ kn service update example-service --traffic @latest=10,stable=60

  The remaining 30% of traffic is split to the example revision, even though it was not specified.

Prerequisites

• The OpenShift Serverless Operator and Knative Serving are installed on your cluster.
• You have logged in to the OpenShift Container Platform web console.

Prerequisites

• The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
• Install the OpenShift CLI (oc).

Prerequisites

• You must have the OpenShift Serverless Operator and Knative Serving installed on your OpenShift Container Platform cluster.
• Install the OpenShift CLI (oc).

Prerequisites

• The OpenShift Serverless Operator and Knative Serving component must be installed on your OpenShift Container Platform cluster.
• Install the OpenShift CLI (oc).

Prerequisites

• The OpenShift Serverless Operator and Knative Serving are installed on the cluster.
• You have created a Knative service.

Procedure

• Set the visibility for your service by adding the networking.knative.dev/visibility=cluster-local label:

  $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

Verification

• Check that the URL for your service is now in the format http://<service_name>.<namespace>.svc.cluster.local, by entering the following command and reviewing the output:

  $ oc get ksvc

  Example output

  NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
  hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

Prerequisites

• The OpenShift Serverless Operator, Knative Serving, and Knative Eventing are installed on your OpenShift Container Platform cluster.
• You have logged in to the web console and are in the Developer perspective.
• 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 created a sink, such as a Knative service, channel or broker.

Prerequisites

• The OpenShift Serverless Operator, Knative Eventing, and Knative Kafka are installed on your OpenShift Container Platform cluster.
• Kafka broker is enabled for use on your cluster, and you have created a Kafka broker.
• 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 (oc) CLI.

Prerequisites

• The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
• You have installed the Knative (kn) CLI.

Prerequisites

• You have logged in to the OpenShift Container Platform web console.
• The OpenShift Serverless Operator and Knative Eventing are installed on your OpenShift Container Platform 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.

Prerequisites

• The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
• You have installed the Knative (kn) CLI.

Prerequisites

• You have logged in to the OpenShift Container Platform web console.
• 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).

Verification

• After you have created the API server source, you will see it connected to the service it is sinked to in the Topology view.

  

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.

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 created the default broker in the same namespace as the one defined in the API server source YAML file.
• Install the OpenShift CLI (oc).

Prerequisites

• You have logged in to the OpenShift Container Platform web console.
• The OpenShift Serverless Operator, Knative Serving 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.

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

Deleting the ping source

• Delete the ping source:

  $ kn delete pingsources.sources.knative.dev <ping_source_name>

Prerequisites

• The OpenShift Serverless Operator, Knative Serving and Knative Eventing are installed on the cluster.
• Install the OpenShift CLI (oc).
• 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.

Deleting the ping source

• Delete the ping source:

  $ oc delete -f <filename>

  Example command

  $ oc delete -f ping-source.yaml

Prerequisites

• You have logged in to the OpenShift Container Platform web console.
• The OpenShift Serverless Operator and Knative Eventing are installed on your OpenShift Container Platform 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.

Verification

• Confirm that the channel now exists by navigating to the Topology page.

  

Prerequisites

• The OpenShift Serverless Operator 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.

Procedure

• Create a channel:

  $ kn channel create <channel_name> --type <channel_type>

  The channel type is optional, but where specified, must be given in the format Group:Version:Kind. For example, you can create an InMemoryChannel object:

  $ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

  Example output

  Channel 'mychannel' created in namespace 'default'.

Verification

• To confirm that the channel now exists, list the existing channels and inspect the output:

  $ kn channel list

  Example output

  kn channel list
  NAME        TYPE              URL                                                     AGE   READY   REASON
  mychannel   InMemoryChannel   http://mychannel-kn-channel.default.svc.cluster.local   93s   True

Deleting a channel

• Delete a channel:

  $ kn channel delete <channel_name>

Prerequisites

• The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
• Install the OpenShift CLI (oc).
• 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.

Prerequisites

• The OpenShift Serverless Operator, Knative Eventing, and the KnativeKafka custom resource are installed on your OpenShift Container Platform cluster.
• Install the OpenShift CLI (oc).
• 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.

• After you have created a channel, create a subscription that allows event sinks to subscribe to channels and receive events.
• Configure event delivery parameters that are applied in cases where an event fails to be delivered to an event sink. See Examples of configuring event delivery parameters.

Prerequisites

• The OpenShift Serverless Operator, Knative Serving, and Knative Eventing are installed on your OpenShift Container Platform cluster.
• You have logged in to the web console.
• You have created an event sink, such as a Knative service, and a channel.
• 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.

Verification

• After the subscription has been created, you can see it represented as a line that connects the channel to the service in the Topology view:

  

Prerequisites

• The OpenShift Serverless Operator and Knative Eventing are installed on the cluster.
• Install the OpenShift CLI (oc).
• 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 Subscription object:

  • Create a YAML file and copy the following sample code into it:

    apiVersion: messaging.knative.dev/v1beta1
    kind: Subscription
    metadata:
      name: my-subscription 1
      namespace: default
    spec:
      channel: 2
        apiVersion: messaging.knative.dev/v1beta1
        kind: Channel
        name: example-channel
      delivery: 3
        deadLetterSink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: error-handler
      subscriber: 4
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display

    1

    Name of the subscription.

    2

    Configuration settings for the channel that the subscription connects to.

    3

    Configuration settings for event delivery. This tells the subscription what happens to events that cannot be delivered to the subscriber. When this is configured, events that failed to be consumed are sent to the deadLetterSink. The event is dropped, no re-delivery of the event is attempted, and an error is logged in the system. The deadLetterSink value must be a Destination.

    4

    Configuration settings for the subscriber. This is the event sink that events are delivered to from the channel.

  • Apply the YAML file:

    $ oc apply -f <filename>

Prerequisites

• The OpenShift Serverless Operator and Knative Eventing are installed on your 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

• Create a subscription to connect a sink to a channel:

  $ kn subscription create <subscription_name> \
    --channel <group:version:kind>:<channel_name> \ 1
    --sink <sink_prefix>:<sink_name> \ 2
    --sink-dead-letter <sink_prefix>:<sink_name> 3

  1

  --channel specifies the source for cloud events that should be processed. You must provide the channel name. If you are not using the default InMemoryChannel channel that is backed by the Channel custom resource, you must prefix the channel name with the <group:version:kind> for the specified channel type. For example, this will be messaging.knative.dev:v1beta1:KafkaChannel for a Kafka backed channel.

  2

  --sink specifies the target destination to which the event should be delivered. By default, the <sink_name> is interpreted as a Knative service of this name, in the same namespace as the subscription. You can specify the type of the sink by using one of the following prefixes:

  ksvc

  A Knative service.

  channel

  A channel that should be used as destination. Only default channel types can be referenced here.

  broker

  An Eventing broker.

  3

  Optional: --sink-dead-letter is an optional flag that can be used to specify a sink which events should be sent to in cases where events fail to be delivered. For more information, see the OpenShift Serverless Event delivery documentation.

  Example command

  $ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display

  Example output

  Subscription 'mysubscription' created in namespace 'default'.

Verification

• To confirm that the channel is connected to the event sink, or subscriber, by a subscription, list the existing subscriptions and inspect the output:

  $ kn subscription list

  Example output

  NAME            CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
  mysubscription   Channel:mychannel   ksvc:event-display                              True

Deleting a subscription

• Delete a subscription:

  $ kn subscription delete <subscription_name>

Prerequisites

• You have installed the Knative (kn) CLI.
• You have created a subscription in your cluster.

Procedure

• Describe a subscription:

  $ kn subscription describe <subscription_name>

  Example output

  Name:            my-subscription
  Namespace:       default
  Annotations:     messaging.knative.dev/creator=openshift-user, messaging.knative.dev/lastModifier=min ...
  Age:             43s
  Channel:         Channel:my-channel (messaging.knative.dev/v1)
  Subscriber:
    URI:           http://edisplay.default.example.com
  Reply:
    Name:          default
    Resource:      Broker (eventing.knative.dev/v1)
  DeadLetterSink:
    Name:          my-sink
    Resource:      Service (serving.knative.dev/v1)
  
  Conditions:
    OK TYPE                  AGE REASON
    ++ Ready                 43s
    ++ AddedToChannel        43s
    ++ ChannelReady          43s
    ++ ReferencesResolved    43s

Prerequisites

• You have installed the Knative (kn) CLI.

Procedure

• List subscriptions on your cluster:

  $ kn subscription list

  Example output

  NAME             CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
  mysubscription   Channel:mychannel   ksvc:event-display                              True

Prerequisites

• You have installed the Knative (kn) CLI.
• You have created a subscription.

Procedure

• Update a subscription:

  $ kn subscription update <subscription_name> \
    --sink <sink_prefix>:<sink_name> \ 1
    --sink-dead-letter <sink_prefix>:<sink_name> 2

  1

  --sink specifies the updated target destination to which the event should be delivered. You can specify the type of the sink by using one of the following prefixes:

  ksvc

  A Knative service.

  channel

  A channel that should be used as destination. Only default channel types can be referenced here.

  broker

  An Eventing broker.

  2

  Optional: --sink-dead-letter is an optional flag that can be used to specify a sink which events should be sent to in cases where events fail to be delivered. For more information, see the OpenShift Serverless Event delivery documentation.

  Example command

  $ kn subscription update mysubscription --sink ksvc:event-display