CN115086330A - 跨集群负载均衡*** - Google Patents
跨集群负载均衡*** Download PDFInfo
- Publication number
- CN115086330A CN115086330A CN202210674605.3A CN202210674605A CN115086330A CN 115086330 A CN115086330 A CN 115086330A CN 202210674605 A CN202210674605 A CN 202210674605A CN 115086330 A CN115086330 A CN 115086330A
- Authority
- CN
- China
- Prior art keywords
- routing
- configuration
- ingress
- service
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012423 maintenance Methods 0.000 claims abstract description 13
- 230000009471 action Effects 0.000 claims abstract description 6
- 238000012544 monitoring process Methods 0.000 claims description 9
- 230000008859 change Effects 0.000 claims description 8
- 230000002159 abnormal effect Effects 0.000 claims description 7
- 239000000126 substance Substances 0.000 claims description 3
- 238000000034 method Methods 0.000 description 20
- 230000008569 process Effects 0.000 description 16
- 238000007726 management method Methods 0.000 description 12
- 239000008186 active pharmaceutical agent Substances 0.000 description 10
- 238000010586 diagram Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 235000014510 cooky Nutrition 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/14—Routing performance; Theoretical aspects
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请实施例提供了一种跨集群负载均衡***，涉及云原生技术领域。该***包括入口报告控制器用于负责与自定义资源定义CRD一同获取业务集群上的Ingress配置信息，并根据自定义资源CustomResource的配置，向软负载后台上报Ingress配置信息；软负载后台用于同步各业务集群的Ingress配置信息，并对相同域名的Ingress配置信息进行归并管理，以及提供默认的路由策略和支持软负载前台修改具体的业务路由策略、支持路由执行单元获取对应的路由配置策略；软负载前台用于向软负载运维人员提供配置页面，以使其进行具体的软负载策略调整；路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作。
Description
技术领域
本申请涉及云原生技术领域，具体而言，本申请涉及一种跨集群负载均衡***。
背景技术
云原生环境下单集群负载均衡的实现方式，包括：(1)使用Ingress提供负载均衡能力，比如通过部署Ingress控制器(Ingress Controller)，完成集群内的同一服务对应的Pod的负载均衡功能。(2)使用外部LoadBalancer设备与NodePort方式实现，比如，在NodePort方式下，可通过K8S集群的节点地址和指定的端口对外提供服务的访问，通常需要在集群外部部署负载均衡设备完成不同节点间的负载均衡。
然而，当应用跨K8S集群部署时，K8S并未提供负载均衡能力来控制不同集群间的负载均衡能力，而且通过硬件负载均衡来配置集群间的负载均衡策略，存在无法感知下级端点变动的问题，且存在所有配置需要人工管理的问题。
发明内容
本申请实施例提供了一种跨集群负载均衡***，可以解决跨集群负载均衡的问题。技术方案如下：
根据本申请实施例的一个方面，提供了一种跨集群负载均衡***，该***包括入口报告控制器Ingress Reporter Controller、软负载后台、软负载前台和路由执行单元；其中，
Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取业务集群上的Ingress配置信息，并根据自定义资源Custom Resource的配置，向软负载后台上报Ingress配置信息；
软负载后台用于同步各业务集群的Ingress配置信息，并对相同域名的Ingress配置信息进行归并管理，以及提供默认的路由策略和支持软负载前台修改具体的业务路由策略、支持路由执行单元获取对应的路由配置策略；
软负载前台用于向软负载运维人员提供配置页面，以使其进行具体的软负载策略调整；
路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作。
在一种可能的实现方式中，Ingress Reporter Controller通过Kubernetes的API-Server提供的API查询和监听业务集群上的目标对象。
在一种可能的实现方式中，Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取业务集群上的Ingress配置信息，包括：
通过CRD将入口报告Ingress Reporter注册到业务集群；
Ingress Reporter Controller被部署到业务集群后、且Ingress Reporter的配置信息被发送到业务集群后，Ingress Reporter Controller开始监听业务集群中相应业务的Ingress配置的新增信息和变更信息。
在一种可能的实现方式中，软负载后台对相同域名的Ingress配置信息进行归并管理，包括：
软负载后台接收各业务集群上部署的Ingress Reporter Controller上报的Ingress配置信息后，根据域名、端口和路径对Ingress配置信息进行归并管理，或者，根据业务的标识信息对Ingress配置信息进行归并管理。
在一种可能的实现方式中，软负载后台还用于支撑软负载前台进行业务配置的增加、删除、修改或查看中的至少一项；
业务配置包括业务应用的配置和业务平台的配置，其中，业务应用的配置包括以下至少一项：应用标签配置，应用后端访问信息列表的配置，应用的路由策略配置，应用引流策略配置，应用归属分组配置；
业务平台的配置包括以下至少一项：登录鉴权配置，角色权限控制配置，应用批量切换配置，应用分组设置及路由执行单元的归属分组配置。
在一种可能的实现方式中，路由执行单元获取具体的负载策略配置，包括：
根据路由分组与应用分组之间的对应关系，确定路由执行单元所在的路由分组对应的应用分组，并获取该应用分组中的业务应用的路由配置策略；
其中，每个应用分组包括一个或多个业务应用，每个路由分组包括一个或多个路由执行单元，各个应用分组分别包括不同的业务应用，各个路由分组分别包括不同的路由执行单元。
在一种可能的实现方式中，路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作，包括：
通过动态化配置具体的路由策略，来实现每次在执行路由策略时，查询具体的路由策略，并根据查询结果确定待访问的路由地址。
在一种可能的实现方式中，动态化配置具体的路由策略，包括：
路由执行单元以第一预定时间间隔周期性获取路由策略的配置信息，并根据配置信息确定需要监听新的域名还是原域名的配置信息发生了修改，其中，若确定需要监听新的域名，则完成新的域名的监听，若确定原域名的配置信息发生了修改，则将原来的配置信息更新为最新的配置信息；
路由执行单元以第二预定时间间隔周期性针对获取的配置信息，对后端的地址信息进行监控检查，并对异常地址进行异常标记和对恢复正常的地址信息进行正常标记。
在一种可能的实现方式中，根据查询结果确定待访问的路由地址，包括：
路由执行单元根据查询结果监听对应的地址信息或域名信息；
路由执行单元获取请求上下文信息并根据查询到的路由策略，匹配可访问的路由地址，若未匹配到对应的路由地址，则查询默认的负载均衡策略，并计算需要使用的路由地址，以重定向至该需要使用的路由地址。
在一种可能的实现方式中，软负载后台、软负载前台及路由执行单元均支持容器化部署，且能够通过deployment的方式进行部署。
在一种可能的实现方式中，***具有对接外部其他***的接口，***通过接口与外部其他***进行目标信息的自动同步。
本申请实施例提供的技术方案带来的有益效果是：可以在应用多集群部署的场景下，实现统一的负载均衡策略管控，从而可以解决跨集群的负载均衡配置，不仅支持云原生的方式获取应用跨集群部署的信息、自动生成配置条目，还可以支持业务服务的逻辑分组、支持以软负载方式替换原有的硬件负载均衡调度的能力。此外，本申请的***通过提供的Ingress Reporter Controller简化了运维人员的负载均衡配置项的填写，可自动同步下级业务集群的Ingress信息，通过分组能力，可实现跨集群负载均衡的分集群承载能力。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的一种跨集群负载均衡***的结构示意图；
图2为本申请实施例提供的云原生环境下应用跨集群负载均衡***的示意图；
图3为本申请实施例提供的自定义Ingress Reporter Controller的结构示意图；
图4为本申请实施例提供的一种对接外部***的跨集群负载均衡***的示意图。
具体实施方式
下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”指示实现为“A”，或者实现为“A”，或者实现为“A和B”。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
先对本申请涉及的几个名词进行介绍和解释：
Kubernetes：简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署，规划，更新，维护的一种机制，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
Pod：一种增强型容器。Pod是Kubernetes集群最基本的部署调度单元，也就是，微服务应用运行的最小单元，每个Pod包括多个容器，可以把它看作是一种容器的扩展或者增强型的容器。Pod里面包括一个主容器和数个辅助容器，它们共同完成一个特定的功能。把多个进程(容器也是一种隔离的进程)打包在一个Name Space里的时候，就构成了一个Pod。Pod里面不同进程的应用包装仍然是独立的(每个容器都会有自己的镜像)。
Ingress：是一个k8s的资源类型，Ingress用于实现用域名的方式访问k8s内部应用。实际上是从kuberenets集群外部访问集群的一个入口，即Ingress为Kubernetes集群中的服务提供了入口，可以提供负载均衡、SSL终止和基于名称的虚拟主机，在生产环境中常用的Ingress有Treafik、Nginx、HAProxy、Istio等。通常情况下，Ingress部署在所有的Node节点上。
Ingress Controller：Ingress controller可以理解为一个***，通过不断地与kube-apiserver打交道，实时的感知后端service、pod的变化，当得到这些变化信息后，Ingress controller再结合Ingress的配置，更新反向代理负载均衡器，达到服务发现的作用。Ingress Controller并不是k8s自带的组件，实际上ingress-controller只是一个统称，用户可以选择不同的Ingress Controller实现，目前，由k8s维护的IngressController只有***云的GCE与ingress-nginx两个。一般来说，Ingress Controller的形式都是一个pod，里面跑着daemon程序和反向代理程序(典型的有nginx负载均衡器)。daemon负责不断监控集群的变化，根据ingress对象生成配置并应用新配置到反向代理，比如nginx-ingress就是动态生成nginx配置，动态更新upstream，并在需要的时候reload程序应用新配置。
当前K8S原生的负载均衡能力(Ingress)都是针对集群内的POD的负载均衡，外部硬件负载器虽然能解决跨集群的负载均衡配置，但无法自动发现集群内的服务，需要手动配置。当应用(亦称为业务应用)跨K8S集群部署时，一方面要求能够跨集群负载均衡调度流量访问不同集群内的POD，另一方面要求能够自动发现不同集群内应用服务(亦称为业务应用服务或业务服务)。同时对应于负载均衡器的部署，本身要求能够支持弹性及业务逻辑分组。
在这种情况下，本申请提出一种跨集群负载均衡***，来解决跨集群的负载均衡配置，不仅支持云原生的方式获取应用跨集群部署的信息、自动生成配置条目，还可以支持业务服务的逻辑分组、支持以软负载方式替换原有的硬件负载均衡调度的能力。
下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。
图1为本申请实施例提供的跨集群负载均衡***的结构示意图，如图1所示，该***包括：入口报告控制器Ingress Reporter Controller 101、软负载后台102、软负载前台103和路由执行单元104；其中，
Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取业务集群上的Ingress配置信息，并根据自定义资源Custom Resource的配置，向软负载后台上报Ingress配置信息；
软负载后台用于同步各业务集群的Ingress配置信息，并对相同域名的Ingress配置信息进行归并管理，以及提供默认的路由策略和支持软负载前台修改具体的业务路由策略、支持路由执行单元获取对应的路由配置策略；
软负载前台用于向软负载运维人员提供配置页面，以使其进行具体的软负载策略调整；
路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作。
具体地，Ingress Reporter Controller部署在业务K8S集群上，软负载后***立部署，软负载前台也独立部署，软负载前台也可以称作配置前台，软负载前台还支持设置整体负载均衡策略，支持针对特例进行独立的负载策略设置以完成具体的引流操作。路由执行单元也是独立部署的，其支持分组部署，按组获取不同的负载策略集合。
CRD(Custom Resource Definition，自定义资源定义)是kubernetes极力推荐的资源扩展方式。通过CRD技术，本申请提供的***可将自定义资源(Ingress Reporter)注册到kubernetes***，并像使用原生资源(如Pod、StatefulSet)一样对自定义资源进行创建、查看、修改、删除等操作。另外，通过CRD机制，可以完成Ingress Reporter配置信息(即报告的目标地址，如软负载后台的消息队列地址及对应的topic)的获取和生效。
本申请提供了一种云原生场景下跨集群负载均衡的***，可以在应用多集群部署的场景下，实现统一的负载均衡策略管控，从而可以解决跨集群的负载均衡配置，不仅支持云原生的方式获取应用跨集群部署的信息、自动生成配置条目，还可以支持业务服务的逻辑分组、支持以软负载方式替换原有的硬件负载均衡调度的能力。此外，本申请的***通过提供的Ingress Reporter Controller简化了运维人员的负载均衡配置项的填写，可自动同步下级业务集群的Ingress信息，通过分组能力，可实现跨集群负载均衡的分集群承载能力。
下面对本申请实施例的技术方案进行详细说明：
本申请实施例的跨集群负载均衡***是云原生环境下的应用跨集群负载均衡***，其主要四部分组成，如图2所示。
Ingress Reporter Controller(入口报告控制器)：部署在业务K8S集群上，负责和CRD(Custom Resource Definition，自定义资源定义)一同，获取业务集群(如图2中的业务K8S集群)上的Ingress配置信息，比如可以通过API Server获取业务集群上的Ingress配置信息，并根据自定义资源custom resource的配置，将获取到的Ingress配置信息上报到对应的软负载后台，如图2中的③上报Ingress信息，图2中的③是指Ingress ReporterController向软负载后台上报Ingress配置信息。
软负载后台：独立部署，用于同步各业务集群的Ingress配置信息，同时对相同域名的Ingress信息进行归并管理(即图2中的④汇总Ingress信息)，提供默认的路由策略，即向路由执行单元提供默认的路由策略，如图2中的⑥动态获取软路由信息，其中，图2中的⑥是指路由执行单元从软负载后台动态获取软路由信息。同时，软负载后台还支持配置前台修改具体业务路由策略，以及路由执行单元获取对应的路由配置策略。
软负载前台：独立部署，用于提供配置页面给软负载运维人员进行具体软负载策略的调整，如图2中的⑤调整软路由策略，即软负载运维人员可能通过软负载前台调整软路由策略。其中，软负载前台还支持设置整体负载均衡策略，支持针对特例进行独立的负载策略设置以完成具体的引流操作。
路由执行单元：独立部署，用于获取具体的负载策略配置，完成具体的负载均衡动作，比如路由执行单元可以从软负载后台动态获取软路由信息(或路由策略)，如图2中的⑥动态获取软路由信息，来实现具体的负载策略配置的获取。换言之，路由执行单元可以根据获取到的具体的路由策略，来得到具体的负载策略配置，进而进行负载均衡并完成完成具体的负载均衡动作。
其中，路由执行单元还支持分组部署和按组获取不同的负载策略集合，如图2中的分组1和分组2，分组1中包括两个不同的路由执行单元(比如路由执行单元A和路由执行单元B)，分组2中包括另外两个不同的路由执行单元(比如路由执行单元C和路由执行单元D)，分组1中的路由执行单元和分组2中的路由执行单元可以按组获取不同的负载策略集合。路由执行单元获取到负载策略后，可以根据获取到的负载策略进行策略路由，即图2中的⑧根据策略路由。
下面介绍具体工作的原理：
1、业务人员创建CRD和CRD Controller(如图2中的①创建CRD和Controller)，CRD(Custom Resource Definition，自定义资源定义)是kubernetes极力推荐的资源扩展方式。通过CRD技术，本申请的***可将自定义资源(如Ingress Reporter)注册到kubernetes***中，即通过CRD将Ingress Reporter注册到业务集群(如kubernetes)中，并像使用原生资源(如Pod、StatefulSet)一样对自定义资源进行创建、查看、修改、删除等操作。通过CRD机制，可以完成Ingress Reporter配置信息(即报告的目标地址，如：软负载后台的消息队列地址及对应的topic)的获取，生效。
其中，CRD是在Kubernetes 1.7之后增加的二次开发能力来扩展Kubernetes API，通过CRD可以向Kubernetes API中增加新资源类型，而不需要修改Kubernetes源码或创建自定义的API server，该功能大大提高了Kubernetes的扩展能力。CRD是一种无需编码就可以扩展原生kubenetes API接口的方式，适合扩展kubernetes的自定义接口和功能。
当创建一个新的自定义资源定义(CRD)时，Kubernetes API Server通过创建一个新的RESTful资源路径进行应答，无论是在命名空间还是在集群范围内，正如在CRD的scope域指定的那样。与现有的内建对象一样，删除一个命名空间将会删除该命名空间内所有的自定义对象。CRD本身并不区分命名空间，对所有的命名空间可用。
在实际应用中，可以通过如下两种方式将Custom resources添加到集群：(1)Custom Resource Definitions(CRDs)：更易用、不需要编码；(2)API Aggregation：需要编码，允许通过聚合层的方式提供更加定制化的实现。
2、自定义Controller(如Ingress Reporter Controller)的实现。如图3所示，自定义Controller实际是通过Kubernetes的Api-server提供的API来查询和监听业务集群(如K8S)上的Service、Ingress这些对象的。其中，可以通过k8s.io/client-go/informers来简化监听功能的实现。相当于，Ingress Reporter Controller通过Kubernetes的API-Server提供的API查询和监听业务集群上的目标对象，其中，目标对象包括但不限于Service、Ingress等。
3、通过上面1、2步的实现，由业务人员将Ingress Reporter Controller部署到业务集群后(如图2中的②业务人员配置Ingress)，然后通过命令行将Ingress Reporter的配置信息下发到业务集群后，Ingress Reporter Controller就开始监听业务集群的Ingress配置的新增信息和变更信息，在业务***完成了Ingress的配置之后，Ingress ReporterController将该配置的配置信息(包括Ingress配置的新增信息和变更信息)上报到软负载后台。
换言之，根据上面1、2步的实现可以看出，Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取所述业务集群上的Ingress配置信息，包括：通过CRD将入口报告Ingress Reporter注册到所述业务集群；接着，Ingress Reporter Controller被部署到所述业务集群后、且Ingress Reporter的配置信息被发送到业务集群后，IngressReporter Controller开始监听业务集群中相应业务的Ingress配置变更信息。
4、软负载后台收到各业务集群上部署的Ingress Reporter Controller上报的Ingress配置信息之后，汇总相同服务的不同路由地址。这里有两种汇总方式，一种方式是根据域名、端口和路径，归并相同服务。另一种方式是根据业务标识(如应用编码)，来进行关联或归并。这里要求对接其他***(如CMDB)，来获取应用编码和对应Ingress的关联。相当于，软负载后台对相同域名的Ingress配置信息进行归并管理，包括：软负载后台接收各业务集群上部署的Ingress Reporter Controller上报的Ingress配置信息后，根据域名、端口和路径对Ingress配置信息进行归并管理，或者，根据业务的标识信息(如应用编码)对Ingress配置信息进行归并管理，例如，如果上报的两个Ingress配置信息都含有相同的业务标识(比如含有相同的应用编码)，则对该两个Ingress配置信息进行归并管理。
5、软负载后台支撑软负载前台进行业务配置的增、删、改、查。具体的业务配置包括业务应用的配置和业务平台的配置，业务应用的配置包括但不限于应用标签、应用后端访问信息列表(如Ingress地址+port+路径的形式)、应用的路由策略(如后端访问的权重、负载均衡策略等)、独立的访问路由策略(比如基于请求头、参数、cookie等进行特定的路由选择)、应用归属分组信息等配置；业务平台的配置包括但不限于登录鉴权、角色权限控制、应用批量切换、应用分组设置、路由执行单元的归属分组等配置。另外，软负载后台还可以提供API供外部***(例如CMDB)调用。
也就是说，软负载后台还用于支撑软负载前台进行业务配置的增加、删除、修改或查看中的至少一项；其中，业务配置包括业务应用的配置和业务平台的配置，其中，业务应用的配置包括以下至少一项：应用标签配置，应用后端访问信息列表的配置，应用的路由策略配置，应用引流策略配置，应用归属分组配置；业务平台的配置包括以下至少一项：登录鉴权配置，角色权限控制配置，应用批量切换配置，应用分组设置及路由执行单元的归属分组配置。
6、软负载前台提供Web访问入口，可支持用户登录鉴权、角色权限控制、支持修改应用标签、设置应用分组、应用批量切换、路由执行单元的归属分组、通用的应用的路由策略配置、独立的应用引流策略配置等。如图2中的⑤调整软路由策略，软负载运维人员可能通过软负载前台调整软路由策略。
其中，应用分组是指对多个业务应用(比如2个、3个或更多个业务应用)进行分组管理。假如同时存在3个业务应用，分别为业务应用A、业务应用B及业务应用C，则：可以根据需求将业务应用A和业务应用B分为一组(比如记作应用分组1)、并将业务应用C分为另一组(比如记作应用分组2)，也可以根据需求将业务应用A和业务应用C分为一组(比如记作应用分组1)、并将业务应用B分为另一组(比如记作应用分组2)，当然还可以根据需求对业务应用A、业务应用B及业务应用C进行其他可能情况的分组，本申请实施例不对其做限制。
路由执行单元的归属分组是指对路由执行单元进行分组管理或分组部署。假如同时存在3个路由执行单元，分别为路由执行单元A、路由执行单元B及路由执行单元C，则：可以根据需求将路由执行单元A和路由执行单元C分为一组(比如记作路由分组1)、并将路由执行单元B分为另一组(比如记作路由分组2)，也可以根据需求将路由执行单元B和路由执行单元用C分为一组(比如记作路由分组1)、并将路由执行单元A分为另一组(比如记作路由分组2)，当然还可以根据需求对路由执行单元A、路由执行单元B及路由执行单元C进行其他可能情况的分组，本申请实施例不对其做限制。
7、路由执行单元具体完成的功能为用户接入后的具体路由策略执行，其可通过动态化配置实现，比如每次在执行路由策略时，查询具体的路由策略，并通过匹配情况(即路由策略的查询情况或查询结果)，确定具体的路由策略的执行。具体可以分为两个过程，一个是配置的动态生效过程，另一个是用户访问的路由信息确定过程。其中，配置的动态生效过程可以理解为是动态化配置具体的路由策略的过程，用户访问的路由信息确定过程可以理解为是路由策略的查询结果确定待访问的路由地址的过程。换句话说，路由执行单元具体完成的功能，包括：通过动态化配置具体的路由策略，来实现每次在执行路由策略时，查询具体的路由策略，并根据查询结果确定待访问的路由地址。
考虑到不仅可以对业务应用(亦可记作应用或业务)进行分组管理，即支持对业务应用进行分组管理，比如上述的将多个业务应用(业务应用A、业务应用B及业务应用C)分为不同的应用分组(亦可记作业务分组)，还可以对路由执行单元进行分组管理，比如上述的将多个路由执行单元(路由执行单元A、路由执行单元B及路由执行单元C)分为不同的路由分组，又比如图2中的将4个路由执行单元分为不同的路由分组(即分组1和分组2)；于是，路由执行单元每次在获取或查询具体的路由配置策略时，可以执行如下处理：
根据路由分组与应用分组之间的对应关系(或映射关系)，确定路由执行单元所在的路由分组对应的应用分组，并获取或查询该应用分组中的业务应用的路由配置策略，其中，每个应用分组包括一个或多个业务应用，每个路由分组包括一个或多个路由执行单元，各个应用分组分别包括不同的业务应用，各个路由分组分别包括不同的路由执行单元。
通过对路由执行单元进行路由分组和对业务应用进行业务分组这种处理，可以使得路由执行单元支持根据业务分组进行路由配置策略的获取，确保路由执行单元能够根据路由分组和业务分组之间的对应关系，查询对应的业务分组，并只会获取该对应的业务分组中的业务应用的路由策略配置，从而做到不同路由分组的路由执行单元获取的路由配置策略不同，进而能够进行隔离处理。
在一个示例中，假如存在路由分组1(包含路由执行单元A和路由执行单元B)和路由分组2(包含路由执行单元C和路由执行单元D)，同时存在应用分组1(包含业务应用A)和应用分组2(包含业务应用B和业务应用C)，且路由分组1与应用分组1之间是一一对应关系的，路由分组2与应用分组2之间是一一对应关系的，则：
路由执行单元A每次在获取或查询路由配置策略时，先根据路由执行单元A所在的路由分组1与应用分组之间的对应关系关联到应用分组1，然后，路由执行单元A获取或查询该应用分组1中的业务应用A的路由配置策略。同样地，路由执行单元C每次在获取或查询路由配置策略时，先根据路由执行单元C所在的路由分组2与应用分组之间的对应关系关联到应用分组2，然后，路由执行单元C获取或查询该应用分组2中的业务应用B和业务应用C的路由配置策略。
在一种可能的实施方式中，配置的动态生效过程可以包括如下几个步骤：
步骤1，路由执行单元获取路由策略的配置信息；该获取路由策略的配置信息的过程，也是根据路由分组与应用分组之间的对应关系(或映射关系)，确定路由执行单元所在的路由分组对应的应用分组，并获取或查询该应用分组中的业务应用的路由配置策略，具体内容请见前文，在此不再赘述。
步骤2，根据配置信息判断是需要监听新的域名还是原域名里的配置信息发生了修改；
步骤3，如果需要监听新的域名，则完成新的域名的监听；
步骤4，确定原域名的配置信息发生了修改，则将原来的配置信息更新为最新的状态(如最新的配置信息)；
步骤5，定时执行上述步骤1至步骤4；
步骤6，针对获取的配置信息，对后端的地址进行监控检查；
步骤7，对异常地址进行标记(如异常标记)和对恢复正常的地址信息进行标记(如正常标记)。
步骤8，定时执行上述步骤6至步骤7。
需要说明的是，上述步骤1至步骤8介绍的配置的动态生效过程，也可以表述为动态化配置具体的路由策略的过程，该过程可以为：路由执行单元以第一预定时间间隔周期性获取路由策略的配置信息，并根据配置信息确定需要监听新的域名还是原域名的配置信息发生了修改，其中，若确定需要监听新的域名，则完成新的域名的监听，若确定原域名的配置信息发生了修改，则将原来的配置信息更新为最新的配置信息；路由执行单元以第二预定时间间隔周期性针对获取的配置信息，对后端的地址信息进行监控检查，并对异常地址进行异常标记和对恢复正常的地址信息进行正常标记。
用户访问的路由信息确定过程，可以包括如下几个步骤：
步骤1，用户请求到具体的路由执行单元；
步骤2，路由执行单元监听对应的地址信息或域名信息；
步骤3，路由执行单元获取用户请求上下文信息，包括域名+端口+地址、请求头、cookie、URL中的参数、提交的数据等等；
步骤4，根据配置的负载策略(特定场景引流)，匹配用户可访问的后端地址(即路由地址)；
步骤5，如果未匹配到对应的路由地址，则查询默认的负载均衡策略，计算需要使用的后端地址(即路由地址)；
步骤6，将用户重定向到计算出的需要使用的后端地址。
需要说明的是，上述步骤1至步骤6介绍的用户访问的路由信息确定过程，也可以表述为根据路由策略的查询结果确定待访问的路由地址的过程。其中，根据路由策略的查询结果确定待访问的路由地址的过程可以为：路由执行单元根据所述查询结果确定对应的地址信息或域名信息；接着，路由执行单元获取请求上下文信息并根据查询到的路由策略，匹配可访问的路由地址，若未匹配到对应的路由地址，则查询默认的负载均衡策略，并计算需要使用的路由地址，以重定向至该需要使用的路由地址。
当外部***存在业务***管理相同应用在不同集群的Ingress分组信息和应用分组信息时，本申请的跨集群负载均衡***支持对接外部***，如CMDB(ConfigurationManagement Database，配置管理数据库)，如图4所示。其中，对接外部***的跨集群负载均衡***(即图4所示的***)与原来的跨集群负载均衡***(即图2所示的***)的差别在于：部分信息(如应用标签和应用分组信息)可自动同步，而不需要软负载运维人员自行手动通过页面维护。即，本申请的跨集群负载均衡***具有对接外部其他***的接口，本申请的跨集群负载均衡***通过该接口与外部其他***进行目标信息的自动同步，其中，目标信息包括但不限于应用标签、应用分组信息等等。
需要说明的是，本本申请的跨集群负载均衡***中的软负载前台、软负载后台、路由执行单元等是支持容器化部署的，可通过deployment的方式进行部署。即，软负载后台、软负载前台及路由执行单元均支持容器化部署，且能够通过deployment的方式进行部署。
可见，本申请实施例提供了一种云原生场景下跨集群负载均衡的解决方案，可以在应用多集群部署的场景下，实现统一的负载均衡策略管控；通过提供的IngressReporter Controller简化了运维人员的负载均衡配置项的填写，可自动同步下级业务集群的Ingress信息；通过分组能力，可实现跨集群负载均衡的分集群承载的能力；可对接外部***，进一步简化负载均衡配置项的填写；并且，整个跨集群负载均衡***支持云原生部署。
以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。
Claims (11)
1.一种跨集群负载均衡***，其特征在于，包括入口报告控制器Ingress ReporterController、软负载后台、软负载前台和路由执行单元；其中，
所述Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取所述业务集群上的Ingress配置信息，并根据自定义资源Custom Resource的配置，向软负载后台上报所述Ingress配置信息；
所述软负载后台用于同步各业务集群的Ingress配置信息，并对相同域名的Ingress配置信息进行归并管理，以及提供默认的路由策略和支持软负载前台修改具体的业务路由策略、支持路由执行单元获取对应的路由配置策略；
所述软负载前台用于向软负载运维人员提供配置页面，以使其进行具体的软负载策略调整；
所述路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作。
2.根据权利要求1所述的***，其特征在于，所述Ingress Reporter Controller通过Kubernetes的API-Server提供的API查询和监听所述业务集群上的目标对象。
3.根据权利要求1或2所述的***，其特征在于，所述Ingress Reporter Controller用于负责与自定义资源定义CRD一同获取所述业务集群上的Ingress配置信息，包括：
通过所述CRD将入口报告Ingress Reporter注册到所述业务集群；
所述Ingress Reporter Controller被部署到所述业务集群后、且所述IngressReporter的配置信息被发送到所述业务集群后，所述Ingress Reporter Controller开始监听所述业务集群中相应业务的Ingress配置的新增信息和变更信息。
4.根据权利要求1-3任一项所述的***，其特征在于，所述软负载后台对相同域名的Ingress配置信息进行归并管理，包括：
所述软负载后台接收各业务集群上部署的Ingress Reporter Controller上报的Ingress配置信息后，根据域名、端口和路径对所述Ingress配置信息进行归并管理，或者，根据业务的标识信息对所述Ingress配置信息进行归并管理。
5.根据权利要求1-3任一项所述的***，其特征在于，所述软负载后台还用于支撑所述软负载前台进行业务配置的增加、删除、修改或查看中的至少一项；
所述业务配置包括业务应用的配置和业务平台的配置，其中，所述业务应用的配置包括以下至少一项：应用标签配置，应用后端访问信息列表的配置，应用的路由策略配置，应用引流策略配置，应用归属分组配置；
所述业务平台的配置包括以下至少一项：登录鉴权配置，角色权限控制配置，应用批量切换配置，应用分组设置及路由执行单元的归属分组配置。
6.根据权利要求1或5所述的***，其特征在于，所述路由执行单元获取具体的负载策略配置，包括：
根据路由分组与应用分组之间的对应关系，确定路由执行单元所在的路由分组对应的应用分组，并获取该应用分组中的业务应用的路由配置策略；
其中，每个应用分组包括一个或多个业务应用，每个路由分组包括一个或多个路由执行单元，各个应用分组分别包括不同的业务应用，各个路由分组分别包括不同的路由执行单元。
7.根据权利要求1或6所述的***，其特征在于，所述路由执行单元用于获取具体的负载策略配置、完成具体的负载均衡动作，包括：
通过动态化配置具体的路由策略，来实现每次在执行路由策略时，查询具体的路由策略，并根据查询结果确定待访问的路由地址。
8.根据权利要求7所述的***，其特征在于，所述动态化配置具体的路由策略，包括：
所述路由执行单元以第一预定时间间隔周期性获取路由策略的配置信息，并根据所述配置信息确定需要监听新的域名还是原域名的配置信息发生了修改，其中，若确定需要监听新的域名，则完成新的域名的监听，若确定原域名的配置信息发生了修改，则将原来的配置信息更新为最新的配置信息；
所述路由执行单元以第二预定时间间隔周期性针对获取的所述配置信息，对后端的地址信息进行监控检查，并对异常地址进行异常标记和对恢复正常的地址信息进行正常标记。
9.根据权利要求7所述的***，其特征在于，所述根据路由策略的查询结果确定待访问的路由地址，包括：
所述路由执行单元根据所述查询结果监听对应的地址信息或域名信息；
所述路由执行单元获取请求上下文信息并根据所述查询到的路由策略，匹配可访问的路由地址，若未匹配到对应的路由地址，则查询默认的负载均衡策略，并计算需要使用的路由地址，以重定向至该需要使用的路由地址。
10.根据权利要求1-9任一项所述的***，其特征在于，所述软负载后台、所述软负载前台及所述路由执行单元均支持容器化部署，且能够通过deployment的方式进行部署。
11.根据权利要求1-9任一项所述的***，其特征在于，所述***具有对接外部其他***的接口，所述***通过所述接口与所述外部其他***进行目标信息的自动同步。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210674605.3A CN115086330B (zh) | 2022-06-14 | 2022-06-14 | 跨集群负载均衡*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210674605.3A CN115086330B (zh) | 2022-06-14 | 2022-06-14 | 跨集群负载均衡*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115086330A true CN115086330A (zh) | 2022-09-20 |
| CN115086330B CN115086330B (zh) | 2024-03-01 |
Family
ID=83252028
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210674605.3A Active CN115086330B (zh) | 2022-06-14 | 2022-06-14 | 跨集群负载均衡*** |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115086330B (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115242877A (zh) * | 2022-09-21 | 2022-10-25 | 之江实验室 | 面向多K8s集群的Spark协同计算、作业方法及装置 |
| CN115883258A (zh) * | 2023-02-15 | 2023-03-31 | 北京微步在线科技有限公司 | Ip信息处理方法、装置、电子设备和存储介质 |
| US11954525B1 (en) | 2022-09-21 | 2024-04-09 | Zhejiang Lab | Method and apparatus of executing collaborative job for spark faced to multiple K8s clusters |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111343037A (zh) * | 2019-08-19 | 2020-06-26 | 海通证券股份有限公司 | 云平台负载按应用的流量监控方法、装置、计算机设备 |
| CN112995273A (zh) * | 2021-01-28 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 网络打通方案生成方法、装置、计算机设备和存储介质 |
| CN113094182A (zh) * | 2021-05-18 | 2021-07-09 | 联想(北京)有限公司 | 一种服务的负载均衡处理方法、装置及云端服务器 |
| WO2021205212A1 (en) * | 2020-04-08 | 2021-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Traffic controller for cloud native deployment |
| CN113572831A (zh) * | 2021-07-21 | 2021-10-29 | 重庆星环人工智能科技研究院有限公司 | Kubernetes集群间的通信方法、计算机设备及介质 |
| US20220038311A1 (en) * | 2020-07-30 | 2022-02-03 | Vmware, Inc. | Hierarchical networking for nested container clusters |
-
2022
- 2022-06-14 CN CN202210674605.3A patent/CN115086330B/zh active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111343037A (zh) * | 2019-08-19 | 2020-06-26 | 海通证券股份有限公司 | 云平台负载按应用的流量监控方法、装置、计算机设备 |
| WO2021205212A1 (en) * | 2020-04-08 | 2021-10-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Traffic controller for cloud native deployment |
| US20220038311A1 (en) * | 2020-07-30 | 2022-02-03 | Vmware, Inc. | Hierarchical networking for nested container clusters |
| CN112995273A (zh) * | 2021-01-28 | 2021-06-18 | 腾讯科技（深圳）有限公司 | 网络打通方案生成方法、装置、计算机设备和存储介质 |
| CN113094182A (zh) * | 2021-05-18 | 2021-07-09 | 联想(北京)有限公司 | 一种服务的负载均衡处理方法、装置及云端服务器 |
| CN113572831A (zh) * | 2021-07-21 | 2021-10-29 | 重庆星环人工智能科技研究院有限公司 | Kubernetes集群间的通信方法、计算机设备及介质 |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115242877A (zh) * | 2022-09-21 | 2022-10-25 | 之江实验室 | 面向多K8s集群的Spark协同计算、作业方法及装置 |
| CN115242877B (zh) * | 2022-09-21 | 2023-01-24 | 之江实验室 | 面向多K8s集群的Spark协同计算、作业方法及装置 |
| US11954525B1 (en) | 2022-09-21 | 2024-04-09 | Zhejiang Lab | Method and apparatus of executing collaborative job for spark faced to multiple K8s clusters |
| CN115883258A (zh) * | 2023-02-15 | 2023-03-31 | 北京微步在线科技有限公司 | Ip信息处理方法、装置、电子设备和存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115086330B (zh) | 2024-03-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102604082B1 (ko) | 멀티 클러스터 인그레스 | |
| CN109032755B (zh) | 一种容器服务托管***及提供容器服务的方法 | |
| CN107070972B (zh) | 一种分布式文件处理方法及装置 | |
| CN115086330B (zh) | 跨集群负载均衡*** | |
| US8200789B2 (en) | Method, system and program product for automated topology formation in dynamic distributed environments | |
| CN111464592A (zh) | 基于微服务的负载均衡方法、装置、设备及存储介质 | |
| US20240176672A1 (en) | Systems and methods providing serverless dns integration | |
| CN113778623B (zh) | 资源处理方法和装置、电子设备及存储介质 | |
| CN112698992B (zh) | 一种云集群的容灾管理方法以及相关装置 | |
| CN114070822B (zh) | 一种Kubernetes Overlay IP地址管理方法 | |
| CN110391940B (zh) | 服务地址的响应方法、装置、***、设备和存储介质 | |
| CN113014611B (zh) | 一种负载均衡方法及相关设备 | |
| CN111966482B (zh) | 边缘计算*** | |
| CN109525590B (zh) | 数据包的传输方法及装置 | |
| CN113079098B (zh) | 路由更新的方法、装置、设备和计算机可读介质 | |
| CN101534255A (zh) | 一种实现特定请求定向处理的方法及装置 | |
| CN112655185B (zh) | 软件定义网络中的服务分配的设备、方法和存储介质 | |
| US20240176762A1 (en) | Geographically dispersed hybrid cloud cluster | |
| CN114615268A (zh) | 基于Kubernetes集群的服务网络、监控节点、容器节点及设备 | |
| CN113709054A (zh) | 一种基于keepalived的LVS***部署调节方法、装置及*** | |
| CN112910796A (zh) | 流量管理方法、装置、设备、存储介质以及程序产品 | |
| US20200293386A1 (en) | Messaging abstraction layer for integration with message oriented middleware platforms | |
| CN115378993B (zh) | 支持命名空间感知的服务注册与发现的方法和*** | |
| CN111404980B (zh) | 一种数据存储方法及一种对象存储*** | |
| CN108965494A (zh) | 数据***中数据传输方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |