GKE集群多次触发node auto repair，无日志/指标可查，如何排查？

安全阿岳

2026-6-27

排查GKE集群频繁触发Node Auto Repair的问题

1. 确认Node Auto Repair的配置状态

首先检查集群和节点池的自动修复配置，确认是否存在阈值设置不合理的情况：

查看集群级别的自动修复配置：
```
gcloud container clusters describe CLUSTER_NAME --zone ZONE
```
重点关注nodePoolConfig.management.autoRepair和autoUpgrade字段，确认自动修复是否启用，以及是否有自定义的健康检查阈值。
查看单个节点池的详细配置：
```
gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --zone ZONE
```
不同节点池可能有独立的自动修复设置，需逐一验证。

控制平面日志无线索时，节点本地的日志往往能找到触发修复的直接原因：

登录到触发过自动修复的节点：

gcloud compute ssh NODE_NAME --zone ZONE

查看kubelet服务的历史日志，排查节点健康上报异常：
```
journalctl -u kubelet --since "48 hours ago"
```
重点关注NotReady状态上报、kubelet连接异常、资源不足告警等信息。
查看容器运行时（如containerd）的日志，排查容器运行故障：
```
journalctl -u containerd --since "48 hours ago"
```
检查是否有容器崩溃、镜像拉取失败、运行时资源耗尽等问题。

检查节点的历史资源使用情况：

# 查看系统负载历史
uptime
# 查看当前资源占用
top
# 检查磁盘空间（自动修复可能触发于磁盘满）
df -h

GKE的自动修复逻辑会关联节点上Pod的健康状态，大量异常Pod可能触发节点修复：

列出目标节点上的所有Pod，筛选异常状态的实例：
```
kubectl get pods --field-selector spec.nodeName=NODE_NAME -A
```
重点关注CrashLoopBackOff、ImagePullBackOff、Failed状态的Pod。

查看异常Pod的崩溃日志：

kubectl logs POD_NAME -n NAMESPACE --previous

GKE触发Node Auto Repair的核心依据是节点的Ready状态，需详细分析节点的状态条件：

查看节点的详细状态描述：
```
kubectl describe node NODE_NAME
```
重点关注Conditions字段中Ready状态的Status、Reason和Message，确认节点是否长期处于NotReady状态，以及具体的故障原因（如kubelet未响应、网络异常等）。

除了节点自身问题，外部因素也可能引发自动修复：

查看节点对应VM实例的系统事件，排查主机级别的故障或维护：
```
gcloud compute instances describe NODE_NAME --zone ZONE
```
检查statusMessage、lastStartTimestamp、lastStopTimestamp字段，确认是否有VM重启、磁盘故障、网络中断等记录。
检查节点所在区域的历史维护记录，确认是否GCP底层主机维护导致节点状态波动。
排查内部运维工具或脚本，确认是否有自动化操作（如节点重启、资源清理）误触发了健康检查异常。

若上述排查无结果，可临时调整自动修复配置来缩小排查范围：

内容的提问来源于stack exchange，提问作者Shweta Raman