掌桥专利:专业的专利平台
掌桥专利
首页

负载均衡方法、平台、电子设备及计算机可读存储介质

文献发布时间:2023-06-19 19:38:38


负载均衡方法、平台、电子设备及计算机可读存储介质

技术领域

本公开涉及容器服务技术领域,特别涉及一种负载均衡方法、平台、电子设备及计算机可读存储介质。

背景技术

容器集群管理系统(Kubernetes,K8s),是一个开源的、基于容器技术的分布式架构系统,可以实现容器集群的自动化部署、自动扩缩容、维护等功能;负载均衡是指将负载例如工作任务平衡或分摊到K8s容器化平台中的多个操作单元上运行,从而通过多个操作单元协同完成工作任务。在k8s容器化平台,为pod提供的负载均衡技术需要先进行代理相关的地址转换处理再进行数据包的流量转发,流量转发的流量耗时较长,导致负载均衡的处理性能较差。

发明内容

本公开提供一种负载均衡方法、平台、电子设备及计算机可读存储介质,可以提高负载均衡的处理性能。

第一方面,本公开提供了一种负载均衡方法,该负载均衡方法包括:接收用户设备的访问请求,所述访问请求用于请求访问预定的应用程序,且所述访问请求中携带有虚拟网络地址;从预设的路由表信息中查找与所述虚拟网络地址对应的路由信息,所述路由信息用于指示所述虚拟网络地址与多个服务副本的网络地址的路由关系;所述多个服务副本为所述应用程序的服务副本,且所述多个服务副本运行于容器集群管理系统中的至少一个节点设备;通过每个服务副本的网络地址,将所述访问请求转发至所述每个服务副本的数据接收接口,所述访问请求的转发用于将对所述应用程序的访问均衡分布到每个服务副本。

第二方面,本公开提供了一种容器集群管理系统,该容器集群管理系统包括:容器集群管理系统包括负载管理平台,所述负载管理平台包括:接收模块,用于接收用户设备的访问请求,所述访问请求用于请求访问预定的应用程序,且所述访问请求中携带有虚拟网络地址;查找模块,用于从预设的路由表信息中查找与所述虚拟网络地址对应的第一路由信息,所述第一路由信息用于指示所述虚拟网络地址与多个服务副本中的每个服务副本的网络地址的路由关系;所述多个服务副本为所述应用程序的服务副本,且所述多个服务副本运行于所述容器集群管理系统中的至少一个节点设备;转发模块,用于通过所述每个服务副本的网络地址,将所述访问请求转发至所述每个服务副本的数据接收接口,所述访问请求的转发用于将对所述应用程序的访问均衡分布到每个服务副本。

第三方面,本公开提供了一种电子设备,该电子设备包括:至少一个处理器;以及与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序,一个或多个所述计算机程序被所述至少一个处理器执行,以使所述至少一个处理器能够执行上述的负载均衡方法。

第四方面,本公开提供了一种计算机可读存储介质,其上存储有计算机程序,其中,所述计算机程序在被处理器/处理核执行时实现上述的负载均衡方法。

本公开所提供的实施例,用户设备的访问请求中携带了虚拟网络地址,根据预先建立的虚拟网络地址与多个服务副本的网络地址的路由关系,可以将对预定的应用程序的访问请求,均衡分布到每个服务副本,实现对来自用户设备的访问请求的负载均衡。在该方法中,通过建立虚拟网络地址与多个服务副本的网络地址的路由关系,将来自用户设备的访问请求直接转发到多个服务副本上,相较于相关技术中的负载均衡处理需要先进行代理相关的地址转换处理再进行数据包的流量转发,本公开实施例的方法可以减少数据转发过程的时间消耗,有利于提高负载均衡的处理性能。

应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用来提供对本公开的进一步理解,并且构成说明书的一部分,与本公开的实施例一起用于解释本公开,并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述,以上和其他特征和优点对本领域技术人员将变得更加显而易见,在附图中:

图1为本公开实施例提供的一种负载均衡方法的流程图;

图2为本公开实施例提供的容器集群管理系统的架构示意图;

图3为本公开实施例提供的一种容器集群管理系统的框图;

图4为本公开实施例提供的容器集群管理系统的框图;

图5为本公开实施例提供的一种电子设备的框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案,以下结合附图对本公开的示范性实施例做出说明,其中包括本公开实施例的各种细节以助于理解,应当将它们认为仅仅是示范性的。因此,本领域普通技术人员应当认识到,可以对这里描述的实施例做出各种改变和修改,而不会背离本公开的范围和精神。同样,为了清楚和简明,以下的描述中省略了对公知功能和结构的描述。

在不冲突的情况下,本公开各实施例及实施例中的各特征可相互组合。

如本文所使用的,术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例,且不意欲限制本公开。如本文所使用的,单数形式“一个”和“该”也意欲包括复数形式,除非上下文另外清楚指出。还将理解的是,当本说明书中使用术语“包括”和/或“由……制成”时,指定存在特征、整体、步骤、操作、元件和/或组件,但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接,而是可以包括电性的连接,不管是直接的还是间接的。

除非另外限定,否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解,诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义,且将不解释为具有理想化或过度形式上的含义,除非本文明确如此限定。

在本公开实施例中,K8s系统中,节点设备(Node)上的最小运行单元是虚拟容器或者节点设备中增强型容器(Pod),Pod是K8S创建或部署的用于操作容器的基本调度单元;每个Pod里面可以包括多个容器,可以把Pod看作是一种容器的扩展或者增强型的容器,Pod里面的多个容器共同完成一个特定的功能。一个Pod代表集群上正在运行的一个进程或者一个应用程序的实例,把多个进程打包在一个Name Space里的时候,就构成了一个Pod。

在k8s容器化平台,为pod提供负载均衡地技术,主要包含k8s集群(k8s cluster)原生的k8s群(cluster)负载技术,路由规则服务(ingress-nginx)技术等,这类负载核心技术是通过代理的方式实现流量转发到pod上。

对于k8s cluster负载技术,在Kubernetes集群中,每个节点上可以运行一个kube-proxy进程。其中,kube-proxy是Kubernetes中运行在节点上的一个网络代理组件,运行在每个节点上,Kube-proxy可以用于维护Node上的网络规则。运行在每个节点上的kube-proxy进程其实就是一个智能的软件负载均衡器,它会负责把对服务(Service)的请求转发到后端的某个Pod实例上并在内部实现服务的负载均衡与会话保持机制。

对于入口负载均衡器(Ingress-nginx)技术,Ingress在kubernetes中是一个具有七层协议的路由转发机制,典型的访问方式是超文本传输协议(Hyper Text TransferProtocol,HTTP)和超文本传输安全协议(Hypertext Transfer Protocol Secure,HTTPS);Ingress可以理解为是从kuberenets集群外部访问集群的一个入口,即Ingress为Kubernetes集群中的服务提供了入口,实现用域名的方式访问k8s内部应用,并可以提供负载均衡功能,常用的Ingress包括负载均衡器(Nginx)。通常情况下,Ingress部署在所有的Node节点上,通过定义路由规则,得到从集群外部到集群内部的HTTP和HTTPS的路由规则。通过控制策略以及结合具体提供转发服务的Ingress控制器(Controller)来实现基于灵活的Ingress策略定义的服务路由功能。

在相关技术中,K8S中的“负载均衡”不是直接通过负载设备本身提供的功能实现对流量的负载,而是可以使用操作系统Linux操作系统提供的防火墙(IPTables)规则或者IP虚拟服务器(IP Virtual Server,IPvs)提供的负载能力,实现到pod流量的转发。IPTables是Linux上常用的防火墙软件;其中,IPvs是运行在Linux虚拟服务器(LinuxVirtual Server,LVS)下的提供负载平衡功能的一种技术;K8s cluster在安装k8s集群的时候,需要指定是使用IPTables或者IPVS的负载方法;相关技术中,K8S中的“负载均衡”也可以使用开源nginx负载软件提供的负载能力,实现到pod流量的转发。

具体地,在相关技术中,k8s cluster和ingress-nginx负载均衡技术,都需要通过k8s应用程序接口(Application Program Interface,API)监控(watch)接口提供的功能,实时监听Pod的变化(变化包括:重启,删除,新增),当监听到变化的时候,k8s cluster会更新iptables规则表,ingress-nginx会更新upstream转发表,最终实现访问cluster和ingress提供的负载虚拟网络地址(Virtual IP Address,VIP)实现流量转发的pod上。

