Release notes

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 plug-in now uses func 1.7.0.

Integrated development environment (IDE) plug-ins 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.

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.

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.

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.

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

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

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.

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.

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

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

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

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

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

buildEnvs: []

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

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

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.

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

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

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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:

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.