7.10. 其它问题


7.10.1. 解决 运行时网络未就绪 错误

部署集群后,您可能会收到以下错误:

`runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: Missing CNI default network`
Copy to Clipboard Toggle word wrap

Cluster Network Operator 负责部署网络组件以响应安装程序创建的特殊对象。它会在安装过程的早期阶段运行(在 control plane(master)节点启动后,bootstrap control plane 被停止前运行。它可能表明存在更细微的安装程序问题,如启动 control plane(master)节点时延迟时间过长,或者 apiserver 通讯的问题。

流程

  1. 检查 openshift-network-operator 命名空间中的 pod:

    $ oc get all -n openshift-network-operator
    Copy to Clipboard Toggle word wrap
    NAME                                    READY STATUS            RESTARTS   AGE
    pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m
    Copy to Clipboard Toggle word wrap
  2. provisioner 节点上,确定存在网络配置:

    $ kubectl get network.config.openshift.io cluster -oyaml
    Copy to Clipboard Toggle word wrap
    apiVersion: config.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      serviceNetwork:
      - 172.30.0.0/16
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      networkType: OVNKubernetes
    Copy to Clipboard Toggle word wrap

    如果不存在,安装程序不会创建它。要确定安装程序没有创建它的原因,请执行以下操作:

    $ openshift-install create manifests
    Copy to Clipboard Toggle word wrap
  3. 检查 network-operator 是否正在运行:

    $ kubectl -n openshift-network-operator get pods
    Copy to Clipboard Toggle word wrap
  4. 检索日志:

    $ kubectl -n openshift-network-operator logs -l "name=network-operator"
    Copy to Clipboard Toggle word wrap

    在具有三个或更多 control plane(master)节点的高可用性集群中,Operator 将执行领导选举机制,所有其他 Operator 会休眠。如需了解更多详细信息,请参阅 故障排除

部署集群后,您可能会收到以下出错信息:

No disk found with matching rootDeviceHints
Copy to Clipboard Toggle word wrap

要解决 No disk found with matching rootDeviceHints 错误,一个临时解决方法是将 rootDeviceHints 更改为 minSizeGigabytes: 300

更改 rootDeviceHints 设置后,使用以下命令引导 CoreOS,然后使用以下命令验证磁盘信息:

$ udevadm info /dev/sda
Copy to Clipboard Toggle word wrap

如果您使用 DL360 Gen 10 服务器,请注意它们有一个 SD-card 插槽,它可能会被分配 /dev/sda 设备名称。如果服务器中没有 SD 卡,可能会导致冲突。确定在服务器的 BIOS 设置中禁用 SD 卡插槽。

如果 minSizeGigabytes 临时解决方案没有满足要求,您可能需要将 rootDeviceHints 恢复为 /dev/sda。此更改允许 ironic 镜像成功引导。

修复此问题的另一种方法是使用磁盘的串行 ID。但是,请注意,发现串行 ID 可能具有挑战性,并且可能会导致配置文件无法读取。如果选择此路径,请确保使用之前记录的命令收集串行 ID,并将其合并到您的配置中。

如果集群节点没有通过 DHCP 获得正确的 IPv6 地址,请检查以下内容:

  1. 确保保留的 IPv6 地址不在 DHCP 范围内。
  2. 在 DHCP 服务器上的 IP 地址保留中,确保保留指定了正确的 DHCP 唯一标识符(DUID)。例如:

    # This is a dnsmasq dhcp reservation, 'id:00:03:00:01' is the client id and '18:db:f2:8c:d5:9f' is the MAC Address for the NIC
    id:00:03:00:01:18:db:f2:8c:d5:9f,openshift-master-1,[2620:52:0:1302::6]
    Copy to Clipboard Toggle word wrap
  3. 确保路由声明正常工作。
  4. 确保 DHCP 服务器正在侦听提供 IP 地址范围所需的接口。

在 IPv6 部署过程中,集群节点必须通过 DHCP 获得其主机名。有时 NetworkManager 不会立即分配主机名。control plane(master)节点可能会报告错误,例如:

Failed Units: 2
  NetworkManager-wait-online.service
  nodeip-configuration.service
Copy to Clipboard Toggle word wrap

这个错误表示集群节点可能在没有从 DHCP 服务器接收主机名的情况下引导,这会导致 kubelet 使用 localhost.localdomain 主机名引导。要解决错误,请强制节点更新主机名。

流程

  1. 检索 主机名

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap

    如果主机名是 localhost,请执行以下步骤。

    注意

    其中 X 是 control plane 节点号。

  2. 强制集群节点续订 DHCP 租期:

    [core@master-X ~]$ sudo nmcli con up "<bare_metal_nic>"
    Copy to Clipboard Toggle word wrap

    <bare_metal_nic> 替换为与 baremetal 网络对应的有线连接。

  3. 再次检查 主机名

    [core@master-X ~]$ hostname
    Copy to Clipboard Toggle word wrap
  4. 如果主机名仍然是 localhost.localdomain,重启 NetworkManager

    [core@master-X ~]$ sudo systemctl restart NetworkManager
    Copy to Clipboard Toggle word wrap
  5. 如果主机名仍然是 localhost.localdomain,请等待几分钟并再次检查。如果主机名仍为 localhost.localdomain,请重复前面的步骤。
  6. 重启 nodeip-configuration 服务:

    [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service
    Copy to Clipboard Toggle word wrap

    此服务将使用正确的主机名引用来重新配置 kubelet 服务。

  7. 因为 kubelet 在上一步中更改,所以重新载入单元文件定义:

    [core@master-X ~]$ sudo systemctl daemon-reload
    Copy to Clipboard Toggle word wrap
  8. 重启 kubelet 服务:

    [core@master-X ~]$ sudo systemctl restart kubelet.service
    Copy to Clipboard Toggle word wrap
  9. 确保 kubelet 使用正确的主机名引导:

    [core@master-X ~]$ sudo journalctl -fu kubelet.service
    Copy to Clipboard Toggle word wrap

如果集群节点在集群启动并运行后没有通过 DHCP 获得正确的主机名,比如在重启过程中,集群会有一个待处理的 csr不要 批准 csr,否则可能会出现其他问题。

处理 csr

  1. 在集群上获取 CSR:

    $ oc get csr
    Copy to Clipboard Toggle word wrap
  2. 验证待处理的 csr 是否包含 Subject Name: localhost.localdomain:

    $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text
    Copy to Clipboard Toggle word wrap
  3. 删除包含 Subject Name: localhost.localdomain 的任何 csr

    $ oc delete csr <wrong_csr>
    Copy to Clipboard Toggle word wrap

7.10.5. 路由无法访问端点

在安装过程中,可能会出现虚拟路由器冗余协议(VRRP)冲突。如果之前使用特定集群名称部署的 OpenShift Container Platform 节点仍在运行,但不是使用相同集群名称部署的当前 OpenShift Container Platform 集群的一部分,则可能会出现冲突。例如,一个集群使用集群名称 openshift 部署,它 部署了三个 control plane(master)节点和三个 worker 节点。之后,一个单独的安装使用相同的集群名称 openshift,但这个重新部署只安装了三个 control plane(master)节点,使以前部署的三个 worker 节点处于 ON 状态。这可能导致 Virtual Router Identifier(VRID)冲突和 VRRP 冲突。

  1. 获取路由:

    $ oc get route oauth-openshift
    Copy to Clipboard Toggle word wrap
  2. 检查服务端点:

    $ oc get svc oauth-openshift
    Copy to Clipboard Toggle word wrap
    NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m
    Copy to Clipboard Toggle word wrap
  3. 尝试从 control plane(master)节点访问该服务:

    [core@master0 ~]$ curl -k https://172.30.19.162
    Copy to Clipboard Toggle word wrap
    {
      "kind": "Status",
      "apiVersion": "v1",
      "metadata": {
      },
      "status": "Failure",
      "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
      "reason": "Forbidden",
      "details": {
      },
      "code": 403
    Copy to Clipboard Toggle word wrap
  4. 识别 provisioner 节点的 authentication-operator 错误:

    $ oc logs deployment/authentication-operator -n openshift-authentication-operator
    Copy to Clipboard Toggle word wrap
    Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-authentication-operator", Name:"authentication-operator", UID:"225c5bd5-b368-439b-9155-5fd3c0459d98", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'OperatorStatusChanged' Status for clusteroperator/authentication changed: Degraded message changed from "IngressStateEndpointsDegraded: All 2 endpoints for oauth-server are reporting"
    Copy to Clipboard Toggle word wrap

解决方案

  1. 确保每个部署的集群名称都是唯一的,确保没有冲突。
  2. 关闭所有不是使用相同集群名称的集群部署的一部分的节点。否则,OpenShift Container Platform 集群的身份验证 pod 可能无法成功启动。

7.10.6. 在 Firstboot 过程中 Ignition 失败

在 Firstboot 过程中,Ignition 配置可能会失败。

流程

  1. 连接到 Ignition 配置失败的节点:

    Failed Units: 1
      machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap
  2. 重启 machine-config-daemon-firstboot 服务:

    [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service
    Copy to Clipboard Toggle word wrap

7.10.7. NTP 不同步

OpenShift Container Platform 集群的部署需要集群节点间的 NTP 同步时钟。如果没有同步时钟,如果时间差大于 2 秒,则部署可能会因为时钟偏移而失败。

流程

  1. 检查集群节点的 AGE 的不同。例如:

    $ oc get nodes
    Copy to Clipboard Toggle word wrap
    NAME                         STATUS   ROLES    AGE   VERSION
    master-0.cloud.example.com   Ready    master   145m   v1.26.0
    master-1.cloud.example.com   Ready    master   135m   v1.26.0
    master-2.cloud.example.com   Ready    master   145m   v1.26.0
    worker-2.cloud.example.com   Ready    worker   100m   v1.26.0
    Copy to Clipboard Toggle word wrap
  2. 检查时钟偏移导致的时间延迟。例如:

    $ oc get bmh -n openshift-machine-api
    Copy to Clipboard Toggle word wrap
    master-1   error registering master-1  ipmi://<out_of_band_ip>
    Copy to Clipboard Toggle word wrap
    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap
                   Local time: Tue 2020-03-10 18:20:02 UTC
               Universal time: Tue 2020-03-10 18:20:02 UTC
                     RTC time: Tue 2020-03-10 18:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: no
                  NTP service: active
              RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

处理现有集群中的时钟偏移

  1. 创建一个 Butane 配置文件,其中包含要发送到节点的 chrony.conf 文件的内容。在以下示例中,创建 99-master-chrony.bu 将文件添加到 control plane 节点。您可以修改 worker 节点的 文件,或者对 worker 角色重复此步骤。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.13.0
    metadata:
      name: 99-master-chrony
      labels:
        machineconfiguration.openshift.io/role: master
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            server <NTP_server> iburst 
    1
    
            stratumweight 0
            driftfile /var/lib/chrony/drift
            rtcsync
            makestep 10 3
            bindcmdaddress 127.0.0.1
            bindcmdaddress ::1
            keyfile /etc/chrony.keys
            commandkey 1
            generatecommandkey
            noclientlog
            logchange 0.5
            logdir /var/log/chrony
    Copy to Clipboard Toggle word wrap
    1
    <NTP_server> 替换为 NTP 服务器的 IP 地址。
  2. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony.yaml,其中包含要交付至节点的配置:

    $ butane 99-master-chrony.bu -o 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap
  3. 应用 MachineConfig 对象文件:

    $ oc apply -f 99-master-chrony.yaml
    Copy to Clipboard Toggle word wrap
  4. 确保 系统时钟同步 值为 yes

    $ sudo timedatectl
    Copy to Clipboard Toggle word wrap
                   Local time: Tue 2020-03-10 19:10:02 UTC
               Universal time: Tue 2020-03-10 19:10:02 UTC
                     RTC time: Tue 2020-03-10 19:36:53
                    Time zone: UTC (UTC, +0000)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no
    Copy to Clipboard Toggle word wrap

    要在部署前设置时钟同步,请生成清单文件并将此文件添加到 openshift 目录中。例如:

    $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml
    Copy to Clipboard Toggle word wrap

    然后,继续创建集群。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat