7.2. 验证节点健康状况

流程

1. kubelet 通过每个节点上的 systemd 服务来管理。通过在 debug pod 中查询 kubelet systemd 服务来查看 kubelet 的状态。

   1. 为节点启动 debug pod:

      $ oc debug node/my-node

      注意

      如果您在 control plane 节点上运行 oc debug，可以在 /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs 目录中找到管理 kubeconfig 文件。

   2. 将 /host 设置为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /host，您可以运行主机可执行路径中包含的二进制文件：

      # chroot /host

      注意

      运行 Red Hat Enterprise Linux CoreOS（RHCOS）的 OpenShift Container Platform 集群节点不可变，它依赖于 Operator 来应用集群更改。不建议使用 SSH 访问集群节点，节点将会标记为 accessed 污点。但是，如果 OpenShift Container Platform API 不可用，或 kubelet 在目标节点上无法正常工作, oc 操作将会受到影响。在这种情况下，可以使用 ssh core@<node>.<cluster_name>.<base_domain> 来访问节点。

   3. 检查 kubelet systemd 服务是否在该节点上活跃：

      # systemctl is-active kubelet

   4. 输出更详细的 kubelet.service 状态概述：

      # systemctl status kubelet

流程

1. 查询 OpenShift Container Platform 集群节点的 kubelet journald 单元日志。以下示例仅查询 control plane 节点：

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

   1

   根据情况替换 kubelet 以查询其他单元日志。

2. 从集群节点上 /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

      注意

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