安装故障排除 - 故障排除 | 支持 | OpenShift Container Platform 4.17

确定安装问题发生的位置
用户预配的基础设施安装注意事项
在安装 OpenShift Container Platform 之前检查负载均衡器配置
指定 OpenShift Container Platform 安装程序日志级别
排查 openshift-install 命令问题
监控安装进度
收集引导节点诊断数据
调查控制平面节点安装问题
调查 etcd 安装问题
调查控制平面节点 kubelet 和 API 服务器问题
调查工作节点安装问题
安装后查询操作符状态
收集来自失败安装的日志
其他资源

确定安装问题发生的位置

在排查 OpenShift Container Platform 安装问题时，您可以监控安装日志以确定问题发生在哪个阶段。然后，检索与该阶段相关的诊断数据。

OpenShift Container Platform 安装过程包括以下阶段：

创建 Ignition 配置文件。
引导机器启动并开始托管控制平面机器启动所需的远程资源。
控制平面机器从引导机器获取远程资源并完成引导。
控制平面机器使用引导机器来形成 etcd 集群。
引导机器使用新的 etcd 集群启动临时 Kubernetes 控制平面。
临时控制平面将生产控制平面调度到控制平面机器。
临时控制平面关闭并控制权移交给生产控制平面。
引导机器将 OpenShift Container Platform 组件添加到生产控制平面。
安装程序关闭引导机器。
控制平面设置工作节点。
控制平面以一组操作符的形式安装其他服务。
集群下载并配置日常运营所需的其余组件，包括在受支持的环境中创建工作机器。

用户预配的基础设施安装注意事项

默认安装方法使用安装程序预配的基础设施。对于安装程序预配的基础设施集群，OpenShift Container Platform 管理集群的所有方面，包括操作系统本身。如果可能，请使用此功能以避免必须预配和维护集群基础设施。

您也可以在您提供的基础设施上安装 OpenShift Container Platform 4.17。如果您使用此安装方法，请仔细遵循用户预配的基础设施安装文档。此外，在安装之前，请查看以下注意事项：

检查Red Hat Enterprise Linux (RHEL) 生态系统，以确定您选择的服务器硬件或虚拟化技术提供的 Red Hat Enterprise Linux CoreOS (RHCOS) 支持级别。
许多虚拟化和云环境需要在客户机操作系统上安装代理。确保这些代理作为通过守护程序集部署的容器化工作负载安装。

如果您想启用诸如动态存储、按需服务路由、节点主机名到 Kubernetes 主机名解析以及集群自动伸缩之类的功能，请安装云提供商集成。

在混合使用来自不同云提供商的资源或跨越多个物理或虚拟平台的 OpenShift Container Platform 环境中，无法启用云提供商集成。节点生命周期控制器不允许将外部节点添加到集群，并且无法指定多个云提供商集成。

如果您想使用机器集或自动伸缩来自动配置 OpenShift Container Platform 集群节点，则需要特定于提供商的 Machine API 实现。
检查您选择的云提供商是否提供了一种方法，可以在其初始部署过程中将 Ignition 配置文件注入主机。如果他们没有，则需要使用 HTTP 服务器托管 Ignition 配置文件。解决 Ignition 配置文件问题的步骤将取决于这两种方法中的哪一种被部署。
如果您想利用可选的框架组件（例如嵌入式容器注册表、Elasticsearch 或 Prometheus），则需要手动配置存储。除非显式配置，否则不会在用户配置的基础设施安装中定义默认存储类。
在高可用性 OpenShift Container Platform 环境中，需要负载均衡器来将 API 请求分发到所有控制平面节点。您可以使用任何满足 OpenShift Container Platform DNS 路由和端口要求的基于 TCP 的负载均衡解决方案。

安装 OpenShift Container Platform 之前检查负载均衡器配置

在启动 OpenShift Container Platform 安装之前，检查您的负载均衡器配置。

先决条件

您已配置了您选择的外部负载均衡器，以准备 OpenShift Container Platform 安装。以下示例基于使用 HAProxy 为集群提供负载均衡服务的 Red Hat Enterprise Linux (RHEL) 主机。
您已配置 DNS 以准备 OpenShift Container Platform 安装。
您可以通过 SSH 访问您的负载均衡器。

