1.6. 已知问题

  • 如果您安装了 Service Mesh,请在升级 OpenShift Container Platform 前升级 Service Mesh。如需临时解决方案,请参阅 Updating OpenShift Service Mesh from 1.0.1 to 1.0.2
  • 在部署失败时,Topology 视图中认定的活动 Pod 可能会不正确。(BZ#1760828)
  • 当具有有限集群范围权限的用户使用 Add 页面中的 Container Image 选项创建应用程序,并选择 Image name from internal registry 选项时,即使镜像流存在,在项目中也无法检测到镜像流。(BZ#1784264)
  • 发布时 registry 不支持 ImageContentSourcePolicyBZ#1787112)。在断开网络连接的环境中,可以默认启用 Jenkins 来拉取。在断开网络连接的环境中,使用以下命令来使用 Jenkins 做为一个临时解决方案:

    $ oc tag <jenkins_source_image> jenkins:2 --reference-policy=source -n openshift
  • OpenShift Cluster Version Operator (CVO) 无法正确挂载来自主机的 SSL 证书,这会阻止在使用 MITM 代理检查时进行集群版本更新。(BZ#1773419)
  • builds.config.openshift.io中添加 defaultProxygitProxy 时,Jenkins 的 pipeline 构建无法获得代理配置。(BZ#1753562)
  • 当在 Red Hat OpenStack Platform 13 或 16 上安装时,使用自签名 TLS 证书配置 OpenStack 端点会导致安装失败。(BZ#1786314,BZ#1769879,BZ#1735192)
  • 当 OpenStack Neutron 负载非常重时,OpenStack 上的安装程序部署的基础架构会失败,错误为 Security group rule already exists。(BZ#1788062)
  • etcd 加密迁移过程中,集群会在 etcd 备份或恢复功能后显示错误和异常状态。(BZ#1776811)
  • 当从 4.2.12 升级到 4.3.0 时,RHCOS master 和 worker 节点可能会进入 NotReady,SchedulingDisabled 状态。(BZ#1786993)
  • 如果启用了 FIPS 模式,则无法直接使用 RHEL 的公共云访问镜像。这是因为公共云镜像不允许内核完整性检查。为了解决这个问题,需要上传自己的镜像。(BZ#1788051)
  • 当启用 Kuryr SDN 时,Operator Lifecycle Manager (OLM) 在 OpenShift Container Platform 中无法工作。(BZ#1786217)
  • 对于受限制的集群,oc adm catalog buildoc adm catalog mirror 命令无法正常工作。(BZ#1773821)
  • 当将 OpenShift Container Platform 集群从 4.1 升级到 4.2 时,使用 Node Tuning Operator 调整的 Pod 可能会处于 ContainerCreating 状态。

    要确认这个问题,请运行:

    $ oc get pods -n openshift-cluster-node-tuning-operator

    一个或多个调整的 Pod 处于 ContainerCreating 状态 。

    要解决这个问题,请应用以下临时解决方案。运行:

    $ oc delete daemonset/tuned -n openshift-cluster-node-tuning-operator
    $ oc get daemonset/tuned -n openshift-cluster-node-tuning-operator
    $ oc get pods -n openshift-cluster-node-tuning-operator

    验证 Pod 是否现在处于 Running 状态。(BZ#1791916)

  • Node Feature Discovery (NFD) Operator 版本 4.3 无法从 OpertorHub 部署到 OpenShift Container Platform Web 控制台。作为临时解决方案,为您的操作系统下载 oc 客户端,并将 kubeconfig 文件放在 ~/.kube/config中。运行这些命令从 CLI 和 GitHub 部署 NFD Operator:

    $ cd $GOPATH/src/openshift
    $ git clone https://github.com/openshift/cluster-nfd-operator.git
    $ cd cluster-nfd-operator
    $ git checkout release-4.3
    $ PULLPOLICY=Always make deploy
    $ oc get pods -n openshift-nfd

    输出示例:

    $ oc get pods -n openshift-nfd
    NAME READY STATUS RESTARTS AGE
    nfd-master-gj4bh 1/1 Running 0 9m46s
    nfd-master-hngrm 1/1 Running 0 9m46s
    nfd-master-shwg5 1/1 Running 0 9m46s
    nfd-operator-b74cbdc66-jsgqq 1/1 Running 0 10m
    nfd-worker-87wpn 1/1 Running 2 9m47s
    nfd-worker-d7kj8 1/1 Running 1 9m47s
    nfd-worker-n4g7g 1/1 Running 1 9m47s

    (BZ#1793535)

  • 如果配置了集群范围的出口(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 除外,它不受影响。

    (BZ#1751903)

  • 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

    (BZ#1784201)

  • 当升级到新的 OpenShift Container Platform z-stream 发行版本时,当节点升级后,与 API 服务器的连接可能会中断,这会导致 API 请求失败。(BZ#1791162)
  • 当升级到新的 OpenShift Container Platform z-stream 版本时,路由器的连接可能会在路由器 Pod 被更新后中断。在升级期间, 一 些应用程序可能无法被稳定访问。(BZ#1809665)
  • 通过 HTTPS 代理的 git clone 操作会失败。使用非 TLS (HTTP) 代理不会出现这个问题。(BZ#1750650)
  • 如果源 URI 使用 git://ssh://,则需要通过代理进行的构建的 git clone 操作都会失败。(BZ#1751738)
  • 在 OpenShift Container Platform 4.1 中,匿名用户可以访问发现端点。之后的版本会取消对这端点的访问,以减少可能的安全漏洞攻击面。一些发现端点被转发到聚合的 API 服务器。但是,升级的集群中会保留未经身份验证的访问,因此现有用例不会中断。

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

    警告

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