1.8. 已知问题

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

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

    警告

    如果您的应用程序依赖未经身份验证的访问,在撤销了未经身份验证的访问后可能会收到 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)

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

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

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

  • 如果您在使用 x86_64 架构的 VMware 上运行集群,且 install-config.yaml 文件中设置了 platform: none 字段,则在 OpenShift Container Platform 集群版本 4.7 或从集群版本 4.6 升级到版本 4.7 上可能会失败。当集群使用通过虚拟硬件版本 14 或更高版本配置的虚拟机时,会出现这个失败。作为临时解决方案,您可以将虚拟机配置为使用虚拟硬件版本 13。

    部署到 VMware Cloud(VMC)的集群不会遇到虚拟硬件版本 14 或更高版本的问题。(BZ#1941714

  • 如果您使用附加的 Prometheus PVC 运行集群监控,在升级到 OpenShift Container Platform 4.7 时可能会出现 OOM 终止的情况。当 Prometheus 使用持久性存储时,Prometheus 内存在升级过程中会加倍,并在升级完成后的几小时内仍会是这个情况。为了避免 OOM 终止问题,允许升级前有双倍可用内存的 worker 节点。(BZ#1925061
  • 启动和停止 pod 迅速可能会导致 pod 处于 Terminating 状态。作为临时解决方案,您必须运行以下命令删除卡住的 pod:

    $ oc delete --force -n <project_name> <pod_name>

    此问题将在 OpenShift Container Platform 以后的发行版本中解决。(BZ#1929463

  • 目前仅在计算节点上支持 RHCOS 实时(RT)内核,而不是 control plane 节点。OpenShift Container Platform 4.7 中的 RT 内核不支持紧凑集群。(BZ#1887007)
  • 由于当前 OpenShift Container Platform 的限制,目前还无法在安装到 AWS C2S Secret 区域的集群中使用 AWS 安全令牌服务(STS)。以后的 OpenShift Container Platform 发行版本中会解决这个问题。(BZ#1927157
  • 红帽推荐的 CloudFormation 模板使用您自己的基础架构将集群安装到 AWS C2S Secret Region 无法正常工作,因为在安装过程中创建 bootstrap 节点时存在问题。(BZ#1924080
  • 将 Performance Addon Operator 从 4.6 升级到 4.7 会失败并显示以下错误:

    "Warning  TooManyOperatorGroups  11m   operator-lifecycle-manager  csv created in namespace with multiple operatorgroups, can't pick one automatically"

    在升级前,请按照在以前安装到特定命名空间时升级 Performance Addon Operator 中的步骤进行操作。

    BZ#1913826

  • 有时需要重启来在支持的 NIC 上实现 SR-IOV 更改。SR-IOV 目前会在重新引导时执行。如果此重启与 Machine Config 策略中的更改一致,则该节点可能会处于未确定的状态。Machine Config Operator 假设没有应用更新后的策略。

    注意

    这种竞争条件也可以通过将节点添加到具有 MCP 和 SR-IOV 更改的机器配置池中导致。

    为了避免这个问题,应该按顺序完成需要 MCO 和 SR-IOV 更改的新节点。首先,应用所有 MCO 配置并等待节点发生。然后,应用 SR-IOV 配置。

    如果一个新节点被添加到包含 SR-IOV 的机器配置池中,可以通过从 Machine Config Pool 中删除 SR-IOV 策略来避免此问题,然后添加新的 worker。然后,重新应用 SR-IOV 策略。

    BZ#1921321

  • stalld 服务会触发内核中的一个错误,并导致节点出现问题。为了临时解决这个问题,Performance Addon Operator 默认禁用 stalld。这个修复会影响与基于 DPDK 的工作负载关联的延迟,但在内核程序漏洞(BZ#1912118)被修复后,功能将会被恢复。
  • 带有 ruby-kafka-1.1.0fluent-plugin-kafka-0.13.1 gems 的 Fluentd pod 与 Apache Kafka 版本 0.10.1.0 不兼容。如需更多信息,请参阅 Red Hat OpenShift Logging 5.0 发行注记中的"已知问题"
  • 精度时间协议(PTP)错误会在适配器卡 Mellanox MT27800 系列 [ConnectX-5] 中观察到。在 ptp4l 日志中会出现与时钟同步相关的错误。

    这些错误会因为 NIC 硬件时钟被重置而导致系统时钟更新大于正常的情况。造成此问题的根原因未知,目前还没有临时解决方案。

    BZ#1913279

  • 在以前的版本中,OpenStack SDK 中的一个错误会在请求服务器组 OSP16 时失败。因此,UPI playbook control-plane.yaml 在创建 control plane 服务器时会失败。作为临时解决方案,您可以请求一个热修复来更新 OpenStack SDK,它会更新堡垒主机上的 OpenStack SDK,以便将 UPI Ansible 任务更新至至少 python-openstacksdk-0.36.4-1.20201113235938.el8ost。使用这个热修复后,playbook 可以成功运行。(BZ#1891816)
  • 当在使用最新的 Dell 固件(04.40.00.00)节点在裸机中尝试 IPI 安装时,不会部署节点,并在它们的状态中显示错误。这是因为 Dell Firmware(4.40.00.00)使用 eHTML5 作为虚拟控制台插件。

    要临时解决这个问题,请将虚拟控制台插件改为 HTML5 并再次运行部署。现在,节点应该可以被成功部署。如需更多信息,请参阅使用虚拟介质安装的固件要求

    BZ#1915828

  • 在使用 Kuryr 的 RHOSP 上安装集群会超时,并在 bootstrapping 过程中出现以下信息:

    INFO Waiting up to 20m0s for the Kubernetes API at https://api.ostest.shiftstack.com:6443...
    INFO API v1.20.0+ba45583 up
    INFO Waiting up to 30m0s for bootstrapping to complete...
    ERROR Attempted to gather ClusterOperator status after wait failure: listing ClusterOperator objects: Get "https://api.ostest.shiftstack.com:6443/apis/config.openshift.io/v1/clusteroperators": dial tcp 10.46.44.166:6443: connect: connection refused
    INFO Use the following commands to gather logs from the cluster
    INFO openshift-install gather bootstrap --help
    FATAL failed to wait for bootstrapping to complete: timed out waiting for the condition

    超时是因为 Kuryr 检测集群节点的 RHOSP Networking 服务(neutron)子网变化的方式造成的。

    作为临时解决方案,请不要删除 control plane 机器清单,如安装文档中的"创建 Kubernetes 清单和 Ignition 配置文件" 部分所述。当您被指示要运行以下命令时:

    $ rm -f openshift/99_openshift-cluster-api_master-machines-*.yaml openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    运行这个命令替代:

    $ rm -f openshift/99_openshift-cluster-api_worker-machineset-*.yaml

    BZ#1927244

  • 在 OpenShift Container Platform 4.3 和 4.4 中,如果用户在多个标签页中打开了控制台,Developer 视角中的一些侧边栏链接没有直接链接到项目,在所选项目中会出现意外切换的情况。这将在以后的发行版本中解决。(BZ#1839101)
  • 在 OpenShift Container Platform 4.5 中,具有扩展权限的用户如果无法编辑对部署或部署配置的权利,则无法使用控制台扩展部署或部署配置。这将在以后的发行版本中解决。(BZ#1886888)
  • 在 OpenShift Container Platform 4.5 中,当 Developer 视角中存在最小或无数据时,大多数监控图表或图形(CPU 消耗、内存用量和带宽)都会显示 -1 到 1 范围但是这些值都不能低于零。这将在以后的发行版本中解决。(BZ#1904106)
  • 目前,Web 控制台快速启动卡的先决条件以一个段落而不是列表的形式出现。这将在以后的发行版本中解决。(BZ#1905147)
  • 目前,在 Search Page 中,在应用或删除 Name 过滤器后,Pipelines 资源表不会被立即更新。但是,如果您刷新页面或关闭并展开 Pipelines 部分,则会应用 Name 过滤器。在删除 Name 过滤器时会出现同样的行为。这将在以后的发行版本中解决。(BZ#1901207)。
  • Operator SDK CLI 工具支持在 macOS 上运,但 OpenShift 镜像站点中没有 macOS 二进制文件。macOS 二进制文件将在以后的更新中添加。(BZ#1930357
  • 目前,在启用 IPsec 的集群中,Red Hat Enterprise Linux(RHEL)7.9 节点无法与 Red Hat Enterprise Linux CoreOS(RHCOS)节点通信。(BZ#1925925
  • 如果您的集群通过管理员置备的外部负载均衡器公开默认 Ingress Controller,将所有 HTTP 流量重定向到 HTTPS,则必须修补新的明文 Ingress Canary 路由,以便在 4.6 升级到 4.7 升级过程中使用边缘终止(edge termination)。

    patch 命令示例

    $ oc patch route/canary -n openshift-ingress-canary -p '{"spec":{"tls":{"termination":"edge","insecureEdgeTerminationPolicy":"Redirect"}}}'

    BZ#1932401

  • 对 openvswitch ("net: openvswitch: reorder masks array based on usage") 代码的更新会导致 openvswitch et/openvswitch/flow_table::flow_lookup 访问 preemptible(和 migratable)项中的 per-cpu 数据条件,从而会导致一个实时内核l panic。因此,kernel-rt 不稳定,并会影响低延迟应用程序。

    在这个问题被解决前,建议不要升级到 OpenShift Container Platform 4.7。

    (BZ#1918456)

  • SR-IOV 设备插件不允许作为资源公开节点上的 VFIO 设备。这会导致在 Intel 设备中阻止 DPDK 工作负载。

    在修复这个问题之前,建议 SR-IOV 用户不要升级到 OpenShift Container Platform 4.7。

    BZ#1930469

  • 在 OpenShift Container Platform 4.7 中,添加到 Operator 基础架构代码中的 ConfigInformers 对象无法成功启动。因此,ConfigObserver 对象无法同步缓存。当发生这种情况时,oVirt CSI Driver Operator 会在几分钟后关闭,这会导致持续重启。作为临时解决方案,您可以执行以下步骤:

    1. 使用 oVirt CSI Operator 将项目切换到集群:

      $ oc project openshift-cluster-csi-drivers
    2. 检查 warning: restart 信息:

      $ oc status
    3. 如果没有警告,请输入以下命令:

      $ oc get pods

    因此,oVirt CSI Driver Operator 不会再不断重启。(BZ#1929777

  • oc annotate 命令不适用于包含了等号(=)的 LDAP 组名称,因为命令使用等号作为注释名称和值之间的分隔符。作为临时解决方案,使用 oc patchoc 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
  • 在 OpenShift Container Platform 4.7 中,pod 限制和请求不会出现在 web 控制台中。这个功能无法在不中断监控功能的情况下在此版本中实施。此功能已在 OpenShift Container Platform 4.8 版本中解决。详情请参阅 Red Hat Knowledge Base solution OpenShift Container Platform 4.7 console no longer displays request or limit lines on CPU and Memory usage charts (BZ#1975147)