当Kubernetes集群Service超200个时节点CPU持续高于70%、响应延迟上升，大概率因kube-proxy使用iptables模式导致线性遍历开销，须切换至IPVS模式；需确认当前模式、检查并加载ip_vs等5个内核模块、修改ConfigMap启用mode: "ipvs"、滚动更新DaemonSet并验证ipvsadm规则生效。
当Kubernetes集群中Service数量超过200个时，节点CPU使用率持续高于70%、Service响应延迟明显上升，大概率是kube-proxy仍在使用iptables模式——它在规则量激增时会触发线性遍历开销，必须切换到IPVS模式才能恢复稳定。
确认当前模式并检查节点支持
先验证当前kube-proxy是否运行在iptables模式：执行 kubectl -n kube-system logs $(kubectl -n kube-system get pod -l k8s-app=kube-proxy -o jsonpath='{.items[0].metadata.name}') | grep -i "using.*iptables"，若输出匹配则确认为iptables模式。
在所有Master和Worker节点上运行 lsmod | grep -E 'ip_vs|nf_conntrack'，必须看到 【ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh、nf_conntrack】 五个模块全部列出，缺一不可；若缺失，后续IPVS无法初始化，会静默回退到iptables。
这一步操作起来很简单，直接把命令复制粘贴到每个节点终端里执行就行。
加载IPVS内核模块（永久生效）
方法一：创建开机自动加载配置
在所有节点执行：echo -e "ip_vs\nip_vs_rr\nip_vs_wrr\nip_vs_sh\nnf_conntrack" | sudo tee /etc/modules-load.d/ipvs.conf → 然后运行 sudo systemctl restart systemd-modules-load。
方法二：临时加载（仅当前会话有效，重启即失效）
运行 sudo modprobe ip_vs ip_vs_rr ip_vs_wrr ip_vs_sh nf_conntrack。⚠️注意：此方式必须在每次节点重启后重新执行，生产环境严禁只用该方法。
修改kube-proxy ConfigMap启用IPVS
第一步：编辑ConfigMap
kubectl edit configmap kube-proxy -n kube-system
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
第二步：定位到data.config.conf字段下的mode行，将 mode: "" 或 mode: "iptables" 改为 mode: "ipvs"。
第三步：可选增强配置——在ipvs段下添加调度策略与ARP防护：
ipvs: strictARP: true scheduler: "rr"
strictARP设为true能防止局域网ARP广播风暴，rr表示轮询调度，这是最稳妥的初始选择。
滚动更新kube-proxy DaemonSet
① 删除全部旧Pod：kubectl delete pod -l k8s-app=kube-proxy -n kube-system
② 等待新Pod就绪：kubectl get pod -n kube-system -l k8s-app=kube-proxy -w，直到状态变为Running且READY为1/1。
③ 验证日志是否加载IPVS：kubectl logs -n kube-system $(kubectl -n kube-system get pod -l k8s-app=kube-proxy -o jsonpath='{.items[0].metadata.name}') | grep -i "ipvs proxier"，应输出 【Using ipvs Proxier】 和 【Creating dualStackProxier for ipvs】。
④ 最终确认：在任一节点执行 ipvsadm -Ln，能看到类似 TCP 10.96.0.1:443 rr -> 192.168.31.103:6443 Masq 的真实转发条目，说明IPVS规则已生成并生效。
