Serverless

• OpenShift Serverless now uses Knative Serving 1.7.
• OpenShift Serverless now uses Knative Eventing 1.7.
• OpenShift Serverless now uses Kourier 1.7.
• OpenShift Serverless now uses Knative (

  kn

  ) CLI 1.7.
• OpenShift Serverless now uses Knative Kafka 1.7.
• The

  kn func

  CLI plug-in now uses

  func

  1.9.1 version.
• Node.js and TypeScript runtimes for OpenShift Serverless Functions are now Generally Available (GA).
• Python runtime for OpenShift Serverless Functions is now available as a Technology Preview.
• Multi-container support for Knative Serving is now available as a Technology Preview. This feature allows you to use a single Knative service to deploy a multi-container pod.

• In OpenShift Serverless 1.29 or later, the following components of Knative Eventing will be scaled down from two pods to one:

  • imc-controller

  • imc-dispatcher

  • mt-broker-controller

  • mt-broker-filter

  • mt-broker-ingress

• The

  serverless.openshift.io/enable-secret-informer-filtering

  annotation for the Serving CR is now deprecated. The annotation is valid only for Istio, and not for Kourier.

  With OpenShift Serverless 1.28, the OpenShift Serverless Operator allows injecting the environment variable

  ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID

  for both

  net-istio

  and

  net-kourier

  .

  To prevent problems when upgrading from OpenShift Serverless 1.28 to some future version, users must annotate their secrets with

  networking.internal.knative.dev/certificate-uid:some_cuid

  .

• Currently, runtimes for Python are not supported for OpenShift Serverless Functions on IBM Power, IBM zSystems, and IBM® LinuxONE.

  Node.js, TypeScript, and Quarkus functions are supported on these architectures.

• On the Windows platform, Python functions cannot be locally built, run, or deployed using the Source-to-Image builder due to the

  app.sh

  file permissions.

  To work around this problem, use the Windows Subsystem for Linux.

• OpenShift Serverless now uses Knative Serving 1.6.
• OpenShift Serverless now uses Knative Eventing 1.6.
• OpenShift Serverless now uses Kourier 1.6.
• OpenShift Serverless now uses Knative (

  kn

  ) CLI 1.6.
• OpenShift Serverless now uses Knative Kafka 1.6.
• The

  kn func

  CLI plug-in now uses

  func

  1.8.1.
• Namespace-scoped brokers are now available as a Technology Preview. Such brokers can be used, for instance, to implement role-based access control (RBAC) policies.

• KafkaSink

  now uses the

  CloudEvent

  binary content mode by default. The binary content mode is more efficient than the structured mode because it uses headers in its body instead of a

  CloudEvent

  . For example, for the HTTP protocol, it uses HTTP headers.
• You can now use the gRPC framework over the HTTP/2 protocol for external traffic using the OpenShift Route on OpenShift Container Platform 4.10 and later. This improves efficiency and speed of the communications between the client and server.
• API version

  v1alpha1

  of the Knative Operator Serving and Eventings CRDs is deprecated in 1.27. It will be removed in future versions. Red Hat strongly recommends to use the

  v1beta1

  version instead. This does not affect the existing installations, because CRDs are updated automatically when upgrading the Serverless Operator.
• The delivery timeout feature is now enabled by default. It allows you to specify the timeout for each sent HTTP request. The feature remains a Technology Preview.

• Previously, Knative services sometimes did not get into the

  Ready

  state, reporting waiting for the load balancer to be ready. This issue has been fixed.

• Integrating OpenShift Serverless with Red Hat OpenShift Service Mesh causes the

  net-kourier

  pod to run out of memory on startup when too many secrets are present on the cluster.

• Namespace-scoped brokers might leave

  ClusterRoleBindings

  in the user namespace even after deletion of namespace-scoped brokers.

  If this happens, delete the

  ClusterRoleBinding

  named

  rbac-proxy-reviews-prom-rb-knative-kafka-broker-data-plane-{{.Namespace}}

  in the user namespace.

• If you use

  net-istio

  for Ingress and enable mTLS via SMCP using

  security.dataPlane.mtls: true

  , Service Mesh deploys

  DestinationRules

  for the

  *.local

  host, which does not allow

  DomainMapping

  for OpenShift Serverless.

  To work around this issue, enable mTLS by deploying

  PeerAuthentication

  instead of using

  security.dataPlane.mtls: true

  .

• OpenShift Serverless Functions with Quarkus is now GA.
• OpenShift Serverless now uses Knative Serving 1.5.
• OpenShift Serverless now uses Knative Eventing 1.5.
• OpenShift Serverless now uses Kourier 1.5.
• OpenShift Serverless now uses Knative (

  kn

  ) CLI 1.5.
