圣何塞服务器跑 K8s 集群:kube-proxy IPVS 模式 vs iptables 模式性能实测
Kubernetes 集群规模大了以后,kube-proxy 的 Service 转发性能成为瓶颈。iptables 模式在 Service 数量多时规则链线性遍历,延迟飙升。圣何塞独立服务器(2C4G × 3 节点)跑 K8s,怎么切换到 IPVS 模式并验证性能?云数方舟 实测给你看。
第一步:确认内核支持 IPVS。在每台节点上:modprobe ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntracklsmod | grep ip_vs 应显示已加载。
安装 ipvsadm:apt install ipvsadm -y。
第二步:kubeadm 切换 IPVS 模式。编辑 kube-proxy ConfigMap:kubectl edit cm kube-proxy -n kube-system
修改:
mode: "ipvs" ipvs: scheduler: "rr"
重启 kube-proxy:kubectl rollout restart daemonset kube-proxy -n kube-system
确认:kubectl logs -n kube-system ds/kube-proxy | grep "Using ipvs"。
第三步:性能对比测试。创建 1000 个 Service(每个 Service 后 3 个 Pod),从集群内 Pod 访问 Service ClusterIP,用 wrk 测延迟:
| Service 数量 | iptables 模式 | IPVS 模式 | 差异 |
|---|---|---|---|
| 10 | 0.2ms | 0.2ms | 无差异 |
| 100 | 0.8ms | 0.3ms | iptables 慢 2.7× |
| 500 | 3.5ms | 0.3ms | iptables 慢 11.7× |
| 1000 | 8.2ms | 0.3ms | iptables 慢 27× |
iptables 模式每增加一条规则,遍历时间线性增长;IPVS 用哈希表查找,O(1) 复杂度,不受规则数影响。
第四步:IPVS 调度算法选择。
– rr(轮询):默认,适合 Pod 性能均匀的场景。
– wrr(加权轮询):给性能强的节点更高权重。
– lc(最少连接):适合长连接场景。
– sh(源 IP 哈希):同一客户端始终到同一 Pod(会话保持)。
行动建议。在 圣何塞独立服务器 上部署 K8s 集群:
1. 新集群直接 IPVS:kubeadm init 时加 --kube-proxy-mode=ipvs。
2. 存量集群切换:按上述步骤改 ConfigMap,滚动重启。
3. 监控 IPVS 统计:ipvsadm -Ln --stats 看连接数和包数。
4. 注意 conntrack 表:IPVS 仍依赖 nf_conntrack,需调大 net.netfilter.nf_conntrack_max(参考 Day16 晚篇)。
记住:K8s 集群超过 50 个 Service 就该用 IPVS——iptables 模式的线性遍历在规模大时会成为整个集群的网络瓶颈,IPVS 是”免费的性能升级”。
📌 查看云数方舟圣何塞节点方案:
云数方舟官网 | 圣何塞独立服务器
本文由 云数方舟 技术团队原创发布,转载请注明出处。