×

For an overview of OpenShift Serverless functionality, see Getting started with OpenShift Serverless.

Knative Eventing is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview/.

Release Notes for Red Hat OpenShift Serverless 1.10.1

This release of OpenShift Serverless addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.

Fixed issues

  • A universal base image (UBI) has been upgraded from ubi8-minimal-container-8.2-349 in 1.10.0 to ubi8-minimal-container-8.3-230 in this release.

Release Notes for Red Hat OpenShift Serverless 1.10.0

New features

  • OpenShift Serverless now uses Knative Operator 0.16.0.

  • OpenShift Serverless now uses Knative Serving 0.16.0.

  • OpenShift Serverless uses Knative Eventing 0.16.0.

  • OpenShift Serverless now uses Kourier 0.16.0.

  • OpenShift Serverless now uses Knative kn CLI 0.16.1.

  • The annotation knative-eventing-injection=enabled that was previously used to label namespaces for broker creation is now deprecated. The new annotation is eventing.knative.dev/injection=enabled. For more information, see the documentation on Event delivery workflows using brokers and triggers.

  • Multi-container support is now available on Knative as a Technology Preview feature. You can enable multi-container support in the config-features config map. For more information, see the Knative documentation.

Fixed issues

  • In previous releases, Knative Serving had a fixed, minimum CPU request of 25m for queue-proxy. If your cluster had any value set that conflicted with this, for example, if you had set a minimum CPU request for defaultRequest of more than 25m, the Knative service failed to deploy. This issue is fixed in 1.10.0.

Release Notes for Red Hat OpenShift Serverless 1.9.0

New features

  • OpenShift Serverless now uses Knative Operator 0.15.2. The Knative Serving and Knative Eventing Operators are now merged into a common Operator.

  • OpenShift Serverless now uses Knative Serving 0.15.2.

  • OpenShift Serverless now uses Knative kn CLI 0.15.2.

  • OpenShift Serverless uses Knative Eventing 0.15.2.

  • OpenShift Serverless now uses Kourier 0.15.0.

  • OpenShift Serverless now supports some integrated Red Hat OpenShift Service Mesh features, including enabling sidecars, and JSON Web Token (JWT) authentication. Supported features are documented in the Networking guide.

Known issues

  • After deleting the KnativeEventing custom resource (CR), the v0.15.0-upgrade-xr55x and storage-version-migration-eventing-99c7q pods remain on the cluster and show a Completed status. You can delete the namespace where the KnativeEventing CR was installed to completely remove these pods.

Release Notes for Red Hat OpenShift Serverless 1.8.0

New features

  • OpenShift Serverless now uses Knative Serving 0.14.1.

  • OpenShift Serverless now uses Knative Serving Operator 0.14.0.

  • OpenShift Serverless now uses Knative kn CLI 0.14.0.

  • OpenShift Serverless uses Knative Eventing 0.14.2.

  • OpenShift Serverless now uses Knative Eventing Operator 0.14.0.

  • OpenShift Serverless now uses Kourier 0.14.1.

Known issues

  • Knative Serving has a fixed, minimum CPU request of 25m for the queue-proxy setting. If your cluster has any value set that conflicts with this, for example, if you have set a minimum CPU request for defaultRequest of more than 25m, the Knative service fails to deploy. As a workaround, you can configure the resourcePercentage annotation individually for your Knative services.

    Example resourcePercentage configuration
    spec:
      template:
        metadata:
          annotations:
            queue.sidecar.serving.knative.dev/resourcePercentage: "10" (1)
    1 queue.sidecar.serving.knative.dev/resourcePercentage is the percentage of user container resources to be used for queue-proxy. This can be between a range of 0.1 - 100.
  • On OpenShift Container Platform 4.5 and newer versions, deploying a Knative service with traffic distribution shows an invalid URL for the general service address in the Developer perspective of the web console.

    The correct URL is shown in YAML resources and CLI command outputs.

  • If you use a ping source with OpenShift Serverless, after you uninstall and delete all other Knative Eventing components, the pingsource-jobrunner Deployment resource is not deleted.

  • If you delete a sink before you delete the sink binding connected to it, the SinkBinding object deletion might hang.

    As a workaround, you can edit the SinkBinding object and remove the finalizer that causes the hanging:

      finalizers:
       - sinkbindings.sources.knative.dev
  • The sink binding behavior has changed in OpenShift Serverless 1.8.0, which breaks backwards compatibility.

    To use sink binding, cluster administrators must now label the namespace configured in the SinkBinding object with bindings.knative.dev/include:"true".

    Resources configured in the SinkBinding object must also be labeled with bindings.knative.dev/include:"true"; however, this task can be completed by any OpenShift Serverless user.

    1. As a cluster administrator, you can label the namespace by entering the following command:

      $ oc label namespace <namespace> bindings.knative.dev/include=true
    2. Users must manually add a bindings.knative.dev/include=true label to resources.

      For example, to add this label to a CronJob object, add the following lines to the Job resource YAML definition:

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"

