第 7 章 故障排除
7.1. 安装故障排除
7.1.1. 确定安装问题在哪里发生
当对 OpenShift Container Platform 安装问题进行故障排除时,可以监控安装日志来确定在哪个阶段出现问题。然后,检索与该阶段相关的诊断数据。
OpenShift Container Platform 安装过程包括以下阶段:
- 创建 Ignition 配置文件。
- 启动引导计算机并开始托管要启动的 control plane 机器(也称为 master 机器)所需的远程资源。
- control plane 机器从 bootstrap 机器获取远程资源并完成启动。
- control plane 机器使用 bootstrap 机器组成 etcd 集群。
- bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
- 临时 control plane 将生产环境 control plane 调度到 control plane 机器。
- 临时 control plane 关机,并将控制权交给生产环境 control plane。
- bootstrap 机器将 OpenShift Container Platform 组件添加到生产环境 control plane。
- 安装程序关闭 bootstrap 机器。
- control plane 设置 worker 节点。
- control plane 以一组 Operator 的形式安装其他服务。
- 集群下载并配置日常运作所需的其余组件,包括在受支持的环境中创建 worker 机器。
7.1.2. 用户置备的基础架构安装注意事项
默认安装方法使用安装程序置备的基础架构。对于安装程序置备的基础架构的集群,OpenShift Container Platform 可以管理集群的所有方面,包括操作系统本身。若有可能,可以使用此功能来避免置备和维护集群基础架构。
您也可以在自己提供的基础架构上安装 OpenShift Container Platform 4.7。如果您使用这个安装方法,请完全遵循用户置备的基础架构安装文档中的内容。另外,在安装前请考虑以下事项:
- 查看 Red Hat Enterprise Linux(RHEL)生态系统中的内容来决定您所使用的服务器硬件或虚拟环境可以获得的 Red Hat Enterprise Linux CoreOS(RHCOS)对其支持的级别。
- 很多虚拟化和云环境需要在客户端操作系统中安装代理。确保将这些代理作为通过守护进程集部署的容器化工作负载安装。
如果要启用动态存储、按需服务路由、节点主机名到 Kubernetes 主机名解析以及集群自动扩展等功能,请安装云供应商集成。
注意不可能在混合有不同云供应商,或跨多个物理或虚拟平台的 OpenShift Container Platform 环境中启用云供应商集成。节点生命周期控制器不允许将来自现有供应商外部的节点添加到集群中,且无法指定多个云供应商集成。
- 如果要使用机器集或自动扩展来自动置备 OpenShift Container Platform 集群节点,则需要针对于供应商的 Machine API 实现。
- 检查您所选云供应商是否提供了将 Ignition 配置文件注入主机的方法作为其初始部署的一部分。如果不这样做,则需要使用 HTTP 服务器托管 Ignition 配置文件。解决 Ignition 配置文件问题的步骤会因部署了这两种方法的不同而有所不同。
- 如果要使用可选的框架组件,如嵌入式容器 registry、Elasticsearch 或 Prometheus 等可选框架组件,则需要手动置备存储。除非明确进行了配置,用户置备的基础架构安装中不定义默认存储类。
- 在高可用性 OpenShift Container Platform 环境中,需要一个负载均衡器来在所有 control plane 节点(也称为 master 节点)之间分发 API 请求。您可以使用任何满足 OpenShift Container Platform DNS 路由和端口要求的基于 TCP 的负载平衡解决方案。
7.1.3. 在 OpenShift Container Platform 安装前检查负载均衡器配置
在开始 OpenShift Container Platform 安装前,请检查您的负载均衡器配置。
先决条件
- 已根据选择配置了外部负载均衡器,准备 OpenShift Container Platform 安装。以下示例基于使用 HAProxy 为集群提供负载均衡服务的 Red Hat Enterprise Linux(RHEL)主机。
- 为准备 OpenShift Container Platform 安装已配置了 DNS 准备。
- 有到负载均衡器的 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 Enterprise Linux(RHEL)7 或更高版本中使用
ss
命令而不是netstat
。SS
由 iproute 软件包提供。有关ss
命令的详情请参考 Red Hat Enterprise Linux(RHEL)7 性能调节指南。
检查通配符 DNS 记录是否被解析为负载均衡器:
$ dig <wildcard_fqdn> @<dns_server>
7.1.4. 指定 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
。
7.1.5. openshift-install 命令问题故障排除
如果您在运行 openshift-install
命令时遇到问题,请检查以下内容:
安装过程在 Ignition 配置文件创建后 24 小时内启动。运行以下命令时创建 Ignition 文件:
$ ./openshift-install create ignition-configs --dir=./install_dir
-
install-config.yaml
文件与安装程序位于同一个目录中。如果使用./openshift-install --dir
选项声明了其他不同的安装路径,请验证install-config.yaml
文件是否存在于该目录中。
7.1.6. 监控安装进度
您可以在 OpenShift Container Platform 安装过程中监控高级别安装、bootstrap 和 control plane 日志。这提高了安装过程的可视性,并有助于识别安装失败的阶段。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您需要有到主机的 SSH 访问权限。
您有 bootstrap 和 control plane 节点的完全限定域名(也称为 master 节点)。
注意初始
kubeadmin
密码可在安装主机的<install_directory>/auth/kubeadmin-password
中找到。
流程
在安装过程中监控安装日志:
$ tail -f ~/<installation_directory>/.openshift_install.log
在 bootstrap 节点引导后,监控
bootkube.service
journald 单元日志。这可让您了解第一个 control plane 的 bootstrap。将<bootstrap_fqdn>
替换为 bootstrap 节点的完全限定域名:$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
注意bootstrap 节点上的
bootkube.service
日志会输出 etcdconnection refused
错误,这表示 bootstrap 服务器无法在 control plane 节点上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后,这个错误应该会停止。引导后,监控 control plane 节点上的
kubelet.service
journald 单元日志。这可让您了解 control plane 节点代理活动。使用
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
引导后,监控 control plane 节点上的
crio.service
journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。使用
oc
监控日志:$ oc adm node-logs --role=master -u crio
如果 API 无法正常工作,使用 SSH 来查看日志。将
<master-node>.<cluster_name>.<base_domain>
替换为适当的值:$ ssh core@master-N.cluster_name.sub_domain.domain journalctl -b -f -u crio.service
7.1.7. 收集 bootstrap 节点诊断数据
当遇到与 bootstrap 相关的问题,可以从 bootstrap 节点收集 bootkube.service
journald
单元日志和容器日志。
先决条件
- 具有到 bootstrap 节点的 SSH 访问权限。
- 具有 bootstrap 节点的完全限定域名。
- 如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。
流程
- 如果可以访问 bootstrap 节点的控制台,请监控控制台,直到节点可以提供登录提示。
验证 Ignition 文件配置。
如果您使用 HTTP 服务器托管 Ignition 配置文件。
验证 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
。
要验证 bootstrap 节点是否收到 Ignition 文件,请查询服务主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件,请输入以下命令:
$ grep -is 'bootstrap.ign' /var/log/httpd/access_log
如果收到 bootstrap Ignition 文件,相关的
HTTP GET
日志消息将包含200 OK
成功状态,这表示请求成功。- 如果未收到 Ignition 文件,请检查 Ignition 文件是否存在,是否在服务主机上具有适当的文件和 Web 服务器权限。
如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。
- 查看 bootstrap 节点的控制台,以确定机制是否正确注入 bootstrap 节点 Ignition 文件。
- 验证 bootstrap 节点分配的存储设备是否可用。
- 验证 bootstrap 节点是否已从 DHCP 服务器分配了一个 IP 地址。
从 bootstrap 节点收集
bootkube.service
journald 单元日志。将<bootstrap_fqdn>
替换为 bootstrap 节点的完全限定域名:$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
注意bootstrap 节点上的
bootkube.service
日志会输出 etcdconnection refused
错误,这表示 bootstrap 服务器无法在 control plane 节点(也称为 master 节点)上连接到 etcd。在各个 control plane 节点上启动 etcd 且节点已加入集群后,这个错误应该会停止。从 bootstrap 节点容器收集日志。
使用 bootstrap 节点上的
podman
来收集日志。将<bootstrap_fqdn>
替换为 bootstrap 节点的完全限定域名:$ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'
如果 bootstrap 过程失败,请验证以下内容。
-
您可从安装主机解析
api.<cluster_name>.<base_domain>
。 - 负载均衡器代理端口 6443 连接到 bootstrap 和 control plane 节点。确保代理配置满足 OpenShift Container Platform 安装要求。
-
您可从安装主机解析
7.1.8. 调查 control plane 节点安装问题
如果您遇到 control plane 节点(也称为 master 节点)安装问题,请确定 control plane 节点 OpenShift Container Platform 软件定义的网络 (SDN) 和网络 Operator 状态。收集 kubelet.service
、crio.service
journald 单元日志和 control plane 节点容器日志,以检查 control plane 节点代理、CRI-O 容器运行时和 pod 的情况。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您需要有到主机的 SSH 访问权限。
- 您有 bootstrap 和 control plane 节点的完全限定域名。
如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。
注意初始
kubeadmin
密码可在安装主机的<install_directory>/auth/kubeadmin-password
中找到。
流程
- 如果您可以访问 control plane 节点的控制台,请监控控制台,直到节点可以提供登录提示。在安装过程中,Ignition 日志消息输出到控制台。
验证 Ignition 文件配置。
如果您使用 HTTP 服务器托管 Ignition 配置文件。
验证 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
。
要验证 control plane 节点是否收到 Ignition 文件,请查询服务主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件:
$ grep -is 'master.ign' /var/log/httpd/access_log
如果收到 master Ignition 文件,相关的
HTTP GET
日志消息将包含200 OK
成功状态,表示请求成功。- 如果未收到 Ignition 文件,请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。
如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。
- 查看 control plane 节点的控制台,以确定机制是否正确注入 control plane 节点 Ignition 文件。
- 检查分配给 control plane 节点的存储设备是否可用。
- 验证 control plane 节点是否已从 DHCP 服务器分配了一个 IP 地址。
确定 control plane 节点状态。
查询 control plane 节点状态:
$ oc get nodes
如果一个 control plane 节点没有处于
Ready
状态,检索详细的节点描述:$ oc describe node <master_node>
注意如果某个安装问题导致 OpenShift Container Platform API 无法运行,或者 kubelet 还没有在每个节点上运行,则无法运行
oc
命令:
确定 OpenShift Container Platform SDN 状态。
在
openshift-sdn
命名空间内查看sdn-controller
、sdn
和ovs
守护进程集的状态:$ oc get daemonsets -n openshift-sdn
如果这些资源列为
Not found
,查看openshift-sdn
命名空间中的 pod:$ oc get pods -n openshift-sdn
检查
openshift-sdn
命名空间中与失败的 OpenShift Container Platform SDN pod 相关的日志:$ oc logs <sdn_pod> -n openshift-sdn
确定集群网络配置状态。
查看集群的网络配置是否存在:
$ oc get network.config.openshift.io cluster -o yaml
如果安装程序无法创建网络配置,请再次生成 Kubernetes 清单并查看消息输出:
$ ./openshift-install create manifests
查看
openshift-network-operator
命名空间中的 pod 状态,以确定 Cluster Network Operator(CNO)是否在运行:$ oc get pods -n openshift-network-operator
从
openshift-network-operator
命名空间中收集网络 Operator pod 日志:$ oc logs pod/<network_operator_pod_name> -n openshift-network-operator
引导后,监控 control plane 节点上的
kubelet.service
journald 单元日志。这可让您了解 control plane 节点代理活动。使用
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.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行
oc adm must gather
和其他oc
命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。
引导后,在 control plane 节点上检索
crio.service
journald 单元日志。这可让您了解 control plane 节点 CRI-O 容器运行时的活动。使用
oc
检索日志:$ oc adm node-logs --role=master -u crio
如果 API 无法正常工作,使用 SSH 来查看日志:
$ ssh core@<master-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
从 control plane 节点上的
/var/log/
下的特定子目录收集日志。获取
/var/log/
子目录中所含的日志列表。以下示例列出所有 control plane 节点上的/var/log/openshift-apiserver/
中的文件:$ oc adm node-logs --role=master --path=openshift-apiserver
检查
/var/log/
子目录中的特定日志。以下示例输出来自所有 control plane 节点的/var/log/openshift-apiserver/audit.log
内容:$ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
如果 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 查看 control plane 节点容器日志。
列出容器:
$ 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>
如果您遇到 control plane 节点配置问题,请验证 MCO、MCO 端点和 DNS 记录是否正常工作。Machine Config Operator(MCO)在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。
测试 MCO 端点是否可用。将
<cluster_name>
替换为适当的值:$ curl https://api-int.<cluster_name>:22623/config/master
- 如果端点不响应,请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。
验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。
对定义的 MCO 端点名称运行 DNS 查找:
$ dig api-int.<cluster_name> @<dns_server>
在负载均衡器上对分配的 MCO IP 地址进行逆向查询:
$ dig -x <load_balancer_mco_ip_address> @<dns_server>
验证 MCO 是否直接从 bootstrap 节点运行。将
<bootstrap_fqdn>
替换为 bootstrap 节点的完全限定域名:$ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/master
系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息:
$ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
检查证书的有效性:
$ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text
7.1.9. 解决 etcd 安装问题
如果在安装过程中遇到 etcd 问题,您可以检查 etcd pod 状态并收集 etcd pod 日志。您还可以验证 etcd DNS 记录并检查 control plane 节点上的 DNS 可用性(也称为 master 节点)。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您需要有到主机的 SSH 访问权限。
- 您有 control plane 节点的完全限定域名。
流程
检查 etcd pod 的状态。
查看
openshift-etcd
命名空间中的 pod 状态:$ oc get pods -n openshift-etcd
查看
openshift-etcd-operator
命名空间中的 pod 状态:$ oc get pods -n openshift-etcd-operator
如果以上命令中列出的任何 pod 没有显示
Running
或Completed
状态,请为 pod 收集诊断信息。检查 pod 的事件:
$ oc describe pod/<pod_name> -n <namespace>
检查 pod 的日志:
$ oc logs pod/<pod_name> -n <namespace>
如果 pod 有多个容器,以上命令会创建一个错误并在错误消息中提供容器名称。检查每个容器的日志:
$ oc logs pod/<pod_name> -c <container_name> -n <namespace>
如果 API 无法正常工作,请使用 SSH 来查看每个 control plane 节点上的 etcd pod 和容器日志。将
<master-node>.<cluster_name>.<base_domain>
替换为适当的值。列出每个 control plane 节点上的 etcd pod:
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods --name=etcd-
对于没有显示
Ready
状态的 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>'
对于没有显示
Ready
状态的容器,请详细检查容器状态。将<container_id>
替换为上一命令输出中列出的容器 ID:$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
检查任何未显示
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.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行
oc adm must gather
和其他oc
命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。
- 验证 control plane 节点的主和从属 DNS 服务器连接。
7.1.10. 调查 control plane 节点 kubelet 和 API 服务器问题
要在安装过程中调查 control plane 节点(也称为 master 节点)kubelet 和 API 服务器问题,请检查 DNS、DHCP 和负载均衡器功能。另外,请确认证书没有过期。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您需要有到主机的 SSH 访问权限。
- 您有 control plane 节点的完全限定域名。
流程
-
验证 API 服务器的 DNS 记录是否将 control plane 节点上的 kubelet 定向到
https://api-int.<cluster_name>.<base_domain>:6443
。确保记录引用负载均衡器。 - 确保负载均衡器的端口 6443 定义引用每个 control plane 节点。
- 检查 DHCP 是否提供了唯一的 control plane 节点主机名。
检查每个 control plane 节点上的
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.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行
oc adm must gather
和其他oc
命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。
检查 control plane 节点 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'
7.1.11. 调查 worker 节点安装问题
如果遇到 worker 节点安装问题,可以查看 worker 节点的状态。收集 kubelet.service
、crio.service
journald 单元日志和 worker 节点容器日志,以检查 worker 节点代理、CRI-O 容器运行时和 pod 的情况。另外,还可以检查 Ignition 文件和 Machine API Operator 是否正常工作。如果 worker 节点安装后配置失败,检查 Machine Config Operator(MCO)和 DNS 是否正常工作。您还可以验证 bootstrap、master 和 worker 节点之间的系统时钟是否同步,并验证证书。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。 - 您需要有到主机的 SSH 访问权限。
- 您有 bootstrap 和 worker 节点的完全限定域名。
如果使用 HTTP 服务器托管 Ignition 配置文件,则必须具有 HTTP 服务器的完全限定域名和端口号。还必须有到 HTTP 主机的 SSH 访问权限。
注意初始
kubeadmin
密码可在安装主机的<install_directory>/auth/kubeadmin-password
中找到。
流程
- 如果可以访问 worker 节点的控制台,请监控控制台,直到节点可以提供登录提示。在安装过程中,Ignition 日志消息输出到控制台。
验证 Ignition 文件配置。
如果您使用 HTTP 服务器托管 Ignition 配置文件。
验证 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
。
要验证 worker 节点是否收到 Ignition 文件,请查询 HTTP 主机上的 HTTP 服务器日志。例如,如果您使用 Apache web 服务器提供 Ignition 文件:
$ grep -is 'worker.ign' /var/log/httpd/access_log
如果收到 worker Ignition 文件,相关的
HTTP GET
日志消息将包含200 OK
成功状态,表示请求成功。- 如果未收到 Ignition 文件,请检查是否直接存在于服务主机上。确定有适当的文件权限和网页服务器权限。
如果您使用云供应商机制将 Ignition 配置文件注入主机作为其初始部署的一部分。
- 查看 worker 节点的控制台,以确定机制是否正确注入 worker 节点 Ignition 文件。
- 检查 worker 节点分配的存储设备是否可用。
- 验证 worker 节点是否已从 DHCP 服务器分配了一个 IP 地址。
确定 worker 节点状态。
查询节点状态:
$ oc get nodes
获取没有显示
Ready
状态的 worker 节点的详细节点描述:$ oc describe node <worker_node>
注意如果某个安装问题导致 OpenShift Container Platform API 无法运行,或者 kubelet 还没有在每个节点上运行,则无法运行
oc
命令。
与 control plane 节点(也称为 master 节点)不同,worker 节点使用 Machine API Operator 部署和扩展。检查 Machine API Operator 的状态。
查看 Machine API Operator pod 状态:
$ oc get pods -n openshift-machine-api
如果 Machine API Operator pod 没有处于
Ready
状态,请详细列出 pod 的事件:$ oc describe pod/<machine_api_operator_pod_name> -n openshift-machine-api
检查
machine-api-operator
容器日志。容器在machine-api-operator
pod 中运行:$ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c machine-api-operator
同时检查
kube-rbac-proxy
容器日志。容器也会在machine-api-operator
pod 中运行:$ oc logs pod/<machine_api_operator_pod_name> -n openshift-machine-api -c kube-rbac-proxy
引导后,监控 worker 节点上的
kubelet.service
journald 单元日志。这可让您了解 worker 节点代理活动。使用
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
注意运行 Red Hat Enterprise Linux CoreOS(RHCOS)的 OpenShift Container Platform 4.7 集群节点不可变,它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点,节点将会标记为 accessed 污点。在尝试通过 SSH 收集诊断数据前,请运行
oc adm must gather
和其他oc
命令看它们是否可以提供足够的数据。但是,如果 OpenShift Container Platform API 不可用,或 kubelet 在目标节点上无法正常工作,oc
操作将会受到影响。在这种情况下,可以使用ssh core@<node>.<cluster_name>.<base_domain>
来访问节点。
引导后,在 worker 节点上获取
crio.service
journald 单元日志。这可让您了解 worker 节点 CRI-O 容器运行时的活动。使用
oc
检索日志:$ oc adm node-logs --role=worker -u crio
如果 API 无法正常工作,使用 SSH 来查看日志:
$ ssh core@<worker-node>.<cluster_name>.<base_domain> journalctl -b -f -u crio.service
从 worker 节点上的
/var/log/
下的特定子目录收集日志。获取
/var/log/
子目录中所含的日志列表。以下示例列出所有 worker 节点上/var/log/sssd/
中的文件:$ oc adm node-logs --role=worker --path=sssd
检查
/var/log/
子目录中的特定日志。以下示例输出来自所有 worker 节点的/var/log/sssd/audit.log
内容:$ oc adm node-logs --role=worker --path=sssd/sssd.log
如果 API 无法正常工作,请使用 SSH 来查看每个节点上的日志。以下示例显示
/var/log/sssd/sssd.log
的尾部信息:$ ssh core@<worker-node>.<cluster_name>.<base_domain> sudo tail -f /var/log/sssd/sssd.log
使用 SSH 查看 worker 节点容器日志。
列出容器:
$ 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>
如果您遇到 worker 节点配置问题,检查 MCO、MCO 端点和 DNS 记录是否正常运行。Machine Config Operator(MCO)在安装过程中管理操作系统配置。同时还要检查系统时钟准确性以及证书的有效性。
测试 MCO 端点是否可用。将
<cluster_name>
替换为适当的值:$ curl https://api-int.<cluster_name>:22623/config/worker
- 如果端点不响应,请验证负载均衡器配置。确保端点配置为在端口 22623 上运行。
验证 MCO 端点的 DNS 记录是否已配置并解析到负载均衡器。
对定义的 MCO 端点名称运行 DNS 查找:
$ dig api-int.<cluster_name> @<dns_server>
在负载均衡器上对分配的 MCO IP 地址进行逆向查询:
$ dig -x <load_balancer_mco_ip_address> @<dns_server>
验证 MCO 是否直接从 bootstrap 节点运行。将
<bootstrap_fqdn>
替换为 bootstrap 节点的完全限定域名:$ ssh core@<bootstrap_fqdn> curl https://api-int.<cluster_name>:22623/config/worker
系统时钟时间必须在 bootstrap、master 和 worker 节点间保持同步。检查每个节点的系统时钟参考时间和时间同步统计信息:
$ ssh core@<node>.<cluster_name>.<base_domain> chronyc tracking
检查证书的有效性:
$ openssl s_client -connect api-int.<cluster_name>:22623 | openssl x509 -noout -text
7.1.12. 安装后查询 Operator 状态
您可以在安装结束时检查 Operator 状态。检索不可用的 Operator 的诊断数据。检查所有列为 Pending
或具有错误状态的 Operator pod 的日志。验证有问题的 pod 所使用的基础镜像。
先决条件
-
您可以使用具有
cluster-admin
角色的用户访问集群。 -
已安装 OpenShift CLI(
oc
)。
流程
检查安装结束时,是否所有集群 Operator 都可用。
$ oc get clusteroperators
验证所有所需的证书签名请求(CSR)是否已批准。有些节点可能无法变为
Ready
状态,且有些集群 Operator 可能无法使用(如果待处理的 CSR)。检查 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 ...
在本例中,两台机器加入了集群。您可能会在列表中看到更多已批准的 CSR。
如果 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
查看 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
7.1.13. 从失败安装中收集日志
如果您为安装程序提供了 SSH 密钥,则可以收集有关失败安装的数据。
与从正在运行的集群收集日志相比,您可以使用其他命令收集失败安装的日志。如果必须从正在运行的集群中收集日志,请使用 oc adm must-gather
命令。
先决条件
- 在 bootstrap 过程完成前,OpenShift Container Platform 安装会失败。bootstrap 节点正在运行,并可通过 SSH 访问。
-
ssh-agent
进程在您的计算机上处于活跃状态,并且为ssh-agent
进程和安装程序提供了相同的 SSH 密钥。 - 如果尝试在您置备的基础架构上安装集群,则必须具有 bootstrap 和 control plane 节点(也称为 master 节点)的完全限定域名。
流程
生成从 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
注意默认集群包含三台 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"
如果需要创建关安装失败的红帽支持问题单,请在问题单中附上压缩日志。
7.1.14. 其他资源
- 如需了解更多与 OpenShift Container Platform 安装类型和流程相关的详细信息,请参阅安装过程。