8.6. 故障排除

流程

1. 登录到 bootstrap 虚拟机：

   $ ssh core@172.22.0.2

2. 要检查容器日志，请执行以下操作：

   [core@localhost ~]$ sudo podman logs -f <container-name>

   将 <container-name> 替换为 ironic-api、ironic-conductor 或 ironic-inspector 之一。如果您遇到 control plane 节点没有通过 PXE 引导的问题，请检查 ironic-conductor pod。ironic-conductor pod 包含了有关尝试引导集群节点的最详细信息，因为它尝试通过 IPMI 登录该节点。

流程

1. 登录到 bootstrap 虚拟机：

   $ ssh core@172.22.0.2

2. 检查 bootstrap 虚拟机中的 ipa-downloader 和 coreos-downloader 容器的状态：

   [core@localhost ~]$ sudo podman logs -f ipa-downloader

   [core@localhost ~]$ sudo podman logs -f coreos-downloader

   如果 bootstrap 虚拟机无法访问镜像的 URL，使用 curl 命令验证虚拟机能否访问镜像。

3. 要检查 bootkube 日志以了解在部署阶段是否启动了所有容器，请执行以下操作：

   [core@localhost ~]$ journalctl -xe

   [core@localhost ~]$ journalctl -b -f -u bootkube.service

4. 验证所有 pod 都在运行，包括 dnsmasq、mariadb、httpd 和 ironic：

   [core@localhost ~]$ sudo podman ps

5. 如果 pod 存在问题，请检查相关的容器日志。要检查 ironic-api 的日志，请执行以下操作：

   [core@localhost ~]$ sudo podman logs <ironic-api>

流程

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

   $ oc get all -n openshift-network-operator

   NAME                                    READY STATUS            RESTARTS   AGE
   pod/network-operator-69dfd7b577-bg89v   0/1   ContainerCreating 0          149m

2. 在 provisioner 节点上，确定存在网络配置：

   $ kubectl get network.config.openshift.io cluster -oyaml

   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: OpenShiftSDN

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

   $ openshift-install create manifests

3. 检查 network-operator 是否正在运行：

   $ kubectl -n openshift-network-operator get pods

4. 检索日志：

   $ kubectl -n openshift-network-operator logs -l "name=network-operator"

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

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]

3. 确保路由声明（Route Announcement）正在正常工作。
4. 确定 DHCP 服务器正在侦听提供 IP 地址范围所需的接口。

流程

1. 检索 主机名:

   [core@master-X ~]$ hostname

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

   注意

   其中 X 是 control plane 节点（也称为 master 节点）号。

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

   [core@master-X ~]$ sudo nmcli con up "<bare-metal-nic>"

   将 <bare-metal-nic> 替换为与 baremetal 网络对应的有线连接。

3. 再次检查 主机名:

   [core@master-X ~]$ hostname

4. 如果主机名仍然是 localhost.localdomain，重启 NetworkManager:

   [core@master-X ~]$ sudo systemctl restart NetworkManager

5. 如果主机名仍然是 localhost.localdomain，请等待几分钟并再次检查。如果主机名还是 localhost.localdomain，重复前面的步骤。

6. 重启 nodeip-configuration 服务：

   [core@master-X ~]$ sudo systemctl restart nodeip-configuration.service

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

7. 因为 kubelet 在上一步中有所改变，所以重新加载单元文件定义：

   [core@master-X ~]$ sudo systemctl daemon-reload

8. 重启 kubelet 服务：

   [core@master-X ~]$ sudo systemctl restart kubelet.service

9. 确保 kubelet 使用正确的主机名引导：

   [core@master-X ~]$ sudo journalctl -fu kubelet.service

处理 csr

1. 在集群上获取 CSR:

   $ oc get csr

2. 验证待处理的 csr 是否包含 Subject Name: localhost.localdomain:

   $ oc get csr <pending_csr> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -noout -text

3. 删除包含 Subject Name: localhost.localdomain 的任何 csr:

   $ oc delete csr <wrong_csr>

1. 获取路由：

   $ oc get route oauth-openshift

2. 检查服务端点：

   $ oc get svc oauth-openshift

   NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
   oauth-openshift   ClusterIP   172.30.19.162   <none>        443/TCP   59m

3. 尝试从 Control Plane（master）节点访问该服务：

   [core@master0 ~]$ curl -k https://172.30.19.162

   {
     "kind": "Status",
     "apiVersion": "v1",
     "metadata": {
     },
     "status": "Failure",
     "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
     "reason": "Forbidden",
     "details": {
     },
     "code": 403

4. 找到 provisioner 节点的 authentication-operator 错误：

   $ oc logs deployment/authentication-operator -n openshift-authentication-operator

   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"

解决方案

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

流程

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

   Failed Units: 1
     machine-config-daemon-firstboot.service

2. 重启 machine-config-daemon-firstboot 服务：

   [core@worker-X ~]$ sudo systemctl restart machine-config-daemon-firstboot.service

流程

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

   $ oc get nodes

   NAME                         STATUS   ROLES    AGE   VERSION
   master-0.cloud.example.com   Ready    master   145m   v1.16.2
   master-1.cloud.example.com   Ready    master   135m   v1.16.2
   master-2.cloud.example.com   Ready    master   145m   v1.16.2
   worker-2.cloud.example.com   Ready    worker   100m   v1.16.2

2. 检查因为时钟偏移导致的时间延迟。例如：

   $ oc get bmh -n openshift-machine-api

   master-1   error registering master-1  ipmi://<out-of-band-ip>

   $ sudo timedatectl

                  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

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

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

   注意

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

   variant: openshift
   version: 4.8.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

   1

   将 <NTP-server> 替换为 NTP 服务器的 IP 地址。

2. 使用 Butane 生成 MachineConfig 对象文件 99-master-chrony.yaml，包含要发送到节点的配置：

   $ butane 99-master-chrony.bu -o 99-master-chrony.yaml

3. 应用 MachineConfig 对象文件：

   $ oc apply -f 99-master-chrony.yaml

4. 确定 System clock synchronized 的值为 yes：

   $ sudo timedatectl

                  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

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

   $ cp chrony-masters.yaml ~/clusterconfigs/openshift/99_masters-chrony-configuration.yaml

   然后继续创建集群。