步骤

检查haproxy systemd 服务是否处于活动状态

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

验证负载均衡器是否正在监听所需的端口。以下示例引用端口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 建议在 Red Hat Enterprise Linux (RHEL) 7 或更高版本中使用ss命令代替netstat。ss由 iproute 包提供。有关ss命令的更多信息，请参见Red Hat Enterprise Linux (RHEL) 7 性能调整指南。

检查通配符 DNS 记录是否解析到负载均衡器
```
$ dig <wildcard_fqdn> @<dns_server>
```

指定 OpenShift Container Platform 安装程序日志级别

默认情况下，OpenShift Container Platform 安装程序日志级别设置为info。如果在诊断 OpenShift Container Platform 安装失败时需要更详细的日志记录，则可以在再次启动安装时将openshift-install日志级别提高到debug。

先决条件

您可以访问安装主机。

步骤

在启动安装时将安装日志级别设置为debug
```
$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete --log-level debug  (1)
```
1 可能的日志级别包括info、warn、error和debug。

排查 openshift-install 命令问题

如果您在运行openshift-install命令时遇到问题，请检查以下内容

安装是在创建 Ignition 配置文件 24 小时内启动的。运行以下命令时会创建 Ignition 文件
```
$ ./openshift-install create ignition-configs --dir=./install_dir
```
install-config.yaml文件与安装程序位于同一目录中。如果使用./openshift-install --dir选项声明替代安装路径，请验证该目录中是否存在install-config.yaml文件。

监控安装进度

在 OpenShift Container Platform 安装过程中，您可以监控高级安装、引导程序和控制平面日志。这提供了对安装进度如何进行的更好可见性，并有助于确定安装失败的阶段。

先决条件

您可以作为具有cluster-admin集群角色的用户访问集群。
您已安装 OpenShift CLI (oc)。
您可以通过 SSH 访问您的主机。
您拥有引导程序和控制平面节点的完全限定域名。

初始kubeadmin密码可在安装主机上的<install_directory>/auth/kubeadmin-password中找到。

步骤

在安装过程中监视安装日志

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

引导节点启动后，监视引导节点上的bootkube.service journald 单元日志。这提供了对第一个控制平面的引导的可见性。将<bootstrap_fqdn>替换为引导节点的完全限定域名

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

引导节点上的bootkube.service日志输出 etcd连接被拒绝错误，表明引导服务器无法连接到控制平面节点上的 etcd。在 etcd 在每个控制平面节点上启动并且节点加入集群后，错误应该停止。

控制平面节点启动后，监视控制平面节点上的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
控制平面节点启动后，监视控制平面节点上的crio.service journald 单元日志。这提供了对控制平面节点 CRI-O 容器运行时活动的可见性。
1. 使用oc监视日志
  $ oc adm node-logs --role=master -u crio
2. 如果 API 无法正常工作，请改用 SSH 查看日志。将<master-node>.<cluster_name>.<base_domain>替换为适当的值
  $ ssh [email protected]_name.sub_domain.domain journalctl -b -f -u crio.service

收集引导节点诊断数据

遇到与引导相关的問題時，您可以從引导节点收集bootkube.servicejournald单元日志和容器日志。

先决条件

您可以通过 SSH 访问您的引导节点。
您拥有引导节点的完全限定域名。
如果您正在使用 HTTP 服务器托管 Ignition 配置文件，则必须拥有 HTTP 服务器的完全限定域名和端口号。您还必须能够通过 SSH 访问 HTTP 主机。

步骤

如果您有权访问引导节点的控制台，请监视控制台，直到节点到达登录提示符。
验证 Ignition 文件配置。
- 如果您正在使用 HTTP 服务器托管 Ignition 配置文件。
  1. 验证引导节点 Ignition 文件的 URL。将<http_server_fqdn>替换为 HTTP 服务器的完全限定域名。
    
    $ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign (1)
    
    1 -I选项仅返回头部信息。如果 Ignition 文件在指定的 URL 上可用，则命令返回200 OK状态。如果不可用，则命令返回404 file not found。
  2. 要验证引导节点是否已收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache Web 服务器来服务 Ignition 文件，请输入以下命令：
    
    $ grep -is 'bootstrap.ign' /var/log/httpd/access_log
    
    如果收到引导 Ignition 文件，关联的HTTP GET日志消息将包含200 OK成功状态，表明请求成功。
  3. 如果未收到 Ignition 文件，请直接检查服务主机上 Ignition 文件是否存在以及它们是否具有相应的文件和 Web 服务器权限。
