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)

  • 如果您在使用 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)。

    $ 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