对处于 Critical 或 NotReady 状态的工作程序节点进行故障诊断

集群工作程序节点在停止与集群主节点通信时将进入 Critical 或 NotReady 状态。 当此情况发生时，您的工作节点在 IBM Cloud UI 中会被标记 Critical 为，或在执行 ibmcloud oc worker 命令时显示为；在 Red Hat OpenShift 仪表板中则显示 NotReady 为，或在执行 时显示为 oc get nodes。 有几个原因导致工作程序节点与集群主节点之间的通信停止。 遵循以下步骤对处于这些状态的工作程序节点进行故障诊断。

请查看 IBM Cloud 健康与状态仪表板，查看是否有与您的工作节点相关的通知或维护更新。 这些通知或更新可能有助于确定工作程序节点故障的原因。

检查工作程序节点故障的常见原因

有几个原因导致工作程序节点与集群主节点之间的通信停止。 检查以下常见问题是否导致中断。

已删除，重新装入，更新，替换或重新引导工作程序
工作程序节点在被删除，重新装入，更新或替换时，可能会临时显示 Critical 或 NotReady 状态。 如果已在工作程序节点上启动任何这些操作 (无论是手动操作还是作为自动化设置 (例如，集群自动缩放器) 的一部分)，请等待这些操作完成。 然后，再次检查工作程序节点的状态。 如果任何工作程序仍处于 Critical 或 NotReady 状态，请 重新装入 或 替换 受影响的工作程序。
如果工作程序节点已重新装入或更换，并且最初工作正常，但一段时间后返回到 Critical 或 NotReady 状态，那么工作程序上的某些工作负载或组件可能导致该问题。 请参阅 调试工作程序节点 以隔离问题工作负载。

如果工作程序节点在未首先被封锁和排出的情况下重新引导，那么该工作程序节点可能最终处于 Critical 或 NotReady 状态。 如果是这种情况，那么等待重新引导完成不会解决此问题。 重新装入 或 替换 受影响的工作程序。 如果问题仍然存在，请继续执行故障诊断步骤。

工作程序节点已无意中断电
经典集群 在IBM Cloud 控制台资源列表中，经典基础架构上的工作程序节点分类为 计算资源或虚拟机。 有时，用户可能不会意识到这些资源充当集群工作程序节点，并且可能会无意中关闭工作程序节点的电源。 断电的工作程序节点可能显示为 Critical 或 NotReady 状态。 确保受影响的工作程序节点未断电。

故障诊断步骤

如果在解决 常见原因 之后工作程序节点仍处于 Critical 或 NotReady 状态，请继续执行以下故障诊断步骤。

如果先前重新装入或替换的工作程序节点在运行 ibmcloud ks workers 时处于 deploy_failed 或 provision_failed 状态，请遵循 集群中的所有工作程序节点都受影响 部分中的步骤，即使并非所有节点都受影响。 如果指示了其他状态，请参阅 工作程序节点状态 以获取对新工作程序进行故障诊断的步骤。 请勿替换或重新装入任何其他工作程序节点。

如果一个或多个工作程序节点受影响

如果集群中只有部分 (而不是全部) 工作程序节点处于 Critical 或 NotReady 状态，请执行以下步骤以确定中断原因并解决问题。 如果受影响的工作程序节点全部来自同一区域，子网或 VLAN，请继续下一节。

  1. 获取特定节点的详细信息。

    oc describe node <node-IP-address>

  2. 在输出中，检查 条件 部分以确定节点是否迂到任何内存，磁盘或 PID 问题。 此信息可能指示节点在该类型的资源上运行不足。 出现这种情况可能是由于以下原因之一：

    • 由于 pod 上缺少正确的请求和限制而导致内存或 CPU 耗尽。
    • 工作程序磁盘已满，有时是因为节点本身的大型 pod 日志或 pod 输出。
    • 随着时间的推移而积累的内存泄漏缓慢，这可能会导致在一个多月内未更新的工作程序出现问题。
    • 影响 Linux 内核的错误和崩溃。

  3. 如果您能够根据 条件 部分中的信息确定问题的原因，请遵循 调试工作程序节点 中的步骤来隔离问题工作负载。

  4. 如果先前步骤未解决问题，请 重新装入 或一次 更换 受影响的工作程序。

如果单个专区，子网或 VLAN 中的所有工作程序节点都受影响