- 如果您正在使用云提供商机制在主机初始部署过程中注入 Ignition 配置文件。
  1. 查看引导节点的控制台，以确定该机制是否正在正确注入引导节点 Ignition 文件。
验证引导节点分配的存储设备的可用性。
验证引导节点是否已从 DHCP 服务器分配 IP 地址。

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

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

收集引导节点容器的日志。
1. 使用引导节点上的podman收集日志。将<bootstrap_fqdn>替换为引导节点的完全限定域名。
  $ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'
如果引导过程失败，请验证以下内容。
- 您可以从安装主机解析api.<cluster_name>.<base_domain>。
- 负载均衡器将 6443 端口的连接代理到引导节点和控制平面节点。确保代理配置符合 OpenShift Container Platform 安装要求。

调查控制平面节点安装问题

如果遇到控制平面节点安装问题，请确定控制平面节点 OpenShift Container Platform 软件定义网络 (SDN) 和网络 Operator 状态。收集kubelet.service、crio.service journald 单元日志和控制平面节点容器日志，以了解控制平面节点代理、CRI-O 容器运行时和 Pod 活动。

先决条件

您可以作为具有cluster-admin角色的用户访问集群。
您已安装 OpenShift CLI (oc)。
您可以通过 SSH 访问您的主机。
您拥有引导程序和控制平面节点的完全限定域名。
如果您正在使用 HTTP 服务器托管 Ignition 配置文件，则必须拥有 HTTP 服务器的完全限定域名和端口号。您还必须能够通过 SSH 访问 HTTP 主机。

初始kubeadmin密码可在安装主机上的<install_directory>/auth/kubeadmin-password中找到。

步骤

如果您有权访问控制平面节点的控制台，请监视控制台，直到节点到达登录提示符。在安装过程中，Ignition 日志消息将输出到控制台。
验证 Ignition 文件配置。
- 如果您正在使用 HTTP 服务器托管 Ignition 配置文件。
  1. 验证控制平面节点 Ignition 文件的 URL。将<http_server_fqdn>替换为 HTTP 服务器的完全限定域名。
    
    $ curl -I http://<http_server_fqdn>:<port>/master.ign (1)
    
    1 -I选项仅返回头部信息。如果 Ignition 文件在指定的 URL 上可用，则命令返回200 OK状态。如果不可用，则命令返回404 file not found。
  2. 要验证控制平面节点是否已收到 Ignition 文件，请查询服务主机上的 HTTP 服务器日志。例如，如果您使用 Apache Web 服务器来服务 Ignition 文件。
    
    $ grep -is 'master.ign' /var/log/httpd/access_log
    
    如果收到主控 Ignition 文件，关联的HTTP GET日志消息将包含200 OK成功状态，表明请求成功。
  3. 如果未收到 Ignition 文件，请直接检查它是否在服务主机上存在。确保已设置适当的文件和 Web 服务器权限。
- 如果您正在使用云提供商机制在主机初始部署过程中注入 Ignition 配置文件。
  1. 查看控制平面节点的控制台，以确定该机制是否正在正确注入控制平面节点 Ignition 文件。
检查分配给控制平面节点的存储设备的可用性。
验证控制平面节点是否已从 DHCP 服务器分配 IP 地址。
确定控制平面节点状态。
1. 查询控制平面节点状态。
  $ oc get nodes
2. 如果其中一个控制平面节点未达到Ready状态，请检索详细的节点描述。
  $ oc describe node <master_node>
  如果安装问题阻止 OpenShift Container Platform API 运行，或者 kubelet 尚未在每个节点上运行，则无法运行oc命令。
确定 OVN-Kubernetes 状态。
1. 查看openshift-ovn-kubernetes命名空间中的ovnkube-node守护程序集状态。
  $ oc get daemonsets -n openshift-ovn-kubernetes
