支持控制台（Console）开发人员开始试用联系人

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)

  • 目前，使用 OVN-Kubernetes 集群网络供应商从 OpenShift Container Platform 4.5 升级到 4.6 将无法正常工作。这将在以后的 4.6.z 版本中解决。(BZ#1880591)
  • 目前，当将集群扩展到集群中的 75 个节点时，OVN-Kubernetes 集群网络供应商数据库可能会崩溃，使集群处于不可用状态。(BZ#1887585)
  • 目前，在带有 OVN-Kubernetes 集群联网供应商的集群中扩展 Red Hat Enterprise Linux（RHEL）worker 节点将无法正常工作。这个问题将在以后的 RHEL 7.8.z 和 RHEL 7.9.z 发行版本中解决。(BZ#1884323, BZ#1871935)
  • 目前，在扩展 Red Hat Enterprise Linux（RHEL）7.8 上运行的 worker 节点时，OVN-Kubernetes 集群联网供应商无法在新节点上初始化。(BZ#1884323)
  • 以后的 4.5.z 版本中会修复从 OpenShift Container Platform 4.6 降级到 4.5 的问题。(BZ#1882394, BZ#1886148, BZ#1886127)
  • 目前，使用 Red Hat Enterprise Linux（RHEL）的 worker 节点无法从 OpenShift Container Platform 4.5 升级到 4.6。这将在以后的 4.6.z 版本中解决。首先，升级 RHEL，然后升级集群，然后再次运行正常的 RHEL 升级 playbook。(BZ#1887607)
  • 当在绑定设备中配置了外部网络时，OpenShift Container Platform 4.5 升级到 4.6 时会失败。ovs-configuration 服务失败，节点将无法访问。这将在以后的 4.6.z 版本中解决。(BZ#1887545)
  • 目前，当在多个 Non-Uniform Memory Access（NUMA）节点中请求巨页时，巨页无法被正确检测到。这是因为当集群包含多个 NUMA 节点时，cnf-tests 套件报告错误是由于测试将一个 NUMA 上的巨页数与整个节点上的巨页数进行比较。(BZ#1889633)
  • 用于检查数据包转发和接收一直失败的 Data Plane Development Kit（DPDK）测试。(BZ#1889631)
  • 当至少有一台没有原始配置的机器配置时，流控制传输协议（Stream Control Transmission Protocol，SCTP）验证阶段会失败。例如，这会包括只包含内核参数的机器配置。(BZ#1889275)
  • 因为 cnf-tests 套件没有正确地检测运行 PTP 的节点数量，所以 PTP 验证阶段失败。(BZ#1889741)
  • 网络接口卡（NIC）验证阶段失败，因为它没有等待节点上的设备可用。pod 在节点上启动运行的等待时间太短，因此 pod 仍可能处于 Pending 状态，测试不正确。(BZ#1890088)
  • ose-egress-dns-proxy 镜像有一个已知缺陷，导致容器无法启动。这个镜像在以前的版本中也无法正常工作，因此在4.6 中不被视为回归。(BZ#1888024)

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

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

    警告

    如果您的应用程序依赖未经身份验证的访问，在撤销了未经身份验证的访问后可能会收到 HTTP 403 错误。

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

    ## 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

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

    • cluster-status-binding
    • discovery
    • system:basic-user
    • system:discovery
    • system:openshift:discovery

    (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)

  • 在使用 Redfish Virtual Media 功能的裸机节点上安装 OpenShift Container Platform 时，当 Baseboard Management Controller（BMC）尝试从置备网络加载虚拟介质镜像时，会出现一个故障。如果 BMC 没有使用置备网络，或者其网络没有将路由设置为置备网络，则会出现这种情况。作为临时解决方案，在使用虚拟介质时，必须关闭置备网络，或者将 BMC 路由到置备网络作为一个先决条件。(BZ#1872787)
  • 由于一个已知问题，OpenShift Container Platform 安装程序不支持使用 GCP 和 Azure 上的 install-config.yaml 文件来手动模式配置。反之，您必须在集群安装过程的 manifest 生成阶段手动将配置映射插入到清单目录中，如手动为 Azure 创建 IAM 和 手动为 GCP 创建 IAM 所述。(BZ#1884691)
  • 在电源环境中，当使用 FC 持久性卷声明和 targetWWN 创建 pod 时，FC 卷附加会失败（错误信息为 no fc disk found），pod 会保持在 ContainerCreating 状态。(BZ#1887026)
  • 当提供出口 IP 的节点关闭时，在该节点上托管的 pod 不会移到提供出口 IP 的另一个节点中。这会导致在提供出口 IP 的节点关闭时，pod 的出站流量始终失败。(BZ#1877273)
  • 因为一个已知问题，在 us-gov-east-1 区域上安装 AWS GovCloud 时不支持使用断开连接的集群安装。(BZ#1881262).

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

    $ gcloud compute firewall-rules delete <firewall_rule_name>

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

  • opm alpha bundle build 命令在 Windows 10 上会失败。(BZ#1883773)

  • 在 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)

  • 如果在 Rules API 存储前发现存储 API 存储，则有时不会检测到 Rules API 后端。当这种情况发生时，在没有 Rules API 客户端的情况下创建存储引用，来自 Thanos Querier 的 Rules API 端点也不会返回任何规则。(BZ#1870287)

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

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

    示例 install-config.yaml 配置文件

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

    1
    这一行被添加来将 credentialsMode 参数设置为 Mint。

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

    (BZ#1829101)

  • 在 RHOSP 上运行并使用 Kuryr 的集群为每个 hostNetworking pod 创建不必要的 Neutron 端口。您可以安全地删除这些端口。计划在以后的 OpenShift Container Platform 版本中自动删除端口。(BZ#1888318)
  • 在配置了 Kuryr 的 RHOSP 上部署可能会出现 kuryr-cni pod 进入崩溃循环的情况，它会报告 NetlinkError:(17, 'File exists') 错误消息。作为临时解决方案，您必须重新引导节点。计划在以后的 OpenShift Container Platform 版本中解决这个问题。(BZ#1869606)
  • 当以 DNS 代理模式部署出口路由器 Pod 时，pod 无法初始化。(BZ#1888024)
  • 目前仅在计算节点上支持 RHCOS 实时（RT）内核，而不是 control plane 节点。OpenShift Container Platform 4.6 中的 RT 内核不支持紧凑集群。(BZ#1887007)

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

    • NET_RAW：如果没有保护，此功能可让 Pod 生成可以更改标头字段（如低端口、源 IP 地址和源 MAC 地址）的数据包。这个功能可能会被恶意攻击者利用。
    • SYS_CHROOT：一般工作负载不需要 chroot。只有在需要时才应允许对特权操作的访问。

    在 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).

  • OpenShift Container Platform Machine API 裸机操作器目前正在删除底层裸机主机时删除 Machine 对象。此行为与其他云供应商代理器不匹配，后者将 Machine 对象移到失败的阶段，而不会在删除底层云供应商资源时完全删除它。(BZ#1868104)
  • 当将集群从 vSphere 上安装的安装程序置备基础架构的版本 4.5 升级到 4.6 时，如果 control plane 节点 IP 地址在升级过程中发生改变，升级会失败。作为临时解决方案，您必须保留 control plane 节点 IP 地址，然后才能升级到 4.6。查看您的 DHCP 服务器文档以配置保留。(BZ#1883521)

  • 对于需要 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)

  • 使用 Helm 软件包管理器安装 Agones 并尝试使用 Developer 视角检查命名空间中的 chart 资源时，您会看到出错信息而不是资源详情。(BZ#1866087)
  • 当您在 Topology 视图 中选择一个部署时，请点 Actions Edit <deployment_name>，然后修改它; 修改的 Deployment YAML 文件覆盖或移除 Pod Template spec 中的卷挂载。(BZ#1867965)
  • 当使用 Add From Catalog 选项、根据 Template 过滤、选择模板并实例化模板时, Developer 视角中不会显示成功或失败消息。(BZ#1876535)
  • 带有跳过的任务的 PipelineRuns 会错误地将任务显示为 Failed。(BZ#1880389)
  • 在 Application Stages 视图的 Application Details 页面提供了一个不准确到应用程序环境中的项目的链接。(BZ#1889348)
  • 在创建大量 pod 的情况下，创建会失败并显示 error reserved pod name …​: name is reserved 错误信息。CNI 可执行文件的 CRI-O 上下文会终止，它会终止进程。Pod 创建最终会成功，但它需要很多时间。因此，kubelet 认为 CRI-O 没有创建 pod。kubelet 会再次发送请求，并导致名称冲突。这个问题目前正在调查中。(BZ#1785399)
  • 如果集群网络供应商是 OVN-Kubernetes，在使用没有分配给集群中任何节点的服务外部 IP 地址时，则到外部 IP 地址的网络流量将无法被路由。作为临时解决方案，请确保始终为集群中的节点分配一个服务外部 IP 地址。(BZ#1890270)

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

    • amq-online.1.5.3
    • amq-online.1.6.0

    这会导致，在从不可访问的私有容器镜像仓库（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，首选以下要求：

    • 2 个 master 节点的虚拟 CPU
    • 4 个用于 worker 节点的虚拟 CPU
    • 0.5 处理器，适用于所有节点
    • 32 GB 虚拟 RAM，适用于所有节点

  • 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)

  • oc annotate 命令不适用于包含了等号（=）的 LDAP 组名称，因为命令使用等号作为注释名称和值之间的分隔符。作为临时解决方案，使用 oc patch 或 oc edit 添加注解。(BZ#1917280)
  • OVN-Kubernetes 网络供应商不支持 NodePort- 和 LoadBalancer-type 服务的 externalTrafficPolicy 功能。service.spec.externalTrafficPolicy 字段决定服务的流量是路由到节点本地范围或集群范围的端点。目前，此类流量默认路由到集群范围的端点，因此无法限制到节点本地端点的流量。这将在以后的发行版本中解决。(BZ#1903408)
  • 目前，Kubernetes 端口冲突问题可能会导致 pod 到 pod 的通信中断，即使重新部署了 pod。有关详细信息和临时解决方案，请参阅带有 OVN-Kubernetes 的 OpenShift 4 中的 pod 和集群 IP 间的 pod 和集群 IP 端口冲突。（BZ#1939676, BZ#1939045）
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.