1.7. 已知问题

当使用用户置备的基础架构在 vSphere 上打开虚拟机时，扩展节点的过程可能无法正常工作。虚拟机监控程序配置中的一个已知问题会导致在虚拟机监控程序中创建机器，但不会开机。如果在扩展机器集后某个节点可能处于 Provisioning 状态，您可以调查 vSphere 实例本身中的虚拟机状态。使用 VMware 命令 govc tasks 和 govc events 来确定虚拟机的状态。检查类似以下内容的错误消息：

[Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(8192). ]

您可以使用 VMware KBase 文章中的步骤解决这个问题。如需更多信息，请参阅红帽知识库解决方案 [UPI vSphere] 节点扩展功能无法按预期工作。（BZ#1918383）

在 OpenShift Container Platform 4.6.8 中，引入了一个程序错误修正，它更改了 Cluster Logging Operator（CLO）重新生成证书的方式。这个程序修正会导致一个问题，CLO 可能会在 OpenShift Elasticsearch Operator（EO）试图重启集群时重新生成证书。这会导致 EO 和集群间的通信问题，从而导致 EO 节点有不匹配的证书。

不匹配的证书在升级 Elasticsearch 时可能会导致问题。作为临时解决方案，您可以选择性地单独升级 CLO 和 EO。如果无法正常工作，请运行以下命令重启 Elasticsearch Pod：

$ oc delete pod -l component=es

