1.3. Red Hat OpenShift Serverless 1.7.0 发行注记
1.3.1. 新功能
- OpenShift Serverless 1.7.0 包括在 OpenShift Container Platform 4.3 及更新的版本中。在以前的版本中，OpenShift Serverless 是一个技术预览。
- OpenShift Serverless 现在使用 Knative Serving 0.13.2。
- OpenShift Serverless 现在使用 Knative Serving Operator 0.13.2。
-
OpenShift Serverless 现在使用 Knative
knCLI 0.13.2。 -
Knative
knCLI 下载现在支持断开连接或受限的网络安装。 -
现在，Knative
knCLI 库由红帽签名。 - Knative Eventing 现在作为技术预览用于 OpenShift Serverless。OpenShift Serverless 现在使用 Knative kn CLI 0.13.2。
升级到最新的 Serverless 版本前，您必须删除社区版本的 Knative Eventing Operator。安装 Knative Eventing Operator 后，您将无法安装 OpenShift Serverless 1.7.0 中包含的最新 Knative Eventing 技术预览版本。
现在在默认情况下，
autoscaler-hpa、controller、activator、kourier-control和kourier-gateway组件都启用了高可用性功能（HA）。如果您已经安装了 OpenShift Serverless 的早期版本，在更新 KnativeServing 自定义资源 (CR) 后，部署将默认为使用
KnativeServing.spec.high-availability.replicas = 2的 HA 配置。您可以参照配置高可用性组件文档中的步骤来在这些组件中禁用 HA。
-
OpenShift Serverless 现在支持 OpenShift Container Platform 的集群范围代理中的
trustedCA设置，并且与 OpenShift Container Platform 的代理设置完全兼容。 -
OpenShift Serverless 现在支持使用为 OpenShift Container Platform 路由注册的通配符证书的 HTTPS。有关 Knative Serving 的
http和https的更多信息，请查看有关 验证无服务器应用程序部署的文档。
1.3.2. 修复的问题
-
在以前的版本中，在没有指定 API 组的情况下请求 KnativeServing 自定义资源 (CR)（例如，
oc get knativeServing -n knative-serving）有时会导致错误。这个问题已在 OpenShift Serverless 1.7.0 中解决。 在以前的版本中，当因为服务 CA 证书轮转而生成新的服务 CA 证书时，Knative Serving 控制器不会被通知。服务 CA 证书轮转后创建的新修订版本会失败并带有以下错误：
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.
OpenShift Serverless Operator 现在会在生成新服务 CA 证书时重启 Knative Serving 控制器，以确保控制器始终配置为使用当前服务 CA 证书。如需更多信息，请参阅 OpenShift Container Platform 文档中的身份验证部分的使用服务证书来确保服务流量安全的内容。
1.3.3. 已知问题
- 当从 OpenShift Serverless 1.6.0 升级到 1.7.0 时，对 HTTPS 的支持需要更改路由格式。OpenShift Serverless 1.6.0 所创建的 Knative 服务无法通过旧格式 URL 访问。升级 OpenShift Serverless 后，您必须为每个服务获得新的 URL。如需更多信息，请参阅有关 升级 OpenShift Serverless的文档。
-
如果您在 Azure 集群上使用 Knative Eventing，
imc-dispatcherpod 可能无法启动。这是因为 pod 的默认resources设置。作为临时解决方案，您可以删除resources设置。 如果集群中有 1000 个 Knative 服务，然后执行 Knative Serving 的重新安装或升级，则在 KnativeServing 成为 Ready 状态后，创建第一个新服务会有一个延迟。
在创建新服务前，
3scale-kourier-control会整合所有之前的 Knative 服务，这使新服务在变为Ready状态之前，会有大约 800 秒的时间处于IngressNotConfigured或Unknown状态。
