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
knCLI 0.13.2. -
Knative
knCLI downloads now support disconnected, or restricted network installations. -
Knative
knCLI 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, andkourier-gatewaycomponents.If you have installed a previous version of OpenShift Serverless, after the
KnativeServingcustom resource (CR) is updated, the deployment will default to a HA configuration withKnativeServing.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
trustedCAsetting 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
KnativeServingCRs without specifying an API group, for example, by using the commandoc 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-dispatcherpod may not start. This is due to the pod’s defaultresourcessettings. As a work-around, you can remove theresourcessettings. 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
KnativeServingCR becomes Ready.The
3scale-kourier-controlcontroller reconciles all previous Knative services before processing the creation of a new service, which causes the new service to spend approximately 800 seconds in anIngressNotConfiguredorUnknownstate before the state will update toReady.
