在Kubernetes集群中暴露Service到外部网络时，spec.externalTrafficPolicy是一个直接影响流量转发行为的关键字段。该字段目前支持Cluster与Local两种取值，二者在源IP保留、负载分发范围以及故障容忍度方面存在本质区别。不少线上故障的根源，正是运维人员在未理解其底层机制前随意切换了该参数。
底层转发机制与iptables规则差异
当Service类型为NodePort或LoadBalancer时，kube-proxy会根据externalTrafficPolicy生成不同的iptables链。在Cluster模式下，kube-proxy在nat表的KUBE-SERVICES链中对目的IP为Service集群IP的报文做MASQUERADE，将源IP改写为节点IP，随后通过随机或轮询方式转发到任一具备就绪端点的Pod，无论该Pod是否位于接收流量的节点上。
Local模式则完全不同。kube-proxy只会把外部流量转发给当前节点上运行的、且属于该Service后端的就绪Pod。它通过KUBE-NODE-PORT-LOCAL等专属链实现，若本节点没有可用端点，则直接丢弃数据包而不跨节点转发。这样做的好处是Pod内拿到的remote address就是真实客户端IP，不需要借助HTTP头或PROXY协议即可做安全策略。
下面是一段简化版的iptables规则示意，展示Local模式如何限制转发范围：
# 仅当本节点存在本地端点时才接受NodePort流量 -A KUBE-NODE-PORT-LOCAL -p tcp --dport 30080 -j KUBE-MARK-MASQ -A KUBE-NODE-PORT-LOCAL -p tcp --dport 30080 -j KUBE-SVC-XXXX # 若不匹配本地链，则直接DROP -A KUBE-NODE-PORT -p tcp --dport 30080 -j KUBE-NODE-PORT-LOCAL -A KUBE-NODE-PORT -p tcp --dport 30080 -j DROP
从规则可见，Local模式在节点无本地端点时不会像Cluster模式那样借助隧道或二次路由去其他节点找Pod，因此外部LB的主动健康检查若打到空节点便会失败。这也是为什么云厂商负载均衡器在Local模式下需要配置仅对存在端点的节点探活。
真实客户端IP与源地址伪装的影响
Cluster模式为了保证调度灵活性，会对数据包做SNAT，即把客户端IP替换为节点IP。对于绝大多数无状态Web服务而言，这不会造成业务错误，但一旦后端依赖TCP层真实源IP做限流、审计或地理位置识别，就会拿到统一的节点IP段，导致策略失效。
Local模式回避了SNAT，它要求kube-proxy以iptables或IPVS方式直接投递给本地Pod。由于未改写源地址，Pod中的服务可以通过标准socket API获取真实用户IP。但代价是：如果集群七个节点中只有三个节点部署了该服务的Pod，那么外部流量若被DNS或LB轮询到其余四个空节点，连接会被重置。
以下Go代码片段演示了在Local模式下HTTP服务如何读取真实IP：
package main
import (
"fmt"
"net/http"
)
func handler(w http.ResponseWriter, r *http.Request) {
// Local模式下 r.RemoteAddr 为客户端真实IP:端口
fmt.Fprintf(w, "client ip: %sn", r.RemoteAddr)
}
func main() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil)
}
如果换成Cluster模式，上述代码输出的将是节点内部网段地址。开发中若需兼顾二者，可考虑在Ingress层终止连接并注入X-Forwarded-For头，但NodePort直暴露场景无法绕过此限制。
高可用性与容量规划的实践对比
从可用性角度看，Cluster模式明显更稳健。因为任意节点收到外部请求都能找得到后端Pod，扩容缩容时无需调整LB的探活节点列表。在大规模集群中，这种免运维特性降低了入口中断风险。
Local模式则倒逼使用者做拓扑约束。例如用daemonSet保证每节点均有Pod，或用 topologyKey 配合反亲和性把Pod铺满特定节点组，否则就会出现部分入口节点“假死”。但它带来的收益是精确的会话保持与更低的网络跳数，对延迟敏感且需IP鉴权的游戏或金融接口尤为合适。
我们可以用一张简表总结二者取舍：
| 维度 | Cluster | Local |
|---|---|---|
| 源IP保留 | 否（SNAT） | 是 |
| 跨节点转发 | 支持 | 不支持 |
| LB健康检查 | 所有节点可通过 | 仅端点节点通过 |
| 适用场景 | 通用Web | IP鉴权、低延迟 |
实际落地时，建议先确认业务是否强依赖真实IP。若不依赖，优先Cluster以减少排障成本；若依赖，则配套使用 endpointSlices 与LB的本地端点探测，并在节点维护时主动 cordon 并摘流，避免Local模式放大单点故障。
KubernetesexternalTrafficPolicyService负载均衡修改时间：2026-08-16 18:20:13