第 7 章 故障排除

1. 创建 Ignition 配置文件。
2. bootstrap 机器启动并开始托管 control plane 机器引导所需的远程资源。
3. control plane 机器从 bootstrap 机器获取远程资源并完成启动。
4. control plane 机器使用 bootstrap 机器组成 etcd 集群。
5. bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
6. 临时 control plane 将生产环境 control plane 调度到 control plane 机器。
7. 临时 control plane 关机，并将控制权交给生产环境 control plane。
8. bootstrap 机器将 OpenShift Container Platform 组件添加到生产环境 control plane。
9. 安装程序关闭 bootstrap 机器。
10. control plane 设置 worker 节点。
11. control plane 以一组 Operator 的形式安装其他服务。
12. 集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建 worker 机器。

流程

1. 检查 haproxy systemd 服务是否活跃：

   $ ssh <user_name>@<load_balancer> systemctl status haproxy

2. 验证负载均衡器是否在监听所需端口。以下示例引用端口 80、443、6443 和 22623。

   • 对于在 Red Hat Enterprise Linux（RHEL）6 上运行的 HAProxy 实例，请使用 netstat 命令验证端口状态：

     $ ssh <user_name>@<load_balancer> netstat -nltupe | grep -E ':80|:443|:6443|:22623'

   • 对于在 Red Hat Enterprise Linux（RHEL）7 或 8 上运行的 HAProxy 实例，请使用 ss 命令验证端口状态：

     $ ssh <user_name>@<load_balancer> ss -nltupe | grep -E ':80|:443|:6443|:22623'

     注意

     红帽建议在 Red Hat Enterprise Linux(RHEL)7 或更高版本中使用 ss 命令而不是 netstat。SS 由 iproute 软件包提供。有关 ss 命令的详情请参考 Red Hat Enterprise Linux（RHEL）7 性能调节指南。

3. 检查通配符 DNS 记录是否被解析为负载均衡器：

   $ dig <wildcard_fqdn> @<dns_server>

流程

1. 在安装过程中监控安装日志：

   $ tail -f ~/<installation_directory>/.openshift_install.log

2. 在 bootstrap 节点引导后，监控 bootkube.service journald 单元日志。这可让您了解第一个 control plane 的 bootstrap。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注意

   bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后，这个错误应该会停止。

3. 引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。

   1. 使用 oc 监控日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

4. 引导后，监控 control plane 节点上的 crio.service journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 监控日志：

      $ oc adm node-logs --role=master -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service

流程

1. 如果可以访问 bootstrap 节点的控制台，请监控控制台，直到节点可以提供登录提示。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 bootstrap 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 bootstrap 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件，请输入以下命令：

        $ grep -is 'bootstrap.ign' /var/log/httpd/access_log

        如果收到 bootstrap Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，这表示请求成功。

     3. 如果未收到 Ignition 文件，请检查 Ignition 文件是否存在，是否在服务主机上具有适当的文件和 Web 服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 bootstrap 节点的控制台，以确定机制是否正确注入 bootstrap 节点 Ignition 文件。
3. 验证 bootstrap 节点分配的存储设备是否可用。
4. 验证 bootstrap 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 从 bootstrap 节点收集 bootkube.service journald 单元日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

   $ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service

   注意

   bootstrap 节点上的 bootkube.service 日志会输出 etcd connection refused 错误，这表示 bootstrap 服务器无法在 control plane 节点上连接到 etcd。在每个 control plane 节点上启动 etcd 且节点已加入集群后，错误应该会停止。

6. 从 bootstrap 节点容器收集日志。

   1. 使用 bootstrap 节点上的 podman 来收集日志。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

      $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'

7. 如果 bootstrap 过程失败，请验证以下内容。

   • 您可从安装主机解析 api.<cluster_name>.<base_domain>。
   • 负载均衡器代理端口 6443 连接到 bootstrap 和 control plane 节点。确保代理配置满足 OpenShift Container Platform 安装要求。

流程

1. 如果您可以访问 control plane 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 control plane 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/master.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 control plane 节点是否收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

        $ grep -is 'master.ign' /var/log/httpd/access_log

        如果收到 master Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。

     3. 如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 control plane 节点的控制台，以确定机制是否正确注入 control plane 节点 Ignition 文件。
3. 检查分配给 control plane 节点的存储设备是否可用。
4. 验证 control plane 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 确定 control plane 节点状态。

   1. 查询 control plane 节点状态：

      $ oc get nodes

   2. 如果一个 control plane 节点没有处于 Ready 状态，检索详细的节点描述：

      $ oc describe node <master_node>

      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令：

