K8S集群日常基础巡检与Flannel网络故障排查修复实践

作为Kubernetes运维的日常工作，新入职或接管一个K8S集群后，基础巡检一定要落实。只有搞清楚集群当前的健康状况，才敢放心支撑业务上线。本文结合生产环境经验，总结K8S日常巡检的关键点，以及Flannel网络插件常见故障的排查和修复方法。文末还有一些小技巧和温馨提示，欢迎收藏！

1. 日常K8S基础巡检步骤

1.1 检查集群节点状态

最基础的巡检就是看看所有节点都在线并健康。一般主节点（master）和工作节点（worker）都正常 Ready。命令如下：

kubectl get nodes

输出类似于：

NAME        STATUS   ROLES                  AGE   VERSION
master231   Ready    control-plane,master   17h   v1.23.17
worker232   Ready    <none>                 17h   v1.23.17
worker233   Ready    <none>                 17h   v1.23.17

如果发现节点不是 Ready，要及时排查原因（如网络、磁盘、kubelet 服务等）。

1.2 检查 Master 关键组件健康

Master 管控面组件（etcd、scheduler、controller-manager）是否健康，会极大影响整个集群的稳定性。

kubectl get cs

注意：kubectl get cs 在1.19以后已弃用，建议结合 Dashboard 或监控工具。但简单场景下仍可作为“活性探针”。

输出示例：

NAME                 STATUS    MESSAGE                         ERROR
etcd-0               Healthy   {"health":"true","reason":""}
scheduler            Healthy   ok
controller-manager   Healthy   ok

1.3 检查 Flannel 网络插件 pod 状态

K8S节点的跨主机Pod通信往往依赖于 Flannel 等 CNI 网络插件。务必确认各节点 Flannel pod 均为 Running 状态，且重启次数异常（>0）需关注。

kubectl get pods -n kube-flannel -o wide

常见输出：

NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE
kube-flannel-ds-ckkbk   1/1     Running   1          16h   10.0.0.233   worker233
kube-flannel-ds-kst7g   1/1     Running   1          16h   10.0.0.232   worker232
kube-flannel-ds-ljktm   1/1     Running   1          16h   10.0.0.231   master231

重点关注：

某 Pod 是否反复重启
某节点 Flannel Pod 是否未 Running（如 CrashLoopBackOff）

1.4 检查各节点的网络设备和状态

每台节点上都有对应的虚拟网卡设备，比如 cni0（CNI虚拟网桥）、flannel.1（Flannel接口）。需要检查这些接口是否存在且网段一致。

查看网卡命令（在每台节点上执行）：

ifconfig   # 现代系统可用 ip a

重点看：

cni0 的 IP（如 10.100.x.1）分别对应不同节点
flannel.1 的 IP（如 10.100.x.0）也对应
RX/TX 是否有错误或大量丢包
网段和预期是否一致

常见问题1：cni0 和 flannel.1 网段不一致

问题表现：跨节点 Pod 无法互通。
解决思路：需对照各节点网段，手动修正或重建虚拟网卡。

常见问题2：无 cni0 设备

表现：Pod 无法通信，或部分业务 Pod 无法访问外部服务。
解决思路：同样需要手动添加该桥接设备。

2. Flannel 异常重启或故障自愈修复方案

如发现 Flannel Pod 报错频繁重启或 Running 状态异常，需要按以下流程处理：

2.1 删除、重建 Flannel 组件

以 root 用户执行：

1）删除原有 Flannel 资源

kubectl delete -f kube-flannel.yml

2）彻底清理虚拟网卡及缓存配置（务必三节点都清理，顺序不能错，建议分节点操作）

ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm -rf /var/lib/cni/flannel/* /var/lib/cni/networks/cbr0/* /var/lib/cni/cache/* /etc/cni/net.d/*
systemctl restart kubelet docker
chmod a+w /var/run/docker.sock
systemctl status kubelet docker

注意：如果环境是containerd，需将“docker”替换为相关容器运行服务。

3）重新创建 Flannel 组件

kubectl apply -f kube-flannel.yml

2.2 手动创建缺失网桥设备（高级修复）

如有节点遗漏 cni0，需手动补齐（确保与同节点 flannel.1 网段一一对应）

以 worker232 节点为例，假设其 flannel.1 的网段为 10.100.1.0：

ip link add cni0 type bridge
ip link set dev cni0 up
ip addr add 10.100.1.1/24 dev cni0

master、worker233 以此类推，注意网段和主机号匹配。

温馨提示：生产建议将该操作进开机自启动脚本，防止主机重启后丢失。

3. 日常自动化巡检小技巧

建议将节点和组件健康状态巡检脚本化，日常定时推送到微信群或邮件。
结合 Prometheus、Grafana 进行 K8S 可视化健康告警。
网络配置和异常日志建议每日巡检1-2次，遇重大变更立即复查。

4. 结语与拓展

K8S 的稳定离不开细致的基础运维巡检。网络插件（如 Flannel）和虚拟网卡等作为基础设施，一旦异常往往直接牵连上层业务全面故障。本篇总结的巡检及修复流程、排查思路，都是我在生产环境中多次踩坑的经验论证。如果对你有帮助，欢迎点赞、收藏和转发给有需要的小伙伴！

如有更多 K8S 网络或运维问题，欢迎留言探讨~

附录：常用命令速查

查看节点状态：
```
kubectl get nodes
```
检查组件健康：
```
kubectl get cs
```

查看 Flannel pod：

kubectl get pods -n kube-flannel -o wide

查看网卡：
```
ifconfig
# 或 ip a
```

手动创建 cni0 网桥：

ip link add cni0 type bridge
ip link set dev cni0 up
ip addr add 10.100.X.1/24 dev cni0

如发现文中有任何可优化细节，欢迎评论区交流补充！

posted on 2025-04-18 00:45 Leo-Yide 阅读(255) 评论(0) 收藏举报