从Flannel迁移到Calico：Kubernetes网络插件实战切换指南
1. 为什么需要从Flannel迁移到Calico？
很多刚开始接触Kubernetes的朋友都会选择Flannel作为默认网络插件，毕竟它简单易用，开箱即配。但当你需要更精细的网络控制时，Flannel就显得力不从心了。我去年负责的一个电商项目就遇到了这个问题 - 当时我们需要实现跨可用区的Pod通信优化，Flannel的简单Overlay网络在跨区延迟上表现不佳。
Calico最大的优势在于它支持纯三层网络方案，这意味着数据包不需要额外的封装解封装，网络性能可以接近物理网络。实测下来，相同集群环境下Calico的网络吞吐量比Flannel高出30%左右，延迟降低约40%。这对于对网络敏感的微服务架构特别重要。
另一个关键区别是网络策略。Flannel只提供基础的连通性，而Calico内置了强大的网络策略引擎。我记得有个金融项目需要实现严格的Pod间隔离，用Calico的NetworkPolicy可以精确控制哪些服务能互相访问，这在等保合规审计时帮了大忙。
2. 迁移前的关键准备工作
2.1 环境检查清单
在动手之前，建议先运行以下检查命令：
# 检查当前Flannel运行状态 kubectl get daemonset -n kube-system | grep flannel kubectl get pods -n kube-system | grep flannel # 记录现有Pod CIDR配置 kubectl cluster-info dump | grep -i cluster-cidr # 检查节点网络接口 ip addr show | grep -E 'flannel|cali'我遇到过最坑的情况是有些节点上残留着Flannel的虚拟网卡，导致Calico无法正常初始化。建议先用ip link delete flannel.1清理这些接口。
2.2 版本兼容性矩阵
Calico版本和Kubernetes版本的匹配特别重要。根据官方文档，当前主流版本的对应关系如下：
| Kubernetes版本 | 推荐Calico版本 |
|---|---|
| 1.25-1.26 | v3.24.x |
| 1.27-1.28 | v3.26.x |
| 1.29+ | v3.28.x |
上个月我在一个客户环境就踩了坑，他们集群是K8s 1.28却装了Calico 3.22，结果BGP对等始终建立不起来。后来升级到3.26才解决。
2.3 关键配置备份
一定要备份这些关键配置：
- Flannel的DaemonSet配置
- 现有的NetworkPolicy
- kube-proxy的ConfigMap
- 节点路由表(
ip route show)
我习惯用这个命令打包所有网络相关配置：
kubectl get ds,deploy,cm -n kube-system -l=k8s-app=kube-proxy > network-backup.yaml3. 分步迁移操作指南
3.1 安全移除Flannel
正确的卸载顺序很重要：
# 先删除Flannel DaemonSet kubectl delete -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml # 清理CNI配置 rm -f /etc/cni/net.d/10-flannel.conflist # 重启kubelet让变更生效 systemctl restart kubelet注意：这时候你的Pod会全部变成NotReady状态，这是正常的。我建议在业务低峰期操作，或者提前准备好维护窗口。
3.2 安装Calico核心组件
推荐使用Operator方式安装，这是目前最稳定的方法：
# 下载Operator manifest curl -L https://github.com/projectcalico/calico/releases/download/v3.28.0/tigera-operator.yaml -o tigera-operator.yaml # 部署Operator kubectl create -f tigera-operator.yaml等Operator运行起来后（约2-3分钟），配置自定义资源：
# custom-resources.yaml apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - name: default-ipv4-ippool cidr: 10.244.0.0/16 # 必须与kubeadm初始化时一致 blockSize: 24 encapsulation: VXLANCrossSubnet natOutgoing: Enabled nodeAddressAutodetection: interface: "eth.*|ens.*" # 根据实际网卡名调整应用配置：
kubectl apply -f custom-resources.yaml3.3 常见问题排错
问题1：节点一直处于NotReady状态
检查Calico-node日志常见错误：
kubectl logs -n calico-system -l k8s-app=calico-node我遇到最多的两个情况：
- 网卡自动发现失败 - 修改custom-resources.yaml中的interface正则
- IP冲突 - 检查
ipPool的CIDR是否被占用
问题2：Pod无法跨节点通信
这通常是MTU设置不当导致的：
# 查看Calico的MTU配置 kubectl get felixconfigurations.crd.projectcalico.org -o yaml # 如果物理网络MTU是1500，Calico的MTU应该设为1450（考虑VXLAN开销）4. 迁移后的关键验证
4.1 基础连通性测试
我通常会部署一个测试工具集：
kubectl create deployment netcheck --image=alpine --replicas=3 -- sleep infinity kubectl exec <pod-name> -- ping <其他节点Pod IP> kubectl exec <pod-name> -- curl <Service ClusterIP>4.2 性能基准测试
用iperf3对比迁移前后的网络性能：
# 在Pod中运行 apk add iperf3 iperf3 -s # 在一个Pod iperf3 -c <server-pod-ip> -t 30 -i 5 # 在另一个Pod正常情况下的性能提升：
- 吞吐量：Flannel 2.5Gbps → Calico 3.8Gbps
- 延迟：Flannel 0.8ms → Calico 0.3ms
4.3 网络策略验证
测试NetworkPolicy是否生效：
# test-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-policy spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: allowed-client应用后验证只有特定标签的Pod能访问。
5. 高级配置调优
5.1 BGP对等配置
对于需要极致性能的场景，可以启用BGP：
# bgp-configuration.yaml apiVersion: projectcalico.org/v3 kind: BGPConfiguration metadata: name: default spec: logSeverityScreen: Info nodeToNodeMeshEnabled: true asNumber: 64512然后配置每个节点的BGP对等：
calicoctl patch node k8s-node-1 -p '{"spec":{"bgp":{"ipv4Address":"10.0.0.1/24"}}}'5.2 IP地址管理
对于大型集群，建议划分多个IP池：
apiVersion: projectcalico.org/v3 kind: IPPool metadata: name: pool-2 spec: cidr: 10.244.64.0/19 blockSize: 27 nodeSelector: rack == "rack-2"5.3 网络监控配置
Calico内置了Prometheus指标，启用方法：
# enable-metrics.yaml apiVersion: projectcalico.org/v3 kind: FelixConfiguration metadata: name: default spec: prometheusMetricsEnabled: true prometheusMetricsPort: 9091然后可以在Grafana中导入Calico的官方仪表板（ID: 13863）。
6. 回滚方案
虽然不推荐，但必要时可以回退到Flannel：
- 删除Calico所有资源
kubectl delete -f tigera-operator.yaml kubectl delete -f custom-resources.yaml- 清理残留接口
ip link delete cali0 ip link delete tunl0- 重新安装Flannel
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml建议回滚后重启所有节点以确保网络栈完全重置。