在相关技术的一些场景中,当用户设备通过源IP地址10.193.7.1访问K8Scluster的VIP地址10.97.217.168时,会将流量数据转发到pod的IP地址10.97.106.99上,整个流量转发可以通过IP Tables规则串联成一条完整的数据转发链路;流量数据到达目标pod后,在目标pod上查看源IP地址,可以看到用户设备的请求源IP地址显示为10.97.3.1,此地址为k8s cluster的流量入口地址,但用户设备的真实源IP地址为10.193.7.1,二者不相符,在目标pod上无法查看到用户设备的真实源IP。

在上述场景的负载均衡处理中,k8s cluster是基于4层的负载均衡技术,Ingress-nginx基于nginx开发的4/7层负载均衡技术;以4层负载均衡技术为例,用户设备通过真实源IP地址访问VIP地址时,基于传输控制协议(Transmission Control Protocol,TCP)或无连接的传输协议(User Datagram Protocol,UDP)的四层网络代理后,Pod只能获取到代理服务器IP,而获取不到真实的用户设备IP,因此,在pod上无法查看到用户设备的真实源IP;并且,用户设备的访问请求通过Kubernetes中的kube-proxy代理组件的处理后,整个业务架构依赖kube-proxy代理组件将数据转发到某个Pod,相当于kube-proxy代理组件成为了统一流量入口或“集中式”网关,这样将导致数据转发过多依赖kube-proxy,一旦kube-proxy代理组件出现故障,将导致与kube-proxy代理组件相关的故障域(服务器、存储和/或网络连接组件)均会出现故障,即存在故障域集中的问题;并且,不同类型的代理组件所依赖的底层技术往往不一致,不利于k8s原生架构统一化标准实现,以及,代理组件需要先进行代理相关的地址转换处理再进行数据包的流量转发,流量转发的流量耗时较长,导致负载均衡的处理性能较差。

根据本公开实施例的负载均衡方法可以由终端设备或服务器等电子设备执行,终端设备可以为车载设备、用户设备(User Equipment,UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant,PDA)、手持设备、计算设备、车载设备、可穿戴设备等,方法可以通过处理器调用存储器中存储的计算机可读程序指令的方式来实现。服务器可以包括独立的物理服务器、有多个服务器组成的服务器集群或者能够进行云计算的云服务器。

图1为本公开实施例提供的一种负载均衡方法的流程图。参照图1,该负载均衡方法可以包括以下步骤。

S110,接收用户设备的访问请求,访问请求用于请求访问预定的应用程序,且访问请求中携带有虚拟网络地址。

S120,从预设的路由表信息中查找与虚拟网络地址对应的路由信息,路由信息用于指示虚拟网络地址与多个服务副本的网络地址的路由关系;多个服务副本为应用程序的服务副本,且多个服务副本运行于容器集群管理系统中的至少一个节点设备。

在该步骤中,节点设备的网络地址(Node IP)可以是节点设备的物理网卡的IP地址;应用程序是在节点设备上运行的程序,可以通过Pod来表示。应用程序的服务副本是指应用程序的拷贝文件,与该应用程序提供相同的功能。示例性地,应用程序的多个服务副本例如3个服务副本可以通过Pod1、Pod2和Pood3来表示,Pod1、Pod2和Pood3提供与该相同的服务,即提供相同的功能,Pod1、Pod2和Pood3具有自己的IP地址,K8S为每个Pod分配了唯一IP地址。

S130,通过每个服务副本的网络地址,将访问请求转发至每个服务副本的数据接收接口,访问请求的转发用于将对应用程序的访问均衡分布到每个服务副本。

在该步骤中,通过虚拟网络地址与多个服务副本的网络地址的路由关系,也即通过VIP与多个Pod IP之间的路由关系,将用户设备发送的携带VIP的访问请求转发到运行于至少一个节点设备的每个pod上,通过访问请求的转发将对应用程序的访问均衡分布到每个服务副本,实现多个pod能被一个VIP地址访问,实现流量的均衡。

在本公开实施例中,用户设备的访问请求中携带了虚拟网络地址,根据预先建立的虚拟网络地址与多个服务副本的网络地址的路由关系,可以将对预定的应用程序的访问请求,均衡分布到每个服务副本,实现对来自用户设备的访问请求的负载均衡。在该方法中,通过建立虚拟网络地址与多个服务副本的网络地址的路由关系,将来自用户设备的访问请求直接转发到多个服务副本上,相较于相关技术中的负载均衡处理需要先进行代理相关的地址转换处理再进行数据包的流量转发,本公开实施例的可以减少数据转发过程的时间消耗,有利于提高负载均衡的处理性能。

