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

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

检查 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，请继续下一节。

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

kubectl describe node <node-IP-address>

在输出中，检查条件部分以确定节点是否迂到任何内存，磁盘或 PID 问题。此信息可能指示节点在该类型的资源上运行不足。出现这种情况可能有以下原因：
- 由于 pod 上缺少正确的请求和限制而导致内存或 CPU 耗尽。
- 工作程序磁盘已满，有时是因为节点本身的大型 pod 日志或 pod 输出。
- 随着时间的推移而积累的内存泄漏缓慢，这可能会导致在一个多月内未更新的工作程序出现问题。
- 影响 Linux 内核的错误和崩溃。
如果您能够根据条件部分中的信息确定问题的原因，请遵循调试工作程序节点中的步骤来隔离问题工作负载。
如果先前步骤未解决问题，请重新装入或一次更换受影响的工作程序。

如果某些 (但并非所有) 工作程序节点频繁进入 Critical 或 NotReady 状态，请考虑启用工作程序自动恢复以自动执行这些恢复步骤。

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

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

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

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

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

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

检查集群，环境或帐户最近是否有任何可能影响工作程序节点的更改。如果是这样，请还原这些更改，然后检查工作程序节点状态以确定这些更改是否导致问题。
- 对于经典集群，请检查用于管理集群工作程序流量的任何防火墙或网关，例如 Virtual Router Appliance，Vyatta 或 Juniper。查找可能会删除或重定向来自集群工作程序的流量的更改或问题。
- 对于 VPC 集群，请检查是否对 VPC 或工作程序节点上的缺省安全组和 ACL 进行了任何更改。如果进行了任何修改，请确保允许从集群工作程序节点到集群主节点，容器注册表和其他关键服务的所有必需流量。有关更多信息，请参阅使用 VPC 安全组控制流量和使用 ACL 控制流量。
- 对于 VPC 集群，请检查任何定制路由规则，以了解可能阻止来自集群 apiserver 的流量的更改。
- 检查应用于集群的任何 Calico 或 Kubernetes 网络策略，并确保它们不会阻止从工作程序节点到集群 apiservice，容器注册表或其他关键服务的流量。
检查集群中的应用程序，安全性或监视组件是否正在使用请求重载集群 apiserver，这可能会导致工作程序节点中断。
如果最近向集群添加了任何组件，请将其除去。如果对集群中的任何现有组件进行了更改，请还原这些更改。然后，检查工作程序节点的状态以查看新组件或更改是否导致该问题。
检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。检查拒绝请求的网络钩子。运行以下命令，获取拒绝请求的网络钩子列表。
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
查看具有 "rejected="true" 状态的网络钩子的输出。
检查工作节点的状态如果它们处于 Normal 状态，请逐个重新添加任何已删除的组件并重新创建任何已还原的更改，直到您可以确定导致工作程序节点中断的配置或组件为止。
如果问题仍未解决，请执行以下步骤以收集工作程序节点数据并提交支持凭单。

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

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

对于经典集群，请检查防火墙或网关。如果存在带宽限制或任何类型的故障，请解决问题。然后，再次检查工作程序节点。
检查集群中的应用程序，安全性或监视组件是否正在使用请求重载集群 apiserver，这可能会导致工作程序节点中断。
如果最近向集群添加了任何组件，请将其除去。如果对集群中的任何现有组件进行了更改，请还原这些更改。然后，检查工作程序节点的状态以查看新组件或更改是否导致该问题。
检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。检查拒绝请求的网络钩子。运行以下命令，获取拒绝请求的网络钩子列表。
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
查看具有 "rejected="true" 状态的网络钩子的输出。
如果问题仍未解决，请执行以下步骤以收集工作程序节点数据并提交支持凭单。

收集支持案例的数据

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

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

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

准备工作

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

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

kubectl 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%

检查任何集群 Webhook 上的更改，这些更改可能会中断 apiserver 请求或阻止工作程序节点与 apiserver 连接的能力。检查拒绝请求的网络钩子。运行以下命令，获取拒绝请求的网络钩子列表。
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
查看具有 "rejected="true" 状态的网络钩子的输出。

正在收集数据

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

获取每个节点的详细信息。保存要包含在支持凭单中的输出详细信息。
```
kubectl describe node <node-ip-address>
```
运行诊断和调试工具。将 kube 和网络测试结果导出到压缩文件，并保存要包含在支持凭单中的文件。如果集群中的所有工作程序都受到影响，那么您可以跳过此步骤，因为如果所有工作程序节点都中断，那么调试工具无法正常工作。
显示没有添加通过获取 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
```
经典集群: 访问其中一个受影响工作程序的 KVM 控制台。然后，收集相关日志和输出。
1. 执行以下步骤以访问 KVM 控制台。
2. 收集并保存以下日志。查看日志以了解工作程序节点中断的可能原因，例如缺少内存或磁盘空间，磁盘进入只读方式以及其他问题。
  - /var/log/containerd.log
  - /var/log/kern.log
  - /var/log/kube-proxy.log
  - /var/log/syslog
  - /var/log/kubelet.log
3. 运行以下命令并保存输出以附加到支持凭单。
  - ps -aux # 转储正在运行的进程
  - df -H # 转储磁盘使用情况信息
  - vmstat # 转储内存使用情况信息
  - lshw # 转储硬件信息
  - last -Fxn2 shutdown reboot # 确定上次重新启动是否正常
  - mount | grep -i "(ro" # 以排除磁盘只读问题。注: tmpfs 正在 ro 正常运行
  - touch /this # 以排除磁盘只读问题
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%，新的工作负载可能无法调度或出现性能下降。
使用以下命令收集 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 节流，从而影响性能。如果 pod 的内存使用量接近极限，则可能会出现 OOM（内存不足）错误，即 Kubernetes 终止进程以释放内存。资源使用率低的 pod 可能会有过度分配的请求，导致资源浪费。

运行 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}

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 可能被过度配置，造成资源浪费。

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

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

识别高内存消耗 pod。

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

监控系统守护进程的资源使用情况。 DaemonSets, 如或监控代理，可能会消耗意想不到的资源。kube-proxy
```
kubectl top pod -n kube-system
```sh
{: pre}
```

如果某些系统 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.

查看 OOMKilled 活动。当 Kubernetes 报告 OOMKilled 时，pod 超过了内存限制并被终止。 pod 的状态更改为 crashloopbackoff。
```
kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
```

在日志中查找 OOM 信息。

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

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

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

收集工作节点日志

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

收集并保存以下日志文件。查看日志以了解工作程序节点中断的可能原因，例如缺少内存或磁盘空间，磁盘进入只读方式以及其他问题。
- /var/log/containerd.log
- /var/log/kern.log
- /var/log/kube-proxy.log
- /var/log/syslog
- /var/log/kubelet.log
运行以下命令并保存输出以附加到支持凭单。

获取容器统计信息（需要 SSH 访问节点）。
```
crictl stats
```
获取特定容器的详细统计信息。
```
crictl stats --id <container-id> --output json
```
运行 commmad 来转储正在运行的进程。
```
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
```
如果问题仍然存在，请开立支持票据，并附上前面步骤中保存的所有输出结果。

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

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

故障诊断步骤

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

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

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

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

收集支持案例的数据

准备工作

正在收集数据

收集工作节点日志

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