本章目标
这一章不只是认识几个 CNI 名字，而是要回答 4 个实际问题：
- CNI 到底是什么，为什么 Kubernetes 离不开它::cite[364]
- Calico、Flannel、Cilium 分别适合什么场景::cite[343]
- Overlay 和 Underlay（或原生路由）方案到底差在哪::cite[346]
- 当你真的要搭集群时，应该如何做插件选型::cite[365]
很多初学者学到这里容易陷入一个误区：把 CNI 当成“安装集群后顺手装一个的网络组件”。实际上，Kubernetes 自己并不直接实现 Pod 网络，它依赖 CNI 插件来完成 Pod 接网、IP 分配、跨节点互通等工作。官方文档说得很明确：Kubernetes 使用 CNI 插件实现集群网络，而且 CNI 插件是落地 Kubernetes 网络模型的必需组件。::cite[364]
1. CNI 是什么
1.1 CNI 的全称与职责
CNI 全称是 Container Network Interface。它是一套标准接口，不是某一个具体产品。Kubernetes 会在 Pod 创建和删除时调用这套接口，让具体插件完成网络接入、地址分配、回收等动作。Calico 文档把这件事拆得很清楚：CNI network plugin 负责把 Pod 接入网络，CNI IPAM plugin 负责给 Pod 分配和回收 IP。::cite[343]
用更接地气的话说，Kubernetes 只负责“我要创建一个 Pod”，但“这个 Pod 用什么 IP、怎么挂网、怎么跨节点通信”，它交给 CNI 去做。::cite[364]
1.2 Kubernetes 为什么依赖 CNI
因为 Kubernetes 的网络模型要求：
- 每个 Pod 都有独立 IP；
- 集群内 Pod 默认可以互通；
- 同一 Pod 内共享网络命名空间；
- 节点重建、Pod 漂移后网络仍要可维护。::cite[352]
这些都不是 kubelet 单独就能优雅完成的事，所以 Kubernetes 采用了插件化方案。官方文档还特别说明：从 1.24 开始，kubelet 不再负责管理 CNI 二进制和配置，这进一步说明 CNI 管理本身已经明确不在 kubelet 的职责范围内。::cite[364]
2. 理解 Overlay 与 Underlay
在对比具体插件之前，你要先理解两种主流网络思路。
2.1 Overlay：在底层网络之上再包一层
Overlay 的核心思路是：底层网络不需要认识 Pod IP，只需要认识节点 IP。跨节点通信时，CNI 会把 Pod 数据包再封装一层，比如 VXLAN，然后把流量送到目标节点，再由目标节点解封装后交给目标 Pod。Calico 文档明确指出，Overlay 的优势是对底层网络依赖低，几乎可以跑在任何只认识节点 IP 的网络之上。::cite[343]
但代价也很明确：
- 封装和解封装有额外 CPU 开销；
- VXLAN / IP-in-IP 额外头部会带来 MTU 损耗；
- Pod IP 通常只在集群内可路由，出集群 often 需要 SNAT。::cite[343]
Flannel 文档也体现了这一思路：它默认推荐 VXLAN 后端，用内核 VXLAN 做封装，在简单环境里非常容易上手。::cite[395]
2.2 Underlay / Native Routing：让底层网络直接认识 Pod 路由
Underlay 或原生路由模式的思路是：不封装，直接让底层网络知道 Pod 网段应该怎么走。Calico 明确表示，如果底层网络能识别 workload IP，尽量不用 overlay，因为这样性能最高，离开 Pod 的包就是真正在链路上传输的包。::cite[346]
Cilium 的 native routing 文档也说明了相同原则：启用原生路由后，集群网络必须能转发 PodCIDR，节点需要通过默认路由、直接节点路由或者 BGP 等方式知道如何到达其他节点的 Pod 网段。::cite[476]
这种模式的优点是：
- 少一层封装，吞吐和时延通常更好；
- 更容易保留原始源地址；
- 更适合高性能和可观测性要求高的场景。::cite[346]
但前提是你的底层网络、云路由或者 BGP 方案足够配合。::cite[476]
3. 常见 CNI 插件对比
3.1 Flannel：简单、轻量、够用
Flannel 的定位非常明确：它主要解决“把 Pod 网络打通”这件事，强调简单和易部署。官方文档指出，Flannel 有多种后端，但推荐选择 VXLAN；如果底层网络支持直接二层互通，经验更足的用户也可以用 host-gw 来获得更好的性能。::cite[395]
你可以把 Flannel 理解成：
- 优先追求简单可用；
- 典型场景是中小规模、要求不复杂的集群；
- 适合“先把集群跑起来”；
- 在网络策略、深度可观测性、复杂流量治理方面不是最强项。::cite[395]
如果你的团队更关心“部署快、理解成本低、问题少”，Flannel 往往是入门友好的选择。::cite[395]
3.2 Calico：通用型、企业常用、路由能力强
Calico 最大的特点是灵活。官方文档明确写到，它既支持 overlay，也支持 non-overlay，还支持结合 BGP 进行路由分发。它可以根据环境选择 VXLAN、IP-in-IP、cross-subnet，或者直接走原生路由。::cite[343]
这意味着 Calico 很适合下面这些需求：
- 需要 Kubernetes NetworkPolicy；
- 既可能跑云上，也可能跑本地机房；
- 希望在“易部署”和“高性能”之间自由切换；
- 有能力理解路由、BGP、IP 池等网络概念。::cite[343]
尤其在自建机房场景，Calico 借助 BGP 可以把 Pod 路由传播给物理网络，让 Pod IP 具备更强的可达性，这也是它在企业环境中很常见的原因之一。::cite[343]
3.3 Cilium：eBPF、性能、可观测性与 kube-proxy 替代
Kubernetes 官方 addons 页面对 Cilium 的描述非常有代表性：它提供扁平三层网络，支持 native routing 或 overlay/encapsulation 模式，可以基于 eBPF 在 L3-L7 做网络策略，还可以替代 kube-proxy，并提供额外的可观测性和安全能力。::cite[365]
Cilium 的两个典型标签是：
- eBPF 数据面：很多转发和策略处理不再依赖传统 iptables 规则堆叠。::cite[471]
- kube-proxy replacement：在适合的环境中，它可以直接替代 kube-proxy 完成 Service 转发。::cite[471]
Cilium 还同时支持 tunneling 和 direct routing，两种模式都能工作。这使它非常适合：
- 大规模集群；
- 高并发流量；
- 需要高级可观测性；
- 对网络性能、源地址保留、服务转发效率有更高要求。::cite[471]
代价也很现实：理解门槛和运维复杂度通常比 Flannel 更高。::cite[476]
4. 怎么做选型，不要只看“谁更先进”
真正做选型时，不要问“哪个最强”，而要问“哪个更匹配我的环境”。
4.1 如果你是学习环境或小型测试集群
优先考虑 Flannel。原因很简单：部署快、概念少、问题边界清楚。VXLAN 是官方推荐后端，大多数场景都能快速跑起来。::cite[395]
4.2 如果你要做企业通用生产集群
优先考虑 Calico。因为它在可用性、网络策略、overlay/underlay 灵活切换、BGP 集成方面都比较均衡，适合“既要稳定，又要具备扩展空间”的场景。::cite[343]
4.3 如果你追求高性能、强可观测性、现代数据面
优先考虑 Cilium。尤其是你希望减少 iptables 复杂度、尝试 eBPF、甚至让 CNI 同时承担一部分 Service 转发能力时，Cilium 的优势会更明显。::cite[365]
4.4 如果你的底层网络不配合 Pod 路由
优先选择 Overlay 模式。比如 Flannel VXLAN、Calico VXLAN、Cilium tunneling。这种方式对底层网络要求低，更容易落地。::cite[343]
4.5 如果你的底层网络能支持 Pod 路由传播
优先考虑 原生路由 / 非 Overlay。例如 Calico BGP、Cilium native routing。这样能减少封装开销，通常也更适合高性能网络场景。::cite[346]
5. 实操：先识别你当前集群正在使用什么 CNI
5.1 常用观察命令
kubectl get pods -n kube-system -o wide
kubectl get daemonset -n kube-system
kubectl get pods -n kube-system | egrep 'calico|cilium|flannel'
如果你有节点登录权限，还可以看 CNI 配置目录：
ls /etc/cni/net.d
ls /opt/cni/bin
官方文档说明，容器运行时需要加载 CNI 配置和插件二进制，因此这两个目录往往能直接反映当前节点的 CNI 装配情况。::cite[364]
5.2 常见识别特征
- 看到
calico-node、calico-kube-controllers，大概率是 Calico。 - 看到
kube-flannel-ds，大概率是 Flannel。 - 看到
cilium、cilium-operator，大概率是 Cilium。::cite[365]
6. YAML 示例：三种常见方案怎么写
下面这部分不是让你现在马上三选一安装，而是帮助你建立“不同插件配置风格完全不同”的感觉。
6.1 Flannel：VXLAN 后端示例
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-flannel-cfg
namespace: kube-flannel
labels:
app: flannel
data:
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
这个示例体现的是 Flannel 最常见的入门思路：给整个集群定义 Pod 网段，并通过 VXLAN 把跨节点流量封装起来。::cite[395]
6.2 Calico：cross-subnet VXLAN 示例
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
calicoNetwork:
bgp: Disabled
ipPools:
- cidr: 10.244.0.0/16
encapsulation: VXLANCrossSubnet
natOutgoing: Enabled
nodeSelector: all()
这个配置表达的意思是：
- Pod 网段使用
10.244.0.0/16； - 只有跨子网时才做 VXLAN 封装；
- 同子网内尽量不封装，以减少额外开销。::cite[346]
这正是 Calico 很典型的“既兼顾性能，又兼顾对底层网络的适配”思路。::cite[346]
6.3 Cilium：native routing + kube-proxy replacement 示例
apiVersion: v1
kind: ConfigMap
metadata:
name: cilium-values
namespace: kube-system
data:
values.yaml: |
routingMode: native
ipv4NativeRoutingCIDR: 10.244.0.0/16
kubeProxyReplacement: true
bpf:
masquerade: true
这个示例强调的是 Cilium 的两类典型能力：
- 用 native routing 直接走底层路由；
- 用 eBPF 替代部分 kube-proxy 行为。::cite[471]
实际安装时通常通过 Helm 传入这些 values，但从学习角度看，把参数整理成 YAML 更容易记忆。::cite[471]
7. 选型建议：用问题驱动，而不是用名气驱动
如果你不知道怎么选，就按下面的顺序问自己：
7.1 我是否需要强网络策略能力？
如果答案是“是”，优先看 Calico 或 Cilium。Kubernetes 官方 addons 页面也明确提到，Cilium 可以在 L3-L7 层实施策略，而 Calico 则长期是 NetworkPolicy 领域最常见的实现之一。::cite[365]
7.2 我的底层网络能不能帮我转发 Pod 路由？
如果不能，先上 Overlay；如果能，而且你非常看重性能，就认真评估原生路由。::cite[346]
7.3 我团队的网络能力到什么水平？
如果团队对 BGP、PodCIDR、路由发布并不熟悉，别一上来就选择最复杂的模式。先选容易稳定运行的方案，远比“架构上最优”更重要。这个道理在 Kubernetes 网络里尤其成立。::cite[343]
7.4 我是否想减少 kube-proxy 的传统规则复杂度？
如果你对 eBPF、可观测性、数据面现代化很感兴趣，Cilium 会非常值得研究。官方文档已经把“kube-proxy replacement”列为它的核心能力之一。::cite[471]
8. 本章小结
这一章最重要的结论有 3 个：
- Kubernetes 依赖 CNI，不是可选项，而是网络模型落地的基础。::cite[364]
- Flannel、Calico、Cilium 没有绝对高下，关键是你的场景、团队能力、底层网络条件。::cite[343]
- 先理解 Overlay 与 Underlay，再谈插件选型，思路会清楚很多。::cite[346]
如果你现在已经能回答“为什么我的集群选 Flannel/Calico/Cilium，而不是另外两个”，那这一章就已经学到位了。下一章我们继续往下看：Service 的转发规则到底是谁生成的，iptables 和 IPVS 到底有什么差别。
📝 版权声明：本文为原创技术博客，转载请注明出处。
如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！