从Flannel迁移到Calico在Ubuntu 24.04上为K8s v1.28更换网络插件的完整避坑指南当Kubernetes集群规模扩大或安全需求提升时许多团队会面临网络插件的选择困境。Flannel以其简单易用著称但当需要更精细的网络策略、BGP支持或高性能网络时Calico往往成为专业运维团队的首选。本文将带你深入理解两种插件的核心差异并提供从Flannel平滑迁移到Calico的完整路线图。1. 迁移前的关键决策与准备1.1 Flannel与Calico的架构对比在拆除旧网络架构前必须理解两者的根本区别。Flannel采用简单的overlay网络模型而Calico提供的是纯三层网络方案特性FlannelCalico网络模型Overlay (VXLAN/主机网关)三层路由 (BGP/VXLAN/IPIP)策略支持仅基础网络隔离细粒度网络策略(NetworkPolicy)性能损耗较高(封装开销)较低(原生路由)适用场景中小规模集群大规模/安全敏感型集群地址分配全局分配每节点独立CIDR块关键发现当集群节点超过50个或需要跨机房组网时Calico的BGP路由优势会显著降低网络延迟。1.2 环境预检清单执行以下命令确认当前环境状态# 检查现有Flannel组件 kubectl get daemonset -n kube-system -l appflannel # 记录当前Pod IP分配情况 kubectl get pods -o wide --all-namespaces flannel_ip_record.txt # 验证网络连通性 kubectl run net-test --imagealpine --rm -it -- ping 8.8.8.8必须备份的关键数据/etc/cni/net.d/目录下的所有CNI配置所有自定义NetworkPolicy资源kube-proxy的当前配置模式(iptables/ipvs)注意迁移过程中会短暂中断集群网络建议在维护窗口期操作并确保关键业务有容灾方案。2. 安全移除Flannel的实操步骤2.1 优雅卸载Flannel组件错误的卸载方式会导致僵尸IP分配问题以下是经过验证的清理流程# 1. 先删除DaemonSet避免自动恢复 kubectl delete daemonset kube-flannel-ds -n kube-system # 2. 清理CNI接口配置 sudo rm -f /etc/cni/net.d/10-flannel.conflist sudo ip link delete cni0 2/dev/null # 3. 检查残留进程 ps aux | grep -E flanneld|kube-flannel常见陷阱直接删除Flannel命名空间会导致某些节点网络僵死。应先缩容DaemonSet至0副本kubectl scale daemonset kube-flannel-ds -n kube-system --replicas02.2 处理残留网络配置Flannel创建的iptables规则和路由表项需要手动清理# 清除Flannel相关的iptables规则 sudo iptables-save | grep -v FLANNEL | sudo iptables-restore # 删除路由表项(示例为AWS环境) route -n | grep flannel.1 | awk {print $1} | xargs -I {} sudo route del -net {} netmask 255.255.255.0对于使用VXLAN模式的Flannel还需清理虚拟网络设备sudo ip link delete flannel.1 2/dev/null3. Calico的深度定制安装3.1 版本匹配矩阵Calico v3.28与Kubernetes版本的兼容性常被忽视以下是关键匹配关系Calico版本支持的K8s版本关键特性差异v3.251.24-1.26基础BGP支持v3.261.25-1.27增强Windows节点支持v3.281.27-1.29服务网格集成、eBPF数据平面推荐使用Operator安装方式它提供声明式配置和自动升级路径# 下载Operator清单 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.yaml3.2 定制IP池配置修改custom-resources.yaml时这些参数直接影响网络性能apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: ipPools: - name: ipv4-pool cidr: 10.244.0.0/16 blockSize: 24 encapsulation: VXLANCrossSubnet natOutgoing: true nodeSelector: all() nodeAddressAutodetectionV4: interface: ens*|eth* # 匹配多网卡环境性能调优建议生产环境建议blockSize设为26(每个节点62个IP)同机房节点使用IPIP封装跨机房用VXLAN启用natOutgoing使Pod能访问外部网络4. 迁移后的验证与排错4.1 健康检查三部曲组件状态检查watch kubectl get pods -n calico-system正常状态下应看到calico-node-* (每个节点1个)calico-kube-controllers-* (1个副本)calico-typha-* (3个副本用于大规模集群)BGP对等验证如果启用BGPkubectl exec -ti calico-node-pod -n calico-system -- birdcl show protocols输出应显示Established状态的对等连接。端到端测试kubectl run test-nginx --imagenginx kubectl create poddisruptionbudget test-pdb --selectorruntest-nginx --max-unavailable1 kubectl exec test-nginx -- curl -I http://www.google.com4.2 典型故障处理手册案例一Node持续NotReady症状calico-nodePod报错BIRD is not ready 解决方案# 检查网络接口匹配规则 kubectl edit installation default -n calico-system # 在spec.calicoNetwork.nodeAddressAutodetectionV4中添加 interface: ens.*|eth.* # 重启Calico节点 kubectl delete pod -n calico-system -l k8s-appcalico-node案例二DNS解析失败症状Pod内无法解析集群服务名称 快速修复# 检查CoreDNS Pod是否被分配了IP kubectl get pods -n kube-system -l k8s-appkube-dns -o wide # 临时解决方案如需 kubectl edit configmap/coredns -n kube-system # 在Corefile中添加 forward . /etc/resolv.conf { prefer_udp }案例三网络策略不生效调试步骤# 查看Felix日志每个节点上 kubectl logs -n calico-system calico-node-pod -c felix # 检查全局网络策略 calicoctl get globalnetworkpolicy -o yaml # 启用策略日志临时调试 calicoctl patch globalnetworkpolicy policy-name --patch{spec: {logSeverityScreen: Info}}5. 高级配置场景5.1 BGP与网络硬件集成在企业级部署中Calico可以通过BGP协议与物理网络设备交互。典型拓扑配置示例apiVersion: projectcalico.org/v3 kind: BGPPeer metadata: name: edge-router-1 spec: peerIP: 192.168.0.254 asNumber: 64512 nodeSelector: has(edge-router)路由优化技巧使用Route Reflector模式避免全网状连接通过communities属性控制路由传播范围对关键业务Pod添加nodeAffinity确保部署在特定节点5.2 网络策略实战模板Calico的网络策略比Kubernetes原生策略更强大以下是生产级示例apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: frontend-to-db spec: selector: role frontend types: - Egress egress: - action: Allow protocol: TCP destination: selector: role database ports: [5432] - action: Deny destination: nets: [0.0.0.0/0]策略编写原则先定义默认拒绝所有流量的全局策略按最小权限原则逐步开放必要通信使用命名端口(port name)而非数字端口对生产环境策略添加description注解迁移到Calico不仅是网络组件的更换更是集群网络架构的升级。在完成基础迁移后建议逐步探索这些高级特性基于eBPF的数据平面加速服务网格集成(如Istio)网络流量可视化(Calico Enterprise)安全审计日志与合规检查