1. Documentation
    2. Page history / Open an issue
×

OpenShift Serverless Release Notes

Release Notes for Red Hat OpenShift Serverless 1.16.0

New features

  • OpenShift Serverless now uses Knative Serving 0.22.0.

  • OpenShift Serverless now uses Knative Eventing 0.22.0.

  • OpenShift Serverless now uses Kourier 0.22.0.

  • OpenShift Serverless now uses Knative kn CLI 0.22.0.

  • OpenShift Serverless now uses Knative Kafka 0.22.0.

  • The kn func CLI plug-in now uses func 0.16.0.

  • The kn func emit command has been added to the functions kn plug-in. You can use this command to send events to test locally deployed functions.

Known issues

  • The AMQ Streams Operator might prevent the installation or upgrade of the OpenShift Serverless Operator. If this happens, the following error is thrown by Operator Lifecycle Manager (OLM):

    WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

    You can fix this issue by uninstalling the AMQ Streams Operator before installing or upgrading the OpenShift Serverless Operator. You can then reinstall the AMQ Streams Operator.

  • If Service Mesh is enabled with mTLS, metrics for Knative Serving are disabled by default because Service Mesh prevents Prometheus from scraping metrics.

    If you want to enable Knative Serving metrics for use with Service Mesh and mTLS, you must complete the following steps:

    1. Specify prometheus as the metrics.backend-destination in the observability spec of the Knative Serving custom resource (CR):

      apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    observability:
      metrics.backend-destination: "prometheus"

      This step prevents metrics from being disabled by default.

    2. Apply the following network policy to allow traffic from the Prometheus namespace:

      apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring-ns
  namespace: knative-serving
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: "openshift-monitoring"
  podSelector: {}
  policyTypes:
  - Ingress

    3. Modify and reapply the default Service Mesh control plane in the istio-system namespace, so that it includes the following spec:

      spec:
  proxy:
    networking:
      trafficControl:
        inbound:
          excludedPorts:
          - 8444

  • If you deploy Service Mesh CRs with the Istio ingress enabled, you might see the following warning in the istio-ingressgateway pod:

    2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

    Your Knative services might also not be accessible.

    You can use the following workaround to fix this issue by recreating the knative-local-gateway service:

    1. Delete the existing knative-local-gateway service in the istio-system namespace:

      $ oc delete services -n istio-system knative-local-gateway

    2. Create and apply a knative-local-gateway service that contains the following YAML:

      apiVersion: v1
kind: Service
metadata:
 name: knative-local-gateway
 namespace: istio-system
 labels:
   experimental.istio.io/disable-gateway-port-translation: "true"
spec:
 type: ClusterIP
 selector:
   istio: ingressgateway
 ports:
   - name: http2
     port: 80
     targetPort: 8081

  • If you have 1000 Knative services on a cluster, and then perform a reinstall or upgrade of Knative Serving, there is a delay when you create the first new service after the KnativeServing custom resource definition (CRD) becomes Ready.

    The 3scale-kourier-control service reconciles all previously existing 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 updates to Ready.

Release Notes for Red Hat OpenShift Serverless 1.15.0

New features

  • OpenShift Serverless now uses Knative Serving 0.21.0.

  • OpenShift Serverless now uses Knative Eventing 0.21.0.

  • OpenShift Serverless now uses Kourier 0.21.0.

  • OpenShift Serverless now uses Knative kn CLI 0.21.0.

  • OpenShift Serverless now uses Knative Kafka 0.21.1.

  • OpenShift Serverless Functions is now available as a Technology Preview.

The serving.knative.dev/visibility label, which was previously used to create private services, is now deprecated. You must update existing services to use the networking.knative.dev/visibility label instead.

Release Notes for Red Hat OpenShift Serverless 1.14.0

