如何为 Kubernetes 集群设计和实现全局负载均衡器

介绍

在多集群(可能是混合云)部署中使用 Kubernetes 或 OpenShift 时,需要考虑的问题之一是如何将流量定向到跨这些集群部署的应用程序。为了解决这个问题,我们需要一个全局负载均衡器。
https://cloudnativehub.com/uploads/article/20211017/cb7581539484fbe190a021e050d72b66.png

上图描绘了一个名为“ app”的应用程序,部署到两个 Kubernetes 集群,可通过Ingress 或网关 API 资源(为简单起见,以下称为Ingress)访问,这些资源又由两个本地负载均衡器 (LLB) 公开,可通过两个虚拟 IP(VIP)访问): VIP1 和VIP2。全局负载均衡器位于 LLB 之上,并将消费者引导至任一集群。消费者引用单个全局FQDN (在本例中为app.globaldomain.io)来访问应用程序。

实际上,Kubernetes 社区内还没有明确的方向来说明如何为 Kubernetes 集群设计和实现全局负载均衡器。只尝试了小的孤立的努力。

在本文中,我们将讨论正确构建全局负载均衡器解决方案需要什么,以及基于 Kubernetes 集群中运行的工作负载自动化配置需要什么。


在继续进行特定的架构选项之前,我们将回顾全局负载均衡器应该具有的共同特征。

全局负载均衡器要求


Kubernetes 集群的全局负载均衡器负责确定与在单个 Kubernetes 集群中运行的实例相关的服务连接应该路由到哪里。这些集群可以在地理上分布或驻留在同一都市区域内。

Kubernetes 为传入流量进入集群提供了两种主要方法:Ingresses(Ingress、Gateway API 和OpenShift Routes)和LoadBalancer Services。

我们的全球负载均衡器需要同时支持两者。值得注意的是,在 Ingresses(一个 L7 反向代理)的情况下,我们经常有一个本地负载均衡器暴露多个应用程序共享的 VIP。

此外,除了循环之外,全局负载均衡器还应提供复杂的负载均衡策略。特别是,经常请求的策略是能够根据某些指标(延迟、地理距离等)返回最接近尝试连接的消费者的端点。在地理分布的场景中,此策略允许消费者以最低延迟连接到端点。在城域场景中,这允许在同一数据中心内路由源自数据中心的连接。

另一种常用的策略是加权路由,它通过一次仅将所有权重分配给一个集群来帮助实现主动/被动配置。

最后,全局负载均衡器应该能够识别应用程序何时变得不可用,并且应该只将流量引导到健康的端点。这通常通过配置健康检查来完成。

总而言之,以下是我们在全局负载均衡器中寻找的要求:

  1. 能够通过 LoadBalancer 服务和 Ingress 进行负载平衡
  2. 复杂的负载均衡策略
  3. 支持健康检查和从负载均衡池中删除不健康端点的能力


介绍全局负载均衡器架构选项

根据我们的经验,有两种设计全局负载均衡器的架构方法:
  1. 基于 DNS。
  2. 基于任播(也称选播)。
让我们分别检查它们。

基于 DNS 的方法


https://cloudnativehub.com/uploads/article/20211017/8c113360ce05c08a41dabbc85aa7b970.png


在基于 DNS 的方法中,负载平衡决策由 DNS 服务器做出。

从上图中我们可以看出,服务消费者向 DNS 服务器查询app.globaldomain.io ,DNS 服务器以两个集群的地址之一进行响应。

基于 DNS 的负载平衡具有相对容易实施的优势,因为 DNS 服务器是任何网络基础设施的一部分。然而,简单性带来了一系列限制:

1、客户端会将 DNS 响应缓存一段时间(通常根据 TTL,但不能保证)。

如果缓存中的位置发生中断,客户端可能无法运行,直到该位置的问题得到解决或 DNS 缓存刷新。

2、当 DNS 服务器配置为返回多个 IP 值时,客户端将负责选择它将连接到的特定端点,从而导致潜在的不平衡流量模式。

即使 DNS 服务器随机化返回 IP 的顺序也是如此。

这是因为 DNS 规范中没有任何内容要求在响应遍历 DNS 服务器层次结构时必须保留 IP 的顺序,或者服务消费者必须遵守该顺序。

除了上述限制之外,典型的 DNS 服务器不支持复杂的负载平衡策略,也不支持后端健康检查。

但是,有几种高级 DNS 实现确实支持这些功能,包括:

  • 网络设备,例如F5 BigIP 和Citrix ADC,常见于本地数据中心
  • DNS 托管解决方案,例如Infoblox 和CloudFlare
  • 主要公有云提供商的DNS服务:AWS Route53、Azure Traffic Manager

