一、当Kubernetes网络突然罢工时
想象一下这个场景：你正喝着咖啡，突然收到告警说集群里的服务全都失联了。Pod之间无法通信，跨节点流量像被黑洞吞噬了一样。这时候你意识到——网络插件出问题了。
在Kubernetes中，Calico和Flannel就像城市的交通信号灯系统。Calico采用BGP协议实现路由分发，适合需要精细网络策略的场景；而Flannel使用简单的overlay网络，像给所有道路铺了一层统一的地毯。两者都可能因为配置错误、资源冲突或版本兼容性问题突然"罢工"。
二、Calico经典故障现场还原
假设我们使用Calico v3.20作为网络插件，突然发现所有Pod都处于NotReady状态。首先检查Calico的核心组件：
# 检查calico-node守护进程状态（技术栈：Kubernetes+Calico）
kubectl get pods -n kube-system -l k8s-app=calico-node
# 正常应该看到每个节点都有一个Running状态的pod
如果发现大量CrashLoopBackOff，接着查看日志：
kubectl logs -n kube-system <calico-pod-name> -c calico-node
常见错误1：bird: BGP peer x.x.x.x not established
这表示节点间的BGP对等体通信失败。检查物理网络是否放行了TCP 179端口，或者尝试重置BGP配置：
# calico-configmap.yaml示例修复配置
apiVersion: v1
kind: ConfigMap
metadata:
name: calico-config
namespace: kube-system
data:
typha_service_name: "none" # 小型集群可以禁用Typha
veth_mtu: "1440" # 解决某些云环境的MTU问题
三、Flannel网络异常诊断手册
当使用Flannel作为网络插件（这里以Flannel v0.15为例），典型症状是新建Pod无法获取IP地址。首先检查核心服务：
# 检查flannel守护进程（技术栈：Kubernetes+Flannel）
kubectl get pods -n kube-system -l app=flannel
如果发现flanneld不断重启，可能是后端存储配置问题。查看日志会有明显提示：
kubectl logs -n kube-system <flannel-pod-name> | grep "Failed to create"
常见错误1：Failed to create SubnetManager
这通常意味着etcd连接异常。检查Flannel使用的etcd配置：
# kube-flannel.yml关键片段
containers:
- name: kube-flannel
args:
- --ip-masq
- --kube-subnet-mgr
- --iface=eth0 # 显式指定网卡避免选择错误
env:
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
四、网络恢复的黄金四步法
无论使用Calico还是Flannel，系统化恢复应该遵循以下步骤：
基础设施检查
确认节点基础网络连通性：# 跨节点连通性测试 kubectl get nodes -o wide ping <node-internal-ip>组件健康诊断
使用专用诊断工具：# Calico专用诊断 calicoctl node status # Flannel网络检查 ip route show | grep flannel配置版本回溯
如果最近升级过插件，尝试回退到上个稳定版本：# Calico版本回退示例 kubectl apply -f https://docs.projectcalico.org/archive/v3.19/manifests/calico.yaml资源清理重建
终极解决方案（谨慎操作）：# 清理Flannel残留网络设备 ip link delete flannel.1 systemctl restart docker kubelet
五、预防胜于治疗的运维哲学
根据生产环境经验，这些预防措施能减少90%的网络故障：
版本兼容矩阵
Calico v3.x需要匹配Kubernetes 1.19+，Flannel v0.15+需要etcd v3.4+资源预留配置
在values.yaml中为网络组件预留资源：# calico-operator资源限制示例 resources: limits: cpu: "2" memory: 1Gi requests: cpu: "500m" memory: 256Mi定期验证方案
创建自动化测试Pod验证跨节点通信：kubectl run net-test --image=alpine --restart=Never -- sleep 3600 kubectl exec net-test -- ping <其他节点PodIP>
六、技术选型的思考维度
当在Calico和Flannel之间抉择时，考虑这些关键差异点：
| 维度 | Calico | Flannel |
|---|---|---|
| 网络性能 | 原生三层路由，延迟低 | Overlay有10%性能损耗 |
| 策略支持 | 支持NetworkPolicy | 需额外组件 |
| 部署复杂度 | 需要配置BGP | 一键部署 |
| 适用规模 | 500+节点集群 | 中小规模集群 |
对于需要细粒度安全控制的金融系统，Calico是更好的选择；而快速迭代的互联网业务可能更适合Flannel的简单可靠。
七、那些年我们踩过的坑
云厂商的特殊限制
阿里云等厂商的VPC路由表有200条上限，Calico需要调整ippool的blockSize：apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: default-ipv4-ippool spec: blockSize: 26 # 默认26（64个IP）可减少路由条目Windows节点兼容问题
Flannel在Windows节点需要特殊配置：# flannel-daemonset-windows.yaml片段 args: - --kube-subnet-mgr - --iface=以太网 # Windows网卡名称需本地化内核版本依赖
Calico的eBPF模式要求Linux内核5.3+，在CentOS 7上需要手动升级内核。
八、终极救火队员工具箱
把这些命令保存到你的应急脚本库：
#!/bin/bash
# Kubernetes网络诊断大全（技术栈：Linux+Kubectl）
function netcheck() {
echo "=== 节点基础网络 ==="
ip a | grep -E 'eth0|flannel|cali'
echo "=== 路由表检查 ==="
ip route show | grep -E 'flannel|calico'
echo "=== 端口监听检查 ==="
netstat -tulnp | grep -E '179|8472' # Calico BGP端口/Flannel VXLAN端口
}
把这些知识装进你的工具箱，下次遇到网络故障时，你就能像老练的消防员一样快速定位问题源头。记住，好的网络运维不是在问题发生时力挽狂澜，而是通过合理的设计让问题根本无处藏身。
评论