kube-proxy 的两种模式
kube-proxy 负责把 Service 的虚拟 IP 与端口落到真实后端 Pod 上，它有两种主流实现。iptables 模式用内核 NAT 规则做四层转发，通用性最好，规则量随 Service 与端点数量线性增长；IPVS 模式借助内核 IPVS 模块建立转发条目，用哈希表查找，端点规模大时性能更平稳，并支持多种调度算法。较新版本中 IPVS 模式已被标记为弃用，选型应跟随发行版与云厂商的建议。
两种模式对比
| 维度 | iptables | IPVS |
|---|---|---|
| 实现机制 | 内核 netfilter 规则链（KUBE-SERVICES 等） | 内核 IPVS 虚拟服务与真实服务器条目 |
| 查找方式 | 规则顺序匹配，规模大时延迟增长 | 哈希查找，端点规模大时更平稳 |
| 调度算法 | 随机等基础行为 | 支持轮询、最少连接等多种算法 |
| 依赖 | 仅需 iptables 能力 | 需要 IPVS 内核模块与对应工具 |
| 现状 | 长期默认与通用选择 | 较新版本中已标记弃用，跟随发行版建议 |
典型使用场景
- 大集群 Service 数量多：关注转发时的规则量与查找开销，评估是否需要换模式
- 连接不均衡：iptables 模式可能因规则顺序产生偏好，观察是否需要更均衡的调度算法
- 内核能力受限环境：部分精简发行版缺少 IPVS 模块，只能使用 iptables
- 排查转发异常：确认节点上的转发规则是否存在，判断 kube-proxy 是否在工作
- 升级评估：模式切换需要逐节点滚动重启，属于有业务风险的变更
查看当前模式与规则
查看当前模式与规则
kubectl -n kube-system get cm kube-proxy -o yaml | grep -i -A2 mode # 配置里声明的模式
kubectl -n kube-system logs ds/kube-proxy --tail=20 | grep -i -E 'ipvs|iptables'
# 以下命令需在节点上执行
# iptables -t nat -L KUBE-SERVICES -n | head -20 # iptables 模式下的规则链
# ipvsadm -Ln | head -30 # IPVS 模式下的虚拟服务与后端排查要点
| 现象 | 检查点 | 说明 |
|---|---|---|
| Service 集群内不通 | 对应节点上的转发规则 | 规则缺失说明 kube-proxy 未生效或未同步 |
| 个别节点异常 | 该节点 kube-proxy Pod 日志 | 多副本部署时常见单点异常 |
| 大量 Service 时延迟升高 | 节点规则数量与查找开销 | 评估模式是否需要调整 |
| 切换模式后服务短暂异常 | 滚动与就绪时间 | 切换需重启组件，逐节点进行并留出观察窗口 |
kube-proxy 只是转发规则的实现者：Service 的端点计算、会话保持与拓扑感知由 API 侧与组件共同决定。集群内访问异常时，先确认 Endpoints 是否为空，再谈转发模式。
切换转发模式需要逐节点重启 kube-proxy，期间该节点上的 Service 转发会短暂异常。务必滚动进行、确认每个节点恢复后再继续，并避免与业务发布窗口重叠。