k8s实现LoadBalancer Service的网络方案

场景

在非云服务厂商提供的k8s环境下我们无法直接使用云厂商提供的LB此时我们需要在基于裸金属服务器、边缘以及虚拟化的 Kubernetes 环境中使用 LoadBalancer 类型的 Service 对外暴露服务。

方案1、通过BGP来实现

特点

• 建议使用 BGP 模式因为它可以让您创建一个没有故障转移中断和带宽瓶颈的高可用性系统。

原理

• Kubernetes 集群中部署了一个由两个 Pod 支持的 Service并分配了一个 IP 地址 172.22.0.2 供外部访问。

• 安装在 Kubernetes 集群中的 LB控制器 与 BGP 路由器建立 BGP 连接并将去往 Service 的路由发布到 BGP 路由器。

• 当外部客户端机器尝试访问 Service 时BGP 路由器会根据从 OpenELB 获得的路由在 master、worker 1 和 worker 2 节点之间进行负载均衡。 Service流量到达一个节点后kube-proxy可以进一步将流量转发到其他节点进行负载均衡Pod 1和Pod 2都可以通过kube-proxy到达

• 可以使用开源的GoBGP库来建立BGP连接进行路由发布

限制

• 要使用 BGP 模式您的路由器必须支持 BGP 和等价多路径 (ECMP) 路由。如果您的路由器不支持 BGP 或 ECMP您可以使用anonymous ARP二层模式或keepalived VIP 模式来实现类似的功能。

方案2、通过2层的anonymous ARP来实现

特点

• 一般建议使用BGP模式因为它可以让你创建一个没有故障转移中断和带宽瓶颈的高可用性系统。但是BGP 模式需要您的路由器支持 BGP 和等价多路径 (ECMP) 路由这在某些系统中可能不可用。在这种情况下您可以使用第 2 层模式来实现类似的功能。
• Worker 1和Worker 2在流量转发方面采用主备模式。当发生故障转移时Kubernetes 集群中的服务会中断一小段时间。
• 所有服务流量始终首先发送到一个节点然后在第二跳中通过 kube-proxy 转发到其他节点。因此Service带宽受限于单个节点的带宽造成带宽瓶颈
  原理

• Kubernetes 集群中部署了一个由两个 Pod 支持的 Service并分配了一个 IP 地址 192.168.0.91 供外部访问。 Service IP地址与集群节点IP地址在同一网段。

• 安装在 Kubernetes 集群中的 LB控制器 会随机选择一个节点本例中为 worker 1来处理 Service 请求。之后LB控制器 向路由器发送一个 ARP/NDP 数据包路由器将服务 IP 地址映射到 worker 1 的 MAC 地址。

• 如果集群中已经部署了多个LB控制器LB控制器利用Kubernetes的leader选举特性来保证只有一个replica响应ARP/NDP请求。

• 当外部客户端机器尝试访问Service时路由器根据Service IP地址和worker 1的MAC地址之间的映射将Service流量转发给worker 1。Service流量到达worker 1后kube-proxy可以进一步将流量转发到其他节点以进行负载均衡Pod 1 和 Pod 2 都可以通过 kube-proxy 到达。

• 如果worker 1出现故障OpenELB会重新发送一个APR/NDP包给router将Service IP地址映射到worker 2的MAC地址Service流量切换到worker 2。

限制

• 2层的anonymous ARP模式要求您的基础架构环境允许匿名 ARP/NDP 数据包否则无法使用第 2 层模式
• Worker 1和Worker 2在流量转发方面采用主备模式。当发生故障转移时Kubernetes 集群中的服务会中断一小段时间。
• 所有服务流量始终首先发送到一个节点然后在第二跳中通过 kube-proxy 转发到其他节点。因此Service带宽受限于单个节点的带宽造成带宽瓶颈

方案3、通过keepalived vip来实现

特点

• 一般建议使用BGP模式因为它可以让你创建一个没有故障转移中断和带宽瓶颈的高可用性系统。但是BGP 模式需要您的路由器支持 BGP 和等价多路径 (ECMP) 路由这在某些系统中可能不可用。在这种情况下您可以使用2层的anonymous ARP模式或keepalived VIP 模式来实现

• 与二层模式不同VIP模式不需要您的基础设施环境允许匿名ARP/NDP报文因此在适用性方面优于二层模式。

原理

• Kubernetes 集群中部署了一个由两个 Pod 支持的 Service并分配了一个 IP 地址 192.168.0.91 供外部访问。 Service IP地址与集群节点IP地址在同一网段。

• LB控制器 使用 Keepalived 来维护 Service IP 地址。 Keepalived 作为 Pod 安装在 Kubernetes 集群的每个节点上Keepalived 副本由 DaemonSet 管理。

• Keepalived 副本相互协商并选出一个领导者本例中为 worker 1来处理服务请求。之后Keepalived在worker 1的网卡上设置Service IP地址并将Service IP地址映射到worker 1的MAC地址上。私网内的所有设备都可以通过ARP协议获取到这个映射。

• 当外部客户端机器尝试访问Service时路由器根据Service IP地址和worker 1的MAC地址之间的映射将Service流量转发给worker 1。Service流量到达worker 1后kube-proxy可以进一步将流量转发到其他节点以进行负载均衡Pod 1 和 Pod 2 都可以通过 kube-proxy 到达。

• 如果worker 1挂了剩下的Keepalived副本重新选举leader比如worker 2来处理Service请求Service流量切换到worker 2。

限制

• Worker 1和Worker 2在流量转发方面采用主备模式。当发生故障转移时Kubernetes 集群中的服务会中断一小段时间。

• 所有服务流量始终首先发送到一个节点然后在第二跳中通过 kube-proxy 转发到其他节点。因此Service带宽受限于单个节点的带宽造成带宽瓶颈。

可供参考的开源方案openelb

开源的云原生负载均衡器实现openelb