New features

  • OpenShift Serverless now uses Knative Serving 0.20.0.

  • OpenShift Serverless uses Knative Eventing 0.20.0.

  • OpenShift Serverless now uses Kourier 0.20.0.

  • OpenShift Serverless now uses Knative kn CLI 0.20.0.

  • OpenShift Serverless now uses Knative Kafka 0.20.0.

  • Knative Kafka on OpenShift Serverless is now Generally Available (GA).

    Only the v1beta1 version of the APIs for KafkaChannel and KafkaSource objects on OpenShift Serverless are supported. Do not use the v1alpha1 version of these APIs, as this version is now deprecated.

  • The Operator channel for installing and upgrading OpenShift Serverless has been updated to stable for OpenShift Container Platform 4.6 and newer versions.

  • OpenShift Serverless is now supported on IBM Power Systems, IBM Z, and LinuxONE, except for the following features, which are not yet supported:

    • Knative Kafka functionality.

    • OpenShift Serverless Functions developer preview.

Known issues

  • Subscriptions for the Kafka channel sometimes fail to become marked as READY and remain in the SubscriptionNotMarkedReadyByChannel state. You can fix this by restarting the dispatcher for the Kafka channel.

Release Notes for Red Hat OpenShift Serverless 1.13.0

New features

  • OpenShift Serverless now uses Knative Serving 0.19.0.

  • OpenShift Serverless uses Knative Eventing 0.19.2.

  • OpenShift Serverless now uses Kourier 0.19.0.

  • OpenShift Serverless now uses Knative kn CLI 0.19.1.

  • OpenShift Serverless now uses Knative Kafka 0.19.1.

  • A DomainMapping custom resource (CR) has been added to OpenShift Serverless to enable users to map a custom domain name to a Knative Service. See the Knative documentation on Creating a mapping between a custom domain name and a Knative Service.

  • In Knative Serving 0.19.0, v1alpha1 and v1beta1 versions of the Service, Route, Configuration, and Revision resources have been removed. The OpenShift Serverless Operator automatically upgrades older resources to v1, so no user action is required.

    New resources must not be created as v1alpha1 or v1beta1 versions, since this can cause errors and these resources will not be upgraded automatically.

Release Notes for Red Hat OpenShift Serverless 1.12.0

New features

  • OpenShift Serverless now uses Knative Serving 0.18.2.

  • OpenShift Serverless uses Knative Eventing 0.18.6.

  • OpenShift Serverless now uses Kourier 0.18.0.

  • OpenShift Serverless now uses Knative kn CLI 0.18.4.

  • OpenShift Serverless now uses Knative Kafka 0.18.0.

Fixed issues

  • In previous versions, if you used a ping source with OpenShift Serverless, after you uninstalled and deleted all other Knative Eventing components, the pingsource-jobrunner deployment was not deleted. This issue is now fixed, and the pingsource-jobrunner deployment has been renamed to pingsource-mt-adapter.

  • In previous versions, deleting a sink before you delete the SinkBinding resource connected to it caused the resource deletion to hang. This issue is now fixed.

Known issues

  • Using the eventing.knative.dev/scope: namespace annotation for the KafkaChannel objects is not supported.

Release Notes for Red Hat OpenShift Serverless 1.11.0

New features

  • Knative Eventing on OpenShift Serverless is now Generally Available (GA).

  • Knative Kafka features such as Kafka channel and Kafka event source are now available as a Technology Preview on OpenShift Serverless. Kafka integration is delivered through the OpenShift Serverless Operator and does not require a separate community Operator installation.

  • OpenShift Serverless Functions is now delivered as a Developer Preview through the standard Knative kn CLI installation. This feature is not yet supported by Red Hat for production deployments, but can be used for development and testing. For more information about using OpenShift Serverless Functions through the kn func CLI, see the OpenShift Serverless Functions Developer Preview documentation.

  • OpenShift Serverless now uses Knative Serving 0.17.3.

  • OpenShift Serverless uses Knative Eventing 0.17.2.

  • OpenShift Serverless now uses Kourier 0.17.0.

  • OpenShift Serverless now uses Knative kn CLI 0.17.3.

  • OpenShift Serverless now uses Knative Kafka 0.17.1.

Known issues

  • When the horizontal pod autoscaler (HPA) scales up the broker-ingress pod, the imc-dispatcher pod sometimes fails to forward replies. This is because the new broker-ingress pods are Ready before accepting connections, because they lack a readiness probe. If you are using HPA autoscaling and do not want to scale the broker-ingress pod manually, you must configure retries in the Broker.Spec.Delivery.

  • Using the eventing.knative.dev/scope: namespace annotation with Kafka channels is not supported.

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.

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