摘要
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) 条规则的跳转概率为：
$$ P_k = \frac{1}{N - k + 1} $$
其中：
- (N)：Endpoint 总数
- (k)：当前 Endpoint 的序号（从 1 开始）
该设计保证了所有 Endpoint 的最终命中概率相等：
$$ \sum_{k=1}^{N} \left( P_k \times \prod_{i=1}^{k-1} (1 - P_i) \right) = \frac{1}{N} $$
3.3 DNAT 规则
每个 KUBE-SEP-* 链只包含一条 DNAT 规则：
-A KUBE-SEP-XXXX -p tcp -j DNAT --to-destination <PodIP>:<Port>3.4 原子性更新
kube-proxy 使用 iptables-save / iptables-restore 批量加载规则，保证更新过程的原子性，避免规则不完整导致的流量异常。
4. iptables 模式的性能瓶颈
iptables 的核心问题在于：
- 规则链 线性遍历
- 匹配复杂度为：
$$ T(N) = O(N) $$
当 Service / Endpoint 数量达到万级时，CPU 消耗和转发延迟会显著上升。
结论
- iptables 模式稳定、通用，适合中小规模集群
- IPVS 提供 (O(1)) 查找效率，适合大规模生产环境
- nftables 是长期演进方向，值得在新集群中优先考虑
合理选择 kube-proxy 模式，是保障 Kubernetes 网络性能和稳定性的关键。
可以通过查询kube-system ns下的cm kube-proxy 看mode
mode:
iptables
nftables:
masqueradeAll: false
masqueradeBit: null
minSyncPeriod: 0s
syncPeriod: 0s