10.4. Red Hat OpenShift Serverless 技术预览 1.2.0 发行注记

OpenShift Serverless 已更新为使用 Knativeing 0.9.0。
OpenShift Serverless 已更新为使用 Knative Client（kn CLI）0.9.0。
OpenShift Container Platform 4.2 上的 OpenShift Serverless 现在使用 Operator Lifecycle Manager (OLM) 依赖性解析机制来自动安装 ServiceMesh Operator。还为用户安装和管理了所需的 ServiceMeshControlPlane 和 ServiceMeshMemberRoll。
对 KnativeServing 资源的访问现在仅限于 cluster-admin 角色，以防止其他用户阻塞资源。只有 cluster-admin 角色可以创建 KnativeServing CR。
OpenShift Serverless Operator 现在可以通过在 OperatorHub 中搜索 "Knative" 找到。
OpenShift Container Platform Web 控制台现在显示 KnativeServing 资源的状态条件。
在 1.2.0 版本中，OpenShift Serverless Operator 检查命名空间的网络策略。
如果不存在网络策略，Operator 会自动创建一个广泛开放的策略，以确保命名空间和 OpenShift 路由可以接收网络流量。
如果存在网络策略，OpenShift Serverless 将不会创建新策略。Operator 期望用户根据自己的应用程序需要，继续管理自己的网络策略。例如，用户必须设置策略，允许命名空间可以接收网络数据，并在将命名空间添加到 ServiceMeshMemberRoll 后仍允许使用 OpenShift 路由。

在以前的版本中，在不同命名空间中使用相同的服务或路由可导致服务无法正常工作，并导致 OpenShift Container Platform 路由被覆盖。这个问题已被解决。
在以前的版本中，不同的流量分割目标都需要一个强制标签（tag）。现在，一个流量分隔可以使用 untagged 的流量目标定义。
在 OpenShift Serverless Operator 版本 1.1.0 中创建的，已存在的公共可见的 Knative 服务和路由无法更新为只在集群范围内可见。这个问题现已解决。
Unknown Uninitialized : Waiting for VirtualService 错误已被修复。
当集群长时间运行时，Knative 服务不再会返回 503 状态代码。

使用 OLM 在比 4.2.4 更老的 OpenShift Container Platform 版本上安装 OpenShift Serverless Operator 可能会错误地使用依赖软件包的社区版本。作为临时解决方案，在 4.2.4 之前的 OpenShift Container Platform 版本中，在安装 OpenShift Serverless Operator 前，明确安装红帽提供的 Elastic Search 、Jaeger 、Kiali 和 ServiceMesh Operators 版本。
如果您要将 OpenShift Server 从1.1.0 升级到1.2.0，并且已设置了一个 ServiceMeshControlPlane 和 ServiceMeshMemberRoll 与 Knative 实例一同工作，则必须从 istio-system 的 ServiceMeshMemberRoll 中删除 knative-serving 命名空间以及包含 Knative Services 的其他所有命名空间。
如果其他应用程序不需要，您还可以从命名空间中完全删除 ServiceMeshControlPlane。
升级开始后，现有服务会象以前一样继续工作，但新服务将永远无法就绪。一旦通过从 ServiceMeshMemberRoll 中删除 knative-serving 以及任何其他相关的命名来取消阻塞发行后，所有活跃的服务都会有一个短暂的中断。这会自行修复。请确定从原始 ServiceMeshMemberRoll 中删除所有包含 Knative Services 的命名空间。
gRPC 和 HTTP2 不适用于路由。这是 OpenShift 路由的一个已知的局限性。