Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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 不支持 ImageContentSourcePolicy （BZ#1787112）。在断开网络连接的环境中，可以默认启用 Jenkins 来拉取。在断开网络连接的环境中，使用以下命令来使用 Jenkins 做为一个临时解决方案： 

    $ oc tag <jenkins_source_image> jenkins:2 --reference-policy=source -n openshift
    Copy to Clipboard Toggle word wrap
  • OpenShift Cluster Version Operator (CVO) 无法正确挂载来自主机的 SSL 证书，这会阻止在使用 MITM 代理检查时进行集群版本更新。(BZ#1773419)
  • 在 builds.config.openshift.io中添加 defaultProxy 和 gitProxy 时，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 build 和 oc 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
    Copy to Clipboard Toggle word wrap

    一个或多个调整的 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
    Copy to Clipboard Toggle word wrap

    验证 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
    Copy to Clipboard Toggle word wrap

    输出示例： 

    $ 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
    Copy to Clipboard Toggle word wrap

    (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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

    (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
    Copy to Clipboard Toggle word wrap

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

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

    (BZ#1821771)

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat