一、kube-proxy 负责什么¶

除 ExternalName 之外，大多数 Service 的流量转发都依赖 kube-proxy。它运行在每个节点上，负责把访问 Service 的流量重定向到后端 Pod。

原文把常见代理模式分成两类：

• iptables
• ipvs

两种模式的目标一样，都是完成 Service 到后端实例的转发；差别主要在实现机制、性能特征和调度能力。

二、iptables 模式怎么工作¶

在 iptables 模式下，kube-proxy 会监听 Service 和 Endpoint/EndpointSlice 的变化，然后把对应规则写入 Linux 内核的 netfilter/iptables。

可以把它概括成三步：

1. 读取 Service 和后端端点信息
2. 生成匹配 Service IP 与端口的 iptables 规则
3. 将流量重定向到某个后端 Pod

原文总结的优缺点也很典型：

• 优点：实现成熟、稳定、易理解
• 缺点：Service 越多，规则越多，规模大时性能和维护成本会变高

三、IPVS 模式为什么更适合大规模场景¶

IPVS 是 Linux 内核里的虚拟服务器负载均衡能力，专门为高性能流量分发而设计。kube-proxy 在 ipvs 模式下，会通过 netlink 配置 IPVS 规则，而不是主要依赖大规模 iptables 链规则。

它的优势主要有：

• 数据结构更高效，查找更快
• 大量 Service 场景下性能更稳
• 原生支持更多负载均衡算法

但要注意一个前提：节点必须具备 IPVS 内核模块，否则 kube-proxy 可能退回到 iptables 模式。

四、IPVS 支持哪些调度算法¶

原文列了几种常见算法：

• rr：轮询
• lc：最少连接
• sh：源地址哈希
• dh：目标地址哈希
• nq：Never Queue
• sed：Shortest Expected Delay

如果你只先记三个最常见的就够了：

• rr 适合一般均匀分发
• lc 适合连接数差异明显的场景
• sh 适合基于源地址的稳定转发需求

五、怎么查看和切换 kube-proxy 代理模式¶

原文通过本地端口查看当前模式：

curl 127.0.0.1:10249/proxyMode

默认常见结果是：

iptables

如果是 kubeadm 方式安装，可以修改 kube-proxy 的 ConfigMap，把：

mode: "ipvs"

写进去。非 kubeadm 场景，则可能需要直接改 /etc/kubernetes/kube-proxy.yaml，然后重启 kube-proxy：

systemctl restart kube-proxy

六、怎么修改 IPVS 调度算法¶

原文还演示了把调度算法改成 lc，也就是最少连接。kubeadm 场景里可以在 kube-proxy 配置中写：

scheduler: "lc"

然后通过给 DaemonSet 模板打补丁触发 kube-proxy Pod 重启：

kubectl patch daemonset kube-proxy -n kube-system -p '{"spec":{"template":{"metadata":{"annotations":{"date":"'"$(date +%s)"'"}}}}}'

验证方式包括：

curl 127.0.0.1:10249/proxyMode
yum install ipvsadm -y
ipvsadm -ln

如果 ipvsadm -ln 里已经出现 lc，就说明调度算法生效了。

七、生产里该怎么选¶

可以简单理解成：

• 小规模、默认场景：iptables 足够用
• Service 数量多、流量大、需要更强调度能力：优先考虑 ipvs

不过无论哪种模式，Service 的本质都没有变：给客户端一个稳定入口，再由节点侧的转发组件把流量送到真正的 Pod。只不过 kube-proxy 选择了不同的内核手段去完成这件事。