2. 如果这些资源列为未找到，请查看openshift-ovn-kubernetes命名空间中的 Pod。
  $ oc get pods -n openshift-ovn-kubernetes
3. 查看与openshift-ovn-kubernetes命名空间中失败的 OpenShift Container Platform OVN-Kubernetes Pod 相关的日志。
  $ oc logs <ovn-k_pod> -n openshift-ovn-kubernetes
确定集群网络配置状态。
1. 查看集群的网络配置是否存在。
  $ oc get network.config.openshift.io cluster -o yaml
2. 如果安装程序未能创建网络配置，请再次生成 Kubernetes 清单并查看消息输出。
  $ ./openshift-install create manifests
3. 查看openshift-network-operator命名空间中的 Pod 状态，以确定集群网络 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

控制平面节点启动后，监视控制平面节点上的kubelet.service journald 单元日志。这提供了对控制平面节点代理活动的可见性。

使用oc检索日志。

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

如果 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.17 集群节点是不可变的，并且依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点。在尝试通过 SSH 收集诊断数据之前，请查看运行oc adm must gather和其他oc命令收集的数据是否足够。但是，如果 OpenShift Container Platform API 不可用，或者 kubelet 在目标节点上运行不正常，则oc操作将受到影响。在这种情况下，可以使用ssh core@<node>.<cluster_name>.<base_domain>访问节点。

在控制平面节点启动后，检索控制平面节点上的crio.service journald 单元日志。这提供了对控制平面节点 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
收集控制平面节点上/var/log/下的特定子目录中的日志。
1. 检索/var/log/子目录中包含的日志列表。以下示例列出了所有控制平面节点上/var/log/openshift-apiserver/中的文件。
  $ oc adm node-logs --role=master --path=openshift-apiserver
2. 检查/var/log/子目录中的特定日志。以下示例输出所有控制平面节点上的/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

使用 SSH 查看控制平面节点容器日志。

列出容器。

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

使用crictl检索容器的日志。

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

如果您遇到控制平面节点配置问题，请验证 MCO、MCO 端点和 DNS 记录是否正常运行。机器配置 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_fqdn>替换为引导节点的完全限定域名。
  $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master
5. 引导节点、主节点和工作节点之间的系统时钟时间必须同步。检查每个节点的系统时钟参考时间和时间同步统计信息。
  $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
6. 检查证书有效性。
  $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

调查 etcd 安装问题

如果在安装过程中遇到 etcd 问题，您可以检查 etcd pod 状态并收集 etcd pod 日志。您还可以验证 etcd DNS 记录并检查控制平面节点上的 DNS 可用性。

先决条件

您可以作为具有cluster-admin角色的用户访问集群。
您已安装 OpenShift CLI (oc)。
您可以通过 SSH 访问您的主机。
您拥有控制平面节点的完全限定域名。

步骤

检查 etcd pod 的状态。
1. 查看openshift-etcd命名空间中 pod 的状态。
  $ oc get pods -n openshift-etcd
2. 查看openshift-etcd-operator命名空间中 pod 的状态。
  $ oc get pods -n openshift-etcd-operator
如果前面命令列出的任何 pod 未显示“运行中”或“已完成”状态，请收集该 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>

如果 API 无法运行，请改用 SSH 检查每个控制平面节点上的 etcd pod 和容器日志。将<master-node>.<cluster_name>.<base_domain>替换为适当的值。

列出每个控制平面节点上的 etcd pod。

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

