1.9. 已知问题


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

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

    警告

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

  • oc annotate 命令不适用于包含了等号(=)的 LDAP 组名称,因为命令使用等号作为注释名称和值之间的分隔符。作为临时解决方案,使用 oc patchoc edit 添加注解。(BZ#1917280)
  • 当使用用户置备的基础架构在 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

  • 当使用 ECKD 类型 DASD 作为 VirtIO 块设备时,在 IBM Z 上安装 RHEL KVM 时安装 RHCOS 会失败。(BZ#1960485)
  • 一个 Open Virtual Network(OVN)程序错误会导致 Octavia 负载均衡器的持久性连接问题。创建 Octavia 负载均衡器时,OVN 可能不会将它们插入到一些 Neutron 子网中。对于某些 Neutron 子网,这些负载平衡器可能无法访问。这个问题会在配置 Kuryr 时随机影响针对每个 OpenShift 命名空间创建的 Neutron 子网。因此,当出现这个问题时,从受此问题影响的 OpenShift 命名空间无法访问实施 OpenShift Service 对象的负载均衡器。由于这个程序错误,在修复程序错误前,不建议在带有 OVN 和 OVN Octavia 的 Red Hat OpenStack Platform(RHOSP)16.1 上使用 Kuryr SDN 的 OpenShift Container Platform 4.8 部署。(BZ#1937392)
  • Console Operator 没有为控制台的路由(consoledownloads)正确地更新带有 componentRoutes 条件的 Ingress 资源。(BZ#1954148)
  • 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
  • 对于使用 OVN-Kubernetes 网络供应商且计算节点运行 RHEL 7.9 的集群,BZ#1976232 会阻止从 OpenShift Container Platform 4.7 升级到 OpenShift Container Platform 4.8。要升级到 4.8,您必须等待包含这个程序错误修复的 4.8 补丁。(BZ#1976232
  • 对于使用 OVN-Kubernetes 网络供应商并从 OpenShift Container Platform 4.7 升级到 OpenShift Container Platform 4.8 的集群,OVN-Kubernetes 中的错误有时可能会导致 pod IP 地址过时。该错误会在非常罕见的情况下导致争用问题。因此,在升级到 4.8 发行版本的过程中,节点无法排空,一些 Operator 会报告 Degraded 状态。作为临时解决方案,请识别一直处于 CrashLoopBackOff 状态且没有完成升级的 pod。使用 oc delete <pod-name> 命令删除这些 pod。(BZ#1974403
  • kubeletconfig 资源的 tlsSecurityProfile 字段的描述(例如,使用 oc explain 命令时)不会列出 TLS 安全配置集的正确密码。作为临时解决方案,请查看受影响节点的 /etc/kubernetes/kubelet.conf 文件中的密码列表。(BZ#1971899
  • 在单个节点上运行 CNF 测试时,以常规模式运行 CNF 测试时,可以了解集群是否就绪缺少详情。特别是,创建 SR-IOV 网络只有在至少一分钟前才会创建网络附加定义。所有 DPDK 测试均在级联中失败。当针对单一节点上的安装(使用 -ginkgo.skip 参数)运行时,以常规模式运行 CNF 测试会跳过 DPDK 功能。以 Discovery 模式运行 CNF 测试,对单个节点上的安装执行测试。(BZ#1970409
  • 目前,CNF-tests 不支持通过 MLX NIC 进行 SR-IOV 和 DPDK 测试的安全引导。当针对启用了安全引导的环境以常规模式运行 CNF 测试时,可以使用 -ginkgo.skip 参数运行 CNF 测试跳过 SR-IOV 功能。在发现模式下运行是推荐使用 MLX 卡对安全引导环境执行测试的方法。这将在以后的发行版本中解决。(BZ#1975708)
  • ArgoCD Operator 订阅并启动 ArgoCD 和 AppProject 时,启动名为 guestbook 的示例应用程序会失败,因为镜像无法在更严格的 OpenShift Container Platform 环境中工作。作为临时解决方案,用户可通过部署以下示例来确保 ArgoCD Operator 正常工作:

    PROJ=younamespace
    cat > $PROJ-app.yaml <<EOF
    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: simple-restricted-webserver
      namespace: $PROJ
    spec:
      destination:
        namespace: $PROJ
        server: https://kubernetes.default.svc
      project: default
      source:
        path: basic-nginx
        repoURL: 'https://github.com/opdev/argocd-example-restricted-apps.git'
        targetRevision: HEAD
    EOF
    oc create -f $PROJ-app.yaml

    如需更多信息,请参阅 BZ#1812212

  • 如果您在多个标签页中打开了控制台,Developer 视角中的一些侧栏链接不会直接链接到项目,所选项目中会出现意外更改。这将在以后的发行版本中解决。(BZ#1839101)
  • 当使用 pathType: Prefix 时,使用 Ingress 创建透传路由会失败。反之,您可以通过将 pathType 设置为ImplementSpecific 并将 path 设置为 '' 来创建 passthrough 路由:

    Ingress YAML 文件示例

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: ingress7
      namespace: test-ingress
      annotations:
        route.openshift.io/termination: passthrough
    spec:
      rules:
      - host: <ingress-psql-example-test-ingress.apps>
        http:
          paths:
          - path: ''
            pathType: ImplementationSpecific
            backend:
              service:
                name: <ingress-psql-example>
                port:
                  number: 8080

    如需更多信息,请参阅 BZ#1878685

  • 目前,在 Search 页面中,在应用或删除 Name 过滤器后,Pipelines 资源表不会立即更新。但是,如果您刷新页面并展开 Pipelines 部分,则会应用 Name 过滤器。在删除 Name 过滤器时会出现同样的行为。这将在以后的发行版本中解决。(BZ#1901207)。
  • 文档现在描述了 Provisioning 自定义资源中的 ProvisioningNetworkCIDR 值。这会因为 dnsmasq 将 IPv6 调配网络限制为 /64。(BZ#1947293)
  • 为了协助故障排除,安装程序收集的 boostratp 失败的日志现在包括 control plane 和 bootstrap 主机的 IP 地址和路由。(BZ#1956079)
  • 当使用自签名的 Amazon Commercial Cloud Services 集群时,您无法从内部镜像 registry 中拉取(pull)或推送到内部镜像 registry。作为临时解决方案,您必须在 configs.imageregistry/cluster 资源中把 spec.disableRedirects 设为 true。这可让您从镜像 registry 中拉取镜像层,而不是直接从 S3 存储拉取。(BZ#1924568)
  • 在以前的版本中,如果 OpenShift Container Platform Web 控制台中使用 Bitbucket 存储库为部署创建的拓扑 URL 无法正常工作,如果它们包含包含斜杠字符的分支名称。这是因为 Bitbucket API BCLOUD-9969 存在问题。当前发行版本可以缓解这个问题。如果分支名称包含斜杠,则拓扑 URL 指向存储库的默认分支页面。此问题将在 OpenShift Container Platform 以后的发行版本中解决。(BZ#1969535)。
  • 在 Red Hat Virtualization(RHV)上安装 OpenShift Container Platform(OCP)版本 4.6 需要 RHV 版本 4.4。如果您在 RHV 4.3 上运行较早版本的 OCP,请不要将其更新至 OCP 版本 4.6。红帽还没有测试在 RHV 版本 4.3 上运行 OCP 版本 4.6 且不支持这个组合。如需有关测试的集成的更多信息,请参阅 OpenShift Container Platform 4.x Tested Integrations(x86_x64)
  • 当使用 --build-cmd 标志运行operator-sdk pkgman-to-bundle 命令时会退出并显示错误。如需更多信息,请参阅(BZ#1967369))。
  • 目前,Web 控制台快速启动卡的先决条件以一个段落而不是列表的形式出现。这将在以后的发行版本中解决。(BZ#1905147)
  • 在 OpenShift Container Platform 单一节点配置中,使用实时内核(kernel-rt)时 pod 创建时间比使用非实时内核时慢两倍。当使用 kernel-rt 时,较慢的创建时间会影响支持的最大 pod 数量,因为恢复时间会在节点重启后受到影响。作为使用 kernel-rt 时的一个临时解决方案,您可以使用 rcupdate.rcu_normal_after_boot=0 内核参数引导来提高受影响的恢复时间,该参数需要实时内核 kernel-rt-4.18.0-305.16.1.rt7.88.el8_4 或更高版本。这个已知问题适用于 OpenShift Container Platform 版本 4.8.15 及更新的版本。(BZ#1975356)
  • 在 OpenShift Container Platform 单节点重启后,所有 pod 都会重启,这会导致大量负载比正常的 pod 创建时间更长。这是因为 Container Network Interface (CNI) 无法足够快速地处理 pod add 事件。这时显示以下错误消息:timed out waiting for OVS port binding。OpenShift Container Platform 单一节点实例最终会恢复,但比预期要慢。这个已知问题适用于 OpenShift Container Platform 版本 4.8.15 及更新的版本。(BZ#1986216)
  • 在 OpenShift Container Platform 4.8 之前,默认的负载平衡算法是 leastconn。在 OpenShift Container Platform 4.8.0 中,对于非透传的路由,默认设置为 random。切换到 random 与需要使用长时间运行的 websocket 连接的环境不兼容,因为它显著提高了这些环境中的内存消耗。为缓解这种显著内存消耗,在 OpenShift Container Platform 4.8 中默认负载均衡算法被恢复为 leastconn。一旦有一个不会产生大量内存用量的解决方案可用后,在以后的 OpenShift Container Platform 发行版本中,默认值将更改为 random

    您可以输入以下命令来检查默认设置:

    $ oc get deployment -n openshift-ingress router-default -o yaml | grep -A 2 ROUTER_LOAD_BALANCE_ALGORITHM
            - name: ROUTER_LOAD_BALANCE_ALGORITHM
              value: leastconn

    random 选项仍然可用。但是,受益于此算法选择的路由必须通过输入以下命令在注解中明确设置该选项:

    $ oc annotate -n <NAMESPACE> route/<ROUTE-NAME> "haproxy.router.openshift.io/balance=random"

    (BZ#2017708)

  • 如果 RHCOS 和 Machine Config Operator(MCO)的镜像在从 OpenShift Container Platform 4.8.z 发行版本升级到更新的 4.8.z 版本时不会改变,则升级会在 control plane 节点完成升级前将标记为完成。因此,如果在升级实际完成前在集群中执行操作,升级可能会失败。作为临时解决方案,请验证在集群上执行额外的操作前,在 control plane 节点上完成更新。您可以使用 oc get mcp/master 命令检查每个池可用的 MCO 管理的节点的状态。(BZ#2025396)
  • 从 4.7 OpenShift Container Platform 集群升级到 4.8 后,默认禁用 OpenShift Container Platform 节点上的二级网络接口控制器 (NIC) 从内部网络到外部网络 pod 的路由路径。这是因为从 4.8 开始,共享网关是 Open Virtual Network (OVN) 设计的默认网关模式。如果需要该路由路径,则作为升级前或之后的临时解决方案,请在 openshift-network-operator 命名空间中创建一个 gateway-mode-config 配置映射,将 OVN 网关模式强制设置为 local。

    输入以下命令在 openshift-network-operator 命名空间中创建 gateway-mode-config

    $ cat localGW.yml
    apiVersion: v1
    kind: ConfigMap
    metadata:
        name: gateway-mode-config
        namespace: openshift-network-operator
    data:
        mode: "local"
    immutable: true
    $ oc apply -f localGW.yml
    configmap/gateway-mode-config created

    有关其他指导信息,请参阅(KCS)和(BZ#2089389)。这个设置将在以后的发行版本中进一步解决。

  • 当虚拟功能(VF)已存在时,无法在物理功能(PF)上创建 macvlan。此问题会影响 Intel E810 NIC。(BZ#2120585)
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.