这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
作者： Aohan Yang
译者： Allen Zhang
本文介绍 Kubernetes 1.29 中一个新的 Alpha 特性。 此特性提供了一种可配置的方式用于定义 Service 的实现方式，本文中以 kube-proxy 为例介绍如何处理集群内从 Pod 到 Service 的流量。
在 Kubernetes 早期版本中，kube-proxy 会拦截指向 type: LoadBalancer Service 关联
IP 地址的流量。这与你为 kube-proxy 所使用的哪种模式无关。
这种拦截实现了预期行为（流量最终会抵达服务后挂载的端点）。这种机制取决于 kube-proxy 的模式，在 Linux 中，运行于 iptables 模式下的 kube-proxy 会重定向数据包到后端端点；在 ipvs 模式下， kube-proxy 会将负载均衡器的 IP 地址配置到节点的一个网络接口上。采用这种拦截有两个原因：
然而，上述行为存在几个问题：
kube-ipvs0（绑定负载均衡器 IP 的接口）上并被忽略。即使新的 Alpha 特性默认关闭，也有临时解决方案，
即为 Service 设置 .status.loadBalancer.ingress.hostname 以绕过 kube-proxy 绑定。
但这终究只是临时解决方案。
总之，为云厂商提供选项以禁用当前这种行为大有裨益。
Kubernetes 1.29 版本为 Service 引入新的 Alpha 字段 .status.loadBalancer.ingress.ipMode 以解决上述问题。
该字段指定负载均衡器 IP 的运行方式，并且只有在指定 .status.loadBalancer.ingress.ip 字段时才能指定。
.status.loadBalancer.ingress.ipMode 可选值为："VIP" 和 "Proxy"。
默认值为 VIP，即目标 IP 设置为负载均衡 IP 和端口并发送到节点的流量会被 kube-proxy 重定向到后端服务。
这种方式保持 kube-proxy 现有行为模式。Proxy 用于阻止 kube-proxy 在 ipvs 和 iptables 模式下绑定负载均衡 IP 地址到节点。
此时，流量会直达负载均衡器然后被重定向到目标节点。转发数据包的目的值配置取决于云厂商的负载均衡器如何传输流量。
DNAT）的方式到达 Pod，目的地应当设置为节点和 IP 和端口；开启该特性的必要步骤：
v1.29.0 或更新）。--feature-gates=LoadBalancerIPMode=true 在 kube-proxy、kube-apiserver 和
cloud-controller-manager 开启特性门控。type: LoadBalancer 类型的 Service，将 ipMode 设置为合适的值。
这一步可能由你在 EnsureLoadBalancer 过程中选择的 cloud-controller-manager 进行处理。通过 Slack 频道 #sig-network, 或者通过邮件列表联系我们。
非常感谢 @Sh4d1 的原始提案和最初代码实现。 我中途接手并完成了这项工作。同样我们也向其他帮助设计、实现、审查特性代码的贡献者表示感谢（按首字母顺序排列）：