从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.26v3.24.x1.27-1.28v3.26.x1.29v3.28.x上个月我在一个客户环境就踩了坑他们集群是K8s 1.28却装了Calico 3.22结果BGP对等始终建立不起来。后来升级到3.26才解决。2.3 关键配置备份一定要备份这些关键配置Flannel的DaemonSet配置现有的NetworkPolicykube-proxy的ConfigMap节点路由表(ip route show)我习惯用这个命令打包所有网络相关配置kubectl get ds,deploy,cm -n kube-system -lk8s-appkube-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-appcalico-node我遇到最多的两个情况网卡自动发现失败 - 修改custom-resources.yaml中的interface正则IP冲突 - 检查ipPool的CIDR是否被占用问题2Pod无法跨节点通信这通常是MTU设置不当导致的# 查看Calico的MTU配置 kubectl get felixconfigurations.crd.projectcalico.org -o yaml # 如果物理网络MTU是1500Calico的MTU应该设为1450考虑VXLAN开销4. 迁移后的关键验证4.1 基础连通性测试我通常会部署一个测试工具集kubectl create deployment netcheck --imagealpine --replicas3 -- sleep infinity kubectl exec pod-name -- ping 其他节点Pod IP kubectl exec pod-name -- curl Service ClusterIP4.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.3ms4.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-25.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重新安装Flannelkubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml建议回滚后重启所有节点以确保网络栈完全重置。