6. 确定 OpenShift Container Platform SDN 状态。

   1. 在 openshift-sdn 命名空间内查看 sdn-controller、sdn 和 ovs 守护进程集的状态：

      $ oc get daemonsets -n openshift-sdn

   2. 如果这些资源列为 Not found，查看 openshift-sdn 命名空间中的 pod：

      $ oc get pods -n openshift-sdn

   3. 检查 openshift-sdn 命名空间中与失败的 OpenShift Container Platform SDN pod 相关的日志：

      $ oc logs <sdn_pod> -n openshift-sdn

7. 确定集群网络配置状态。

   1. 查看集群的网络配置是否存在：

      $ oc get network.config.openshift.io cluster -o yaml

   2. 如果安装程序无法创建网络配置，请再次生成 Kubernetes 清单并查看消息输出：

      $ ./openshift-install create manifests

   3. 查看 openshift-network-operator 命名空间中的 pod 状态，以确定 Cluster Network Operator（CNO）是否在运行：

      $ oc get pods -n openshift-network-operator

   4. 从 openshift-network-operator 命名空间中收集网络 Operator pod 日志：

      $ oc logs pod/<network_operator_pod_name> -n openshift-network-operator

8. 引导后，监控 control plane 节点上的 kubelet.service journald 单元日志。这可让您了解 control plane 节点代理活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.15 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

9. 引导后，在 control plane 节点上检索 crio.service journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

10. 从 control plane 节点上的 /var/log/ 下的特定子目录收集日志。

    1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 control plane 节点上的 /var/log/openshift-apiserver/ 中的文件：

       $ oc adm node-logs --role=master --path=openshift-apiserver

    2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 control plane 节点的 /var/log/openshift-apiserver/audit.log 内容：

       $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log

    3. 如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例是 /var/log/openshift-apiserver/audit.log 的尾部的内容：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/openshift-apiserver/audit.log

11. 使用 SSH 查看 control plane 节点容器日志。

    1. 列出容器：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. 使用 crictl 检索容器日志：

       $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

12. 如果您遇到 control plane 节点配置问题，请验证 MCO、MCO 端点和 DNS 记录是否正常工作。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

       $ curl https://api-int.<cluster_name>:22623/config/master

    2. 如果端点不响应，请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。

    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

       1. 对定义的 MCO 端点名称运行 DNS 查找：

          $ dig api-int.<cluster_name> @<dns_server>

       2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master

    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 检查证书的有效性：

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

流程

1. 检查 etcd pod 的状态。

   1. 查看 openshift-etcd 命名空间中的 pod 状态：

      $ oc get pods -n openshift-etcd

   2. 查看 openshift-etcd-operator 命名空间中的 pod 状态：

      $ oc get pods -n openshift-etcd-operator

2. 如果以上命令中列出的任何 pod 没有显示 Running 或 Completed 状态，请为 pod 收集诊断信息。

   1. 检查 pod 的事件：

      $ oc describe pod/<pod_name> -n <namespace>

   2. 检查 pod 的日志：

      $ oc logs pod/<pod_name> -n <namespace>

   3. 如果 pod 有多个容器，以上命令会创建一个错误并在错误消息中提供容器名称。检查每个容器的日志：

      $ oc logs pod/<pod_name> -c <container_name> -n <namespace>

3. 如果 API 无法正常工作，请使用 SSH 来查看每个 control plane 节点上的 etcd pod 和容器日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值。

   1. 列出每个 control plane 节点上的 etcd pod：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-

   2. 对于没有显示 Ready 状态的 pod，详细检查 pod 状态。将 <pod_id> 替换为上一命令输出中列出的 pod ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>

   3. 列出与 pod 相关的容器：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps | grep '<pod_id>'

   4. 对于没有显示 Ready 状态的容器，请详细检查容器状态。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>

   5. 检查任何未显示 Ready 状态的容器的日志。将 <container_id> 替换为上一命令输出中列出的容器 ID:

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.15 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

4. 验证 control plane 节点的主和从属 DNS 服务器连接。

流程

1. 验证 API 服务器的 DNS 记录是否将 control plane 节点上的 kubelet 定向到 https://api-int.<cluster_name>.<base_domain>:6443。确保记录引用负载均衡器。
2. 确保负载均衡器的端口 6443 定义引用每个 control plane 节点。
3. 检查 DHCP 是否提供了唯一的 control plane 节点主机名。

4. 检查每个 control plane 节点上的 kubelet.service journald 单元日志。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.15 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

5. 检查 control plane 节点 kubelet 日志中的证书过期信息。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=master -u kubelet | grep -is 'x509: certificate has expired'

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <master-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service  | grep -is 'x509: certificate has expired'

流程

1. 如果可以访问 worker 节点的控制台，请监控控制台，直到节点可以提供登录提示。在安装过程中，Ignition 日志消息输出到控制台。

