一、问题概述
1.1 故障现象
生产 Kubernetes 集群出现服务异常：
kubectl操作超时，无法正常获取集群资源：
bash
kubectl get nodes
Unable to connect to the server:
net/http: request canceled (Client.Timeout exceeded while awaiting headers)- 部分业务 Pod 创建失败：
text
FailedCreatePodSandBox
networkPlugin cni failed to set up pod network
error getting ClusterInformation- kube-proxy、Calico 组件访问 Kubernetes API 超时：
text
Failed to watch *v1.Service
the server was unable to return a response in the time allotted影响：
- Kubernetes API 部分不可用
- 新 Pod 创建失败
- 部分业务发布受到影响
二、集群架构说明
生产环境采用三 Master 高可用架构：
VIP / LB
Kubernetes API入口
|
+------------+------------+
| | |
↓ ↓ ↓
Master-1 Master-2 Master-3
kube-apiserver kube-apiserver kube-apiserver
+------------+------------+
|
etcd集群
etcd节点1 etcd节点2 etcd节点3组件说明：
| 组件 | 作用 |
|---|---|
| kube-apiserver | Kubernetes API入口，无状态服务，多节点部署 |
| etcd | Kubernetes数据存储，需要多数节点正常 |
| kube-proxy | 维护Service访问规则 |
| Calico | Pod网络插件 |
| LB | 负责API请求负载均衡 |
三、问题排查过程
3.1 排查 Kubernetes API Server
首先检查 kube-apiserver 服务状态：
bash
systemctl status kube-apiserver发现：
- 部分 Master 节点 kube-apiserver 正常运行
- 部分 Master 节点因主机重启后未自动启动
异常节点状态：
kube-apiserver.service disabled进一步检查：
bash
ss -lntp | grep 6443发现部分 Master 节点 Kubernetes API 端口未监听。
3.2 排查 etcd 集群状态
由于 kube-apiserver 日志出现：
etcd-client
context deadline exceeded初步怀疑 etcd 异常。
通过 etcdctl 检查：
bash
etcdctl endpoint health检查结果：
etcd节点1 healthy
etcd节点2 healthy
etcd节点3 healthy结论：
- etcd 集群正常
- 数据存储无异常
- 非 etcd 故障
3.3 排查 kube-proxy / Calico
kube-proxy 日志：
Failed to watch *v1.Service
the server was unable to return a response in the time allottedCalico 日志：
error getting ClusterInformation
connect: connection refused分析调用链：
Pod创建
↓
Calico CNI
↓
Kubernetes Service
↓
kube-apiserver由于 Kubernetes API 服务部分节点不可用：
- Service访问异常
- CNI初始化失败
- Pod Sandbox 创建失败
四、问题根因分析
4.1 直接原因
两台 Master 主机发生重启后：
- kube-apiserver 服务未自动启动
- API Server 后端节点不可用
异常状态：
Master-1
kube-apiserver 正常
Master-2
kube-apiserver 未启动
Master-3
kube-apiserver 未启动导致：
- API请求访问部分异常节点时失败
- Kubernetes控制面响应超时
4.2 根本原因
原因1：核心 Kubernetes 服务未配置开机自启
检查：
bash
systemctl is-enabled kube-apiserver发现：
disabled导致：
服务器重启后：
- kube-apiserver 未自动恢复
- kube-controller-manager 未自动恢复
- kube-scheduler 未自动恢复
原因2：负载均衡未有效摘除异常 API Server
正常状态：
LB
|
+-- Master-1 API Server 正常
+-- Master-2 API Server 正常
+-- Master-3 API Server 正常异常状态：
LB
|
+-- Master-1 API Server 正常
+-- Master-2 API Server 不可用
+-- Master-3 API Server 不可用LB仍转发请求到异常节点，导致：
- kubectl超时
- kube-proxy访问API超时
- Calico网络初始化失败
五、恢复过程
5.1 启动异常 Master 节点 API Server
异常节点执行：
bash
systemctl start kube-apiserver确认：
bash
systemctl status kube-apiserver状态恢复：
Active: active (running)5.2 检查 API Server 监听状态
执行：
bash
ss -lntp | grep 6443确认所有 Master：
6443端口正常监听5.3 验证集群状态
检查节点：
bash
kubectl get nodes检查系统组件：
bash
kubectl get pods -n kube-system检查业务：
bash
kubectl get pods -A确认：
- API访问恢复
- Calico恢复
- Pod创建正常
六、整改措施
6.1 配置 Kubernetes 核心服务开机自启
所有 Master 节点执行：
bash
systemctl enable kube-apiserver
systemctl enable kube-controller-manager
systemctl enable kube-scheduler
systemctl enable etcd验证：
bash
systemctl is-enabled kube-apiserver结果：
enabled6.2 增加 Master 节点启动巡检
服务器重启后自动检查：
- etcd状态
- kube-apiserver状态
- kube-controller-manager状态
- kube-scheduler状态
- kubelet状态
异常自动告警。
6.3 优化 API Server 负载均衡健康检查
LB增加后端健康检测：
检查：
- TCP 6443端口
- Kubernetes API健康接口
避免：
后端 API Server 已不可用，但仍接收流量。
6.4 建立 Master 节点重启操作规范
Master节点维护前：
- 确认其他 Master 正常；
- 确认 etcd 集群健康；
- 重启后确认核心服务；
- 验证：
bash
kubectl get nodes
kubectl get pods -n kube-system七、最终结论
本次故障不是 Kubernetes 数据丢失或 etcd 故障。
排查确认：
- etcd 集群正常 ✅
- Kubernetes 数据正常 ✅
- 网络插件无根因异常 ✅
最终原因：
三 Master 高可用 Kubernetes 集群中，两台 Master 主机重启后 kube-apiserver 服务未自动恢复，导致 API Server 后端部分节点不可用；同时负载均衡未及时摘除异常节点，引发 Kubernetes API 请求超时，进一步导致 kube-proxy、Calico 和 Pod 创建异常。
后续重点：
- 所有 Kubernetes 核心组件开启系统自启动；
- 完善 LB 健康检查机制；
- 增加 Master 节点重启后的自动巡检和告警。