请注意,在实施这些全局负载平衡器方法时,如果使用入口(入口v1、v2或OpenShift路由)将流量路由到应用程序,则入口中配置的主机名必须与消费者在查询DNS服务器时使用的全局FQDN相同。此主机名将不同于应用程序的默认地址,该地址通常是特定于群集的,必须显式设置。

概括
https://cloudnativehub.com/uploads/article/20211017/8f7b719198fb72c3fdad955e9e3544ca.png

任播的方法

基于任播的方法是指一种架构模式,其中许多服务器通告相同的 IP,路由器可以通过不同的网络路径将数据包路由到这些位置。


有两种方法可以实现这种架构:

  • 基于 IP/BGP 的任播服务:明确设计和利用 IP/BGP 技术来实现任播负载平衡功能。
  • 使用任播/CDN 云服务:利用现有的支持任播的网络(例如提供以任播为中心的负载平衡和 CDN 服务的特殊公共云任播服务)。
此类云服务的示例包括Google Cloud Network Load balancer、AWS Global Accelerator 以及来自其他提供商的类似全球负载平衡服务。BGP/任播功能在本地数据中心并不总是可用。鉴于 BGP 在 L3/4 级别运行,它不直接支持独立故障转移共享同一 VIP 的多个应用程序的能力。

基于 IP/BGP 的方法


我们首先来看一个基于 IP/BGP 的任播设计。这可以通过 IPv4 的BGP 和ECMP或通过对 IPv6 中任播的本机支持来实现。

由此产生的架构可以类似于以下描述:

https://cloudnativehub.com/uploads/article/20211017/93f8e79c973af9ad7c793bc5162706e1.png


该图显示了部署在两个集群内并通过LoadBalancer服务公开的应用程序。两种负载平衡器服务的VIP是相同的(图中VIP Global中的VIP为VIP)。通过BGP对路由器进行编程,为VIPG的两条路径(ECMP)分配相等的成本,从而实现主动选播负载均衡器解决方案。备用BGP指标(如不等成本和本地偏好)也可用于实施额外的负载平衡策略,包括主动备用。


特别是,可以通过让一个集群发布比另一个集群更好的路由度量来实现主备,这样,在正常情况下,所有到特定 VIP 的流量都路由到该集群,而不管与客户端的 IP 跳距如何。当灾难发生时,会选择不太理想的路线,因为它成为唯一可行的选择。

这种方法的优点是故障转移不依赖于客户端并由路由器管理,与基于 DNS 的解决方案相比,故障转移速度更快(毫秒级)。

为了获得最佳故障转移体验,路由器需要使用 3 元组或 5 元组散列以及一致散列(有时称为弹性散列)来执行流量感知多路径负载平衡。如果没有此功能,故障转移性能和可用性可能会受到影响,因为大量 TCP 会话可能会在网络故障事件时重置,从而导致会话从一个后端重新散列和重新路由到另一个后端。现代路由器通常支持这些功能;但是,有必要确保正确配置它们以实现一致的散列。

这种方法有以下限制:

  • BGP/任播功能在本地数据中心并不总是可用。
  • 鉴于 BGP 在 L3/4 级别运行,它不直接支持独立故障转移共享同一 VIP 的多个应用程序的能力。


Kubernetes 参考实现

实现上述方法的一种选择是在 BGP 模式下使用MetalLB 来实现 Kubernetes LoadBalancer 服务,并将集群节点连接到支持 BGP 的物理网络。拓扑类似于上图,其中部署到每个集群节点的 MetalLB 代理将与外部 BGP 网络对等,以通过多个集群的多个节点通告同一 VIP 的可达性:

https://cloudnativehub.com/uploads/article/20211017/149865fc759cc99bac9351f976d61b9d.png


请注意,不需要使用 BGP 路由进行集群内 pod-to-pod 网络的 CNI 插件来实现此解决方案。BGP 仅由 MetalLB 用于向外部网络通告 LoadBalancer VIP。MetalLB 遵循 Kubernetes 服务规范的 LoadBalancer API,因此可用于没有可用云提供商或云提供商不遵循LoadBalancer Service API 的场景。

为了让全局负载均衡器正常工作,需要配置多个集群,为实现相同应用程序的 Kubernetes 服务使用相同的 VIP。

还可以实施额外的自动化以确保跨集群的此配置同步,例如,发现需要全局化的 LoadBalancer 服务或强制它们具有相同的 LoadBalancer VIP。也可以通过中央自动化协调对 BGP 路由度量标准的支持,例如本地优先级,以便可以为一个集群提供优先于另一个集群的优先级。

请注意,自 4.8 起,OpenShift 目前不支持 MetalLB,但它是未来包含在产品中的路线图上的一个项目,包括对 BGP 模式的支持。

基于任播负载均衡云服务的方法