2. 验证 Ignition 文件配置。

   • 如果您使用 HTTP 服务器托管 Ignition 配置文件。

     1. 验证 worker 节点 Ignition 文件 URL。将 <http_server_fqdn> 替换为 HTTP 服务器的完全限定域名：

        $ curl -I http://<http_server_fqdn>:<port>/worker.ign  1

        1

        -I 选项只返回标头。如果指定的 URL 中有 Ignition 文件，该命令会返回 200 OK 状态。如果没有，该命令会返回 404 file not found。

     2. 要验证 worker 节点是否收到 Ignition 文件，请查询 HTTP 主机上的 HTTP 服务器日志。例如，如果您使用 Apache web 服务器提供 Ignition 文件：

        $ grep -is 'worker.ign' /var/log/httpd/access_log

        如果收到 worker Ignition 文件，相关的 HTTP GET 日志消息将包含 200 OK 成功状态，表示请求成功。

     3. 如果未收到 Ignition 文件，请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。

   • 如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。

     1. 查看 worker 节点的控制台，以确定机制是否正确注入 worker 节点 Ignition 文件。
3. 检查 worker 节点分配的存储设备是否可用。
4. 验证 worker 节点是否已从 DHCP 服务器分配了一个 IP 地址。

5. 确定 worker 节点状态。

   1. 查询节点状态：

      $ oc get nodes

   2. 获取没有显示 Ready 状态的 worker 节点的详细节点描述：

      $ oc describe node <worker_node>

      注意

      如果某个安装问题导致 OpenShift Container Platform API 无法运行，或者 kubelet 还没有在每个节点上运行，则无法运行 oc 命令。

6. 与 control plane 节点不同，worker 节点使用 Machine API Operator 部署和扩展。检查 Machine API Operator 的状态。

   1. 查看 Machine API Operator pod 状态：

      $ oc get pods -n openshift-machine-api

   2. 如果 Machine API Operator pod 没有处于 Ready 状态，请详细列出 pod 的事件：

      $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api

   3. 检查 machine-api-operator 容器日志。容器在 machine-api-operator pod 中运行：

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator

   4. 同时检查 kube-rbac-proxy 容器日志。容器也会在 machine-api-operator pod 中运行：

      $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

7. 引导后，监控 worker 节点上的 kubelet.service journald 单元日志。这可让您了解 worker 节点代理活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=worker -u kubelet

   2. 如果 API 无法正常工作，使用 SSH 来查看日志。将 <worker-node>.<cluster_name>.<base_domain> 替换为适当的值：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u kubelet.service

      注意

      运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.15 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据前，请运行 oc adm must gather 和其他 oc 命令看它们是否可以提供足够的数据。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下,可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

8. 引导后，在 worker 节点上获取 crio.service journald 单元日志。这可让您了解 worker 节点 CRI-O 容器运行时的活动。

   1. 使用 oc 检索日志：

      $ oc adm node-logs --role=worker -u crio

   2. 如果 API 无法正常工作，使用 SSH 来查看日志：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service

9. 从 worker 节点上的 /var/log/ 下的特定子目录收集日志。

   1. 获取 /var/log/ 子目录中所含的日志列表。以下示例列出所有 worker 节点上 /var/log/sssd/ 中的文件：

      $ oc adm node-logs --role=worker --path=sssd

   2. 检查 /var/log/ 子目录中的特定日志。以下示例输出来自所有 worker 节点的 /var/log/sssd/audit.log 内容：

      $ oc adm node-logs --role=worker --path=sssd/sssd.log

   3. 如果 API 无法正常工作，请使用 SSH 来查看每个节点上的日志。以下示例显示 /var/log/sssd/sssd.log 的尾部信息：

      $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log

10. 使用 SSH 查看 worker 节点容器日志。

    1. 列出容器：

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl ps -a

    2. 使用 crictl 检索容器日志：

       $ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>

11. 如果您遇到 worker 节点配置问题，检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator（MCO）在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。

    1. 测试 MCO 端点是否可用。将 <cluster_name> 替换为适当的值：

       $ curl https://api-int.<cluster_name>:22623/config/worker

    2. 如果端点不响应，请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。

    3. 验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。

       1. 对定义的 MCO 端点名称运行 DNS 查找：

          $ dig api-int.<cluster_name> @<dns_server>

       2. 在负载均衡器上对分配的 MCO IP 地址进行逆向查询：

          $ dig -x <load_balancer_mco_ip_address> @<dns_server>

    4. 验证 MCO 是否直接从 bootstrap 节点运行。将 <bootstrap_fqdn> 替换为 bootstrap 节点的完全限定域名：

       $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker

    5. 系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息：

       $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking

    6. 检查证书的有效性：

       $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