在本公开实施例中,由于可以直接将对应用程序的访问请求转发到应用程序的多个服务副本上,每个服务副本可以直接获取到发起访问请求的用户设备的真实源IP,因此,在需要使用用户真实源IP的场景中,可以基于用户设备的真实源IP实现各种业务应用;这些场景例如可以包括:在容器集群管理系统中进行基于用户设备真实源IP的网络探测、异地登录的风险预警等,满足容器集群的安全要求。

本公开实施例的负载均衡方法,不依赖kube-proxy代理组件进行与访问请求相关的流量转发,而是可以通过设置多个服务副本运行于不同的节点设备,实现每个应用程序的分布式负载,应用程序的一个服务副本出现问题,不影响应用程序的其他副本的运行,所以不会出现相关技术中由于使用kube-proxy代理组件而带来的故障域集中的问题,提高了系统的运行稳定性;

并且,在本公开实施例中,相比相关技术中若容器集群管理系统中使用不同类型的代理组件时,由于不同类型的代理组件依赖的底层技术不一致,会导致k8s原生架构无法实现统一化的底层技术标准,根据本公开实施例的负载均衡方法,多个服务组件在容器集群管理系统中的至少一个节点设备上运行,每个服务组件的底层均是基于容器技术(底层技术一致)来实现,从而有利于实现k8s原生架构底层技术的统一化标准。

图2为本公开实施例提供的容器集群管理系统的架构示意图。在图2中,该容器集群管理系统200包括:负载管理平台210、容器集群平台220、配置管理数据库230和网络管理平台240。

在图2中,负载管理平台(k8s负载管理平台)210,用于通过建立虚拟网络地址与多个服务副本的网络地址的路由关系,将来自用户设备的访问请求直接转发到多个服务副本上,实现对用户设备的访问请求均衡分布到每个服务副本,实现访问请求的流量均衡;容器集群平台(简称k8s平台)220,负责管理整个k8s集群中的集群组件,集群组件包括多个Node和每个Node上运行的Pod;在图2中,多个Node例如包括Node1、Node2和Node3,Node1上运行有pod1、Node2上运行有pod2、Node3上运行有pod3;pod1、pod2和pod3为同一应用程序的3个服务副本,提供相同的功能。在一些实施例中,Node是一台物理服务器,当某一台物理服务器加入到k8s集群,在k8s中可以将此物理服务器定义为一个Node。

继续参考图2,配置管理数据库(Configuration Management Database,CMDB)系统230,用于存储如路由器的路由信息,交换机信息,服务器信息等基础相关信息,是一个基础资产管理平台;网络管理平台(简称k8s网络管理平台)240,用于管理pod使用的IP地址以及确保网络连通。

下面结合图2中的容器集群管理系统,详细描述本公开实施例的负载管理方法。

在一些实施例中,在步骤S110之前,负载均衡方法还包括:

S11,获取预先存储的每个服务副本的基础信息和预先存储的与至少一个节点设备对应的路由器的路由信息。

在一些实施例中,负载管理平台210可以通容器集群平台220获取每个服务副本的基础信息,从配置管理数据库230提供基础的硬件信息中获取每个服务副本的基础信息对应的路由器信息等。

示例性地,基础信息(PodInfo)中可以包括:每个服务副本的服务副本名称(PodName)、每个服务副本的网络地址(Pod IP)、每个服务副本对应的节点设备的网络地址(Node IP)以及该对应的节点设备的网关地址(GatewayIP)中的一项或多项。不同服务副本具有不同的Pod name和Pod IP。

示例性地,对应的路由器信息(Routeinfo)中可以包括:该节点设备的网关地址(gatewayip)和该网关地址对应的路由表信息(Routelist)。

S12,根据基础信息和路由器的路由信息生成虚拟网络地址。

在该步骤中,负载管理平台210可以自动生成虚拟网络地址,每个虚拟网络地址与基础信息中的Pod IP和Node IP相对应。

