Chapter 1. OpenShift Serverless Release Notes

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.

spec:
  template:
    metadata:
      annotations:
        queue.sidecar.serving.knative.dev/resourcePercentage: "10" 

spec:
  template:
    metadata:
      annotations:
        queue.sidecar.serving.knative.dev/resourcePercentage: "10" 

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

  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.

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.

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.

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.

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.