Kubernetes kube-proxy 模式选型与切换：iptables vs IPVS

来源：老郭 | 发布日期：2026-05-09

问题场景：Service 多了就卡

集群里 Service 数量一多，Pod 访问其他 Service 的延迟开始飘，P99 响应时间从 75ms 飙到 550ms，超时失败率冲到 18%。节点 CPU、内存、数据库连接池一切正常——问题可能出在 kube-proxy 的转发模式上。

⚠️ 更新提醒：K8s v1.32 实验性支持 nftables 模式，v1.33 正式 GA。但截至目前 iptables 仍是默认模式，切换 IPVS/nftables 需手动操作。

先看当前模式

# 方法1：看 kube-proxy Pod 启动日志
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=50 | grep -E "Using|proxier"
# iptables → "Using iptables proxy"
# IPVS → "Using ipvs Proxier"

# 方法2：看 ConfigMap
kubectl get cm kube-proxy -n kube-system -o yaml | grep -E "^  mode:"
# "" 或不存 → iptables；"ipvs" → IPVS

原理差异

iptables 模式：防火墙路由方案

kube-proxy 在每个 Service 的 NAT prerouting 链上插入一条规则，数据包需逐个遍历 KUBE-SERVICES 链上的规则。规则数量与 Service 数 + Endpoint 总数成正比——2000 个 Service 时，内核可能连查 2000 次才能决定包的去向。复杂度 O(n)。

IPVS 模式：专用负载均衡模块

IPVS（IP Virtual Server）是 Linux 内核的四层负载均衡模块，通过 netlink 接口直接创建虚拟服务与后端 RS，数据面使用哈希表。复杂度 O(1)——Service 从 500 涨到 5000，内核处理第一个包的时间基本持平。

IPVS 下的 SNAT、包过滤等辅助功能仍用到少量 iptables 和 ipset 规则，但数量是常数级，不随 Service 线性增长。

对比总结

性能拐点

结论：Service < 100 时两者几乎一致；1000 左右持平；超过 1000 后 iptables 延迟和 CPU 开销明显上升。超过 1000 个 Service 就可以认真考虑切换 IPVS。

IPVS 的坑（切换前必读）

坑 1：短连接 + 滚动更新 → 请求发到已不存在的 Pod

内核 net.ipv4.vs.conn_reuse_mode 参数相关。当客户端在两分钟内发大量五元组相同的短连接请求，IPVS 会复用之前连接的信息，将新请求转发到已被销毁的 Pod。

• 内核 ≥ 5.9：问题已修复（kube-proxy v1.22+ 不再主动修改此参数）
• 内核 < 5.9：conn_reuse_mode 被默认置为 0 规避 SYN 丢包，但又引入请求到旧 Pod 的问题——旧内核上两种模式"两难"

坑 2：旧内核缺 IPVS 模块

CentOS 7.6、EulerOS 2.5（内核 3.10 左右）不带或带不完整 IPVS 模块。裸切换会导致 kube-proxy 启动失败或 fallback 到 iptables。

坑 3：CNI 插件兼容性

老版本 CNI（尤其涉及 ipset 管理的网络策略）在 IPVS 模式下可能异常。主流 CNI（Calico、Cilium）已较好支持，但自研/过时方案需谨慎验证。

切换操作步骤

Step 1：安装 IPVS 内核模块（所有节点）

cat > /etc/sysconfig/modules/ipvs.modules << 'EOF'
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack
EOF
chmod 755 /etc/sysconfig/modules/ipvs.modules
bash /etc/sysconfig/modules/ipvs.modules
lsmod | grep -e ip_vs -e nf_conntrack  # 验证加载

Step 2：变更 kube-proxy 模式

推荐方式：ConfigMap 原地更新

kubectl edit cm kube-proxy -n kube-system
# 将 mode: "" 改为 mode: "ipvs"
# 可选配置调度算法：
#   ipvs.scheduler: "rr"  (轮询，默认)
#   ipvs.scheduler: "lc"  (最少连接，适合长连接)
#   ipvs.scheduler: "sh"  (源地址哈希，会话保持)

kubectl delete pod -n kube-system -l k8s-app=kube-proxy  # 触发重启

建议逐节点滚动：删一个节点的 Pod，等它起来确认 Running 后再删下一个。

备选方式：集群滚动增删节点 — 加新 IPVS 节点 → 驱逐老节点 → 循环。资源消耗大但隔离性好，适合极度敏感的生产环境。

Step 3：验证切换

kubectl logs -n kube-system <kube-proxy-pod> | grep "Using ipvs Proxier"
# 节点上查看 IPVS 规则
ipvsadm -L -n
# 预期输出：Prot LocalAddress:Port Scheduler Flags
#          -> RemoteAddress:Port Forward Weight ActiveConn InActConn

切换后必调的 sysctl

1. conn_reuse_mode（内核 < 5.9 必调）

sysctl -w net.ipv4.vs.conn_reuse_mode=0
# 或 1，依据业务场景和内核版本判断

2. conntrack 容量调大

# 检查当前使用率
sysctl net.netfilter.nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count
# 如果 count/max > 80%，扩容
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
echo 32768 > /proc/sys/net/netfilter/nf_conntrack_buckets

3. ARP 参数（多网卡/虚拟 IP 场景）

# 避免 ARP 响应错乱，通常在 MetalLB 或裸机部署时使用
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

FAQ（常见问题）

快速检查表（上线前逐项确认）

• [ ] 所有节点 lsmod | grep ip_vs 能看到相关内核模块
• [ ] kubectl logs 确认 kube-proxy 使用 "Using ipvs Proxier"
• [ ] 至少一个节点执行 ipvsadm -L -n，能看到 VS 和 RS 列表
• [ ] 测试访问正常：kubectl run -it --rm debug --image=busybox --restart=Never -- sh，手工 wget -qO- http://your-service:80/health
• [ ] 节点内核版本 < 5.9 时，已评估 conn_reuse_mode 潜在影响

关联页面