Kubernetes 1.29 新的 Alpha 特性：Service 的负载均衡器 IP 模式

作者： 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 地址配置到节点的一个网络接口上。采用这种拦截有两个原因：

  1. 流量路径优化： 高效地重定向 Pod 流量 - 当 Pod 中的容器发送指向负载均衡器 IP 地址的出站包时， 会绕过负载均衡器直接重定向到后端服务。
  1. 处理负载均衡数据包： 有些负载均衡器发送的数据包设置目标 IP 为负载均衡器的 IP 地址。 因此，这些数据包需要被直接路由到正确的后端（可能不在该节点本地），以避免回环。

问题

然而，上述行为存在几个问题：

  1. 源 IP（Source IP）： 一些云厂商在传输数据包到节点时使用负载均衡器的 IP 地址作为源 IP。在 kube-proxy 的 ipvs 模式下， 存在负载均衡器健康检查永远不会返回的问题。原因是回复的数据包被转发到本地网络接口 kube-ipvs0（绑定负载均衡器 IP 的接口）上并被忽略。
  1. 负载均衡器层功能缺失： 某些云厂商在负载均衡器层提供了部分特性（例如 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 进行处理。

更多信息

联系我们

通过 Slack 频道 #sig-network, 或者通过邮件列表联系我们。

特别鸣谢

非常感谢 @Sh4d1 的原始提案和最初代码实现。 我中途接手并完成了这项工作。同样我们也向其他帮助设计、实现、审查特性代码的贡献者表示感谢（按首字母顺序排列）：