Kubernetes 节点 NotReady 状态的系统化排查清单-优快云博客

本文链接：https://blog.youkuaiyun.com/hezuijiudexiaobai/article/details/149173863

目录标题

🧭 Kubernetes NotReady 节点排查指南
✅ 总结建议
补充 20250707
补充 20250708

以下是针对 Kubernetes 节点 NotReady 状态的系统化排查清单，已按模块优化结构、补充细节并修正描述，便于定位问题：

🧭 Kubernetes NotReady 节点排查指南

当节点出现 NotReady 状态时，可能由多种组件异常或资源耗尽导致，建议按以下模块逐步排查：

一、节点状态初查（从集群视角出发）

✅ 1. 查看节点状态：

kubectl get nodes -o wide

✅ 2. 查看节点详细描述信息（含 Taints、Conditions、Events）：

kubectl describe node <node-name> > node-describe.log

✅ 3. 导出完整节点对象 YAML 以查看内部配置：

kubectl get node <node-name> -o yaml > node.yaml

✅ 4. 查看当前集群 Events 是否有异常提示：

kubectl get events --sort-by='.lastTimestamp' -A > events.log

二、Kubelet 状态与日志排查（节点核心组件）

🔍 5. 查看 kubelet 服务运行状态：

systemctl status kubelet

🔍 6. 查看 kubelet 日志（可按需拉取最近 1000 行）：

journalctl -u kubelet -n 1000 > kubelet.log
# 或持续追踪日志
journalctl -xeu kubelet

三、容器运行时检查（docker / containerd）

🚦 7. 查看容器运行时服务状态：

systemctl status docker
systemctl status containerd

📄 8. 导出运行时日志：

journalctl -u docker > docker.log
journalctl -u containerd > containerd.log

🔎 9. 检查容器运行时是否卡住（可检测是否卡在某状态）：

对于 Docker：

for c in $(docker ps -qa); do echo "Inspecting $c..."; docker inspect $c > /dev/null; done

对于 containerd：

crictl ps -q | while read id; do echo "Inspecting $id..."; crictl inspect $id > /dev/null; sleep 1; done

四、系统资源与内核状态排查（可能是资源耗尽）

💾 10. 检查磁盘空间（重点关注 /var /root /etc 等）：

df -h | grep -v tmpfs > disk-space.log

🧠 11. 查看内存、负载使用情况：

top -n 1
free -m
uptime

📓 12. 查看系统级日志（如硬件故障、OOM 等）：

tail -n 100 /var/log/messages

五、核心服务容器排查（api-server / etcd）

⚙️ 13. 检查核心服务是否仍运行中（根据容器运行时类型）：

Kubernetes v1.18 使用 Docker：

docker ps | grep -E 'kube-apiserver|etcd'

Kubernetes v1.24+ 使用 containerd：

crictl ps | grep -E 'kube-apiserver|etcd'

六、监控视角辅助排查

📈 14. 使用 Prometheus 查询节点 Ready 状态（可搭配 Grafana）：

kube_node_status_condition{condition="Ready", node="qfusion01", status="true"}

若返回为空，表示该节点确实 NotReady；
可通过时间序列查看是否出现频繁波动。

七、网络与 DNS 层问题（可选补充）

🌐 15. 验证节点网络连通性：

ping <apiserver-ip>
curl -k https://<apiserver-ip>:6443/healthz

📡 16. 检查节点 DNS 是否解析异常：

cat /etc/resolv.conf
dig kubernetes.default.svc.cluster.local

✅ 总结建议

排查方向	工具/命令	重点关注项
节点状态	`kubectl get/describe node`	Condition 为 `Ready=False` 的原因
Kubelet	`systemctl status` / `journalctl -u kubelet`	启动失败、证书错误、配置问题
容器运行时	`docker ps` / `crictl ps`	容器卡顿、Runtime 异常
系统资源	`df -h` / `free -m` / `uptime`	磁盘、内存是否耗尽
日志分析	`/var/log/messages`	OOM、硬件错误、网络异常
核心服务	`crictl ps` / `docker ps`	etcd / apiserver 是否运行
监控辅助	`Prometheus + Grafana`	节点健康指标趋势

