10.2. Red Hat OpenShift Serverless 技术预览 1.4.0 发行注记

重要

OpenShift Serverless 1.4.0 包含一个错误的所有有者引用，可导致 Kubernetes 模板收集器错误地删除整个 Knative control plane，包括所有服务。您必须安装 OpenShift Serverless 1.4.1 来解决这个问题。

10.2.1. 新功能

  • OpenShift Serverless 1.4.0 包括在 OpenShift Container Platform 4.2 及更新的版本中。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.11.1。
  • OpenShift Serverless 已更新为使用 Knative Client（kn CLI）0.11.0。
  • OpenShift Serverless 已更新为使用 Knative Serving 0.11.1。
  • kn CLI 现在可以通过 OpenShift Container Platform web 控制台中的 Command Line Tools 页面下载。

  • 本发行版本中的 KnativeServing 对象的 API 组已从 service.knative.dev 改为 operator.knative.dev。您需要调整所有依赖旧 API 组的脚本或应用程序，以使用新的 API 组。OpenShift Serverless 安装说明已更新为使用新的 API 组。

    当从 OpenShift Serverless 1.3.0 升级到 1.4.0 时，OpenShift Serverless Operator 会在新 API 组中创建一个 KnativeServing 自定义资源 (CR) 。此 CR 是在 OpenShift Serverless 1.3.0 中使用的旧组中的 KnativeServing CR 的一个镜像（mirror）。

    如果需要临时使用旧的组，您可以像以前一样使用旧的 CR。但是，这个 CR 已被弃用，最终会被删除。

    在更新了对新 API 组的引用后，您可以删除任何旧的 CR 版本，并使用新部署的 KnativeServing CR。为了安全地这样做而无需停机，请使用以下方法从新部署的 KnativeServing CR 中删除所有者引用 ： 

     $ oc edit knativeserving.operator.knative.dev knative-serving -n knative-serving

    删除所有者引用后，您可以安全地删除任何旧的 CR 版本，然后开始使用新的 CR。

    重要

    如果之前的 CR 版本存在，OpenShift Serverless Operator 将覆盖对新 CR 的更改。在旧的 CR 仍处于活跃状态时，需要对该 CR 进行所有更改。

10.2.2. 修复的问题

  • 从一个不是 knative-serving-ingress Service Mesh 一部分的命名空间连接到私有的、集群本地的 Knative Service 会导致 i/o timeout 错误。这个问题现已解决。
  • OpenShift Container Platform 4.3 中删除了 container_name 和 pod_name 指标标签。文档已更新，以使用新的容器和 pod 指标标签。如果在 OpenShift Container Platform 4.3 或更高版本中使用 Serverless metering ，您必须根据 Serverless metering 当前版本的文档内容更新 Prometheus 查询。

10.2.3. 已知问题

  • 因为迁移到一个新的 API 组，通过非限定格式使用 oc 命令中的 KnativeServing 将无法工作。例如，这个命令将无法正常工作： 

    $ oc get knativeserving -n knative-serving

    改为使用显式完全限定格式。例如： 

    $ oc get knativeserving.operator.knative.dev -n knative-serving
  • OpenShift Container Platform 从零延迟扩展，会在创建 pod 时有大约 10 秒的延迟。这是当前 OpenShift Container Platform 的一个限制。