spec:
template:
metadata:
annotations:
queue.sidecar.serving.knative.dev/resourcePercentage: "10" (1)
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/. |
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.
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.
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.
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.
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.
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" (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.
As a cluster administrator, you can label the namespace by entering the following command:
$ oc label namespace <namespace> bindings.knative.dev/include=true
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"
This release of OpenShift Serverless addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
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.
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.
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
.
OpenShift Serverless is based on the open source Knative project.
For details about the latest Knative Serving release, see the Knative Serving releases page.
For details about the latest Knative Serving Operator release, see the Knative Serving Operator releases page.
For details about the latest Knative CLI release, see the Knative CLI releases page.
For details about the latest Knative Eventing release, see the Knative Eventing releases page.