1.6. 已知问题

  • 如果您安装了 Service Mesh，请在升级 OpenShift Container Platform 前升级 Service Mesh。如需临时解决方案，请参阅将 OpenShift Service Mesh 从 1.0.1 升级到 1.0.2。
  • 应用程序迁移工具还无法处理的集群范围内的资源，包括集群角色绑定和 SCC (Security Context Constraints) 等资源。如果要迁移的应用程序依赖于源集群上的此类集群范围资源，请手动确保在目标集群中重新创建这些资源。日后的发行版本中将扩展覆盖范围以处理这些资源。
  • 4.2.0 Dynamic Host Configuration Protocol (DHCP) 目前不能搭配任何 Multus CNI 插件。(BZ#1754686)
  • 在没有配置的情况下调用时，Cluster Loader 会失败。(BZ#1761925)
  • 从 additionalNetworks 集合中删除额外网络时，Cluster Network Operator 不会删除 Operator 之前创建的 NetworkAttachmentDefinition。(BZ#1755586)
  • Prometheus Operator 部署 Statefulset 并创建一个内存限制。这个限制对于 rules-configmap-reloader 容器来说太小。(BZ#1735691)
  • DHCP 模式在将它配置为 multus CNI IPAM 时失败。(BZ#1754682)
  • ClusterResourceQuota 从版本 4.1 改为版本 4.2 所造成的 schema 的变化会导致出现问题。(BZ#1755125)
  • 一些部署（包括裸机和 vSphere）可能会导致灾难恢复无法正常工作。(BZ#1718436)
  • 从 Cluster Network Operator 中删除MacvlanConfig 不会删除旧的 network-attachment-definition。您必须手动删除这些资源。(BZ#1755586)
  • 当手动创建 NAD 时，SRIVO Operator Pod 会崩溃。(BZ#1755188)
  • 没有为 kube-controller-manager设置代理服务器。(BZ#1753467)
  • 通过 HTTPS 代理的 git clone 操作将失败。使用非 TLS (HTTP) 代理不会出现这个问题。(BZ#1750650)
  • 当需要使用一个镜像服务器（mirror）中的镜像（image）时（通常用于没有网络连接的环境中），如果镜像服务器需要验证，则无法提取或推送镜像。(BZ#1745192)
  • 镜像流 (image stream) 导入无法使用镜像服务器（mirror）。这通常需要在没有网络连接的环境中使用。(BZ#1741391)
  • 在 Red Hat OpenStack Platform 15 解决这个程序错误之前，OpenShift Container Platform 4.2 无法在 Red Hat OpenStack Platform 15 中工作。(BZ#1751942)
  • 如果构建使用一个构建 secret 时，强烈建议您使用 imageOptimizationPolicy: SkipLayers 对层进行 squash 处理。否则，secret 可能会在使用 source 或 docker 构建策略时出现泄露问题。
  • 在升级 OpenShift Container Platform 时，不会更新 AllowVolumeExpansion 和其它 StorageClass 属性。建议您删除默认 StorageClass，并让 ClusterStorageOperator 在升级完成后使用正确的属性重新创建它。(BZ#1751641)
  • 非无服务器工作负载在 Topology 资源面板中显示无服务器工作负载的资源。(BZ#1760810)
  • Topology 视图、Resources 侧面板和 Deployment Config Details 页面中所述的 pod 状态不一致。(BZ#1760827)
  • 如果应用程序是使用 Add 页面选项创建的，部署的镜像会忽略所选的目标端口，并且始终使用第一个条目。(BZ#1760836)
  • 在 Edge 浏览器中，Topology 视图中无法呈现某些特征，如应用程序名称和构建状态。(BZ#1760858)
  • 在部署失败时，Topology 视图中认定的活动 Pod 可能会不正确。(BZ#1760828)

  • 如果配置了集群范围的出口（egress）代理且之后又取消了设置，则之前由 OLM 管理的 Operator 部署的应用程序的 Pod 可能会进入 CrashLoopBackOff 状态。这是因为所部署的 Operator 仍会被配置为依赖于代理。

    注意

    这个问题会出现在集群范围出口代理创建的环境变量、卷和 VolumeMount 中。在使用 SubscriptionsConfig 对象设置环境变量、卷和 VolumeMounts 时也会出现这个问题。

    这个问题计划在 OpenShift Container Platform 以后的发行版本被修复，现在，您可以通过使用 CLI 或 Web 控制台删除 Deployment 来解决这个问题。这会触发 OLM 来重新生成部署并使用正确的网络配置启动 Pod。

    集群管理员可以通过运行以下命令，获取所有受影响的 OLM 管理的 Deployment 的列表： 

    $ oc get deployments --all-namespaces \
    -l olm.owner,olm.owner!=packageserver 1
    1
    packageserver 除外，它不受影响。

    (BZ#1751903)

  • Machine Config Operator (MCO) 支持第 2 天代理支持时存在一个问题，它出现在重新配置现有非代理集群以使用代理时。MCO 应该对 RHCOS 信任捆绑包在 ConfigMap 中应用新配置的代理 CA 证书。当前这无法正常工作。作为临时解决方案，您必须手动将代理 CA 证书添加到信任捆绑包中，然后更新信任捆绑包： 

    $ cp /opt/registry/certs/<my_root_ca>.crt /etc/pki/ca-trust/source/anchors/
$ update-ca-trust extract
$ oc adm drain <node>
$ systemctl reboot

    (BZ#1784201)