对于任何未显示“就绪”状态的 pod，请详细检查 pod 状态。将<pod_id>替换为前面命令输出中列出的 pod ID。
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <pod_id>
```

列出与 pod 相关的容器。

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

对于任何未显示“就绪”状态的容器，请详细检查容器状态。将<container_id>替换为前面命令输出中列出的容器 ID。
```
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
```

查看任何未显示“就绪”状态的容器的日志。将<container_id>替换为前面命令输出中列出的容器 ID。

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

验证控制平面节点与主 DNS 服务器和辅助 DNS 服务器的连接。

调查控制平面节点 kubelet 和 API 服务器问题

要调查安装期间控制平面节点 kubelet 和 API 服务器问题，请检查 DNS、DHCP 和负载均衡器功能。此外，请验证证书是否未过期。

先决条件

您可以作为具有cluster-admin角色的用户访问集群。
您已安装 OpenShift CLI (oc)。
您可以通过 SSH 访问您的主机。
您拥有控制平面节点的完全限定域名。

步骤

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

检查每个控制平面节点上kubelet.service journald 单元日志。

使用oc检索日志。

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

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

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

检查控制平面节点 kubelet 日志中是否有证书过期消息。

使用oc检索日志。

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

如果 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'

调查工作节点安装问题

如果遇到工作节点安装问题，您可以查看工作节点状态。收集kubelet.service、crio.service journald 单元日志和工作节点容器日志，以了解工作节点代理、CRI-O 容器运行时和 pod 活动。此外，您可以检查 Ignition 文件和 Machine API Operator 功能。如果工作节点安装后配置失败，请检查 Machine Config Operator (MCO) 和 DNS 功能。您还可以验证引导节点、主节点和工作节点之间的系统时钟同步，并验证证书。

先决条件

您可以作为具有cluster-admin角色的用户访问集群。
您已安装 OpenShift CLI (oc)。
您可以通过 SSH 访问您的主机。
您拥有引导节点和工作节点的完全限定域名。
如果您正在使用 HTTP 服务器托管 Ignition 配置文件，则必须拥有 HTTP 服务器的完全限定域名和端口号。您还必须能够通过 SSH 访问 HTTP 主机。

初始kubeadmin密码可在安装主机上的<install_directory>/auth/kubeadmin-password中找到。

步骤

如果您有权访问工作节点的控制台，请监控控制台，直到节点到达登录提示符。在安装过程中，Ignition 日志消息将输出到控制台。
验证 Ignition 文件配置。
- 如果您正在使用 HTTP 服务器托管 Ignition 配置文件。
  1. 验证工作节点 Ignition 文件 URL。将<http_server_fqdn>替换为 HTTP 服务器的完全限定域名。
    
    $ curl -I http://<http_server_fqdn>:<port>/worker.ign (1)
    
    1 -I选项仅返回头部信息。如果 Ignition 文件在指定的 URL 上可用，则命令返回200 OK状态。如果不可用，则命令返回404 file not found。
  2. 要验证工作节点是否已收到 Ignition 文件，请查询 HTTP 主机上的 HTTP 服务器日志。例如，如果您使用 Apache Web 服务器来提供 Ignition 文件。
    
    $ grep -is 'worker.ign' /var/log/httpd/access_log
    
    如果收到工作节点 Ignition 文件，则关联的HTTP GET日志消息将包含200 OK成功状态，表明请求成功。
  3. 如果未收到 Ignition 文件，请直接检查它是否在服务主机上存在。确保已设置适当的文件和 Web 服务器权限。
- 如果您正在使用云提供商机制在主机初始部署过程中注入 Ignition 配置文件。
  1. 查看工作节点的控制台，以确定机制是否正确地注入工作节点 Ignition 文件。
检查工作节点分配的存储设备的可用性。
验证工作节点是否已从 DHCP 服务器分配 IP 地址。
确定工作节点状态。
1. 查询节点状态。
  $ oc get nodes
2. 为任何未显示“就绪”状态的工作节点检索详细的节点描述。
  $ oc describe node <worker_node>
  如果安装问题阻止 OpenShift Container Platform API 运行，或者 kubelet 尚未在每个节点上运行，则无法运行oc命令。
与控制平面节点不同，工作节点是使用 Machine API Operator 部署和缩放的。检查 Machine API Operator 的状态。
1. 查看 Machine API Operator pod 状态。
  $ oc get pods -n openshift-machine-api
2. 如果 Machine API Operator pod 没有“就绪”状态，请详细说明 pod 的事件。
  $ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api
3. 检查machine-api-operator容器日志。该容器运行在machine-api-operatorpod 中。
  $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator
4. 还要检查kube-rbac-proxy容器日志。该容器也运行在machine-api-operatorpod 中。
  $ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy

在工作节点启动后，监控工作节点上的kubelet.service journald 单元日志。这提供了对工作节点代理活动的可见性。

使用oc检索日志。

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

如果 API 无法运行，请改用 SSH 查看日志。将<worker-node>.<cluster_name>.<base_domain>替换为适当的值。

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

在工作节点启动后，检索工作节点上的crio.service journald 单元日志。这提供了对工作节点 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
从工作节点上的/var/log/下的特定子目录收集日志。
1. 检索/var/log/子目录中包含的日志列表。以下示例列出所有工作节点上的/var/log/sssd/中的文件。
  $ oc adm node-logs --role=worker --path=sssd
2. 检查/var/log/子目录中的特定日志。以下示例输出所有工作节点上的/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

使用 SSH 查看工作节点容器日志。

列出容器。

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

使用crictl检索容器的日志。

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

如果遇到工作节点配置问题，请验证 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_fqdn>替换为引导节点的完全限定域名。
  $ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker
5. 引导节点、主节点和工作节点之间的系统时钟时间必须同步。检查每个节点的系统时钟参考时间和时间同步统计信息。
  $ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
6. 检查证书有效性。
  $ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text

安装后查询 Operator 状态

您可以在安装结束时检查 Operator 状态。检索无法访问的 Operator 的诊断数据。查看任何列为Pending或具有错误状态的 Operator Pod 的日志。验证问题 Pod 使用的基础镜像。

先决条件

您可以作为具有cluster-admin角色的用户访问集群。
您已安装 OpenShift CLI (oc)。

步骤

检查安装结束时所有集群 Operator 是否都可用。
```
$ oc get clusteroperators
```

验证所有必需的证书签名请求 (CSR) 是否都已批准。如果存在挂起的 CSR，则某些节点可能无法转为Ready状态，某些集群 Operator 也可能无法访问。

检查 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。

如果 CSR 未批准，在您添加的机器的所有挂起 CSR 状态为Pending后，批准集群机器的 CSR。

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

对于在未启用机器 API 的平台（例如裸机和其他用户预配的基础架构）上运行的集群，您必须实现一种自动批准 kubelet 服务证书请求 (CSR) 的方法。如果未批准请求，则oc exec、oc rsh和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

查看 Operator 事件

$ oc describe clusteroperator <operator_name>

查看 Operator 命名空间内的 Operator Pod 状态
```
$ oc get pods -n <operator_namespace>
```

获取没有Running状态的 Pod 的详细描述

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

检查 Pod 日志

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

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

获取问题 Pod 使用的基础镜像的详细信息

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

列出基础镜像发行版信息

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

收集失败安装的日志

如果您为安装程序提供了 SSH 密钥，则可以收集有关安装失败的数据。

收集不成功安装的日志的命令与收集运行集群的日志的命令不同。如果您必须收集运行集群的日志，请使用oc adm must-gather命令。

先决条件

您的 OpenShift Container Platform 安装在引导过程完成之前失败。引导节点正在运行，并且可以通过 SSH 访问。
您的计算机上ssh-agent进程处于活动状态，并且您为ssh-agent进程和安装程序提供了相同的 SSH 密钥。
如果您尝试在您自己预配的基础架构上安装集群，则必须拥有引导节点和控制平面节点的完全限定域名。

步骤

生成从引导程序和控制平面机器获取安装日志所需的命令

如果您使用了安装程序预配的基础架构，请更改到包含安装程序的目录并运行以下命令：
```
$ ./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> \ (3)
    --master <master_3_address> (3)

1	对于`installation_directory`，请指定运行`./openshift-install create cluster`时指定的相同目录。此目录包含安装程序创建的 OpenShift Container Platform 定义文件。
2	`<bootstrap_address>`是集群引导机器的完全限定域名或 IP 地址。
3	对于集群中的每个控制平面或主控机器，请将`<master_*_address>`替换为其完全限定域名或 IP 地址。

默认集群包含三个控制平面机器。列出所有控制平面机器，无论您的集群使用多少个。

示例输出

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

如果您就安装失败问题打开了 Red Hat 支持案例，请在案例中包含压缩的日志。

其他资源

有关 OpenShift Container Platform 安装类型和过程的更多详细信息，请参阅安装过程。