如果一个区域、子网或 VLAN 中的所有工作节点都处于 Critical 或 NotReady 状态，但群集中的所有其他工作节点都正常运行，则可能是网络组件出现了问题。 请遵循 如果集群中的所有工作程序节点都受影响 中的步骤，特别是有关可能影响专区，子网或 VLAN 的任何联网组件 (例如防火墙或网关规则，ACL 或定制路由，或者 Calico 和 Kubernetes 网络策略) 的步骤。

如果您检查了网络组件，但仍无法解决问题，请 收集工作程序节点数据 并开具支持凭单。

如果集群中的所有工作程序节点都受影响

如果集群中的所有工作程序节点同时显示 Critical 或 NotReady，那么集群 apiserver 或工作程序与 apiserver 之间的网络路径可能存在问题。 请遵循以下故障诊断步骤来确定原因并解决问题。

某些步骤特定于专用区域，例如联网或自动化。 在完成这些步骤之前，请咨询组织中的相关管理员或团队。

  1. 检查集群，环境或帐户最近是否有任何可能影响工作程序节点的更改。 如果是这样，请还原这些更改，然后检查工作程序节点状态以确定这些更改是否导致问题。

    • 对于经典集群，请检查用于管理集群工作程序流量的任何防火墙或网关，例如 Virtual Router Appliance，Vyatta 或 Juniper。 查找可能会删除或重定向来自集群工作程序的流量的更改或问题。
    • 对于 VPC 集群，请检查是否对 VPC 或工作程序节点上的缺省安全组和 ACL 进行了任何更改。 如果进行了任何修改，请确保允许从集群工作程序节点到集群主节点，容器注册表和其他关键服务的所有必需流量。 有关更多信息，请参阅 了解默认情况下的安全群集 VPC 网络 以及 创建和管理 VPC 安全组和 使用 ACL 控制流量。
    • 对于 VPC 集群，请检查任何定制路由规则，以了解可能阻止来自集群 apiserver 的流量的更改。
    • 检查应用于集群的任何 Calico 或 Kubernetes 网络策略，并确保它们不会阻止从工作程序节点到集群 apiservice，容器注册表或其他关键服务的流量。

  2. 检查集群中的应用程序，安全性或监视组件是否正在使用请求重载集群 apiserver，这可能会导致工作程序节点中断。

  3. 如果最近向集群添加了任何组件，请将其除去。 如果对集群中的任何现有组件进行了更改，请还原这些更改。 然后，检查工作程序节点的状态以查看新组件或更改是否导致该问题。

  4. 检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。 检查拒绝请求的网络钩子。 运行以下命令，获取拒绝请求的网络钩子列表。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. 查看具有 "rejected="true" 状态的网络钩子的输出。

  6. 除去并重新生成任何定制 Docker 拉取私钥，如果配置错误，可能会阻止工作程序节点从 Docker 注册表拉取映像。

    1. 运行 oc delete secret -n openshift pull-secret 和 oc delete secret -n openshift-config pull-secret 命令以删除定制 Docker 拉取私钥。
        oc delete secret -n openshift pull-secret
    ```
    ```sh {: pre}
    oc delete secret -n openshift-config pull-secret
    ```
1. 等待集群重新生成定制 Docker 拉取私钥。 重新生成的拉取私钥中不再存在任何配置错误的组件。

  7. 检查您的工作节点状态。 如果它们处于 Normal 状态，请逐个重新添加任何已删除的组件并重新创建任何已还原的更改，直到您可以确定导致工作程序节点中断的配置或组件为止。

  8. 如果问题仍未解决，请执行以下步骤以 收集工作程序节点数据 并提交支持凭单。

如果工作程序节点在正常状态和临界状态之间切换

如果工作程序节点在 Normal 与 Critical 或 NotReady 状态之间切换，请检查以下组件以了解可能中断工作程序节点的任何问题或最新更改。

  1. 对于经典集群，请检查防火墙或网关。 如果存在带宽限制或任何类型的故障，请解决问题。 然后，再次检查工作程序节点。

  2. 检查集群中的应用程序，安全性或监视组件是否正在使用请求重载集群 apiserver，这可能会导致工作程序节点中断。

  3. 如果最近向集群添加了任何组件，请将其除去。 如果对集群中的任何现有组件进行了更改，请还原这些更改。 然后，检查工作程序节点的状态以查看新组件或更改是否导致该问题。

  4. 检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。 检查拒绝请求的网络钩子。 运行以下命令，获取拒绝请求的网络钩子列表。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. 查看具有 "rejected="true" 状态的网络钩子的输出。

  6. 如果问题仍未解决，请执行以下步骤以 收集工作程序节点数据 并提交支持凭单。

收集支持案例的数据

如果无法解决故障诊断步骤的问题，请收集有关工作程序节点的信息。 然后，提交支持凭单 并包含您收集的工作程序节点信息。

在提交支持凭单之前，请查看信息并遵循 调试工作程序节点，工作程序节点状态 和 对处于 Critical 或 NotReady 状态的工作程序节点进行故障诊断 中的任何故障诊断步骤。

如果群集中或一个区域、子网或 VLAN 中的所有工作节点都受到影响，您可以在不收集数据的情况下打开初始支持单。 但是，稍后可能会要求您收集相关数据。 如果只有一个或部分工作程序节点受到影响，那么必须收集要包含在支持凭单中的相关数据。

准备工作

在收集数据之前，请检查工作程序节点和集群的条件。

  1. 检查节点的 CPU 和内存级别。 如果任何节点的 CPU 或内存使用率超过 80%，请考虑供应更多节点或减少工作负载。

    oc top node

    示例输出

    NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
10.001.1.01     640m         16%    6194Mi          47%       
10.002.2.02     2686m        68%    4024Mi          30%       
10.003.3.03     2088m        53%    10735Mi         81%

  2. 检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。 检查拒绝请求的网络钩子。 运行以下命令，获取拒绝请求的网络钩子列表。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  3. 查看具有 "rejected="true" 状态的网络钩子的输出。

正在收集数据

执行以下步骤以收集相关工作程序节点数据。

  1. 获取每个节点的详细信息。 保存要包含在支持凭单中的输出详细信息。

    oc describe node <node-ip-address>

  2. 显示没有添加通过获取 Webhook 详细信息来突变或验证集群中剩余的 Webhook。 保存要包含在支持凭单中的命令输出。 请注意，以下突变 Webhook 可能仍存在并且不需要删除: alertmanagerconfigs.openshift，managed-storage-validation-webhooks，multus.openshift.io，performance-addon-operator，prometheusrules.openshift.io 和 snapshot.storage.k8s.io。

    kubectl get mutatingwebhookconfigurations

    kubectl get validatingwebhookconfigurations

  3. 经典集群: 访问其中一个受影响工作程序的 KVM 控制台。 然后，收集相关日志和输出。

    1. 执行以下步骤以访问 KVM 控制台。
    2. 收集并保存以下日志。 查看日志以了解工作程序节点中断的可能原因，例如缺少内存或磁盘空间，磁盘进入只读方式以及其他问题。
      • /var/log/boot.log
      • /var/log/calico/cni/cni.log
      • /var/log/crio.log
      • /var/log/cron
      • /var/log/messages
      • /var/log/secure
    3. 运行以下命令并保存输出以附加到支持凭单。
      • ps -aux # 转储正在运行的进程
      • df -H # 转储磁盘使用情况信息
      • vmstat # 转储内存使用情况信息
      • lshw # 转储硬件信息
      • last -Fxn2 shutdown reboot # 确定上次重新启动是否正常
      • mount | grep -i "(ro" # 以排除磁盘只读问题。 注: tmpfs 正在 ro 正常运行
      • touch /this # 以排除磁盘只读问题

  4. VPC 群集：使用 kubectl top 命令收集工作节点的资源使用情况，如下例所示。

    kubectl top nodes

    示例输出以毫微米（m）为单位显示 CPU 使用情况，以兆字节（Mi）为单位显示内存使用情况。

    NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
k8s-node-1      250m              12%    800Mi                         40%
k8s-node-2      180m               9%     600Mi                         30%
k8s-node-3      250m               22%    700Mi                        50%
    名称
    节点的名称。
    CPU（核心数）
    当前 CPU 使用率，单位为毫核 (m)。1000m 等于 1 个内核。
    CPU使用率
    节点 CPU 总容量的百分比。
    内存（字节）
    当前内存使用量，单位为 MiB （兆字节）或 GiB （千兆字节）。
    内存
    所用内存容量占总内存容量的百分比。

    CPU% 或 MEMORY% 较高（超过 80%）的节点可能已超负荷，需要额外资源。 CPU% 或 MEMORY% 较低（低于 20%）的节点可能未得到充分利用，这表明仍有重新分配工作负载的余地。 如果节点的 CPU 或内存使用率达到 100%，新的工作负载可能无法调度或出现性能下降。

  5. 使用以下命令收集 pod 的资源使用情况。

    kubectl top pods --all-namespaces

    示例输出

    NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
default            my-app-564bc58dad-hk5gn       120m            256Mi
default             my-db-789d9c6c4f-tn7mv         300m            512Mi
    名称
    pod 的名称。
    CPU（核心数）
    pod 在所有容器中使用的 CPU 总量。
    内存（字节）
    pod 在所有容器中使用的内存总量。

    如果 pod 的 CPU 占用率较高，则可能存在 CPU 节流，从而影响性能。 若某个进程组的内存使用量接近其限制，则可能面临内存不足（OOM）错误的风险，此时 Kubernetes 系统会终止进程以释放内存。 资源使用率低的 pod 可能会有过度分配的请求，导致资源浪费。

  6. 运行 top pod 命令检查容器级指标。

    kubectl top pod pod-a --containers -n appns
```sh
{: pre}
Example output
```sh
NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
pod-a            app-container        100m         300Mi
pod-a            db-container           50m          200Mi
```sh
{: screen}

  7. kubectl top 命令只显示实际使用情况，不显示请求的或有限的资源。 要比较和分析 top 命令的输出结果，请使用以下命令检查 pod 规范。

    kubectl describe pod <pod-name> -n <namespace>

    示例输出

    Containers:
 app-container:
   Requests:
  cpu: 250m
  memory: 512Mi
  Limits:
  cpu: 500m
  memory: 1Gi

    如果 CPU 或内存使用量超出请求，则可能表明供应不足，从而导致性能问题。 如果使用量接近限制，容器可能会在资源紧张时被节流或终止。 如果使用量大大低于请求量，则 pod 可能被过度配置，造成资源浪费。

  8. 确定哪些 pod 消耗的 CPU 最多。

    kubectl top pod --all-namespaces | sort -k3 -nr | head -10

  9. 识别高内存消耗 pod。

    kubectl top pod --all-namespaces | sort -k4 -nr | head -10

  10. 监控系统守护进程的资源使用情况。 DaemonSets, 如 或监控代理，可能会消耗意想不到的资源。kube-proxy

    kubectl top pod -n kube-system