如需自动化收集相关信息，我可为你定制诊断脚本或采集工具。是否需要进一步生成？

当然有，下面是对原有排查流程的进一步补充与增强建议，帮助你更全面定位 NotReady 节点的根因，尤其适用于复杂生产环境：

补充 20250707

🧩 补充一：Node Condition 详细含义与触发机制

Kubernetes 中的 NodeNotReady 多数由 Conditions 中的某项为 False 或 Unknown 导致，常见影响项有：

Condition	含义	异常原因举例
`Ready`	节点是否健康	kubelet、runtime、网络、磁盘
`MemoryPressure`	内存压力过大	节点有 OOMKill、内存超限
`DiskPressure`	磁盘满或 inode 枯竭	`/var`、`/etc/kubernetes` 分区写满
`PIDPressure`	可分配 PID 耗尽	有大量进程或内核限制过小
`NetworkUnavailable`	网络插件未初始化	CNI 异常、calico/flannel crash

🔍 查看这些状态：

kubectl get node <node-name> -o jsonpath='{.status.conditions[*]}'

📦 补充二：kubelet 常见异常原因表

异常类型	日志特征	原因说明
`certificate expired`	TLS handshake failed	节点证书过期，可配合 `kubeadm certs renew`
`unable to update node lease`	context deadline exceeded	apiserver 网络不通或服务挂了
`container runtime is down`	failed to get container status	containerd/docker 挂了
`disk pressure`	eviction manager triggered	磁盘 IO 写入失败，常见于数据盘满或 inode 用尽

🕸️ 补充三：网络组件（CNI）检查

如果 CNI 插件（如 Calico/Flannel）异常，也会导致节点 NotReady，需检查：

kubectl get pods -n kube-system -o wide | grep -E 'cni|calico|flannel'
kubectl logs <cni-pod> -n kube-system

可进一步排查：

ip link show
ip route
iptables -L -n -v

🔐 补充四：节点 kubelet 与 apiserver 证书校验

证书过期是 kubelet 无法与 apiserver 通信的常见原因：

openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -text | grep Not

查看证书是否已过期，或节点与 apiserver 是否 TLS 不匹配。

🛠️ 补充五：节点驱逐/eviction 情况检查

节点可能是因为 Eviction（驱逐）而变为 NotReady，检查如下：

kubectl describe node <node-name> | grep -A 10 "Conditions"
kubectl get pod -A -o wide | grep <node-name>

也可查询是否被 eviction manager 驱逐过：

journalctl -u kubelet | grep -i eviction

☁️ 补充六：云平台（如公有云）节点元数据/宿主故障

在公有云（如 AWS、阿里云、腾讯云）场景下，也可能是宿主机或云网络异常导致心跳丢失。
建议排查：
- 云平台控制台是否提示节点/主机宕机；
- 安全组、NAT、VPC 网络是否异常；
- 云监控（如 CloudMonitor、CloudWatch）告警项。

🔄 补充七：NotReady 节点恢复建议

当排查完问题后，可执行以下操作恢复节点：

# 重启 kubelet
systemctl restart kubelet

# 如需重启运行时
systemctl restart containerd   # 或 docker

# 节点恢复后确认状态
kubectl get nodes

如仍无效，可考虑执行：

# 驱逐所有 Pod
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# 删除后自动重新注册
kubectl delete node <node-name>

⚠️ 前提是 kubelet 运行正常，且无密钥问题，否则会无法自动注册。

📌 最终建议：自动化 + 可观测性

Prometheus + Grafana：建立节点 CPU/内存/disk pressure 可视化告警。
Node Problem Detector：官方 DaemonSet，用于上报硬件/内核错误。
日志集中化（如 ELK/Fluentd）：便于快速搜索集群异常。

