Kubernetes集群网络故障排查与恢复实战

1. 问题背景与现象描述

最近在本地VMware Workstation虚拟化环境中搭建了一个Kubernetes三节点集群用于实验，具体配置如下：

• 1个Master节点
• 2个Worker节点
• 网络插件采用Calico
• 操作系统为CentOS 7

为了便于实验回滚，我养成了定期创建虚拟机快照的习惯。某次实验后，我恢复了之前的快照，并顺手将虚拟机内存从4GB调整到8GB。重启系统后，发现集群网络出现异常。

关键现象：执行ip a命令后，原本应该显示的tunl0、cali*等网络接口全部消失，仅剩lo和ens160接口，且ens160没有分配任何IP地址。这意味着整个Kubernetes网络栈已经崩溃。

2. 初步排查与问题定位

2.1 网卡状态检查

首先确认网卡硬件是否被系统识别：

bash复制ip link show

输出显示：

code复制1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:0c:29:xx:xx:xx brd ff:ff:ff:ff:ff:ff

这表明：

• 物理网卡ens160确实存在且处于UP状态
• 问题出在IP配置层而非硬件驱动层

2.2 网络配置文件检查

进一步检查网络配置文件：

bash复制ls -l /etc/sysconfig/network-scripts/

发现目录下只有README文件，关键的ifcfg-ens160配置文件丢失。这就是导致网卡无法自动获取IP的根本原因。

经验提示：VMware快照恢复时，如果同时修改了虚拟机硬件配置（如内存、CPU等），在某些Linux发行版中可能导致网络配置文件丢失。这是VMware Tools与系统交互的一个已知边界情况。

3. 网络恢复操作实录

3.1 重建网络配置文件

手动创建网卡配置文件：

bash复制vi /etc/sysconfig/network-scripts/ifcfg-ens160

写入以下内容：

ini复制TYPE=Ethernet
BOOTPROTO=dhcp
NAME=ens160
DEVICE=ens160
ONBOOT=yes

关键参数说明：

• BOOTPROTO=dhcp：通过DHCP获取IP（实验环境建议改为static）
• ONBOOT=yes：确保系统启动时自动激活网卡

3.2 重启网络服务

应用新的配置：

bash复制systemctl restart NetworkManager
ip a show ens160

此时应能看到ens160已经获取到IP地址，例如：

code复制inet 192.168.30.11/24 brd 192.168.30.255 scope global dynamic ens160

4. Kubernetes集群恢复过程

4.1 检查核心组件状态

虽然网络恢复，但执行kubectl get nodes仍报错：

code复制The connection to the server 192.168.30.11:6443 was refused

这表明控制平面尚未正常工作。

逐步检查各组件：

bash复制systemctl status containerd  # 容器运行时
systemctl status kubelet     # 节点代理

发现虽然服务显示为running状态，但实际功能异常。

4.2 关键服务重启序列

执行以下重启序列：

bash复制systemctl restart containerd
systemctl restart kubelet

等待约30秒后，Master节点状态恢复：

bash复制kubectl get nodes

输出示例：

code复制NAME       STATUS   ROLES           AGE   VERSION
k8s-node1  Ready    control-plane   15d   v1.28.2
k8s-node2  NotReady <none>          15d   v1.28.2 
k8s-node3  NotReady <none>          15d   v1.28.2

4.3 Worker节点恢复

在每个Worker节点执行：

bash复制systemctl restart containerd
systemctl restart kubelet

等待组件重新建立连接后，集群状态完全恢复：

code复制NAME       STATUS   ROLES           AGE   VERSION
k8s-node1  Ready    control-plane   15d   v1.28.2
k8s-node2  Ready    <none>          15d   v1.28.2
k8s-node3  Ready    <none>          15d   v1.28.2

5. 深度问题分析与预防措施

5.1 根本原因剖析

本次故障链如下：

1. 快照恢复：VMware快照不包含瞬时硬件状态
2. 硬件配置变更：内存调整触发设备树重建
3. 网络配置丢失：NetworkManager未保留原始配置
4. 集群雪崩：IP变化导致kubelet无法连接API Server

5.2 关键恢复要点总结

5.3 实验环境最佳实践

1. 网络配置固化

   • 使用静态IP替代DHCP
   • 示例静态配置：

     ini复制BOOTPROTO=static
     IPADDR=192.168.30.11
     NETMASK=255.255.255.0
     GATEWAY=192.168.30.1
     DNS1=8.8.8.8
     

2. VMware操作规范

   • 创建快照前暂停虚拟机
   • 恢复快照后不立即修改硬件配置
   • 考虑使用vmware-toolbox-cmd备份网络配置

3. Kubernetes加固措施

   • 为kubelet配置--node-ip静态参数
   • 在Calico配置中明确指定接口匹配规则
   • 启用kubelet自动证书轮换

6. 扩展思考与进阶建议

6.1 生产环境应对策略

对于生产环境，建议采用以下高可用方案：

• 使用Keepalived实现VIP漂移
• 部署多个API Server实例
• 配置etcd数据定期备份

6.2 监控方案集成

配置基础监控告警规则：

yaml复制# Prometheus告警规则示例
- alert: NodeNetworkDown
  expr: up{job="node-exporter"} == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Node network down (instance {{ $labels.instance }})"

6.3 灾难恢复演练

建议定期执行以下演练：

1. 模拟节点网络故障
2. 测试API Server恢复流程
3. 验证工作负载自动迁移能力

在实际操作中发现，Calico网络对底层网络变化较为敏感。当节点IP变更时，需要特别注意：

bash复制# 清理旧的Calico端点
calicoctl delete node <node-name>
# 强制重新注册
systemctl restart calico-node

经过这次故障处理，我深刻体会到基础设施稳定性的重要性。特别是在实验环境中，一个小配置变更可能引发连锁反应。建议每位Kubernetes学习者都建立完整的操作日志和回滚方案，这能大幅降低故障排查难度。