作者： 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 地址配置到节点的一个网络接口上。采用这种拦截有两个原因：
会绕过负载均衡器直接重定向到后端服务。
因此，这些数据包需要被直接路由到正确的后端（可能不在该节点本地），以避免回环。
问题
然而，上述行为存在几个问题：
一些云厂商在传输数据包到节点时使用负载均衡器的 IP 地址作为源 IP。在 kube-proxy 的 ipvs 模式下，
存在负载均衡器健康检查永远不会返回的问题。原因是回复的数据包被转发到本地网络接口
kube-ipvs0（绑定负载均衡器 IP 的接口）上并被忽略。某些云厂商在负载均衡器层提供了部分特性（例如 TLS 终结、协议代理等）。
绕过负载均衡器会导致当数据包抵达后端服务时这些特性不会生效（导致协议错误等）。
即使新的 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 和端口； - 如果流量被直接转发到 Pod，目的地应当被设置为 Pod 的 IP 和端口。
用法
开启该特性的必要步骤：
- 下载 Kubernetes 最新版本（
v1.29.0或更新）。 - 通过命令行参数
--feature-gates=LoadBalancerIPMode=true在 kube-proxy、kube-apiserver 和
cloud-controller-manager 开启特性门控。 - 对于
type: LoadBalancer类型的 Service，将ipMode设置为合适的值。
这一步可能由你在EnsureLoadBalancer过程中选择的 cloud-controller-manager 进行处理。
更多信息
- 阅读指定负载均衡器状态的 IPMode。
- 阅读 KEP-1860 - 让 Kubernetes 感知负载均衡器的行为 (sic)。
联系我们
通过 Slack 频道 #sig-network,
或者通过邮件列表联系我们。
特别鸣谢
非常感谢 @Sh4d1 的原始提案和最初代码实现。
我中途接手并完成了这项工作。同样我们也向其他帮助设计、实现、审查特性代码的贡献者表示感谢（按首字母顺序排列）：
- @aojea
- @danwinship
- @sftim
- @tengqm
- @thockin
- @wojtek-t
