Kubernetes CNI 插件选型指南：Calico vs Flannel vs Cilium

为什么 CNI 选型很重要

CNI (Container Network Interface) 决定了 Pod 的网络连通性、性能和安全能力。选型不当会导致后续扩展、网络策略或多集群场景受限。本指南从工作原理、功能差异、性能与运维复杂度等方面对主流 CNI 进行对比，并给出按场景的推荐方案。

快速对比表

方案	主要模式	NetworkPolicy 支持	性能/延迟	复杂度	典型场景
Flannel	VXLAN / host-gw	❌	中	低	Demo、单集群小规模
Calico	BGP / IPIP / VXLAN	✅	高	中	企业生产、灵活网络策略
Cilium	eBPF (可选 kube-proxy-free)	✅ (L7)	高/低延迟	中-高	高性能、可观测、安全强化

核心结论：

只需要“能跑起来”，且对策略/性能要求不高：Flannel。

需要成熟 NetworkPolicy、较好性能、兼容性高：Calico。

需要 L7 策略、eBPF、可观测或 Service Mesh 优化：Cilium。

工作原理速览

Flannel

通过 flanneld 管理子网，默认 VXLAN 封装实现跨节点通信；也可选 host-gw。
简单稳定，但不支持 NetworkPolicy，需要额外插件（如 Calico policy-only）。

Calico

支持 BGP/Route Reflector 或 IPIP/VXLAN 隧道；可按场景切换。
原生实现 NetworkPolicy 与 GlobalNetworkPolicy，具备 egress 控制、DNS 策略等。
网络模式选择：
- 小规模/裸机：IPIP Always / CrossSubnet
- 云上：VXLAN CrossSubnet 或直接使用云路由 + PolicyOnly

Cilium

基于 eBPF 实现数据平面，可选择 kube-proxy 模式或 kube-proxy-free。
支持 L3/L4/L7 策略、Hubble 可观测性、Socket LB，性能与延迟优势明显。
对内核版本有要求（推荐 ≥ 5.4，理想 ≥ 5.10），需要确认环境兼容性。

选型决策思路

网络策略需求：若必须实现 Zero Trust (NetworkPolicy)，优先 Calico/Cilium。
性能诉求：对低延迟/高吞吐要求高（金融、音视频）倾向 Cilium；一般业务 Calico 足够。
平台能力：需要 L7 策略、可观测 (Hubble) 或 eBPF 安全加固 → Cilium。
运维团队熟悉度：Flannel 成本最低；Calico 社区资料最丰富；Cilium 需要对内核/eBPF 有一定积累。
云厂商集成：
- 托管 Kubernetes (EKS/AKS/GKE) 通常有托管 CNI，可结合 Calico/Cilium policy-only。
- 自建裸机/混合云：Calico/Cilium 更灵活；需检查云路由表和 MTU 配置。

部署与配置要点

Calico（IPIP/VXLAN）

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
# 调整 encapsulation 模式
kubectl -n kube-system edit ds calico-node
# 设置 IP_AUTODETECTION_METHOD、CALICO_IPV4POOL_IPIP/CALICO_IPV4POOL_VXLAN

Cilium（kube-proxy-free 示例）

helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=strict \
  --set k8sServiceHost=<apiserver_host> \
  --set k8sServicePort=6443 \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

生产环境请结合内核版本、MTU、隧道模式 (Geneve/VXLAN) 做专项验证。

Flannel + Calico Policy-only（轻量策略）

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
# 再安装 Calico policy-only 以启用 NetworkPolicy
kubectl apply -f https://docs.projectcalico.org/manifests/calico-policy-only.yaml

验证与故障排查

连通性：kubectl exec + ping/curl 跨节点测试。
MTU：封装模式可能导致碎片，使用 ip link/tcpdump 检查；必要时调低 MTU。
BGP 状态（Calico）：calicoctl node status、calicoctl bgp peer status。
eBPF 状态（Cilium）：cilium status、cilium monitor、cilium connectivity test。
常见问题：
- DNS 解析失败：NetworkPolicy 未放行 UDP/53；或 NodeLocal DNSCache 未配置。
- 节点间不通：云路由表/安全组未放行封装端口，或 MTU 过高。
- 策略不生效：使用不支持 NetworkPolicy 的 CNI，或 CRD 未安装。

总结

CNI 是集群网络的地基。Calico 提供成熟的策略与可靠性能，适合大多数生产场景；Cilium 在 eBPF/L7/观测方面更强，适合对性能与安全有更高要求的团队；Flannel 胜在简单，适合轻量和 PoC。根据性能需求、团队经验与云环境约束，选择成本最低、可靠性最高的组合，并在上线前做好基准测试与回滚预案。

为什么 CNI 选型很重要​

快速对比表​

工作原理速览​

Flannel​

Calico​

Cilium​

选型决策思路​

部署与配置要点​

Calico（IPIP/VXLAN）​

Cilium（kube-proxy-free 示例）​

Flannel + Calico Policy-only（轻量策略）​

验证与故障排查​

总结​