K8s节点失联排查手册：当kubelet突然找不到master节点时该怎么办？

最新推荐文章于 2026-05-18 05:14:03 发布

原创

最新推荐文章于 2026-05-18 05:14:03 发布 · 1k 阅读

标签

#Kubernetes #kubelet #节点故障 #运维排查

Kubernetes节点失联深度排查：从“找不到Master”到集群恢复的实战指南

凌晨三点，告警平台的短信把手机屏幕点亮，一行刺眼的红色文字：“K8s节点失联，Pod调度失败”。你从床上弹起来，打开电脑，登录集群，kubectl get nodes 命令返回的结果里，那个本该承载着核心服务的节点状态变成了 NotReady，更糟糕的是，kubectl logs 命令直接报错：The connection to the server 192.168.2.129:6443 was refused。紧接着，查看节点上的 kubelet 日志，你看到了那个熟悉又令人头疼的错误：kubelet.go:2461] “Error getting node“ err=“node \“k8s-master\“ not found“。

这不是第一次了。在复杂的生产环境中，Kubernetes 节点与 Master 失联是运维人员最不愿遇到却又无法完全避免的故障之一。它不像某个 Pod 崩溃那样影响局部，而是直接切断了一个计算节点与集群大脑的连接，导致其上的所有工作负载陷入“孤岛”状态，无法被管理、无法被调度、也无法正常提供服务。对于依赖 Kubernetes 稳定性的企业来说，这种故障意味着服务中断的风险和潜在的业务损失。

面对这样的场景，慌乱地重启服务往往不是最佳选择。一个系统化的、基于故障树分析（FTA）的排查思路，才是快速定位问题、恢复集群健康的关键。本文将从一个资深 SRE 的视角出发，为你构建一套从表象到根源、从网络到配置的完整排查体系。我们不仅会解决眼前的“找不到 Master”问题，更会深入理解其背后的机制，让你在下一次告警响起时，能够胸有成竹。

1. 第一响应：建立诊断基线并快速验证网络层

当节点失联告警触发时，首要任务是保持冷静，并迅速建立一个清晰的诊断基线。盲目操作可能会掩盖问题线索，甚至导致故障扩散。

第一步，确认故障范围。 是单个节点失联，还是多个节点同时出现问题？使用一个健康的、能够连接 API Server 的节点（通常是另一个 Master 节点或运维跳板机）执行以下命令：

# 查看所有节点状态，确认故障节点
kubectl get nodes -o wide

# 查看故障节点上的 Pod 状态（从集群视角）
kubectl get pods -o wide --all-namespaces | grep <故障节点IP或主机名>

# 描述故障节点，获取更多事件信息
kubectl describe node <故障节点名>

如果 kubectl 命令本身报连接 API Server 失败，那说明问题可能出在控制平面（所有 Master 节点）或网络层面，需要优先排查 API Server 服务本身。如果只有特定节点失联，则聚焦于该节点与 Master 之间的通信链路。

紧接着，我们必须直击最可能的“元凶”：网络连通性。 Kubernetes 集群的神经中枢是 API Server（默认端口 6443），kubelet 需要持续地与它保持心跳（Node Lease）并汇报状态。网络层面的阻断是导致“找不到 Master”的最常见原因。

你需要登录到失联的节点上，执行一系列网络诊断命令：

# 1. 检查到 Master API Server 端口的连通性
# 假设你的 Master 节点 IP 是 192.168.2.129
ping 192.168.2.129
telnet 192.168.2.129 6443
# 或者使用更现代的 nc (netcat)
nc -zv 192.168.2.129 6443

# 2. 检查本地端口监听情况，确认 kubelet 是否在监听自己的端口（如10250）
sudo netstat -tlnp | grep kubelet

# 3. 检查本地防火墙规则（以 firewalld 为例）
sudo firewall-cmd --list-all
# 或者检查 iptables
sudo iptables -L -n | grep -E '(6443|10250)'

# 4. 检查路由表，确保到 Master 网络的路由正确
ip route get 192.168.2.129

# 5. 检查网络接口和 DNS 解析（如果 Master 使用主机名）
cat /etc/hosts
nslookup kubernetes.default.svc.cluster.local