pod 重启后，不匹配的证书会被修复，从而解决了升级问题。(BZ#1906641)

在 OpenShift Container Platform 4.1 中，匿名用户可以访问发现端点。之后的版本会取消对这端点的访问，以减少可能的安全漏洞攻击面。一些发现端点被转发到聚合的 API 服务器。但是，升级的集群中会保留未经身份验证的访问，因此现有用例不会中断。

如果您是一个从 OpenShift Container Platform 4.1 升级到 4.6 的集群的集群管理员，您可以撤销或继续允许未经身份验证的访问。建议取消未经身份验证的访问，除非有特殊需要。如果您继续允许未经身份验证的访问，请注意相关的风险。

使用以下脚本撤销对发现端点的未经身份验证的访问：

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

此脚本从以下集群角色绑定中删除未经身份验证的对象：

(BZ#1821771)

在没有使用 --helm-chart 标志的情况下运行 operator-sdk new 或 operator- sdk create api 命令会构建基于 Helm 的 Operator，并使用默认的 boilerplate Nginx chart。虽然本示例 chart 在上游 Kubernetes 上可以正常工作，但它无法在 OpenShift Container Platform 上成功部署。

要临时解决这个问题，使用 --helm-chart 标志来提供一个在 OpenShift Container Platform 上成功部署的 Helm chart。例如：

$ operator-sdk new <operator_name> --type=helm \
  --helm-chart=<repo>/<name>

(BZ#1874754)

当使用安装程序置备的基础架构在 Google Cloud Platform（GCP）上运行的集群被破坏时，没有使用基础架构 ID 前缀的机器所使用的防火墙规则会被保留。这会导致安装程序的销毁过程失败。作为临时解决方案，您必须在 GCP web 控制台中手动删除机器的防火墙规则：

$ gcloud compute firewall-rules delete <firewall_rule_name>

删除缺少基础架构 ID 的机器的防火墙规则后，就可以销毁集群。(BZ#1801968)

在 OpenShift Container Platform 4.6 中，资源 metrics API 服务器支持自定义指标。资源 metrics API 服务器没有实现 OpenAPI 规格，以下消息会记录在 kube-apiserver 日志中：

controller.go:114] loading OpenAPI spec for "v1beta1.metrics.k8s.io" failed with: OpenAPI spec does not exist
controller.go:127] OpenAPI AggregationController: action for item v1beta1.metrics.k8s.io: Rate Limited Requeue.

在某些情况下，这些错误可能会导致 KubeAPIErrorsHigh 警报触发，但底层的问题未知导致降级 OpenShift Container Platform 的功能。(BZ#1819053)

如果 AWS 帐户被配置为使用 AWS 机构服务控制策略（SCP），使用全局条件拒绝所有操作或需要特定权限，则验证权限的 AWS 策略模拟器 API 将会产生一个假的负数。当无法验证权限时，OpenShift Container Platform AWS 安装会失败，即使提供的凭证具有安装所需的权限。

要临时解决这个问题，您可以通过在 install-config.yaml 配置文件中设置 credentialsMode 参数的值来绕过 AWS 策略模拟器权限检查。credentialsMode 的值将 Cloud Credential Operator（CCO）的行为改为三种支持的模式之一。

apiVersion: v1
baseDomain: cluster1.example.com
credentialsMode: Mint 1
compute:
- architecture: amd64
  hyperthreading: Enabled
...

在绕过此检查时，请确保您提供的凭证具有指定模式所需的权限。

(BZ#1829101)

要提高安全性，NET_RAW 和 SYS_CHROOT 功能在默认 CRI-O 功能列表中不再可用。

在 OpenShift Container Platform 4.5.16 中，NET_RAW 和 SYS_CHROOT 已从默认能力中删除。为了减少对版本 4.5.16 之前创建的集群的影响，现在将默认的功能列表包含在不同的机器配置中： 99-worker-generated-crio-capabilities 和 99-master-generated-crio-capabilities。OpenShift Container Platform 在从上一发行版本更新时创建新的机器配置。

升级后，建议禁用 NET_RAW 和 SYS_CHROOT 功能，然后测试您的工作负载。当准备删除这些功能时，删除 99-worker-generated-crio-capabilities 和 99-master-generated-crio-capabilities 机器配置。

重要: 如果您要从较早的版本更新，在升级到 4.6 前将其更新至 4.5.16。(BZ#1874671).

对于需要 TLS 验证的 oc 命令，如果证书未设置 Subject Alternative Name，验证不会回退到 Common Name 字段，命令会失败并显示以下错误：

x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

作为临时解决方案，您可以使用带有正确 Subject Alternative Name 的证书，或者在使用 GODEBUG=x509ignoreCN=0 的 oc 命令前暂时覆盖此行为。

将来的 4.6 z-stream 可能会返回警告而不是错误，以便用户有足够的时间更新其证书。

(BZ#1889204)

管理员可以镜像 redhat-operators 目录，在受限网络环境中（也称为断开连接的集群）在 OpenShift Container Platform 4.6 集群中使用 Operator Lifecycle Manager（OLM）。但是，以下 Operator 会返回在 mapping.txt 文件中带有私有主机名 registry-proxy.engineering.redhat.com 而不是预期的公共主机名 registry.redhat.io 的项：

这会导致，在从不可访问的私有容器镜像仓库（registry）中拉取镜像失败。这些私有容器镜像仓库通常用于红帽内部的测试。要临时解决这个问题，在生成 mapping.txt 文件后运行以下命令：

$ sed -i -e 's/registry-proxy.engineering.redhat.com/registry.redhat.io/g' \
    -e 's/rh-osbs\/amq7-/amq7\//g' \
    -e 's/amq7\/tech-preview-/amq7-tech-preview\//g' \
    ./redhat-operator-index-manifests/imageContentSourcePolicy.yaml \
    ./redhat-operator-index-manifests/mapping.txt

对于 PowerVM 上的 IBM Power Systems 上的 OpenShift Container Platform，首选以下要求：

Red Hat Operator 发布过程中存在一个错误，这会导致简单地发布 OpenShift Container Platform 4.6 索引镜像的阶段环境版本。这个程序错误已被解决，镜像很快使用正确的内容重新复制。

如果您在使用此阶段 registry 镜像时尝试安装或升级 Operator，openshift-marketplace 命名空间中的作业可能会失败，并显示以下错误信息，其中显示私有主机名 registry.stage.redhat.io 而不是预期的公共主机名 registry.redhat.io：

ImagePullBackOff for
Back-off pulling image "registry.stage.redhat.io/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c746ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

rpc error: code = Unknown desc = error pinging docker registry registry.stage.redhat.io: Get "https://registry.stage.redhat.io/v2/": dial tcp: lookup registry.stage.redhat.io on 10.0.0.1:53: no such host

这会导致，针对不可访问的私有 registry（通常用于红帽内部测试）的镜像拉取失败，相关的 Operator 安装和升级永远不会成功。如需临时解决方案，请参阅刷新失败的订阅来清理此问题。(BZ#1909152)