S13,通过虚拟设备接口对,生成虚拟网络地址与每个服务副本的关联信息,并生成与每个关联信息对应的路由信息,并将路由信息加入路由表信息中。

在该实施例中,通过虚拟设备接口对,建立虚拟网络地址与应用程序的多个服务副本的直接关联关系,为后续直接将来自用户设备的访问请求转发到多个服务副本上,实现对应用程序的负载均衡提供实现基础。

在一些实施例中,基础信息包括:每个服务副本的网络地址和每个服务副本所对应的节点设备的网络地址、以及对应的节点设备的网关地址;路由器的路由信息包括:每个节点设备的网关地址对应的路由信息。

该实施例中,步骤S12具体可以包括:

S21,基于动态主机配置协议获取一个虚拟网络地址作为第一地址。

参考图2,负载管理平台210可以通过DHCP Client获取动态分配的虚拟网络地。动态主机配置协议(Dynamic Host Configuration Protocol,DHCP)是一个局域网的网络协议,指的是由服务器控制一段IP地址范围,DHCP客户端(DHCP Client)登录DHCP服务器时就可以自动获得服务器分配的IP地址和子网掩码。

S22,从每个节点设备的网关地址对应的路由信息中,查找与第一地址对应的路由信息。

S23,在未查找到第一地址对应的路由信息的情况下,确定第一地址尚未被使用,并将第一地址作为生成的虚拟网络地址。

在该实施例中,在节点设备的网关地址对应的路由信息RouteList中,存储有不同虚拟网络地址对应的路由信息,对生成的虚拟网络地址进行重复性校验,具体地,查看路由信息中是否已经存在的第一地址对应的路由信息,若不存在,则确定第一地址尚未被使用,即生成的虚拟网络地址尚未被使用;若存在,则重新执行步骤S21-S23,直到得到通过重复性校验的虚拟网络地址,为运行于每个节点设备上的每个服务副本生成与Node IP和PodIP相对应的虚拟网络地址。

在一些实施例中,可以通过函数setpodvip执行上述步骤S21-S23,并在执行步骤S23之后,输出生成结果(getresult),若输出的生成结果取值为1,则表示执行成功;若输出的生成结果的取值为2,则表示执行失败;若输出的生成结果取值为0,则表示接口调用失败;若输出的生成结果取值为3,则表示部分失败,例如出现网络错误时导致的执行失败。

在一些实施例中,对于设置全部失败或部分失败的生成结果,可以对该步骤S21中生成的虚拟网络地址执行删除操作,然后重新执行步骤S21-S23。

示例性地,可以通过函数delpodvip来执行对虚拟网络地址的删除。具体地,通过PodIP和Node IP获取生成的对应的虚拟网络地址,然后对该对应的虚拟网络地址执行删除操作。并在执行删除操作之后,输出删除结果,若删除结果(getdelresult)取值为1,则表示删除成功;若删除结果取值为0,则表示删除失败。

应理解,上述分配结果的取值和删除操作的处理结果的取值可以根据实际需要来设置,本公开实施例不做具体限定。

在一些实施例中,若将步骤S13中生成的路由信息称为是第一路由信息,则可以根据虚拟网络地址与每个节点设备的网络地址的路由关系,生成第二路由信息,并将第二路由信息加入路由表信息中。示例性地,在图2的路由表信息中,第二路由信息用于表征虚拟网络地址与多个节点设备例如Node1、Node2和Node3的网络地址的路由关系,通过第二路由信息,可以确定访问请求被转发到哪些节点设备上的服务副本。

在该实施例中,根据虚拟网络地址与每个节点设备的网络地址的路由关系,生成第二路由信息的步骤具体可以包括:根据节点设备的网络地址、运行于节点设备的服务副本的网络地址、以及对应的虚拟网络地址,生成虚拟网络地址的接口信息;将虚拟网络地址的接口信息发布到节点设备对应的路由器,路由器用于在路由表信息中添加与该接口信息对应的路由信息,得到第二路由信息。

示例性地,负载管理平台210将虚拟网络地址(与Node IP和Pod IP对应的VIP)发送至网络管理平台240,网络管理平台240平台根据接收到的上述信息,向对应的节点设备上的节点代理服务器(Node Agent)下发添加vip接口的命令,命令中携带命令参数(NodeIP、Pod IP、VIP),节点设备上的Agent执行上述生成第二路由信息的步骤,为虚拟网络地址分配对应的接口信息,并生成与该接口信息对应的路由信息。

在一些实施例中,通过网络管理平台240用于实现对Node Agent的使用和管理,通过向Node Agent下发设置命令,命令中携带命令参数(Node IP、Pod IP、VIP),Node节点上的Agent解析该命令,得到命令中携带的命令参数,然后通过将VIP与Node IP和Pod IP进行关联,并通过Node Agent将第一路由信息和第二路由信息发布到路由器。

示例性地,负载管理平台210还可以根据管理需求对虚拟网络地址的接口信息执行删除操作。例如,负载管理平台210向Node Agent下发删除命令,命令中携带命令参数(NodeIP、Pod IP、VIP),Node节点上的Agent解析该命令,得到命令中携带的命令参数,然后将与Node IP和Pod IP对应的VIP的接口信息删除。

在该实施例中,负载管理平台210还可以触发负载功能的开启。具体地,负载管理平台210向网络管理平台240发送开启请求,以用于请求开启负载功能;网络管理平台240接收到接受到开启请求,开始向应用程序的服务副本所运行于的节点设备上的Node Agent发送配置命令,通过Node Agent来实现开启负载功能所需的底层配置,配置完成后,通过相关路由协议发布VIP到对应的路由器上。

在一些实施例中,每个服务副本的网络地址与预先设置的一个虚拟网络设备相对应;上述步骤S13中通过虚拟设备接口对,生成虚拟网络地址与每个服务副本的关联信息的步骤,可以包括如下步骤:

S41,将虚拟网络地址和第i个服务副本的网络地址,与对应的虚拟网络设备建立关联关系;其中,虚拟网络设备用于将虚拟网络地址对应的访问请求直接发送至第i个服务副本的数据接收接口,i为大于或等于1且小于多个服务副本的服务副本总数。

在该步骤中,虚拟网络(Veth Pair)设备,是用于解决物理机和pod之间通信的一个软件设备;Veth Pair可以理解为是虚拟网线且Veth Pair包含成对的端口,该成对的端口也可以称为是虚拟设备接口对,从虚拟设备接口对的一个接口进入的数据包,都将从该虚拟设备接口对的另一个接口出来,反之也是一样。

S42,生成与关联关系对应的关联信息,作为虚拟网络地址与第i个服务副本的关联信息。

示例性地,对于任一服务副本Pod1,假设Pod1的Veth Pair设备的设备名称为veth1,Pod1的IP地址为2.2.2.2。Linux系统的route命令用于显示和操作IP路由表,通过命令“route–n”进行路由信息显示如下:“2.2.2.2 255.255.255.255veth1对应pod1”,255.255.255.255为子网掩码;将vip地址和Pod1的网络地址关联方法可以通过下述命令“route add 1.1.1.1mask 255.255.255.0dev veth1”来实现,该命令表示,在路由信息中增加vip地址“1.1.1.1”与Veth Pair设备“veth1”的连接。

该命令执行成功后,vip设置成功后,通过命令route–n的信息显示如下:

2.2.2.2 255.255.255.255 veth1

1.1.1.1 255.255.255.255veth1

此时,Pod1的网络地址和VIP均与Veth Pair设备“veth1”建立了关联。

示例性地,对于任一服务副本Pod2,在VIP地址“1.1.1.1”和Pod2的网络地址“3.3.3.3”与Veth Pair设备“veth2”建立了关联之后,通过命令route–n的信息显示如下:

3.3.3.3 255.255.255.255veth1

1.1.1.1 255.255.255.255veth1

示例性地,对于任一服务副本Pod3,在VIP地址“1.1.1.1”和Pod3的网络地址“4.4.4.4”与Veth Pair设备“veth3”建立了关联之后,通过命令route–n的信息显示如下:

4.4.4.4 255.255.255.255veth1

1.1.1.1 255.255.255.255veth1

示例性地,如果pod1和pod2在同一个Node节点(pod1和pod2为同一个应用程序的2个相同的服务副本),VIP地址1.1.1.1的route–n表现形式如下:

1.1.1.1 255.255.255.255veth1

veth2

