CN113783922A - 负载均衡的方法、系统和装置 - Google Patents
负载均衡的方法、系统和装置 Download PDFInfo
- Publication number
- CN113783922A CN113783922A CN202110323823.8A CN202110323823A CN113783922A CN 113783922 A CN113783922 A CN 113783922A CN 202110323823 A CN202110323823 A CN 202110323823A CN 113783922 A CN113783922 A CN 113783922A
- Authority
- CN
- China
- Prior art keywords
- pod
- load balancing
- service
- cluster
- target
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 66
- 230000004044 response Effects 0.000 claims abstract description 47
- 230000008569 process Effects 0.000 claims description 26
- 238000001514 detection method Methods 0.000 claims description 20
- 230000006870 function Effects 0.000 claims description 20
- 238000004590 computer program Methods 0.000 claims description 9
- 230000003993 interaction Effects 0.000 claims description 8
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 238000011161 development Methods 0.000 claims description 2
- 230000000875 corresponding effect Effects 0.000 description 39
- 238000010586 diagram Methods 0.000 description 12
- 238000004891 communication Methods 0.000 description 6
- 239000003795 chemical substances by application Substances 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000007616 round robin method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000002054 transplantation Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
本公开的实施例公开了负载均衡的方法和装置。该方法的一具体实施方式包括：响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service；基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod；将服务请求发送至目标Pod；接收并转发目标Pod响应服务请求生成的响应报文。可以实现不同机房之间的负载均衡和业务互备。
Description
技术领域
本公开的实施例涉及计算机技术领域，具体涉及云技术领域，尤其涉及一种负载均衡的方法、系统和装置。
背景技术
容器是一种轻量级操作系统层面的虚拟机，由于其轻量化、便捷性、高性能等优点，使得容器技术在互联网领域的应用越发广泛。Kubernetes作为面向应用的容器集群部署和管理系统，具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。通过Kubernetes中内置的Kube-proxy来实现四层负载均衡时，业务方的请求数据需要到Kube-proxy中(即用户空间)中，才能确定真正要转发对象(Pod)。在此过程中会导致性能损耗。
相关技术中采用的负载均衡策略通常是基于业务方的域名进行导流。而在实践中，往往需要在多机房之间进行业务互备和高性能的负载均衡。
发明内容
本公开的实施例提出了负载均衡的方法和装置。
第一方面，本公开的实施例提供了一种负载均衡的方法，该方法包括：响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service，Service为功能相同的Pod组成的集合；基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod；将服务请求发送至目标Pod；接收并转发目标Pod响应服务请求生成的响应报文；其中，虚拟网络地址与Pod的对应关系、当前可用的Pod列表以及各个候选Pod的当前负载状态为负载均衡信息，负载均衡信息获取自Kubernetes集群。
在一些实施例中，该方法还包括：接收Kubernetes集群推送的代理进程，代理进程用于指示如下操作：接收预设网络域的虚拟网络地址；对预设网络域的虚拟网络地址对应的各Pod进行可用性检测，得到可用性检测的结果；基于可用性检测的结果，更新当前可用的Pod列表。
第二方面，本公开的实施例提供了一种负载均衡系统，包括负载均衡服务器集群和Kubernetes集群，其中，负载均衡服务器集群为基于BGP构建的服务器集群，被配置成：接收Kubernetes集群的负载均衡信息，并基于负载均衡信息执行上述任一实施例中的负载均衡的方法；Kubernetes集群包括控制器集群、同步集群和Pod集群，控制器集群被配置成：基于业务需求配置Service，Service为预设功能的Pod的集合；通过同步集群与各Service进行信息交互，以调度各Service中的Pod和获取各Pod的运行状态；基于各Service的配置信息和各Pod的运行状态，生成负载均衡信息；以及，将负载均衡信息发送至负载均衡服务器集群。
在一些实施例中，Pod集群中的各Pod的宿主机归属于不同的物理机房，负载均衡服务器集群包括若干负载均衡服务器子集群，每一个物理机房均部署有至少一个负载均衡服务器子集群。
在一些实施例中，控制器集群还被配置成：基于预先构建负载均衡标识与业务需求的对应关系以及Service对应的业务需求，为Service标记负载均衡标识；基于预先构建的负载均衡标识与网络域的对应关系以及Service的负载均衡标识，确定Service的网络域以及Service在该网络域中的虚拟网络地址。
在一些实施例中，控制器集群被配置成：基于业务需求，从Pod集群中确定出响应该业务需求的Pod集合，基于该集合中每个Pod的宿主机的归属地，将该集合划分成若干Pod子集合，将每个Pod子集合确定为一个Service，并基于预先构建的业务需求与网络域的对应关系，确定每个Service的网络域及其在该网络域中的虚拟网络地址。
在一些实施例中，负载均衡服务器集群还被配置成：响应于业务方的服务请求，解析出业务方的域名；基于预先构建的域名与负载均衡服务器子集群的对应关系，将服务请求发送至业务方的域名对应的目标负载均衡服务器子集群，由目标负载均衡服务器子集群执行上述任一实施例中的负载均衡的方法。
在一些实施例中，负载均衡服务器集群中的每个负载均衡服务器均采用DPDK网卡收发报文，报文包括服务请求和目标Pod生成的响应报文。
在一些实施例中，负载均衡服务器集群还被配置成：基于服务请求的源地址和目标Pod的真实网络地址，构建会话控制表；将会话控制表存储至目标负载均衡服务器，目标负载均衡服务器为将服务请求发送至目标Pod的负载均衡服务器；目标服均衡服务器还被配置成将目标Pod生成的响应报文转发至业务方。
第三方面，本公开的实施例提供了一种负载均衡的装置，装置包括：服务请求解析单元，被配置成响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service集群，Service集群中的每个Service为功能相同的Pod组成的集合；候选Pod确定单元，被配置成基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；目标Pod确定单元，被配置成基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod；服务请求转发单元，被配置成将服务请求发送至目标Pod；响应报文转发单元，被配置成接收并转发目标Pod响应服务请求生成的响应报文；其中，虚拟网络地址与Pod的对应关系、当前可用的Pod列表以及各个候选Pod的当前负载状态为负载均衡信息，负载均衡信息获取自Kubernetes集群。
在一些实施例中，该装置还包括：代理进程单元，被配置成接收Kubernetes集群推送的代理进程，代理进程用于执行如下操作：接收预设网络域的虚拟网络地址；对预设网络域的虚拟网络地址对应的各Pod进行可用性检测，得到可用性检测的结果；基于可用性检测的结果，增加或删除预设网络域的虚拟网络地址对应的Pod。
第四方面，本公开的实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，其上存储有一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如任一实施例中的负载均衡的方法。
第五方面，本公开的实施例提供了一种计算机可读介质，其上存储有计算机程序，其中，程序被处理器执行时实现如上述任一实施例中的负载均衡的方法。
本公开的实施例提供的负载均衡的方法和装置，基于业务方的服务请求，从后端Kubernetes集群中确定出响应该服务请求的候选Pod集合，再基于预设的负载均衡策略和各候选Pod的运行状态，确定出目标Pod，并将服务请求转发给目标Pod，由目标Pod响应该服务请求，最后转发目标Pod生成的响应报文。可以基于接收到的Kubernetes集群的负载均衡信息，对部署在不同机房的物理机上的Pod进行负载均衡，可以实现不同机房之间的负载均衡以及业务互备。
本公开的实施例提供的负载均衡系统，采用BGP协议构建的负载均衡服务器集群可以从Kubernetes获取后端业务容器的负载均衡信息，并基于负载均衡信息执行负载均衡策略，只需增加负载均衡服务器集群中服务器的数量，即可提高负载均衡系统的负载均衡能力，提高了负载均衡系统的可扩展性。此外，负载均衡服务器集群可以采用BGP协议，将每个负载均衡服务器中的数据路由至其他负载均衡服务器，从而实现了N+1冗余。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本公开的其它特征、目的和优点将会变得更明显：
图1是本公开的一些实施例可以应用于其中的示例性系统架构图；
图2是根据本公开的负载均衡的方法的一个实施例的流程图；
图3是根据本公开的负载均衡系统的一个实施例的架构图；
图4是根据本公开的负载均衡系统的一个实施例的流程图；
图5是根据本公开的负载均衡的装置的一个实施例的结构示意图；
图6是适于用来实现本公开的实施例的电子设备的结构示意图。
具体实施方式
下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。
需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
图1示出了可以应用本公开的实施例的负载均衡的方法或负载均衡的装置的示例性系统架构100。
如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105、106、107、108。其中，服务器105为负载均衡服务器，服务器106、107、108为业务服务器，业务服务器上部署有容器集群，容器集群通过Kubernetes进行调度管理。网络104用以在终端设备101、102、103和服务器105之间以及服务器105和服务器106、107、108之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等，例如可以将服务请求发送至服务器105，还可以接收服务器105发送的响应报文。其中，响应报文的生成过程为：服务器105按照预设的负载均衡策略将服务请求分发至业务服务器，由业务服务器上部署的容器响应该服务请求，并生成响应报文。之后，由业务服务器将响应报文发送至服务器105。
终端设备101、102、103可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具备通信功能的电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、膝上型便携计算机和台式计算机等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中。其可以实现成例如用来提供分布式服务的多个软件或软件模块，也可以实现成单个软件或软件模块。在此不做具体限定。
服务器105可以是提供负载均衡服务的服务器，例如转发终端设备101、102、103发送的服务请求以及业务服务器发送的响应报文。
需要说明的是，服务器可以是硬件，也可以是软件。当服务器为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器为软件时，可以实现成例如用来提供分布式服务的多个软件或软件模块，也可以实现成单个软件或软件模块。在此不做具体限定。
需要说明的是，本公开的实施例所提供的负载均衡的方法可以由服务器105执行。相应地，负载均衡的装置可以设置于服务器105中。
继续参考图2，示出了根据本公开的负载均衡的方法的一个实施例的流程200。该负载均衡的方法，包括以下步骤：
步骤201，响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址。
本实施例中，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service，Service为功能相同的Pod组成的集合。
通常，Pod是Kubernetes中的基本功能单元，每个pod包括一组在功能和服务方面密切关联的容器以及该组容器共享的卷(volumes)。容器部署于物理机或虚拟机上，用于执行预设的程序。相同功能的Pod组成的集合为Service，Kubernetes以Service的方式在管理层面调度容器和Pod的方式。当需要调用Service中的功能时(例如接收到业务方的服务请求)，Kubernetes会向Service提出调用请求，而非向单个Pod提出调用请求。Kubernetes通过Kube-proxy为每个Service指派一个ClusterIP(集群内网络地址)，该ClusterIP即为Service的虚拟网络地址，每一个Service均对应一个固定的虚拟网络地址。
本实施例的执行主体可以为负载均衡服务器，也可以是负载均衡服务集群。当执行主体接收到业务方的服务请求时，可以解析出该服务请求的目的地址，该目的地址即为Service在Kubernetes中的虚拟网络地址。
步骤202，基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合。
在本实施例中，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房。
可以理解的是，容器可以部署在物理机上，也可以部署在虚拟机上，本实施例中的宿主机表征Pod中各容器所在的物理机和/或虚拟机所在的物理机。物理机房可以是宿主机组成的集群所在的数据中心。
当前可用的Pod表征Kubernetes在当前时刻可以调用的Pod，例如可以是空闲状态或负载量小于预设负载阈值的Pod，当前可用的Pod在包括了当前时刻Kubernetes中的所有可用的Pod。候选Pod则表征可以响应该服务请求的Pod。虚拟网络地址与Pod的对应关系以及当前可用的Pod列表均来自Kubernetes。
作为示例，执行主体上可以运行有代理进程，代理进程通过GRPC(Google RemoteProcedure Call，谷歌远程过程调用)从Kubernetes的控制器中接收虚拟网络地址与Pod的对应关系和当前可用的Pod列表，然后基于步骤201中得到的目标虚拟网络地址，从当前可用的Pod列表中选取出对应于目标虚拟网络地址的Pod，即得到候选Pod集合。
步骤203，基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod。
本实施例中，目标Pod表征响应业务方的服务请求的Pod。执行主体可以按照预设的负载均衡策略从候选Pod集合中选取出目标Pod，例如，可以将负载最低的候选Pod确定为目标Pod。
负载均衡策略例如可以是最少负载均衡、最少连接负载均衡、加权轮询法等，本申请对此不做限制。
步骤204，将服务请求发送至目标Pod。
在本实施例中，执行主体可以从外部访问Kubernetes集群中的各个Pod，以将业务方的服务请求直接分发至目标Pod。访问方式例如可以包括Hostwork、Hostport、Nodeport、Loadbalancer、Ingress等，本申请对此不作限制。
在一个具体的示例中，执行主体可以采用FULLAT模式与目标Pod进行信息交互。执行主体将服务请求的目的地址替换成目标Pod在Kubernetes中的网络地址，源地址替换成执行主体的本地网络地址，然后由网卡转发更新后的服务请求，从而将更新后的服务请求发送至目标Pod。其中，目标Pod在Kubernetes中的网络地址可以预先通过代理进程获取。
步骤205，接收并转发目标Pod响应服务请求生成的响应报文。
在本实施例中，响应报文表征目标Pod针对服务请求执行对应的动作后得到的结果。响应报文的源地址为目标Pod在Kubernetes中的网络地址，目的地址为执行主体的本地网络地址
作为示例，执行主体接收到目标Pod生成的响应报文之后，执行主体将响应报文的源地址替换为步骤201中得到的目标虚拟地址，将响应报文的目的地址替换为业务方的网络地址(即步骤201中服务请求的源地址)，得到更新后的响应报文，并由网卡发送更新后的响应报文，从而将后端容器针对业务方的服务请求生成的响应结果反馈给业务方。
在一个具体的示例中，执行主体可以是电商平台的负载均衡服务器，电商平台可以在不同地点设置有数据中心，数据中心的业务服务器上部署有容器，并通过Kubernetes调度容器集群。电商品台的用户通过电商平台的客户端与电商平台进行交互。例如，用户可以在电商平台的客户端呈现的商品页面中点击“下单”，则该电商平台的客户端将“下单”这一服务请求通过网络发送至执行主体，该服务请求的目的地址为Kubernetes集群中对应于“下单”这一服务类型的Service，该Service中的Pod均预设有针对“下单”的程序。执行主体解析出该服务请求的目标虚拟网络地址，并从当前可用的Pod列表中，确定出目标虚拟网络地址对应的候选Pod集合。然后，将当前运行负载最低的候选Pod确定为目标Pod。之后，执行主体将服务请求发送至目标Pod。由目标Pod响应该服务请求并生成的响应报文，例如可以是生成待下单商品的确认信息，并将生成的待下单商品的确认信息发送至执行主体，由执行主体将待下单商品的确认信息发送至用户的终端设备，以使用户的终端设备上装载的电商平台的客户端呈现待下单商品的确认信息。
在本实施例的一些可选的实现方式中，该方法还包括：接收Kubernetes集群推送的代理进程，代理进程用于指示如下操作：接收预设网络域的虚拟网络地址；对预设网络域的虚拟网络地址对应的各Pod进行可用性检测，得到可用性检测的结果；基于可用性检测的结果，更新当前可用的Pod列表。
虚拟网络地址与Service是一一对应的，因而本实现方式中的网络域可以表征执行主体负载均衡的范围。可用性检测的结果表征Pod的运行状态，若Pod的运行状态异常，表示该Pod目前不可用，进一步地，若当前可用的Pod列表中存在该Pod，则应从当前可用的Pod列表中移除该Pod。
由于同一个Pod可以被多个Service调用，其运行状态是时刻变化的，通过可用性检测可以确定Pod的运行状态，如此，可以避免将不可用的Pod确定为目标Pod，从而提高负载均衡的可靠性。
进一步地，本实现方式中的执行主体还可以采用如下步骤确定候选Pod集合：确定目标虚拟地址所在的网络域；确定该网络域中的每个虚拟网络地址指向的Service，得到Service集群；若该Service集群中的各个Pod位于当前可用的Pod列表中，则将该Pod确定为候选Pod。
本公开的实施例提供的负载均衡的方法和装置，基于业务方的服务请求，从后端Kubernetes集群中确定出响应该服务请求的候选Pod集合，再基于预设的负载均衡策略和各候选Pod的运行状态，确定出目标Pod，并将服务请求转发给目标Pod，由目标Pod响应该服务请求，最后转发目标Pod生成的响应报文。可以基于接收到的Kubernetes集群的负载均衡信息，对部署在不同机房的物理机上的Pod进行负载均衡，可以实现不同机房之间的负载均衡以及业务互备。
继续参见图3，图3本公开的负载均衡系统的一个实施例的架构图，如图3所示，该负载均衡系统300包括：负载均衡服务器集群301和Kubernetes集群302，其中，负载均衡服务器集群301为基于BGP构建的服务器集群，被配置成：接收Kubernetes集群302的负载均衡信息，并基于负载均衡信息执行上述任一实施例中的负载均衡的方法；Kubernetes集群302包括控制器集群3021、同步集群3022和Pod集群3023，控制器集群3021被配置成：基于业务需求配置Service，Service为预设功能的Pod的集合；通过同步集群3022与各Service进行信息交互，以调度各Service中的Pod和获取各Pod的运行状态；基于各Service的配置信息和各Pod的运行状态，生成负载均衡信息；以及，将负载均衡信息发送至负载均衡服务器集群301。
在本实施例中，负载均衡系统的后端为基于Kubernetes构建的容器集群，容器集群部署于机房中的业务服务器上，可以为业务方提工作种类型的服务。负载均衡系统的运营人员可以通过Kubernetes调度各容器，例如删除或增加Pod、配置Service、在Pod中部署外部访问端口等。负载均衡服务器集群用于将业务方的服务请求分发至后端容器，以此实现四层负载均衡。负载均衡服务器集群可以采用外部访问的方式实现与后端容器的交互，例如可以从控制器集群接收负载均衡信息、将业务方的服务请求发送至Pod以及转发后端Pod生成的响应报文。
在本实施例中，负载均衡服务器集群可以是物理机集群，也可以是部署于物理机上的虚拟机组成的集群，还可以是两者的组合。负载均衡服务器之间采用BGP协议进行数据交互，如此，每个负载均衡服务器可以将数据BGP路由至其他负载均衡服务器，确保单个负载均衡服务器发生故障或者恢复后，可以动态地添加或删除负载均衡服务器，从而实现了负载均衡服务器集群的横向拓展和收缩。
在本实施例的一些可选的实现方式中，Pod集群中的各Pod的宿主机归属于不同的物理机房，负载均衡服务器集群包括若干负载均衡服务器子集群，每一个物理机房均部署有至少一个负载均衡服务器子集群。例如图3中示出的物理机房1和物理机房2。
如此，可以实现不同物理机房之间的负载均衡和业务互备，并实现了业务级容灾。
进一步地，负载均衡服务器集群还被配置成：响应于业务方的服务请求，解析出业务方的域名；基于预先构建的域名与负载均衡服务器子集群的对应关系，将服务请求发送至业务方的域名对应的目标负载均衡服务器子集群，由目标负载均衡服务器子集群执行上述实施例中的负载均衡的方法。
作为示例，可以基于域名所表征的地理区域与物理机房的距离构建域名与负载均衡服务器子集群的对应关系，每个负载均衡服务器子集群对应一个地理区域中的服务请求；还可以基于域名所表征的业务方的属性(例如教育机构、政府部门等机构属性)构建域名与负载均衡服务器子集群的对应关系，负载均衡服务器子集群对应一个或几个属性的服务请求。
示例性的，负载均衡服务器集群包括第一负载均衡服务器子集群和第二负载均衡服务器子集群，其中，第一负载均衡服务器子集群设置于A地，第二负载均衡服务器子集群设置于B地，业务方位于C地，其中，C地距离B地较近，则负载均衡服务器集群接收到业务方的服务请求后，可以将该服务请求分发至第二负载均衡服务器子集群，由第二负载均衡服务器子集群执行负载均衡策略。
如此，可以基于业务方的域名，将业务方的服务请求分发至不同的负载均衡服务器子集群，可以进一步提高负载均衡的效率。
进一步结合图4进行示例性说明，图4示出了本公开的负载均衡系统的一个实施例的流程图400。如图4所示，该流程包括以下步骤：
步骤4011，控制器集群将调度指令发送至同步集群，例如可以是增加或删除Pod的指令，也可以是指派Service虚拟网络地址的指令等。
步骤4012，同步集群将控制器集群发送的调度指令发送至指定的Service，由Service执行调度指令指示的操作，例如可以是指派Service的虚拟网络地址、增减或删除Service中的Pod、在Pod中部署外部访问端口等。
步骤4013，Pod集群将各Pod的运行状态发送至同步集群，运行状态可以表征Pod的负载状态。
步骤4014，同步集群将各Pod的运行状态发送至控制器集群。
经由步骤4011至步骤4014，实现了后端Kubernetes集群内部的调度和信息交互。
步骤4015，由控制集群基于各Service的配置信息和获取到的各Pod的运行状态生成负载均衡信息。作为示例，Service的配置信息可以包括Service的虚拟网络地址、Service的Nodeport、Service中的Pod在Kubernetes集群内部的网络地址、Service中的Pod的外部访问端口等。
可以看出，后端Kubernetes集群可以通过步骤4011至步骤4015生成负载均衡信息。
步骤401，控制器集群将负载均衡信息发送至负载均衡服务器集群。例如，控制器集群可以向负载均衡服务器集群推送代理进程，然后采用GPRC调用该代理进程，以将负载均衡信息发送给负载均衡服务器集群。
步骤402，业务方将服务请求发送至负载均衡服务器集群。
步骤403，负载均衡服务器集群执行上述实施例中的负载均衡的方法，确定出响应服务请求的目标Pod。
步骤404，将服务请求转发至目标Pod。
步骤405，由目标Pod相应服务请求，并根据响应结果生成响应报文。
步骤406，目标Pod将响应报文发送至负载均衡服务器集群。
步骤407，负载均衡服务器集群将响应报文转发至业务方。
在实践中，负载均衡服务器集群可以为每一个负载均衡服务器配置本地网络地址，并将本地网络地址写进网卡配置。负载均衡服务器集群接收到业务方的服务请求之后，可以基于就近原则将该服务请求路由至其中一个负载均衡服务器，由该负载均衡服务器执行上述负载均衡的方法。
在本实施例的一些可选的实现方式中，负载均衡服务器集群还被配置成：基于服务请求的源地址和目标Pod的真实网络地址，构建会话控制表；将会话控制表存储至目标负载均衡服务器，目标负载均衡服务器为将服务请求发送至目标Pod的负载均衡服务器；目标服均衡服务器还被配置成将目标Pod生成的响应报文转发至业务方。
在本实现方式中，会话控制表表征业务方与目标负载均衡服务器的会话信息，目标Pod的真实网络地址表征负载均衡服务器集群可以从外部访问到目标Pod的网络地址，例如可以是目标Pod在Kubernetes集群中的网络地址。基于会话控制表确定转发响应报文的负载均衡服务器，可以由同一个负载均衡服务器处理业务方与后端的交互，有助于提高交互的效率。
在本实施例的一些可选的实现方式中，负载均衡服务器集群中的每个负载均衡服务器均采用DPDK网卡收发报文，报文包括服务请求和目标Pod生成的响应报文。
DPDK网卡具有易开发、便于移植以及转发报文效率更高的优点，因而，采用DPDK网卡收发报文可以进一步提高负载均衡服务器集群转发报文的效率。
本公开的实施例提供的负载均衡系统，采用BGP协议构建的负载均衡服务器集群可以从Kubernetes获取后端业务容器的负载均衡信息，并基于负载均衡信息执行负载均衡策略，只需增加负载均衡服务器集群中服务器的数量，即可提高负载均衡系统的负载均衡能力，提高了负载均衡系统的可扩展性。此外，负载均衡服务器集群可以采用BGP协议，将每个负载均衡服务器中的数据路由至其他负载均衡服务器，从而实现了N+1冗余。
在本实施例的一些可选的实现方式中，控制器集群还被配置成：基于预先构建负载均衡标识与业务需求的对应关系以及Service对应的业务需求，为Service标记负载均衡标识；基于预先构建的负载均衡标识与网络域的对应关系以及Service的负载均衡标识，确定Service的网络域以及Service在该网络域中的虚拟网络地址。
在本实现方式中，负载均衡标识表征Pod集群提供的服务类别，服务类别相同的多个Service可以对应同一个负载均衡标识，如此可以基于服务类别对Kubernetes集群中的各Service进行分类，便于管理和调度。并且服务类别相同的多个Service处于同一个网络域中，当负载均衡服务器集群接收到业务方的服务请求时，可以将服务请求指向的虚拟网络地址所在的网络域中的所有Service中的Pod确定为可以响应该服务请求的Pod，从而拓展了相应服务请求的Pod的数量，有助于提高负载均衡的效率。
在本实施例的一些可选的实现方式中，控制器集群被配置成：基于业务需求，从Pod集群中确定出响应该业务需求的Pod集合，基于该集合中每个Pod的宿主机的归属地，将该集合划分成若干Pod子集合，将每个Pod子集合确定为一个Service，并基于预先构建的业务需求与网络域的对应关系，确定每个Service的网络域及其在该网络域中的虚拟网络地址。
在本实现方式中，还可以从Pod的宿主机归属地的维度配置Service，如此得到的各个Service中的Pod均属于同一个物理机房。当负载均衡服务器集群接收到业务方的服务请求时，可以将服务请求指向的虚拟网络地址所在的网络域中的所有Service中的Pod确定为可以响应该服务请求的Pod，如此得到的响应该服务请求的Pod的宿主机归属于不同的物理机房，可以实现跨机房的负载均衡和业务互备，并且便于Pod的调度和管理。
进一步参考图5，作为对上述各图所示方法的实现，本公开提供了一种负载均衡的装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。
如图5所示，本实施例的负载均衡的装置500包括：服务请求解析单元501，被配置成响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service集群，Service集群中的每个Service为功能相同的Pod组成的集合；候选Pod确定单元502，被配置成基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；目标Pod确定单元503，被配置成基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod；服务请求转发单元504，被配置成将服务请求发送至目标Pod；响应报文转发单元505，被配置成接收并转发目标Pod响应服务请求生成的响应报文；其中，虚拟网络地址与Pod的对应关系、当前可用的Pod列表以及各个候选Pod的当前负载状态为负载均衡信息，负载均衡信息获取自Kubernetes集群。
在本实施例中，该装置500还包括：代理进程单元，被配置成接收Kubernetes集群推送的代理进程，代理进程用于执行如下操作：接收预设网络域的虚拟网络地址；对预设网络域的虚拟网络地址对应的各Pod进行可用性检测，得到可用性检测的结果；基于可用性检测的结果，增加或删除预设网络域的虚拟网络地址对应的Pod。
下面参考图6，其示出了适于用来实现本公开的实施例的电子设备(例如图1中的服务器或终端设备)600的结构示意图。本公开的实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6示出的终端设备仅仅是一个示例，不应对本公开的实施例的功能和使用范围带来任何限制。
如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。
通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。图6中示出的每个方框可以代表一个装置，也可以根据需要代表多个装置。
特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开的实施例的方法中限定的上述功能。需要说明的是，本公开的实施例所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开的实施例中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址，目标虚拟网络地址指向Kubernetes集群中响应服务请求的Service，Service为功能相同的Pod组成的集合；基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出目标虚拟网络地址对应的候选Pod集合，候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；基于预设的负载均衡策略以及各个候选Pod的当前负载状态，从候选Pod集合中确定出目标Pod；将服务请求发送至目标Pod；接收并转发目标Pod响应服务请求生成的响应报文；其中，虚拟网络地址与Pod的对应关系、当前可用的Pod列表以及各个候选Pod的当前负载状态为负载均衡信息，负载均衡信息获取自Kubernetes集群。
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的实施例的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)——连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本公开的实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括服务请求解析单元、候选Pod确定单元、目标Pod确定单元、服务请求转发单元和响应报文转发报文。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，服务请求解析单元还可以被描述为“响应于业务方的服务请求，确定服务请求指向的目标虚拟网络地址的单元”。
以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开的实施例中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开的实施例中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (13)
1.一种负载均衡的方法，其中，包括：
响应于业务方的服务请求，确定所述服务请求指向的目标虚拟网络地址，所述目标虚拟网络地址指向Kubernetes集群中响应所述服务请求的Service，所述Service为功能相同的Pod组成的集合；
基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出所述目标虚拟网络地址对应的候选Pod集合，所述候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；
基于预设的负载均衡策略以及所述各个候选Pod的当前负载状态，从所述候选Pod集合中确定出目标Pod；
将所述服务请求发送至所述目标Pod；
接收并转发所述目标Pod响应所述服务请求生成的响应报文；
其中，所述虚拟网络地址与Pod的对应关系、所述当前可用的Pod列表以及所述各个候选Pod的当前负载状态为负载均衡信息，所述负载均衡信息获取自所述Kubernetes集群。
2.根据权利要求1所述的方法，所述方法还包括：
接收所述Kubernetes集群推送的代理进程，所述代理进程用于指示如下操作：
接收预设网络域的虚拟网络地址；对所述预设网络域的虚拟网络地址对应的各个Pod进行可用性检测，得到可用性检测的结果；基于所述可用性检测的结果，更新所述当前可用的Pod列表。
3.一种负载均衡系统，包括负载均衡服务器集群和Kubernetes集群，其中，
所述负载均衡服务器集群为基于BGP(Border Gateway Protocol，边界网关协议)构建的服务器集群，被配置成：接收所述Kubernetes集群的负载均衡信息，并基于所述负载均衡信息执行权利要求1或2所述的负载均衡方法；
所述Kubernetes集群包括控制器集群、同步集群和Pod集群，所述控制器集群被配置成：基于业务需求配置Service，所述Service为预设功能的Pod的集合；通过所述同步集群与各所述Service进行信息交互，以调度各所述Service中的Pod和获取各所述Service中的Pod的运行状态；基于各所述Service的配置信息和各所述Service中的Pod的运行状态，生成负载均衡信息；以及，将所述负载均衡信息发送至所述负载均衡服务器集群。
4.根据权利要求3所述的系统，其中，所述Pod集群中的各Pod的宿主机归属于不同的物理机房，所述负载均衡服务器集群包括若干负载均衡服务器子集群，每一个所述物理机房均部署有至少一个所述负载均衡服务器子集群。
5.根据权利要求4所述的系统，其中，所述控制器集群还被配置成：基于预先构建的负载均衡标识与业务需求的对应关系以及所述Service对应的业务需求，为所述Service标记负载均衡标识；
基于预先构建的负载均衡标识与网络域的对应关系以及所述Service的负载均衡标识，确定所述Service的网络域以及所述Service在该网络域中的虚拟网络地址。
6.根据权利要求4所述的系统，其中，所述控制器集群被配置成：
基于业务需求，从所述Pod集群中确定出响应该业务需求的Pod集合，基于该集合中每个Pod的宿主机的归属地，将该集合划分成若干Pod子集合，将每个所述Pod子集合确定为一个Service，并基于预先构建的业务需求与网络域的对应关系，确定每个Service的网络域及其在该网络域中的虚拟网络地址。
7.根据权利要求6所述的系统，其中，所述负载均衡服务器集群还被配置成：
响应于业务方的服务请求，解析出所述业务方的域名；
基于预先构建的域名与负载均衡服务器子集群的对应关系，将所述服务请求发送至所述业务方的域名对应的目标负载均衡服务器子集群，由所述目标负载均衡服务器子集群执行权利要求1或2所述的负载均衡的方法。
8.根据权利要求3所述的系统，其中，所述负载均衡服务器集群中的每个负载均衡服务器均采用DPDK(Data Plane Development Kit)网卡收发报文，所述报文包括所述服务请求和目标Pod生成的响应报文。
9.根据权利要求3至8之一所述的系统，其中，所述负载均衡服务器集群还被配置成：
基于所述服务请求的源地址和所述目标Pod的真实网络地址，构建会话控制表；
将所述会话控制表存储至目标负载均衡服务器，所述目标负载均衡服务器为将所述服务请求发送至所述目标Pod的负载均衡服务器；
所述目标服均衡服务器还被配置成将所述目标Pod生成的响应报文转发至所述业务方。
10.一种负载均衡的装置，其中，包括：
服务请求解析单元，被配置成响应于业务方的服务请求，确定所述服务请求指向的目标虚拟网络地址，所述目标虚拟网络地址指向Kubernetes集群中响应所述服务请求的Service集群，所述Service集群中的每个Service为功能相同的Pod组成的集合；
候选Pod确定单元，被配置成基于预存的虚拟网络地址与Pod的对应关系，从当前可用的Pod列表中确定出所述目标虚拟网络地址对应的候选Pod集合，所述候选Pod集合中的各个候选Pod的宿主机归属于不同的物理机房；
目标Pod确定单元，被配置成基于预设的负载均衡策略以及所述各个候选Pod的当前负载状态，从所述候选Pod集合中确定出目标Pod；
服务请求转发单元，被配置成将所述服务请求发送至所述目标Pod；
响应报文转发单元，被配置成接收并转发所述目标Pod响应所述服务请求生成的响应报文；
其中，所述虚拟网络地址与Pod的对应关系、所述当前可用的Pod列表以及所述各个候选Pod的当前负载状态为负载均衡信息，所述负载均衡信息获取自所述Kubernetes集群。
11.根据权利要求10所述的装置，所述装置还包括：
代理进程单元，被配置成接收所述Kubernetes集群推送的代理进程，所述代理进程用于执行如下操作：
接收预设网络域的虚拟网络地址；对所述预设网络域的虚拟网络地址对应的各Pod进行可用性检测，得到可用性检测的结果；基于所述可用性检测的结果，更新所述当前可用的Pod列表。
12.一种电子设备，包括：
一个或多个处理器；
存储装置，其上存储有一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1或2中任一所述的负载均衡的方法。
13.一种计算机可读介质，其上存储有计算机程序，其中，所述程序被处理器执行时实现如权利要求1或2中任一所述的负载均衡的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110323823.8A CN113783922A (zh) | 2021-03-26 | 2021-03-26 | 负载均衡的方法、系统和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110323823.8A CN113783922A (zh) | 2021-03-26 | 2021-03-26 | 负载均衡的方法、系统和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113783922A true CN113783922A (zh) | 2021-12-10 |
Family
ID=78835570
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110323823.8A Pending CN113783922A (zh) | 2021-03-26 | 2021-03-26 | 负载均衡的方法、系统和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113783922A (zh) |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114374696A (zh) * | 2021-12-15 | 2022-04-19 | 深圳前海微众银行股份有限公司 | 一种容器负载均衡方法、装置、设备及存储介质 |
| CN114390101A (zh) * | 2022-01-04 | 2022-04-22 | 上海弘积信息科技有限公司 | 一种基于BGP组网的Kubernetes负载均衡方法 |
| CN114640678A (zh) * | 2022-03-14 | 2022-06-17 | 明阳产业技术研究院(沈阳)有限公司 | 基于SR-IOV的Pod管理方法、设备及介质 |
| CN114900526A (zh) * | 2022-04-28 | 2022-08-12 | 京东科技信息技术有限公司 | 负载均衡方法及系统、计算机存储介质、电子设备 |
| CN115065730A (zh) * | 2022-05-24 | 2022-09-16 | 深信服科技股份有限公司 | 一种数据处理方法、第一容器、电子设备及存储介质 |
| CN115086334A (zh) * | 2022-06-15 | 2022-09-20 | 北京奇艺世纪科技有限公司 | 一种服务器标记方法及相关装置 |
| CN115134424A (zh) * | 2022-06-29 | 2022-09-30 | 中国工商银行股份有限公司 | 负载均衡方法、装置、计算机设备、存储介质和程序产品 |
| CN115277568A (zh) * | 2022-07-20 | 2022-11-01 | 重庆星环人工智能科技研究院有限公司 | 一种数据发送方法、装置、设备及存储介质 |
| CN115408127A (zh) * | 2022-08-25 | 2022-11-29 | 科东(广州)软件科技有限公司 | 一种type1型操作系统中任务分担的装置与方法 |
| CN115834585A (zh) * | 2022-10-17 | 2023-03-21 | 支付宝(杭州)信息技术有限公司 | 数据处理方法及负载均衡系统 |
| US20240028640A1 (en) * | 2022-07-25 | 2024-01-25 | Sap Se | Image scaling cloud database |
| CN117675932A (zh) * | 2024-02-01 | 2024-03-08 | 腾讯科技（深圳）有限公司 | 请求处理方法、装置、电子设备、系统及存储介质 |
| CN115065730B (zh) * | 2022-05-24 | 2024-07-09 | 深信服科技股份有限公司 | 一种数据处理方法、第一容器、电子设备及存储介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110716787A (zh) * | 2018-07-13 | 2020-01-21 | 中兴通讯股份有限公司 | 容器地址设置方法、设备和计算机可读存储介质 |
| CN110727653A (zh) * | 2019-10-12 | 2020-01-24 | 广州华多网络科技有限公司 | 多项目负载均衡方法和装置 |
| CN110780998A (zh) * | 2019-09-29 | 2020-02-11 | 武汉大学 | 基于Kubernetes的动态负载均衡资源调度方法 |
| CN111367662A (zh) * | 2020-02-26 | 2020-07-03 | 普信恒业科技发展（北京）有限公司 | 一种负载均衡方法、装置及系统 |
| CN111752681A (zh) * | 2020-06-29 | 2020-10-09 | 广州华多网络科技有限公司 | 请求处理方法、装置、服务器和计算机可读存储介质 |
| WO2021017279A1 (zh) * | 2019-07-30 | 2021-02-04 | 平安科技（深圳）有限公司 | 基于Kubernetes和网络域的集群安全管理方法、装置及存储介质 |
-
2021
- 2021-03-26 CN CN202110323823.8A patent/CN113783922A/zh active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110716787A (zh) * | 2018-07-13 | 2020-01-21 | 中兴通讯股份有限公司 | 容器地址设置方法、设备和计算机可读存储介质 |
| WO2021017279A1 (zh) * | 2019-07-30 | 2021-02-04 | 平安科技（深圳）有限公司 | 基于Kubernetes和网络域的集群安全管理方法、装置及存储介质 |
| CN110780998A (zh) * | 2019-09-29 | 2020-02-11 | 武汉大学 | 基于Kubernetes的动态负载均衡资源调度方法 |
| CN110727653A (zh) * | 2019-10-12 | 2020-01-24 | 广州华多网络科技有限公司 | 多项目负载均衡方法和装置 |
| CN111367662A (zh) * | 2020-02-26 | 2020-07-03 | 普信恒业科技发展（北京）有限公司 | 一种负载均衡方法、装置及系统 |
| CN111752681A (zh) * | 2020-06-29 | 2020-10-09 | 广州华多网络科技有限公司 | 请求处理方法、装置、服务器和计算机可读存储介质 |
Non-Patent Citations (1)
| Title |
|---|
| 平凡等: "基于Kubernetes的动态负载均衡机制研究与设计", 《 计算机与数字工程》, 20 January 2020 (2020-01-20) * |
Cited By (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023109067A1 (zh) * | 2021-12-15 | 2023-06-22 | 深圳前海微众银行股份有限公司 | 一种容器负载均衡方法、装置、设备及存储介质 |
| CN114374696A (zh) * | 2021-12-15 | 2022-04-19 | 深圳前海微众银行股份有限公司 | 一种容器负载均衡方法、装置、设备及存储介质 |
| CN114390101A (zh) * | 2022-01-04 | 2022-04-22 | 上海弘积信息科技有限公司 | 一种基于BGP组网的Kubernetes负载均衡方法 |
| CN114640678A (zh) * | 2022-03-14 | 2022-06-17 | 明阳产业技术研究院(沈阳)有限公司 | 基于SR-IOV的Pod管理方法、设备及介质 |
| CN114900526A (zh) * | 2022-04-28 | 2022-08-12 | 京东科技信息技术有限公司 | 负载均衡方法及系统、计算机存储介质、电子设备 |
| CN114900526B (zh) * | 2022-04-28 | 2024-04-16 | 京东科技信息技术有限公司 | 负载均衡方法及系统、计算机存储介质、电子设备 |
| CN115065730A (zh) * | 2022-05-24 | 2022-09-16 | 深信服科技股份有限公司 | 一种数据处理方法、第一容器、电子设备及存储介质 |
| CN115065730B (zh) * | 2022-05-24 | 2024-07-09 | 深信服科技股份有限公司 | 一种数据处理方法、第一容器、电子设备及存储介质 |
| CN115086334A (zh) * | 2022-06-15 | 2022-09-20 | 北京奇艺世纪科技有限公司 | 一种服务器标记方法及相关装置 |
| CN115086334B (zh) * | 2022-06-15 | 2024-05-28 | 北京奇艺世纪科技有限公司 | 一种服务器标记方法及相关装置 |
| CN115134424B (zh) * | 2022-06-29 | 2024-02-02 | 中国工商银行股份有限公司 | 负载均衡方法、装置、计算机设备、存储介质和程序产品 |
| CN115134424A (zh) * | 2022-06-29 | 2022-09-30 | 中国工商银行股份有限公司 | 负载均衡方法、装置、计算机设备、存储介质和程序产品 |
| CN115277568A (zh) * | 2022-07-20 | 2022-11-01 | 重庆星环人工智能科技研究院有限公司 | 一种数据发送方法、装置、设备及存储介质 |
| US20240028640A1 (en) * | 2022-07-25 | 2024-01-25 | Sap Se | Image scaling cloud database |
| US11914637B2 (en) * | 2022-07-25 | 2024-02-27 | Sap Se | Image scaling cloud database |
| CN115408127A (zh) * | 2022-08-25 | 2022-11-29 | 科东(广州)软件科技有限公司 | 一种type1型操作系统中任务分担的装置与方法 |
| CN115408127B (zh) * | 2022-08-25 | 2023-07-11 | 科东(广州)软件科技有限公司 | 一种type1型操作系统中任务分担的装置与方法 |
| CN115834585A (zh) * | 2022-10-17 | 2023-03-21 | 支付宝(杭州)信息技术有限公司 | 数据处理方法及负载均衡系统 |
| CN117675932A (zh) * | 2024-02-01 | 2024-03-08 | 腾讯科技（深圳）有限公司 | 请求处理方法、装置、电子设备、系统及存储介质 |
| CN117675932B (zh) * | 2024-02-01 | 2024-05-14 | 腾讯科技（深圳）有限公司 | 请求处理方法、装置、电子设备、系统及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113783922A (zh) | 负载均衡的方法、系统和装置 | |
| US9667749B2 (en) | Client-initiated leader election in distributed client-server systems | |
| CN111614738B (zh) | 基于Kubernetes集群的服务访问方法、装置、设备及存储介质 | |
| EP3447965B1 (en) | Network function instance management method and relevant device | |
| CN109358967B (zh) | 一种me平台app实例化迁移方法及服务器 | |
| US8543680B2 (en) | Migrating device management between object managers | |
| US9390156B2 (en) | Distributed directory environment using clustered LDAP servers | |
| CN111124299A (zh) | 数据存储管理方法、装置、设备、系统及存储介质 | |
| US20230216895A1 (en) | Network-based media processing (nbmp) workflow management through 5g framework for live uplink streaming (flus) control | |
| JP2022069420A (ja) | コンピュータ実装方法、コンピュータシステムおよびコンピュータプログラム製品（エッジコンピューティング環境における障害管理） | |
| CN114911602A (zh) | 一种服务器集群的负载均衡方法、装置、设备和存储介质 | |
| US10231269B2 (en) | Dynamic generation of geographically bound manet IDs | |
| US10637924B2 (en) | Cloud metadata discovery API | |
| JP2021010164A (ja) | 通知プリセットを利用した通知処理方法および装置 | |
| US11595471B1 (en) | Method and system for electing a master in a cloud based distributed system using a serverless framework | |
| CN113726638B (zh) | 一种多云多芯容器管理的方法、装置及设备、存储介质 | |
| US11637737B2 (en) | Network data management framework | |
| US20180123999A1 (en) | Tracking client location using buckets | |
| CN115242791A (zh) | 服务平台的访问方法、装置、设备及存储介质 | |
| US20190069121A1 (en) | Direct update of mobile applications based on features used | |
| CN115883352B (zh) | 服务节点创建方法、相关设备及存储介质 | |
| US11875202B2 (en) | Visualizing API invocation flows in containerized environments | |
| JP6246677B2 (ja) | 通信システム、コントロール装置及び処理装置切替方法 | |
| CN115834481A (zh) | 一种基于saas云平台的api网关的实现方法及装置 | |
| KR20150124592A (ko) | 복수의 사용자 장치간 데이터 동기화를 수행하는 서비스 장치, 장치간 데이터 동기화를 수행하는 사용자 장치, 복수의 사용자 장치간 데이터 동기화를 수행하는 방법 및 컴퓨터 프로그램이 기록된 기록매체 |
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 |