流程

1. 检查安装结束时，是否所有集群 Operator 都可用。

   $ oc get clusteroperators

2. 验证所有所需的证书签名请求（CSR）是否已批准。有些节点可能无法变为 Ready 状态，且有些集群 Operator 可能无法使用（如果待处理的 CSR）。

   1. 检查 CSR 的状态，并确保添加到集群中的每台机器都有 Pending 或 Approved 状态的客户端和服务器请求：

      $ oc get csr

      输出示例

      NAME        AGE     REQUESTOR                                                                   CONDITION
      csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 1
      csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
      csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending 2
      csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
      ...

      1

      客户端请求 CSR。

      2

      服务器请求 CSR。

      在本例中，两台机器加入了集群。您可能会在列表中看到更多已批准的 CSR。

   2. 如果 CSR 没有获得批准，在您添加的机器的所有待处理 CSR 都处于 Pending 状态 后，请批准集群机器的 CSR：

      注意

      由于 CSR 会自动轮转，因此请在将机器添加到集群后一小时内批准您的 CSR。如果没有在一小时内批准它们，证书将会轮转，每个节点会存在多个证书。您必须批准所有这些证书。批准初始 CSR 后，集群的 kube-controller-manager 会自动批准后续的节点客户端 CSR。

      注意

      对于在未启用机器 API 的平台中运行的集群，如裸机和其他用户置备的基础架构，必须采用一种方法自动批准 kubelet 提供证书请求（CSR）。如果没有批准请求，则 oc exec、ocrsh 和 oc logs 命令将无法成功，因为 API 服务器连接到 kubelet 时需要服务证书。与 Kubelet 端点联系的任何操作都需要此证书批准。该方法必须监视新的 CSR，确认 CSR 由 system: node 或 system:admin 组中的 node-bootstrapper 服务帐户提交，并确认节点的身份。

      • 要单独批准，请对每个有效的 CSR 运行以下命令：

        $ oc adm certificate approve <csr_name> 1

        1

        <csr_name> 是当前 CSR 列表中 CSR 的名称。

      • 要批准所有待处理的 CSR，请运行以下命令：

        $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

3. 查看 Operator 事件：

   $ oc describe clusteroperator <operator_name>

4. 查看 Operator 命名空间中的 Operator pod 状态：

   $ oc get pods -n <operator_namespace>

5. 获取没有处于 Running 状态的 pod 的详细描述：

   $ oc describe pod/<operator_pod_name> -n <operator_namespace>

6. 检查 pod 日志：

   $ oc logs pod/<operator_pod_name> -n <operator_namespace>

7. 遇到与 pod 基础镜像相关的问题时，请查看基础镜像状态。

   1. 获取有问题的 pod 使用的基础镜像的详情：

      $ oc get pod -o "jsonpath={range .status.containerStatuses[*]}{.name}{'\t'}{.state}{'\t'}{.image}{'\n'}{end}" <operator_pod_name> -n <operator_namespace>

   2. 列出基础镜像发行信息：

      $ oc adm release info <image_path>:<tag> --commits

流程

1. 生成从 bootstrap 和 control plane 机器获取安装日志的命令：

   • 如果您使用安装程序置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

     $ ./openshift-install gather bootstrap --dir <installation_directory> 1

     1

     installation_directory 是您在运行时指定的目录 。/openshift-install create cluster。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。

     对于安装程序置备的基础架构，安装程序会保存有关集群的信息，因此您不用指定主机名或 IP 地址。

   • 如果您使用您置备的基础架构，请切换到包含安装程序的目录，并运行以下命令：

     $ ./openshift-install gather bootstrap --dir <installation_directory> \ 1
         --bootstrap <bootstrap_address> \ 2
         --master <master_1_address> \ 3
         --master <master_2_address> \ 4
         --master <master_3_address> 5

     1

     对于 installation_directory，请指定您在运行时指定的同一目录 。/openshift-install create cluster。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。

     2

     <bootstrap_address> 是集群 bootstrap 机器的完全限定域名或 IP 地址。

     3 4 5

     对于集群中的每个 control plane 或 master 机器，将 <master_*_address> 替换为其完全限定域名或 IP 地址。

     注意

     默认集群包含三台 control plane 机器。如所示，列出所有 control plane 机器，无论您的集群使用了多少个。

   输出示例

   INFO Pulling debug logs from the bootstrap machine
   INFO Bootstrap gather logs captured here "<installation_directory>/log-bundle-<timestamp>.tar.gz"

   如果需要创建关安装失败的红帽支持问题单，请在问题单中附上压缩日志。