许多公共云提供商支持将全局负载平衡作为一种服务来实现任播方法,因为租户可以使用单个静态全局 IP 地址,并且可以将其用作多集群多区域服务的前端。

此类服务的示例包括Google Cloud Network Load Balancer、AWS Global Accelerator、 Fastly Anycast和CloudFlare Anycast。这些云服务通常与 CDN 和/或 API 网关功能相结合,但在大多数情况下,也可以用作纯粹的全局任播负载平衡服务,而不必使用其他功能。

这些服务通常使用一组边缘云位置来实现,所有这些位置都宣传全局静态 VIP。发往全球 VIP 的流量从请求者定向到最近的边缘云位置,然后在那里进行负载平衡,并在云提供商的网络内部路由到后端实例。

云提供商用于实施此类服务的确切技术对最终用户是隐藏的,但通常涉及基于 IP/BGP 的任播与弹性 ECMP的内部组合 。云提供商能够利用他们的私有网络额外提供高级负载平衡策略和流量控制,尽管这些功能在一个提供商和另一个提供商之间可能并不总是一致的。
https://cloudnativehub.com/uploads/article/20211017/86eee4bba8f41f39d0814db43a2c72b8.png


每个任播云服务提供的功能各不相同,包括是否允许客户为此类服务带来自己的 IP,或者全局 IP 是面向内部还是面向外部。

概括
https://cloudnativehub.com/uploads/article/20211017/8c657f5301bcd8baa25717de4f250718.png

自动化全局负载均衡器配置


到目前为止,我们已经研究了几种构建全局负载均衡器的方法。但是,让我们想象一个场景,其中我们选择了一种方法,我们需要对部署到多个集群的数百个应用程序进行全局负载平衡。拥有某种形式的自动化来帮助为这些应用程序创建全局负载平衡配置肯定会有所帮助。

可以使用传统的自动化工具来自动化网络配置,但在 Kubernetes 上下文中,主流方法是使用Operator。

全局负载均衡器Operator需要监控多个集群的配置,并根据在这些集群中找到的状态来配置全局负载均衡器。这个领域的一个复杂问题是,当今构建Operator的工具生态系统都专注于仅在单个集群上运行的构建Operator。因此,正在开发的大多数Operator都是集群绑定的。


部分出于这个原因,部分出于可用于实现全局负载均衡器Operator的多种方式,Kubernetes 社区中似乎没有针对此类Operator的官方实现。然而,正如我们在介绍中所说,我们知道有两个举措:k8gb 和global-loadbalancer-operator。


K8GB


K8gb 是一个基于 DNS 的全球负载均衡器运营商。k8gb 有趣的部分是 DNS 服务器是作为CoreDNS pod集群实现的,它是自托管的,并分布在它将服务的 Kubernetes 集群中。这提供了固有的灾难恢复能力以及独立于外部网络功能的能力。
https://cloudnativehub.com/uploads/article/20211017/9669b9c53eff6970eb624acf85b3b129.png


k8gb 的一个限制是它对高级负载平衡策略的支持有限。正在努力通过使用 CoreDNS 插件来减轻这些缺点。请参阅最近添加的geoip 负载平衡策略 ,以获取正在进行的一些工作的示例。


全局负载均衡器Operator


global-loadbalancer-operator 是一个设计用于在控制集群中运行并配置为监视多个受控集群的Operator,它将为其构建全局负载均衡器配置。

可以用来配置external-dnsOperator支持的任何DNS服务器 ,实现基本的基于DNS的全局负载均衡。

它旨在解决基于 DNS 和基于云任播的全局负载平衡。在公共云中运行时,还可以使用高级配置选项。

截至本文发布之日,AWS Route53、Azure 流量管理器和即将推出的 Google 全球 IP 作为提供者提供支持,这些提供商具有更高级的功能,例如不同的负载平衡策略和运行状况检查。

控制集群的使用和仅在 OpenShift 中支持部署是 global-loadbalancer-operator 的两个限制。

结论

在本文中,我们研究了在 Kubernetes 集群前构建全局负载均衡器的几种方法。我们看到有几种适用于不同场景的选项,但从自动化的角度来看,我们还处于早期阶段。可以说,应用程序团队自助服务全局负载均衡的能力是阻碍跨多个集群部署应用程序以实现主动/主动架构的障碍之一。

我们希望这篇文章能够重振社区的兴趣,并推动对 Kubernetes 中此类流量管理的更广泛接受的解决方案的研究。


参考链接:Global Load Balancer Approaches

1 个评论

好文,不错,推荐

要回复文章请先登录注册

咨询在线客服

1156141327

服务热线

13720071711

咨询时间 9:00 - 18:00

扫一扫联系我们

扫一扫联系我们