即:pod1和pod2在同一个物理节点上的话,VIP地址1.1.1.1与pod1的网络地址对应的Veth Pair设备“veth1”建立的关联信息,以及VIP地址1.1.1.1与pod2的网络地址对应的Veth Pair设备“veth2”建立的关联信息可以表示为上述形式,表示VIP地址1.1.1.1即关联到veth1,又关联到veth2。

通过上述方式,即可将虚拟网络地址和任一服务副本的网络地址,均与该服务副本对应的Veth Pair设备建立关联关系。

在一些实施例中,上述步骤S13中,生成与每个关联信息对应的路由信息的步骤,具体可以包括:将建立的每个关联关系对应的路由信息,基于预定的路由协议发布到节点设备对应的路由器,路由器用于在路由信息中添加每个关联信息对应的等价路由路径。

示例性地,为了访问VIP 1.1.1.1的时候,与访问请求对对应的数据流量均衡分布到pod1,pod2,pod3,需要将vip发布到边界网关协议(Border Gateway Protocol,BGP)或者开放式最短路径优先(Open Shortest Path First Interior Gateway Protocol,Ospf)协议中形成ECMP等价路由,此时在路由器上会形成到1.1.1.1的ECMP等价路由,ECMP简单来讲就是到1.1.1.1有多条路径,每条路径的权重一致。从而使多个pod能被一个VIP地址访问,且实现流量的均衡。

示例性地,Node Agent可以将Node上运行的Pod的veth信息发布到ospf/bgp,将veth1接口直接通过bgp协议发布到路由信息中时,可以通过函数protocol direct{interface-"veth1(接口)","bgp/ospf(协议)",“和路由器建立邻居”}来实现。

在该实施例中,在路由器的路由表信息中添加:与每个通过Veth Pair设备建立的关联信息对应的等价路由路径,并生成相应的路由信息,得到与虚拟网络地址对应的路由信息。

在该实施例中,通过建立虚拟网络地址与多个服务副本的网络地址的路由关系,将来自用户设备的访问请求直接转发到多个服务副本上,相较于相关技术中的负载均衡处理需要先进行代理相关的地址转换处理再进行数据包的流量转发,本公开实施例的可以减少数据转发过程的时间消耗,有利于提高负载均衡的处理性能。

可以理解,本公开提及的上述各个方法实施例,在不违背原理逻辑的情况下,均可以彼此相互结合形成结合后的实施例,限于篇幅,本公开不再赘述。本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

此外,本公开还提供了容器集群管理系统、电子设备和计算机可读存储介质,上述均可用来实现本公开提供的任一种负载均衡方法,相应技术方案和描述和参见方法部分的相应记载,不再赘述。

图3为本公开实施例提供的一种容器集群管理系统的框图。图3与图2中相同或等同的结构具有相同的标号。

在一些实施例中,容器集群管理系统200包括负载管理平台210,负载管理平台210包括:接收模块211,用于接收用户设备的访问请求,访问请求用于请求访问预定的应用程序,且访问请求中携带有虚拟网络地址;查找模块212,用于从预设的路由表信息中查找与虚拟网络地址对应的第一路由信息,第一路由信息用于指示虚拟网络地址与多个服务副本中的每个服务副本的网络地址的路由关系;多个服务副本为应用程序的服务副本,且多个服务副本运行于容器集群管理系统200中的至少一个节点设备;转发模块213,用于通过每个服务副本的网络地址,将访问请求转发至每个服务副本的数据接收接口,访问请求的转发用于将对应用程序的访问均衡分布到每个服务副本。

在本公开实施例的容器集群管理系统中,通过负载管理平台接收用户设备的访问请求,获取访问请求中携带的虚拟网络地址,根据预先建立的虚拟网络地址与多个服务副本的网络地址的路由关系,将对预定的应用程序的访问请求均衡分布到每个服务副本,实现对来自用户设备的访问请求的负载均衡,相较于相关技术中的负载均衡处理需要先进行代理相关的地址转换处理再进行数据包的流量转发,有利于可以减少数据转发过程的时间消耗和提高负载均衡的处理性能。

图4示出了本公开示例性实施例提供的容器集群管理系统的框图。图4与图2、图3中相同或等同的结构具有相同的标号。

