在 Kubernetes 网络模型中，kube-proxy 与 CNI（Container Network Interface）插件是支撑 Pod 网络通信的两个核心组件。许多初学者会混淆它们的作用，甚至认为它们是冗余的。本文将从架构职责、工作机制、协同方式三个角度，深入剖析 kube-proxy 与 CNI 的关系，并结合常见插件实践进行讲解。
一、Kubernetes 网络模型基础
Kubernetes 网络模型提出以下核心假设：
- 所有 Pod 之间都能直接通信（无 NAT）。
- 节点上的所有 Pod 能访问 node IP 上的所有端口。
- Pod 的 IP 是唯一且稳定的。
为了满足这些需求，Kubernetes 将网络职责拆分为多个组件，CNI 负责网络配置，而 kube-proxy 负责服务负载均衡。下面分别来看。
二、CNI 插件的职责：Pod 网络的"筑路工"
CNI 插件的核心职责是在 Pod 创建时完成以下工作：
- 为 Pod 分配 IP 地址（通常从容器子网中分配）；
- 设置网络命名空间与虚拟网络设备；
- 配置路由，使得 Pod 能和其它 Pod/节点通信；
- 接入外部网络（如 SNAT/DNAT 处理，部分插件支持）；
- 配合 NetworkPolicy 实现流量过滤（如 Calico、Cilium） 。
常见 CNI 插件包括：
- Flannel：提供简单的跨主机 IP 路由，不支持 NetworkPolicy；
- Calico：基于 BGP 的三层网络插件，强大的安全策略能力；
- Cilium：基于 eBPF 的高性能插件，支持 L3-L7 的细粒度控制。
简而言之，CNI 决定了 Pod 可以"去哪儿"。
三、kube-proxy 的职责：为 Service 提供"信号灯"
kube-proxy 是 Kubernetes 节点上的守护进程，核心职责是：
-
监听 Kubernetes 中 Service 与 Endpoints 的变化；
-
将访问 ClusterIP 的请求转发至后端 Pod（Endpoints） ；
-
提供多种代理模式支持：
- iptables 模式：通过大量 iptables 规则进行 NAT 转发；
- ipvs 模式：基于 Linux 内核的 IP Virtual Server；
- userspace 模式（已不推荐） ：基于进程转发。
kube-proxy 不负责 IP 分配、网络连接或安全策略。
简而言之，kube-proxy 决定了"怎么去服务"。
四、两者的协同机制：筑好路后，指挥交通
尽管 kube-proxy 和 CNI 插件在职责上互不重叠，但它们必须协同配合：
| 功能 | CNI 插件 | kube-proxy |
|---|---|---|
| Pod 网络初始化 | ✅ 负责 | ❌ 不负责 |
| Pod 间通信路由 | ✅ 设置路由 | ❌ 不处理 |
| Service 负载均衡 | ❌ 不涉及 | ✅ 维护规则 |
| NetworkPolicy | ✅（部分插件） | ❌ 不处理 |
| Endpoints 分发 | ❌ 不处理 | ✅ 监控并下发规则 |
例如：
- Calico + kube-proxy（ipvs） 是当前生产中常见组合。
- Cilium 可以替代 kube-proxy 提供 Service 代理，简化组件架构（开启
kubeProxyReplacement=true），提升性能。
五、实际示例分析
场景一：Flannel + kube-proxy
- Flannel 设置 Pod 网络，支持不同后端（vxlan、host-gw）；
- kube-proxy 通过 iptables/ipvs 实现 Service 请求转发；
- 不支持 NetworkPolicy，适用于对安全隔离要求不高的场景。
场景二：Calico + kube-proxy
- Calico 设置 Pod 路由表，支持跨节点通信；
- kube-proxy 实现 ClusterIP 到 Endpoints 的转发；
- 支持 NetworkPolicy，实现 L3 层隔离。
场景三：Cilium（开启 kube-proxy replacement）
- Cilium 使用 eBPF 同时处理 Pod 网络与 Service 转发；
- 实现无中断的高性能负载均衡；
- 简化部署架构，省去 kube-proxy。
六、常见误区澄清
- CNI 与 kube-proxy 并不冲突：它们关注的层次不同；
- kube-proxy 并不负责 Pod 间通信：这依赖 CNI 设置的网络；
- Service IP 并不是真实存在的设备：是由 kube-proxy 或 Cilium 通过转发规则实现；
- 关闭 kube-proxy 不意味着不能访问 Service：使用如 Cilium 可以替代它。
七、结语：协作而非对立
kube-proxy 和 CNI 插件像是交通系统中的两种角色：前者负责"指挥交通"（服务访问转发），后者负责"铺设道路"（容器网络连接）。理解它们的职责边界和协同方式，有助于我们更好地排查网络问题、设计网络策略和优化服务性能。
未来，随着 eBPF 技术的成熟，Cilium 等插件可能进一步蚕食 kube-proxy 的地盘，但这并不意味着 kube-proxy 失去价值，而是 Kubernetes 网络生态不断演进的体现。