3. kube-proxy 工作原理：三种模式与数据流转路径

kube-proxy 是 Kubernetes 集群中负责实现 Service 抽象的核心组件，运行在每个 Node 上。它通过监听 API Server 中 Service 与 EndpointSlice 的变化，动态维护节点上的网络规则，将发往 Service VIP（虚拟 IP）的流量转发到后端 Pod。kube-proxy 支持三种运行模式：userspace、iptables 和 IPVS。理解这三种模式的数据流转路径，是进行集群升级与证书轮换时评估规则迁移影响的基础。

3.1 三种模式核心差异对比

特性 userspace 模式 iptables 模式 IPVS 模式
工作层级 用户态代理（监听端口） 内核态 Netfilter 内核态 IPVS 框架
调度算法 轮询（Round Robin） 随机（iptables 规则链） rr/wlc/lc/lblc 等 8 种
性能开销 高（用户态↔内核态拷贝） 中（规则链遍历 O(n)） 低（哈希表 O(1)）
大规模集群 不适用（>1000 Service） 规则膨胀，延迟增加 推荐（万级 Service）
NodePort 支持 需额外 iptables 规则 原生支持 原生支持
当前状态 已弃用（v1.11+） 默认模式（v1.0+） 生产推荐（v1.11+ GA）
升级迁移提示： 在集群升级过程中，如果从 iptables 模式切换到 IPVS 模式，或证书轮换后需要重建 kube-proxy 规则，必须理解两种模式在 conntrack 表项、规则链结构和调度行为上的差异，否则可能导致流量中断或负载不均。

3.2 userspace 模式（已弃用）

userspace 模式是 kube-proxy 最早的实现。kube-proxy 在用户态监听一个随机端口，并为每个 Service 在本地开启一个代理端口。发往 Service VIP 的流量通过 iptables 规则重定向到 kube-proxy 的用户态进程，再由 kube-proxy 转发到后端 Pod。

数据流转路径

  1. 客户端请求 → 目标 Service VIP:Port
  2. Node iptables（PREROUTING 链）将目标 VIP 匹配后，DNAT 到 kube-proxy 本地监听端口（如 127.0.0.1:10443）
  3. kube-proxy 用户态进程 接收连接，从 Endpoint 列表中按轮询选择一个后端 Pod
  4. kube-proxy 发起新连接 到后端 Pod IP:Port（源 IP 为 Node IP）
  5. 响应数据 从 Pod 返回 kube-proxy，再返回客户端
性能瓶颈： 所有流量经过两次用户态↔内核态上下文切换，且 kube-proxy 需要维护大量并发连接，吞吐量低，延迟高。仅适用于小规模测试环境，生产集群不应使用。

3.3 iptables 模式（默认模式）

iptables 模式利用 Linux 内核 Netfilter 框架的 DNAT 规则，直接在内核态完成流量转发，无需用户态进程介入。kube-proxy 负责生成和维护 iptables 规则链，每个 Service 对应一组规则，每个后端 Pod 对应一条随机概率规则。

数据流转路径

  1. 客户端请求 → 目标 Service VIP:Port（或 NodePort）
  2. PREROUTING 链 → KUBE-SERVICES 链：匹配 Service VIP，跳转到对应 Service 的专用链（如 KUBE-SVC-XXXX）
  3. KUBE-SVC-XXXX 链：包含多条规则，每条规则使用 statistic mode random probability 按权重选择后端
  4. 选中的规则 跳转到 KUBE-SEP-YYYY 链，执行 DNAT 将目标 IP 改为 Pod IP
  5. FORWARD 链 允许转发，数据包到达 Pod
  6. 响应包 经过 conntrack 记录，自动做 SNAT 回程
# 查看 Service 对应的 iptables 规则链示例
iptables -t nat -L KUBE-SERVICES -n --line-numbers
iptables -t nat -L KUBE-SVC-XXXX -n
iptables -t nat -L KUBE-SEP-YYYY -n
规则链遍历问题： 当集群中有数千个 Service 时，iptables 规则链线性增长。每个数据包需要遍历所有匹配规则，CPU 开销随规则数线性增加，导致延迟抖动。这是 iptables 模式在大规模集群中的主要瓶颈。