如果你希望我生成一个自动收集节点诊断信息的脚本（支持日志打包、本地资源统计等），我也可以为你定制。是否需要？

补充 20250708

以下是对你提出的 3 个实际故障场景的 排查补充说明，涵盖故障现象、原因分析、排查命令与建议，适用于日常运维与知识沉淀：

✅ 场景一：执行 `df -h` 卡顿（夯住）→ 原因：NAS 挂载超时或中断

🔍 故障现象：

执行 df -h 卡死不返回，或挂载点响应极慢
其他涉及磁盘相关的命令如 ls /mnt/xxx、du -sh 等同样卡顿

📌 常见原因：

NFS/NAS 挂载的远程存储失联（网络异常、存储挂掉）
挂载未使用 soft/timeo 参数，导致默认无限期等待
内核尝试访问丢失的挂载点文件，阻塞调用栈

🧪 排查命令：

mount | grep nfs
showmount -e <nas-ip>       # 测试 NAS 是否仍能导出
timeout 3 ls /mnt/nfsdata   # 检查是否卡顿
dmesg | tail -n 50          # 是否有 NFS timeout 报错

🛠 建议方案：

优化挂载参数：soft,timeo=5,retrans=3 避免死等
使用 df -h -x nfs 排除 NFS 影响
建议使用 stat, findmnt 代替 df 进行快速诊断
异常时重启 stale 挂载：
```
umount -f -l /mnt/nfsdata
```

✅ 场景二：`uptime`、`date` 卡顿 → 原因：系统时间同步源异常（如 chronyd 卡顿）

🔍 故障现象：

执行 uptime 或 date 卡住几秒甚至不返回
有时伴随 systemd-timesyncd 或 chronyd 异常
top/journalctl 启动缓慢

📌 常见原因：

时间同步服务访问慢（NTP 源故障或 unreachable）
读取 /proc/uptime 或 gettimeofday() 卡顿（时间相关系统调用）
容器或虚拟化场景中宿主机时间源漂移

🧪 排查命令：

chronyc tracking
chronyc sources -v
timedatectl status
systemctl status chronyd

🛠 建议方案：

更换可达性更好的 NTP 服务器（如内网高可用 NTP）
确保 chronyd 配置项 makestep, maxdistance 设置合理
观察 /var/log/chrony/ 或 journalctl -u chronyd 中是否报错

✅ 场景三：节点扩容时 nginx 配置错误 → 引发服务路由异常

🔍 故障现象：

新扩容节点加入后，服务发现失败或 404、502
老节点正常，新节点通过 ingress-nginx 访问失败
kubectl get ep 显示 endpoint 正常，但 Nginx 无法转发

📌 常见原因：

nginx 配置中硬编码了 backend IP 或节点标签
ingress controller 中使用 nodePort、hostNetwork 转发策略未匹配新节点
nginx.conf 缓存未更新，或未 reload
ingress 没有正确选择新节点的 pod（调度标签/selector 漏配）

🧪 排查命令：

cat /etc/nginx/nginx.conf

kubectl get nodes -o wide
kubectl get ingress -A
kubectl describe ingress <name> -n <ns>
kubectl get ep <svc-name> -n <ns> -o wide

🛠 建议方案：

检查 Ingress Controller 是否启用了 --watch-ingress-without-class、--publish-service
配置 externalTrafficPolicy=Local 时确保 node 上有 pod 副本
推荐使用 ingressClass 控制 ingress 对象与 nginx 匹配

动态变更后 reload nginx：

kubectl rollout restart deploy ingress-nginx-controller -n ingress-nginx

✅ 总结

场景	原因	排查重点	修复建议
`df -h` 卡住	NAS 网络中断	`mount`, `dmesg`, `timeout`	使用 `soft,timeo`，排除失败挂载
`uptime` 卡住	时间同步阻塞	`chronyc`, `timedatectl`	替换 NTP 源，查看 chronyd 日志
nginx 路由异常	ingress 配置未更新	`ep`, `logs`, `ingress describe`	确保 endpoints 更新，nginx reload