1.16. Red Hat OpenShift Serverless 1.16.0 发行注记
OpenShift Serverless 1.16.0 现已正式发布。OpenShift Container Platform 上的 OpenShift Serverless 的新功能、改变以及已知的问题包括在此文档中。
1.16.1. 新功能
- OpenShift Serverless 现在使用 Knative Serving 0.22.0。
- OpenShift Serverless 现在使用 Knative Eventing 0.22.0。
- OpenShift Serverless 现在使用 Kourier 0.22.0。
-
OpenShift Serverless 现在使用 Knative
knCLI 0.22.0。 - OpenShift Serverless 现在使用 Knative Kafka 0.22.0。
-
kn funcCLI 插件现在使用func0.16.0。 -
kn func emit命令已添加到功能kn插件中。您可以使用此命令发送事件来测试本地部署的功能。
1.16.2. 已知问题
- 在升级到 OpenShift Serverless 1.16.0 前，您必须将 OpenShift Container Platform 升级到 4.6.30、4.7.11 或更高版本。
AMQ Streams Operator 可能会阻止安装或升级 OpenShift Serverless Operator。如果发生这种情况，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.
您可以在安装或升级 OpenShift Serverless Operator 前卸载 AMQ Streams Operator，从而解决这个问题。然后您可以重新安装 AMQ Streams Operator。
- 如果使用 mTLS 启用 Service Mesh，则 Knative Serving 的指标会被默认禁用，因为 Service Mesh 会防止 Prometheus 提取指标。有关启用 Knative Serving 指标以用于 Service Mesh 和 mTLS 的说明，请参阅 Serverless 文档中的"集成 Service Mesh with OpenShift Serverless"部分。
如果您部署启用了 Istio ingress 的 Service Mesh CR，您可能会在
istio-ingressgatewaypod 中看到以下警告：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
您的 Knative 服务也可能无法访问。
您可以按照以下的临时解决方案，通过重新创建
knative-local-gateway服务来解决这个问题：删除
istio-system命名空间中现有的knative-local-gateway服务：$ oc delete services -n istio-system knative-local-gateway
创建并应用包含以下 YAML 的
knative-local-gateway服务：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
如果您在集群中有 1000 个 Knative 服务，然后执行 Knative Serving 的重新安装或升级，则在
KnativeServing自定义资源(CR)变为Ready后创建第一个新服务会有一个延迟。3scale-kourier-control服务会在创建新服务前协调所有以前存在的 Knative 服务。因此，新服务在状态被更新为Ready前，大约会有 800 秒的时间处于IngressNotConfigured或Unknown状态。如果您为 Kafka 频道或新 Kafka 源创建新订阅，在新创建的订阅或 sink 报告就绪状态后 Kafka 数据平面可能会延迟分配信息。
因此，在 data plane 没有报告就绪状态时发送的信息可能无法传送到订阅者或 sink。
有关此问题和可能的解决方案的更多信息，请参阅知识库文章 #6343981。
