在 Kubernetes 中，“容器即服务”已成为常态。但服务如何连通、容器之间如何通信，网络如何可观测与可控，这些问题往往被初学者忽视。深入理解 Pod 网络模型与 CNI 插件，是走向生产落地的必经之路。
一、为什么 Kubernetes 需要特殊的网络模型？
在物理服务器或者虚拟机环境中，网络结构清晰明了：每台机器有唯一 IP，通信依赖交换机和路由器。而在 Kubernetes 中，Pod 是容器的最小调度单元，它们的生命周期短暂、分布随机、迁移频繁。如果直接复用传统网络模型，将面临两个核心挑战：
- 地址冲突和端口复用问题：多个容器共处一台宿主机，如何实现 IP 唯一性和端口分配？
- 跨节点通信问题：不同节点上的 Pod 如何互通而不依赖端口映射或 NAT？
Kubernetes 提出了一个标准化的网络模型来解决这些问题：
- 每个 Pod 拥有独立 IP 地址，Pod 内的所有容器共享该 IP；
- Pod 之间可以直接通信，无需 NAT；
- 宿主机与 Pod 可以双向通信；
- 跨节点通信不依赖中转网关。
从这个模型可以看出，Kubernetes 要求的是一个统一平坦的容器网络空间，而非传统物理网络。为了实现这一目标，Kubernetes 本身并不实现网络，而是通过 CNI（Container Network Interface）插件机制，将网络交给插件处理。
二、CNI 插件：Kubernetes 网络的幕后执行者
CNI 是 CNCF 社区维护的一套接口规范，定义了容器启动和停止时，如何分配网络资源（如 IP、路由、网卡等）。Kubelet 在调度 Pod 时，会调用预配置的 CNI 插件，让其负责：
- 分配 IP 地址
- 配置网络命名空间
- 设置虚拟网卡、路由表
- 实现跨节点通信（通过封装或路由）
不同的 CNI 插件实现方式不同，但它们都遵循统一的接口规范。这种“标准接口 + 多种实现”的方式，使得 Kubernetes 网络能够灵活适配各种环境。
三、Flannel：最适合入门的 Overlay 网络插件
设计理念
Flannel 是最早被广泛应用的 CNI 插件之一，它的目标非常明确：为 Kubernetes 创建一个简单易用的 Overlay 网络，使得跨主机的 Pod 能无缝通信。
核心机制
- 每个节点被分配一个唯一的 Pod 网段，例如 Node A 得到
10.244.1.0/24。 - 节点之间通过 VXLAN 或 UDP 封装，实现虚拟网络连接。
- 当 Pod 需要访问跨节点的目标 Pod，Flannel 会将原始 IP 包封装在 VXLAN 中，发送到目标节点，再解封发送给目标 Pod。
优点
- 安装简单，配置门槛低；
- 对底层网络要求极低；
- 非常适合实验、开发、小规模集群。
局限
- 封装带来的性能损耗不可忽视；
- 不支持 Kubernetes 的 NetworkPolicy；
- 不适合复杂的安全隔离场景。
使用总结
在我早期部署测试集群时，Flannel 是首选方案。其部署逻辑直观，几乎不用调试。但随着业务需求增长，特别是需要实现租户隔离、细粒度访问控制时，它的局限就暴露出来了，迫使我们考虑更强大的替代方案。
四、Calico：生产级网络与安全策略的强强结合
设计理念
Calico 是目前最主流的生产级 CNI 插件之一。与 Flannel 不同，它主打的是三层路由而非 Overlay 网络，强调高性能和网络安全策略支持。
核心机制
- 每个节点负责分配其 Pod IP；
- 节点之间的路由通过 Linux 路由表或 BGP 自动通告；
- 所有流量使用原生 IP 路由，无需封装；
- 支持 NetworkPolicy，实现基于标签、命名空间的流量管控；
- 可选 eBPF 模式，提升性能、监控粒度和策略编排能力。
优点
- 性能高（无封装）；
- 支持完整的 NetworkPolicy；
- 可扩展性强，适配混合云、VPC、裸金属环境；
- 支持 eBPF，未来兼容性好。
局限
- 安装部署略复杂，尤其是需要配置 BGP 时；
- 对网络环境有一定要求，例如节点间必须直连；
- 调试网络策略有一定学习曲线。
使用总结
我们在一次大型电商项目中采用了 Calico，项目涉及多部门协作，需要精细化的网络隔离策略。借助 Calico 的 NetworkPolicy，我能为每个服务定义严格的通信白名单，大大降低了横向攻击风险。在 eBPF 模式下，配合 Prometheus + Grafana 实现了网络流量观测，也成为故障定位的重要手段。
五、两者对比：Flannel vs Calico
| 特性 | Flannel | Calico |
|---|---|---|
| 网络类型 | Overlay (VXLAN) | Routing-based (三层直连) |
| 性能 | 中等 | 高 |
| 安装复杂度 | 简单 | 中等偏高 |
| 网络策略支持 | ❌ 不支持 | ✅ 完整支持 |
| eBPF 支持 | ❌ 无 | ✅ 支持（可选） |
| 使用场景 | 学习、开发环境 | 生产、高性能、安全场景 |
六、思考与总结：为何理解网络如此重要？
Kubernetes 的魅力之一在于抽象资源和环境的能力。但抽象并不意味着忽略，特别是在网络这一层。网络的稳定性、安全性和性能，往往决定了系统可用性与业务 SLA。
我在实践中逐渐认识到：
- 网络策略就是权限系统，没有合理配置，容器之间就没有边界；
- 观测能力比通不通更重要，出问题能不能看出来，决定了解决效率；
- 理解网络模型，才能用好 Service Mesh、Ingress 等高级功能。
如果说容器调度是 Kubernetes 的“肌肉”，那么网络就是它的“神经系统”。用好 Flannel 可以快速搭建环境；用好 Calico，可以把环境“管”得井井有条。
七、结语：从连接到控制，从可用到可控
理解 Kubernetes 网络模型和 CNI 插件的工作原理，不是为了“照着装一个插件”，而是为了在系统复杂性提升时，拥有可控性与可观测性。
如果你正站在 Kubernetes 网络学习的起点，不妨从 Flannel 起步，逐步掌握 Calico 的能力。未来，当你面对多租户、高安全、混合云的业务场景时，这些知识会帮你少走很多弯路。