3.4 IPVS 模式（生产推荐）

IPVS（IP Virtual Server）模式基于 Linux 内核的 IPVS 框架，使用哈希表存储转发规则，实现 O(1) 时间复杂度查找。kube-proxy 仅作为 IPVS 规则的管理者，将 Service 和 Endpoint 映射为 IPVS 虚拟服务器和真实服务器，数据转发完全在内核态完成。

数据流转路径

  1. 客户端请求 → 目标 Service VIP:Port
  2. PREROUTING 链 → KUBE-SERVICES 链：匹配 Service VIP，使用 ipvsadm 创建的虚拟服务器（VS）处理
  3. IPVS 哈希表 直接命中虚拟服务器，根据调度算法（如 rr、wlc）选择后端真实服务器（RS）
  4. 内核态 DNAT 将目标 IP 改为选中的 Pod IP，直接转发
  5. 响应包 通过 conntrack 回程，无需遍历规则链
# 查看 IPVS 虚拟服务器和真实服务器
ipvsadm -L -n

# 输出示例
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 192.168.1.10:6443           Masq    1      0          0
TCP  10.96.0.10:53 rr
  -> 192.168.1.20:53             Masq    1      0          0
调度算法选择： IPVS 支持 rr（轮询）、wlc（加权最少连接）、lc（最少连接）、lblc（基于局部性的最少连接）等 8 种算法。对于无状态服务推荐 rr；对于长连接服务推荐 wlc 或 lc。在证书轮换后，如果后端 Pod 重建，IPVS 的调度算法能更快地平衡新连接。

3.5 三种模式数据流转对比 SVG 图

下图展示了三种模式下从客户端请求到后端 Pod 的完整数据流转路径，突出内核态与用户态的边界差异。

kube-proxy 三种模式数据流转路径对比 用户态 内核态 userspace 模式 客户端请求 iptables DNAT → 本地端口 kube-proxy 用户态进程 后端 Pod iptables 模式 客户端请求 KUBE-SERVICES 链 KUBE-SVC 规则链 后端 Pod IPVS 模式 客户端请求 IPVS 哈希表 调度算法选择 RS 后端 Pod 关键差异说明 • userspace：流量经过用户态进程，两次上下文切换，性能最差（已弃用） • iptables：内核态 DNAT，规则链线性遍历 O(n)，大规模集群延迟增加 • IPVS：内核态哈希表 O(1) 查找，支持 8 种调度算法，生产环境推荐 • 升级迁移时需关注 conntrack 表项清理与规则重建顺序

3.6 证书轮换场景下的规则迁移影响

在集群升级过程中进行证书轮换时，kube-proxy 的规则迁移需要关注以下关键点：

  • 规则重建时机： kube-proxy 在证书轮换后需要重新加载配置，iptables 模式会全量刷新规则链，IPVS 模式则通过 ipvsadm 增量更新虚拟服务器。
  • conntrack 表项： 规则迁移可能导致已有连接的 conntrack 表项失效，需要等待连接超时或主动清理。IPVS 模式对 conntrack 的依赖更轻，迁移影响更小。
  • 调度算法一致性： 如果从 iptables 模式切换到 IPVS 模式，默认的随机调度变为轮询调度，可能导致后端 Pod 负载分布变化，建议在低峰期操作。
  • NodePort 规则： 两种模式对 NodePort 的处理方式不同，iptables 依赖单独的 KUBE-NODEPORTS 链，IPVS 则直接绑定到虚拟服务器，迁移时需要验证 NodePort 可达性。
最佳实践： 在证书轮换前，先通过 kubectl get endpointslices 确认后端 Pod 状态正常；轮换后使用 ipvsadm -L -n（IPVS 模式）或 iptables -t nat -L KUBE-SERVICES -n（iptables 模式）验证规则是否按预期重建。建议在测试环境先执行一次完整的规则迁移演练。
← 上一章 📖 返回目录 下一章 →