• OpenShift Serverless now uses Knative Kafka 1.5.
• OpenShift Serverless now uses Knative Operator 1.3.
• The

  kn func

  CLI plugin now uses

  func

  1.8.1.
• Persistent volume claims (PVCs) are now GA. PVCs provide permanent data storage for your Knative services.

• The new trigger filters feature is now available as a Developer Preview. It allows users to specify a set of filter expressions, where each expression evaluates to either true or false for each event.

  To enable new trigger filters, add the

  new-trigger-filters: enabled

  entry in the section of the

  KnativeEventing

  type in the operator config map:

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...
  ...
  spec:
    config:
      features:
        new-trigger-filters: enabled
  ...

• Knative Operator 1.3 adds the updated

  v1beta1

  version of the API for

  operator.knative.dev

  .

  To update from

  v1alpha1

  to

  v1beta1

  in your

  KnativeServing

  and

  KnativeEventing

  custom resource config maps, edit the

  apiVersion

  key:

  Example KnativeServing custom resource config map

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  ...

  Example KnativeEventing custom resource config map

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeEventing
  ...

• Previously, Federal Information Processing Standards (FIPS) mode was disabled for Kafka broker, Kafka source, and Kafka sink. This has been fixed, and FIPS mode is now available.

• If you use

  net-istio

  for Ingress and enable mTLS via SMCP using

  security.dataPlane.mtls: true

  , Service Mesh deploys

  DestinationRules

  for the

  *.local

  host, which does not allow

  DomainMapping

  for OpenShift Serverless.

  To work around this issue, enable mTLS by deploying

  PeerAuthentication

  instead of using

  security.dataPlane.mtls: true

  .

• OpenShift Serverless now uses Knative Serving 1.4.
• OpenShift Serverless now uses Knative Eventing 1.4.
• OpenShift Serverless now uses Kourier 1.4.
• OpenShift Serverless now uses Knative (

  kn

  ) CLI 1.4.
• OpenShift Serverless now uses Knative Kafka 1.4.
• The

  kn func

  CLI plugin now uses

  func

  1.7.0.
• Integrated development environment (IDE) plugins for creating and deploying functions are now available for Visual Studio Code and IntelliJ.

• Knative Kafka broker is now GA. Knative Kafka broker is a highly performant implementation of the Knative broker API, directly targeting Apache Kafka.

  It is recommended to not use the MT-Channel-Broker, but the Knative Kafka broker instead.

• Knative Kafka sink is now GA. A

  KafkaSink

  takes a

  CloudEvent

  and sends it to an Apache Kafka topic. Events can be specified in either structured or binary content modes.
• Enabling TLS for internal traffic is now available as a Technology Preview.

• Previously, Knative Serving had an issue where the readiness probe failed if the container was restarted after a liveness probe fail. This issue has been fixed.

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

  SinkBinding

  object does not support custom revision names for services.

• The Knative Serving Controller pod adds a new informer to watch secrets in the cluster. The informer includes the secrets in the cache, which increases memory consumption of the controller pod.

  If the pod runs out of memory, you can work around the issue by increasing the memory limit for the deployment.

• If you use

  net-istio

  for Ingress and enable mTLS via SMCP using

  security.dataPlane.mtls: true

  , Service Mesh deploys

  DestinationRules

  for the

  *.local

  host, which does not allow

  DomainMapping

  for OpenShift Serverless.

  To work around this issue, enable mTLS by deploying

  PeerAuthentication

  instead of using

  security.dataPlane.mtls: true

  .

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

• If you use

  net-istio

  for Ingress and enable mTLS via SMCP using

  security.dataPlane.mtls: true

  , Service Mesh deploys

  DestinationRules

  for the

  *.local

  host, which does not allow

  DomainMapping

  for OpenShift Serverless.

  To work around this issue, enable mTLS by deploying

  PeerAuthentication

  instead of using

  security.dataPlane.mtls: true

  .

• 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 plugin 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/v1beta1
  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.

• If you use

  net-istio

  for Ingress and enable mTLS via SMCP using

  security.dataPlane.mtls: true

  , Service Mesh deploys

  DestinationRules

  for the

  *.local

  host, which does not allow

  DomainMapping

  for OpenShift Serverless.

  To work around this issue, enable mTLS by deploying

  PeerAuthentication

  instead of using

  security.dataPlane.mtls: true

  .

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

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

• Rapidly deploying serverless containers.
• Automatically scaling pods.

• Channels and subscriptions, or
• Brokers and Triggers.

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

Prerequisites

• You have access to an OpenShift Container Platform account with cluster administrator access.
• Your cluster has the Marketplace capability enabled or the Red Hat Operator catalog source configured manually.
• You have logged in to the OpenShift Container Platform cluster.

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