kube-proxy 是 Kubernetes 集群中负责 Service 抽象和负载均衡的核心网络组件。它作为控制平面（Control Plane）与数据平面（Data Plane）之间的桥梁，通过持续监控 API Server 中的 Service 和 EndpointSlice 资源，将集群的服务状态转化为节点本地的流量转发规则（如 iptables、IPVS 或 nftables）。本文将详细阐述 kube-proxy 与 API Server 的交互机制，并深入剖析其在经典 iptables 模式下规则的计算、生成与应用过程。

1. Kube-proxy 与 API Server 的交互机制

kube-proxy 在每个工作节点上运行，其核心职责是维护节点上的网络规则，以确保流向 Service ClusterIP 或 NodePort 的流量能够正确地被路由到后端的 Pod 实例。

1.1 控制平面通信：Watch/Sync 循环

kube-proxy 作为一个标准的 Kubernetes 客户端，通过 API Server 提供的 Watch 机制来获取集群状态的实时更新。这种交互模式是异步且事件驱动的，保证了高效和低延迟的状态同步。

资源监听 (Watch)

kube-proxy 持续监听（Watch）以下两种核心资源对象：

Service (Services)：定义了服务的虚拟 IP（ClusterIP）、端口、协议以及选择后端 Pod 的标签选择器（Selector）。

EndpointSlice (或 Endpoints)：由 Controller Manager 根据 Service 的 Selector 自动生成，包含了实际后端 Pod 的 IP 地址和端口列表。EndpointSlice 是在大规模集群中替代 Endpoints 的优化方案，以提高同步效率。

事件处理 (Event Handling)

当 Service 或 EndpointSlice 发生变化时（例如，创建、更新 Service，或 Pod 扩缩容导致 Endpoint 变化），API Server 会立即推送一个事件给 kube-proxy。

状态同步 (Sync Loop)

kube-proxy 接收到事件后，会进入一个同步循环：

计算差异 (Diff Calculation)：将当前集群状态（Service/EndpointSlice）与节点上现有的网络规则进行比对，计算需要新增、修改或删除的规则集。

应用规则 (Rule Application)：根据当前配置的模式（iptables、ipvs 或 nftables），将计算出的规则集应用到节点的内核网络栈中。

这种 Watch → Calculate → Apply 的循环机制保证了幂等性，即使规则应用失败，也能在后续同步周期内自动修复。

2. Kube-proxy 核心工作模式对比

模式	数据平面技术	性能特点	规则复杂度	调度算法	适用场景
iptables	Linux netfilter/iptables	中等，随 Service 数量线性下降	(O(N))	随机（概率均分）	中小型集群
IPVS	Linux 内核 IPVS	优秀，基本不随规模变化	(O(1))	RR / WRR / LC 等	大规模集群
nftables	Linux nftables	优于 iptables	规则更高效	随机	新内核、未来趋势

userspace 模式已废弃，不再讨论。

3. iptables 模式下的规则计算与生成

3.1 规则链结构

链名	作用
KUBE-SERVICES	Service 入口链
KUBE-SVC-*	单个 Service 的负载均衡链
KUBE-SEP-*	单个 Endpoint 的 DNAT 链

3.2 负载均衡概率计算（公式可渲染）

对于一个包含 (N) 个 Endpoint 的 Service，kube-proxy 在 KUBE-SVC-* 链中生成 (N) 条规则。第 (k) 条规则的跳转概率为：

其中：

(N)：Endpoint 总数

(k)：当前 Endpoint 的序号（从 1 开始）

该设计保证了所有 Endpoint 的最终命中概率相等：

3.3 DNAT 规则

每个 KUBE-SEP-* 链只包含一条 DNAT 规则：

3.4 原子性更新

kube-proxy 使用 iptables-save / iptables-restore 批量加载规则，保证更新过程的原子性，避免规则不完整导致的流量异常。

4. iptables 模式的性能瓶颈

iptables 的核心问题在于：

规则链 线性遍历

匹配复杂度为：

当 Service / Endpoint 数量达到万级时，CPU 消耗和转发延迟会显著上升。

结论

iptables 模式稳定、通用，适合中小规模集群

IPVS 提供 (O(1)) 查找效率，适合大规模生产环境

nftables 是长期演进方向，值得在新集群中优先考虑

合理选择 kube-proxy 模式，是保障 Kubernetes 网络性能和稳定性的关键。

可以通过查询kube-system ns下的cm kube-proxy 看mode

如何避免channel重复关闭

openEBS lvm_localpv

Catalog

Last update: 2025-01-26