k8s 排查集群中故障节点

在 Kubernetes 集群中,故障节点可能导致 Pod 无法正常运行或资源分配异常。以下是排查集群中故障节点的常用方法:

1. 使用 kubectl get nodes 查看节点状态

首先检查所有节点的健康状态,kubectl get nodes 命令会显示集群中所有节点的状态。

bash 复制代码
kubectl get nodes

输出示例:

plaintext 复制代码
NAME          STATUS     ROLES    AGE     VERSION
node1         Ready      <role>   10d     v1.24.0
node2         NotReady   <role>   10d     v1.24.0
  • STATUS 列 :节点状态,包括 Ready、NotReady、Unknown 等。如果节点处于 NotReady 或 Unknown 状态,可能存在网络、资源或节点本身的问题。

2. 查看节点详细信息和事件

kubectl describe node <node-name> 命令可用于查看故障节点的详细信息和事件日志。

bash 复制代码
kubectl describe node <node-name>

在输出中查找 Conditions 和 Events 部分,观察是否存在以下常见问题:

  • OutOfDisk:磁盘空间不足。
  • MemoryPressure:内存压力过大,节点内存不足。
  • DiskPressure:磁盘 I/O 压力过高。
  • PIDPressure:进程数过多,节点已超出系统允许的最大 PID。
  • NetworkUnavailable:节点网络不可用,可能是网络插件或连接问题。

3. 检查节点上的关键服务状态

Kubernetes 节点需要关键服务保持正常运行。使用 SSH 登录到节点,检查以下关键服务的状态:

bash 复制代码
# 检查 kubelet 服务
systemctl status kubelet

# 检查容器运行时(如 Docker 或 containerd)
systemctl status docker  # 若使用 Docker
systemctl status containerd  # 若使用 containerd

确保 kubelet 和容器运行时服务都在运行。如果服务出现故障,可以尝试重启:

bash 复制代码
sudo systemctl restart kubelet
sudo systemctl restart docker  # 或 containerd

4. 查看节点的资源使用情况

使用 kubectl top nodes 查看每个节点的 CPU 和内存使用情况,以检查资源是否耗尽。

bash 复制代码
kubectl top nodes

如果某些节点的资源使用率极高(接近 100%),则可能会导致 Pod 调度失败或节点变为 NotReady 状态。

5. 查看网络插件日志

如果 kubectl describe node 显示 NetworkUnavailable 或节点连接中断,可能与网络插件有关(如 Calico、Flannel 等)。检查网络插件的 Pod 日志:

bash 复制代码
kubectl -n kube-system get pods | grep calico  # 查找网络插件 Pod
kubectl -n kube-system logs <network-plugin-pod-name>  # 查看网络插件日志

6. 检查节点上的 kubelet 日志

kubelet 是节点管理服务,其日志可以帮助定位问题。在节点上使用以下命令查看 kubelet 的日志:

bash 复制代码
journalctl -u kubelet -f

日志中查看是否有错误或告警信息,例如认证失败、资源不可用或节点连接问题。

7. 检查网络连接

网络连接问题可能会导致节点状态异常。可以在节点上使用 ping 或 curl 命令检查节点与主节点(如 apiserver)的网络连通性。

bash 复制代码
ping <master-node-ip>
curl -k https://<master-node-ip>:6443/healthz  # 检查 apiserver 健康状态

8. 检查节点的容器日志

如果某些节点上的 Pod 异常,可以查看其容器日志,定位 Pod 运行异常的原因:

bash 复制代码
kubectl logs <pod-name> -n <namespace> -c <container-name>

9. 重新标记节点(若节点恢复正常)

如果节点恢复正常,但仍显示 NotReady,可以先将节点标记为不可调度(cordon)再恢复:

bash 复制代码
kubectl cordon <node-name>    # 暂时标记节点为不可调度
kubectl uncordon <node-name>  # 恢复节点为可调度

总结

通过上述方法可以排查出节点故障原因,比如资源耗尽、服务故障、网络中断等。根据具体问题采取相应的措施,如重启服务、增加资源、调整网络配置等,从而恢复节点正常状态。

相关推荐
沫璃染墨几秒前
《从零入门Linux系统篇(五十一):线程篇·四——pthread线程库详解:从线程创建到终止与分离》
linux·运维·服务器·开发语言·c++·系统架构·线程
墨家前任巨子11 分钟前
定时关机脚本
运维
ESDWAN13 分钟前
企业组网后网络频繁掉线,常见故障排查指南
运维·网络·架构
程序员-Benothing35 分钟前
Linux系统时间管理:date、timedatectl、NTP、Chrony配置
linux·运维·服务器
坏脾气的小十七39 分钟前
docker基本知识
docker·容器·eureka
迪康Defender1 小时前
终端安全实践:浅谈端点安全管理系统内置终端防火墙能力
运维·服务器·网络·经验分享·安全·php·终端安全管理
AI备忘录1 小时前
(二十二)华为华三锐捷迈普思科 802.1X 端口认证配置命令(网络准入五厂商对照)
运维·服务器·开发语言·网络·安全·华为
优化Henry1 小时前
LTE站点以太网光模块告警处理实践
运维·网络·笔记·学习·信息与通信
智能运维指南1 小时前
一体化运维监控:打破工具孤岛,实现监控运维一体化
运维·嘉为蓝鲸·一体化运维监控·全栈智能可观测中心
明王明王1 小时前
PVE 上用 SPICE:统一连接 Debian、Arch 和 Windows 11 桌面
运维·windows·debian