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除外，它不受影响。
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