Release Notes for Red Hat OpenShift Serverless 1.7.2

This release of OpenShift Serverless addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.

Fixed issues

  • In previous versions of OpenShift Serverless, KnativeServing custom resources showed a status of Ready, even if Kourier did not deploy. This bug is fixed in OpenShift Serverless 1.7.2.

Release Notes for Red Hat OpenShift Serverless 1.7.1

New features

  • OpenShift Serverless now uses Knative Serving 0.13.3.

  • OpenShift Serverless now uses Knative Serving Operator 0.13.3.

  • OpenShift Serverless now uses Knative kn CLI 0.13.2.

  • OpenShift Serverless uses Knative Eventing 0.13.0.

  • OpenShift Serverless now uses Knative Eventing Operator 0.13.3.

Fixed issues

  • In OpenShift Serverless 1.7.0, routes were reconciled continuously when this was not required. This bug is fixed in OpenShift Serverless 1.7.1.

Release Notes for Red Hat OpenShift Serverless 1.7.0

New features

  • OpenShift Serverless 1.7.0 is now Generally Available (GA) on OpenShift Container Platform 4.3 and newer versions. In previous versions, OpenShift Serverless was a Technology Preview.

  • OpenShift Serverless now uses Knative Serving 0.13.2.

  • OpenShift Serverless now uses Knative Serving Operator 0.13.2.

  • OpenShift Serverless now uses Knative kn CLI 0.13.2.

  • Knative kn CLI downloads now support disconnected, or restricted network installations.

  • Knative kn CLI libraries are now signed by Red Hat.

  • Knative Eventing is now available as a Technology Preview with OpenShift Serverless. OpenShift Serverless uses Knative Eventing 0.13.2.

Before upgrading to the latest Serverless release, you must remove the community Knative Eventing Operator if you have previously installed it. Having the Knative Eventing Operator installed will prevent you from being able to install the latest Technology Preview version of Knative Eventing that is included with OpenShift Serverless 1.7.0.

  • High availability (HA) is now enabled by default for the autoscaler-hpa, controller, activator , kourier-control, and kourier-gateway components.

    If you have installed a previous version of OpenShift Serverless, after the KnativeServing custom resource (CR) is updated, the deployment will default to a HA configuration with KnativeServing.spec.high-availability.replicas = 2.

    You can disable HA for these components by completing the procedure in the Configuring high availability components documentation.

  • OpenShift Serverless now supports the trustedCA setting in the OpenShift Container Platform cluster-wide proxy, and is now fully compatible with OpenShift Container Platform proxy settings.

  • OpenShift Serverless now supports HTTPS by using the wildcard certificate that is registered for OpenShift Container Platform routes. For more information on HTTP and HTTPS on Knative Serving, see the documentation on Verifying your serverless application deployment.

Fixed issues

  • In previous versions, requesting KnativeServing CRs without specifying an API group, for example, by using the command oc get knativeserving -n knative-serving, occasionally caused errors. This issue is fixed in OpenShift Serverless 1.7.0.

  • In previous versions, the Knative Serving controller was not notified when a new service CA certificate was generated due to service CA certificate rotation. New revisions created after a service CA certificate rotation were failing with the error:

    Revision "foo-1" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/eap/eap-app": failed to resolve image to digest: failed to fetch image information: Get https://image-registry.openshift-image-registry.svc:5000/v2/: x509: certificate signed by unknown authority.

    The OpenShift Serverless Operator now restarts the Knative Serving controller whenever a new service CA certificate is generated, which ensures that the controller is always configured to use the current service CA certificate. For more information, see the OpenShift Container Platform documentation on Securing service traffic using service serving certificate secrets under Authentication.

Known issues

  • When upgrading from OpenShift Serverless 1.6.0 to 1.7.0, support for HTTPS requires a change to the format of routes. Knative services created on OpenShift Serverless 1.6.0 are no longer reachable at the old format URLs. You must retrieve the new URL for each service after upgrading OpenShift Serverless. For more information, see the documentation on Upgrading OpenShift Serverless.

  • If you are using Knative Eventing on an Azure cluster, it is possible that the imc-dispatcher pod may not start. This is due to the pod’s default resources settings. As a work-around, you can remove the resources settings.

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

    The 3scale-kourier-control controller reconciles all previous 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 will update to Ready.

Additional resources

OpenShift Serverless is based on the open source Knative project.