本文发表已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否仍准确无误。

Kubernetes 1.29：新（Alpha）特性，Service 的 Load Balancer IP 模式

作者：杨傲寒 |

本博客介绍 Kubernetes 1.29 中的一项新的 Alpha 特性。它提供了一种可配置的方法，用于定义 Service 实现（本文以 kube-proxy 为例）如何在集群内处理从 Pod 到 Service 的流量。

背景

在较旧的 Kubernetes 版本中，kube-proxy 会拦截发往类型为 LoadBalancer 的 Service 相关联的 IP 地址的流量。无论您使用 kube-proxy 的何种模式，都会发生这种情况。这种拦截实现了预期行为（流量最终到达 Service 后面的预期端点）。实现这一机制取决于 kube-proxy 的模式；在 Linux 上，iptables 模式下的 kube-proxy 会直接将数据包重定向到端点；ipvs 模式下，kube-proxy 会在节点上的一个接口上配置负载均衡器的 IP 地址。实现这种拦截的动机有两个原因：

  1. 流量路径优化：当 Pod 中的容器发送一个发往负载均衡器 IP 地址的出站数据包时，高效地绕过负载均衡器，直接将 Pod 流量重定向到后端服务。

  2. 处理负载均衡器数据包：一些负载均衡器发送的数据包，其目标 IP 设置为负载均衡器的 IP 地址。因此，这些数据包需要直接路由到正确的后端（该后端可能不在该节点本地），以避免循环。

问题

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

  1. 源 IP：一些云提供商在向节点传输数据包时，使用负载均衡器的 IP 作为源 IP。在 kube-proxy 的 ipvs 模式下，存在一个问题，即来自负载均衡器的健康检查永远不会返回。发生这种情况是因为回复数据包会被转发到本地接口 kube-ipvs0（负载均衡器的 IP 绑定在该接口上），然后被忽略。

  2. 负载均衡器层面的功能丢失：某些云提供商在负载均衡器层面提供功能（例如 TLS 终止、代理协议等）。绕过负载均衡器会导致数据包到达服务时这些功能丢失（从而导致协议错误）。

即使禁用新的 alpha 行为（默认设置），也存在一种临时解决方案，即为 Service 设置 .status.loadBalancer.ingress.hostname，以绕过 kube-proxy 绑定。但这只是一个权宜之计。

解决方案

总之，为云提供商提供一个选项来禁用当前行为将非常有益。

为了解决这个问题，Kubernetes v1.29 为 Service 引入了一个新的（alpha）字段 .status.loadBalancer.ingress.ipMode。该字段指定了负载均衡器 IP 的行为方式，并且只有当 .status.loadBalancer.ingress.ip 字段也被指定时才能指定。

.status.loadBalancer.ingress.ipMode 字段可能有两个值："VIP" 和 "Proxy"。默认值是 "VIP"，这意味着传递到节点且目标设置为负载均衡器 IP 和端口的流量将由 kube-proxy 重定向到后端服务。这保留了 kube-proxy 的现有行为。"Proxy" 值旨在阻止 kube-proxy 在 ipvs 和 iptables 两种模式下将负载均衡器的 IP 地址绑定到节点。因此，流量会直接发送到负载均衡器，然后转发到目标节点。转发数据包的目标设置取决于云提供商的负载均衡器如何传递流量：

  • 如果流量传递到节点然后通过 DNAT 转换到 Pod，则目标将设置为节点的 IP 和节点端口；
  • 如果流量直接传递到 Pod，则目标将设置为 Pod 的 IP 和端口。

用法

以下是启用此特性的必要步骤：

  • 下载 最新的 Kubernetes 项目（版本 v1.29.0 或更高）。
  • 在 kube-proxy、kube-apiserver 和 cloud-controller-manager 上使用命令行标志 --feature-gates=LoadBalancerIPMode=true 启用特性门控。
  • 对于类型为 LoadBalancer 的 Service，将 ipMode 设置为适当的值。此步骤通常由您选择的 cloud-controller-manager 在 EnsureLoadBalancer 过程中处理。

更多信息

参与贡献

通过 Slack 联系我们： #sig-network，或通过 邮件列表。

致谢

非常感谢 @Sh4d1 提供了最初的 KEP 和初步实现代码。我中途接手并完成了这项工作。同样，对协助此特性设计、实现和评审的其他贡献者深表感谢（按字母顺序排列）：