在一些实施例中,容器集群管理系统200还包括网络管理平台240;负载管理平台210还包括获取模块和发送模块;获取模块,用于在接收用户设备的访问请求之前,获取预先存储的每个服务副本的基础信息和预先存储的与至少一个节点设备对应的路由器的路由信息;发送模块,用于将基础信息和路由器的路由信息发送至网络管理平台240;网络管理平台240,用于向每个节点设备上运行的节点代理服务器发送地址设置指令,地址设置指令中包括基础信息和路由器的路由信息;每个节点设备上运行的节点代理服务器,用于根据基础信息和路由器的路由信息生成虚拟网络地址,通过虚拟设备接口对,生成虚拟网络地址与每个服务副本的关联信息,并生成与每个关联信息对应的第一路由信息,并将第一路由信息加入路由表信息中。

在一些实施例中,负载管理平台210还用于:基于动态主机配置协议获取一个虚拟网络地址作为第一地址;从每个节点设备的网关地址对应的路由信息中,查找与第一地址对应的路由信息;在未查找到第一地址对应的路由信息的情况下,确定第一地址尚未被使用,并将第一地址作为生成的虚拟网络地址,发送虚拟网络地址至网络管理平台240。

在一些实施例中,每个服务副本的网络地址与预先设置的一个虚拟网络设备相对应;每个节点设备上运行的节点代理服务器,具体用于:将虚拟网络地址和第i个服务副本的网络地址,与对应的虚拟网络设备建立关联关系;其中,虚拟网络设备用于将虚拟网络地址对应的访问请求直接发送至第i个服务副本的数据接收接口,i为大于或等于1且小于多个服务副本的服务副本总数;生成与关联关系对应的关联信息,作为虚拟网络地址与第i个服务副本的关联信息。

根据本公开实施例的容器集群管理系统,通过负载管理平台接收用户设备的访问请求,获取访问请求中携带的虚拟网络地址,根据预先建立的虚拟网络地址与多个服务副本的网络地址的路由关系,将对预定的应用程序的访问请求均衡分布到每个服务副本,实现对来自用户设备的访问请求的负载均衡,相较于相关技术中的负载均衡处理需要先进行代理相关的地址转换处理再进行数据包的流量转发,有利于可以减少数据转发过程的时间消耗和提高负载均衡的处理性能。

需要明确的是,本发明并不局限于上文实施例中所描述并在图中示出的特定配置和处理。为了描述的方便和简洁,这里省略了对已知方法的详细描述,并且上述描述的系统、模块和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

图5为本公开实施例提供的一种电子设备的框图。

参照图5,本公开实施例提供了一种电子设备,该电子设备包括:至少一个处理器501;至少一个存储器502,以及一个或多个I/O接口503,连接在处理器501与存储器502之间;其中,存储器502存储有可被至少一个处理器501执行的一个或多个计算机程序,一个或多个计算机程序被至少一个处理器501执行,以使至少一个处理器501能够执行上述的负载均衡方法。

本公开实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,其中,计算机程序在被处理器/处理核执行时实现上述的负载均衡方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。

本公开实施例还提供了一种计算机程序产品,包括计算机可读代码,或者承载有计算机可读代码的非易失性计算机可读存储介质,当计算机可读代码在电子设备的处理器中运行时,电子设备中的处理器执行上述负载均衡方法。

本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中,在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分;例如,一个物理组件可以具有多个功能,或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读存储介质上,计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。

如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备,或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令,并转发该计算机可读程序指令,以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码,编程语言包括面向对象的编程语言—诸如Smalltalk、C++等,以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中,通过利用计算机可读程序指令的状态信息来个性化定制电子电路,例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA),该电子电路可以执行计算机可读程序指令,从而实现本公开的各个方面。

这里所描述的计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,计算机程序产品具体体现为软件产品,例如软件开发包(Software Development Kit,SDK)等等。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解,流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合,都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器,从而生产出一种机器,使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时,产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中,这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作,从而,存储有指令的计算机可读介质则包括一个制造品,其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上,使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤,以产生计算机实现的过程,从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分,所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

本文已经公开了示例实施例,并且虽然采用了具体术语,但它们仅用于并仅应当被解释为一般说明性含义,并且不用于限制的目的。在一些实例中,对本领域技术人员显而易见的是,除非另外明确指出,否则可单独使用与特定实施例相结合描述的特征、特性和/或元素,或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此,本领域技术人员将理解,在不脱离由所附的权利要求阐明的本公开的范围的情况下,可进行各种形式和细节上的改变。

技术分类

06120115979336