1.7. Release Notes for Red Hat OpenShift Serverless 1.7.0

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

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

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