```sh
{: pre}

  11. 如果某些系统 pod 消耗过多 CPU 或内存，可能需要调整请求和限制。 要连续跟踪资源变化，请使用 watch 命令。

    watch -n 5 kubectl top pod --all-namespaces
```sh
{: pre}
This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.

  12. 查看 OOMKilled 活动。 当 Kubernetes 报告 OOMKilled 时，pod 超过了内存限制并被终止。 pod 的状态更改为 crashloopbackoff。

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace

  13. 在日志中查找 OOM 消息。

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"

  14. 检查容器的最后状态 OOM 终止。

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"

收集工作节点日志

请按照以下步骤 访问 Worker 并收集 Worker 节点日志。

  1. 收集并保存以下日志文件。 查看日志以了解工作程序节点中断的可能原因，例如缺少内存或磁盘空间，磁盘进入只读方式以及其他问题。

    • /var/log/containerd.log
    • /var/log/kern.log
    • /var/log/kube-proxy.log
    • /var/log/syslog
    • /var/log/kubelet.log

  2. 运行以下命令并保存输出以附加到支持凭单。

    获取容器统计信息（需要 SSH 访问节点）。

    crictl stats

    获取特定容器的详细统计信息。

    crictl stats --id <container-id> --output json

    运行该命令转储正在运行的进程。

    ps -aux

    动态、实时地查看正在运行的进程和内核管理的任务，以及资源利用情况，包括 CPU 和内存使用情况。

    top

    获取当前系统状态。

    htop

    获取包含历史数据的全面监控报告。

    atop

    获取系统进程的实时信息

    btop

    获取网络连接详细信息。

    netstat

    获取磁盘使用信息。

    df -H

    运行 vmstat，获取有关进程、内存、分页、块 IO、陷阱和 CPU 活动的报告。 该命令以 2 秒钟为间隔获取信息，共 5 次。

    vmstat 2 5

    运行 iostat，收集磁盘使用统计数据，包括吞吐量、利用率、队列长度、事务处理率等。

    iostat -x 1 5

    收集硬件信息。

    lshw

    使用下面的命令查看上次重启是否优雅。

    last -Fxn2 shutdown reboot

    为排除磁盘问题，请确认磁盘是否可写。

    mount | grep -i "(ro"
touch /this

  3. 如果问题仍然存在，请 开立支持票据，并附上前面步骤中保存的所有输出结果。