Kubernetes集群的负载均衡的处理方法、装置及存储介质

技术领域

本发明涉及计算机软件技术领域，具体而言，涉及一种Kubernetes集群的负载均衡的处理方法、装置及存储介质。

背景技术

随着Kubernetes应用规模不断扩大，其上的各类面向终态处理资源的控制器和组件的数量和复杂性也逐渐增加，变得越来越难以理解和管理。例如，单主问题带来的控制器单点运行，会造成无法负载均衡以及无法水平扩展的问题，导致控制器的运行的效率较低。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种Kubernetes集群的负载均衡的处理方法、装置及存储介质，以至少解决由于单主问题带来的控制器单点运行，造成难以实现负载均衡的技术问题。

根据本发明实施例的一个方面，提供了一种Kubernetes集群的负载均衡的处理方法，包括：Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将所述流量配置规则发送至每个控制器对应的代理容器；通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互。

进一步地，在通过所述代理容器根据所述流量配置规则，控制API服务器与控制器之间的数据交互之前，所述方法还包括：通过所述代理容器接收所述多个控制器中至少一个控制器发送的数据请求指令；通过所述代理容器将所述数据请求指令发送至API服务器，并接收所述API服务器下发的数据。

进一步地，在通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互之前，所述方法还包括：通过所述代理容器接收API服务器触发的数据请求指令；响应所述数据请求指令，通过所述代理容器接收所述API服务器下发的数据。

进一步地，通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互包括：在所述代理容器中基于所述流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；将过滤后的数据发送至所述代理容器对应的控制器。

进一步地，通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互包括：将所述代理容器接收到的数据发送至所述代理容器对应的控制器；在所述代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许所述代理容器对应的控制器进行数据处理；若不符合，则不允许所述代理容器对应的控制器进行数据处理。

进一步地，所述流量配置规则中包括：全局限制规则和分片路由规则，将所述流量配置规则发送至每个控制器对应的代理容器之后，所述方法还包括：所述代理容器对不符合所述全局限制规则的请求进行拦截，对符合所述全局限制规则的请求发送至API服务器；和/或,所述代理容器拦截到来自API服务器的webhook请求；判断所述webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给所述代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

进一步地，所述方法还包括：在所述代理容器中设置安全防护策略，其中，所述安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

进一步地，所述方法还包括：通过所述代理容器对控制器与API服务器之间的交互信息进行监控；将监控到的信息在显示界面上进行显示。

根据本发明实施例的一个方面，提供了一种Kubernetes集群的负载均衡的处理装置，包括：第一获取单元，用于Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；第一发送单元，用于将所述流量配置规则发送至每个控制器对应的代理容器；第一控制单元，用于通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互。

进一步地，所述装置还包括：第一接收单元，用于在通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过所述代理容器接收所述多个控制器中至少一个控制器发送的数据请求指令；第二接收单元，用于通过所述代理容器将所述数据请求指令发送至API服务器，并接收所述API服务器下发的数据。

进一步地，所述装置还包括：第三接收单元，用于在通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过所述代理容器接收API服务器触发的数据请求指令；第一响应单元，用于响应所述数据请求指令，通过所述代理容器接收所述API服务器下发的数据。

进一步地，所述第一控制单元包括：第一处理模块，用于在所述代理容器中基于所述流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；第一发送模块，用于将过滤后的数据发送至所述代理容器对应的控制器。

进一步地，所述第一控制单元包括：第一接收模块，用于将所述代理容器接收到的数据发送至所述代理容器对应的控制器；第一调用模块，用于在所述代理容器对应的控制器触发数据处理时，调用所述代理容器的接口依据所述流量配置规则判断所述数据是否符合规则，若符合，则允许所述代理容器对应的控制器进行数据处理；若不符合，则不允许所述代理容器对应的控制器进行数据处理。

进一步地，所述流量配置规则中包括：全局限制规则和分片路由规则，将所述流量配置规则发送至每个控制器对应的代理容器之后，所述装置还包括：第二发送单元，用于所述代理容器对不符合所述全局限制规则的请求进行拦截，对符合所述全局限制规则的请求发送至API服务器；和/或,第一判断单元，用于所述代理容器拦截到来自API服务器的webhook请求；判断所述webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给所述代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

进一步地，所述装置还包括：第一设置单元，用于在所述代理容器中设置安全防护策略，其中，所述安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

进一步地，所述装置还包括：第一监控单元，用于通过所述代理容器对控制器与API服务器之间的交互信息进行监控；第一显示单元，用于将监控到的信息在显示界面上进行显示。

根据本发明实施例的一个方面，提供了一种存储介质，所述存储介质包括存储的程序，其中，所述程序执行上述任意一项所述的方法。

根据本发明实施例的一个方面，提供了一种设备，包括：处理器；以及存储介质，与所述处理器连接，用于为所述处理器提供处理以下处理步骤的指令：Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将所述流量配置规则发送至每个控制器对应的代理容器；通过所述代理容器根据所述流量配置规则，控制API服务器与所述控制器之间的数据交互。

在本发明实施例中，采用代理容器根据预先配置的流量配置规则控制API服务器与所述控制器之间的数据交互的方式，具体通过Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将流量配置规则发送至每个控制器对应的代理容器；通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互，达到多个控制器可以同时向API服务器请求数据，并且控制器接收到的数据符合流量配置规则中的规则，从而实现多个控制器并行运行的目的，从而实现了Kubernetes集群中控制器负载均衡的技术效果，进而解决了由于单主问题带来的控制器单点运行，造成难以实现负载均衡的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的计算机终端的硬件结构框图；

图2是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法的流程图；

图3是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法的示意图一；

图4是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法的示意图二；

图5是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法中硬限制的示意图；

图6是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法中动态限制的示意图；

图7是根据本发明实施例一提供的Kubernetes集群的负载均衡的处理方法中Webhook流量控制的示意图；

图8是根据本发明实施例二提供的Kubernetes集群的负载均衡的处理装置的示意图；以及

图9是根据本发明实施例的可选的计算机终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

Kubernetes：一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。

控制器：本申请中的控制器是指的Kubernetes中面向终态处理资源的控制器。

Webhook：Kubernetes中资源对象在向Apiserver提交创建/更新/删除请求时的Hook钩子。

Operator：Kubernetes中扩展的自定义addon组件，一般实现为控制器和Webhook。

实施例1

根据本发明实施例，提供了一种Kubernetes集群的负载均衡的处理方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现Kubernetes集群的负载均衡的处理方法的计算机终端(或移动设备)的硬件结构框图。如图1所示，计算机终端10(或移动设备10)可以包括一个或多个(图1中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端10(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本发明实施例中的Kubernetes集群的负载均衡的处理方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的Kubernetes集群的负载均衡的处理方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与计算机终端10(或移动设备)的用户界面进行交互。

在上述运行环境下，本申请提供了如图2所示的Kubernetes集群的负载均衡的处理方法。图2是根据本发明实施例一的Kubernetes集群的负载均衡的处理方法的流程图。

步骤S201，Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则。

如图3所示，在控制平面上负责管理和配置Kubernetes集群中控制器的流量配置规则，以来调整控制器接收到的路由流量或者数据。

步骤S202，将流量配置规则发送至每个控制器对应的代理容器。

该流量配置规则中包括对Kubernetes集群中多个控制器的流量配置规则，将其流量配置规则传送至各个控制器对应的代理容器。

步骤S203，通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互。

通过上述步骤，实现多个控制器可以同时向API服务器请求数据，并且控制器接收到的数据符合流量配置规则中的规则，从而实现多个控制器并行运行的目的，从而实现了Kubernetes集群中控制器负载均衡的技术效果，进而解决了由于单主问题带来的控制器单点运行，造成难以实现负载均衡的技术问题。

可选地，在本申请提供的Kubernetes集群的负载均衡的处理方法中，在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，该方法还包括：通过代理容器接收多个控制器中至少一个控制器发送的数据请求指令；通过代理容器将数据请求指令发送至API服务器，并接收API服务器返回的数据。

如图4所示，在operator中的控制器向API服务器触发数据请求指令之后，通过iptables nat机制拦截控制器发出的数据请求指令，需要说明的是，上述的数据请求指令是用于请求数据的指令，它可以用于请求数据查询、数据读写等等。将该数据请求指令转发至控制器对应的代理容器，通过代理容器将数据请求指令发送至API服务器，并接收API服务器返回的数据。在代理容器中基于流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；将过滤后的数据发送至代理容器对应的控制器。另外，在代理容器中还可以基于流量配置规则做规则路由、熔断、监控等工作，这些代理容器共同构成了一个网络，用于拦截Operator与API服务器之间的网络通信。

在将代理容器接收到的数据发送至代理容器对应的控制器之后，在代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许代理容器对应的控制器进行数据处理；若不符合，则不允许代理容器对应的控制器进行数据处理。

可选地，在本申请提供的Kubernetes集群的负载均衡的处理方法中，在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，该方法还包括：通过代理容器接收API服务器触发的数据请求指令；响应数据请求指令，通过代理容器接收API服务器请求的数据。

如图4所示，在API服务器向operator中的webhook服务器发送数据请求指令之后，通过iptables nat机制拦截API服务器发出的数据请求指令，将该数据请求指令转发至控制器对应的代理容器，通过代理容器将数据请求指令发送至对应的webhook服务器。

可选地，在本申请提供的Kubernetes集群的负载均衡的处理方法中，流量配置规则中包括：全局限制规则和分片路由规则，将流量配置规则发送至每个控制器对应的代理容器之后，该方法还包括：代理容器对不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,代理容器拦截到来自API服务器的webhook请求；判断webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给代理容器的本地webhook服务器处理；如果不符合，则转发给符合规则的实例处理。

从流量控制的维度上分为：全局限制规则，也即，所有此类operator实例都生效的限制规则，用于整体隔离和限制；分片路由规则：不同子集处理不同分片规则的资源，用于水平扩展或灰度升级。控制器的流量控制分为两种方式：第一种：硬限制，完全在代理容器侧做流量控制。例如，代理容器对控制器触发的不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,代理容器拦截到来自API服务器返回的数据，对符合全局限制规则的数据返回给控制器，不符合全局限制规则的数据则过滤掉。第二种，动态限制，通过控制器与代理容器之间交互完成工作队列请求控制。例如，判断数据处理请求是否符合当前实例的分片路由规则；如果符合，则允许控制器做处理；如果不符合，则不允许控制器处理该数据。需要说明的是，全局流量控制只能是硬限制，而分片流量控制可以选择应限制或动态限制。

如图5所示，硬限制在代理容器侧做流量控制：控制器的数据请求结果会被代理容器过滤，只返回符合规则的列表给控制器处理，同时控制器对不符合自身规则的对象做的操作，例如，获取，添加，更新、删除等操作也都会被返回。因此，可以将硬限制(Hard Limit)理解为一种类似于多租的隔离，控制器只能看到也只能操作符合自身规则的资源对象，而其他所有对象对于这个控制器来说都是不存在的。硬限制的优点包括：隔离性强，非常彻底；控制器只能拉取到符合规则的对象，也就是说控制器也只会缓存这部分对象；不需要控制修改任何代码，可以限制任意个处理命名空间维度资源的控制器。硬限制的缺点是：如果控制器要关注集群维度的资源，并根据集群维度资源处理其他命名空间维度资源，这种情况无法使用硬限制来做灰度升级和水平分片；当调整规则时，代理容器会断开对应的控制器的连接来触发控制器重启，从而重新做数据拉取和关注等操作。

如图6所示，动态限制通过代码依赖与代理容器之间交互完成工作队列请求控制。在配置了分片规则后，代理容器仍然会把所有符合全局限制规则的对象传递到控制器侧，而控制器的工作队列在入队和出队的时候调用本地控制器的接口判断这个请求是否符合当前的分片规则，如果不符合，则直接丢弃不做处理。动态限制的兼容性好，可以支持有命名空间维度、集群维度资源交互复杂操作的控制器。当调整规则时，控制器均无需重启，可以动态生效新的规则。动态限制的缺点是，控制器的本地会缓存所有符合全局限制的资源对象，内存占用相比硬限制会大，隔离不完全彻底，虽然实际处理时保证按路由规则处理，但直接查询能查到所有对象。Operator代码需要稍微改动，替换一行代码依赖即可。

另外，Webhook服务器流量控制，如图7所示，代理容器对控制器的流量控制不区分硬限制或动态限制。对于全局(Global)限制规则：代理管控会动态关注本个VirtualOperator中的配置并将过滤规则写入其中。写入后，对于不符合全局(Global)限制规则的资源对象，API服务器不会调用本Webhook处理。因为写入是异步的，有可能短时间内Operator还是会收到来自API服务器不符合规则的对象请求，此时代理容器会拦截到请求并直接返回成功给API服务器，确保不会传递到Webhook服务。

对于分片(Sharding)路由规则：代理容器拦截到来自API服务器的请求后，先判断该请求是否符合本实例的分片规则，如果符合则直接转发给本地Webhook处理，如果不符合则转发给符合规则的实例处理。另外要关注的是，Virtual Operator中需要提前定义本个Webhook的本地证书地址、监听端口、配置、服务名字等信息。

另外，在本申请提供的Kubernetes集群的负载均衡的处理方法中，还可以通过在代理侧注入故障场景，可以对一个或多个控制器实例做故障逻辑验证，从而可以模拟故障场景，以保证控制器的安全性。

可选地，在本申请提供的Kubernetes集群的负载均衡的处理方法中，该方法还包括：在代理容器中设置安全防护策略，其中，安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

上述的限流是为了防止控制器频繁请求API服务器，导致API服务器压力过大、服务不可用的情况，可以通过代理容器对控制器调用API服务器的请求做流量限制，比如每秒钟最大允许的调用次数。

上述的熔断为当API服务器发生异常时，可以通过代理容器将控制器的请求全部截断掉，避免为API服务器带来雪崩式的压力效应，有利于快速恢复API服务器。

上述的一键暂停为当控制器发生故障时，可以通过代理容器将API服务器给控制器的所有请求和返回数据均过滤掉，从而使控制器停止工作。

可选地，在本申请提供的Kubernetes集群的负载均衡的处理方法中，该方法还包括：通过代理容器对控制器与API服务器之间的交互信息进行监控；将监控到的信息在显示界面上进行显示。

代理容器监测到的数据可以分为外层监控和注入监控，通过代理容器外层对Operator与API服务器之间的调用跟踪，统计性能、延迟、流量、错误等服务请求类指标。如果Operator替换了代码依赖，还会采集到控制器与Webhook内部的逻辑相关指标，比如队列堆积、处理性能变化、内存消耗跟踪、工作运行状况等，以上指标都可以作为监控到的信息，在显示界面上进行显示，从而提升用户获取有效信息的速度。另外，用户还可以配置Prometheus服务器的采集以满足各自的监控需求。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述Kubernetes集群的负载均衡的处理的装置，如图8所示，该装置包括：第一获取单元301、第一发送单元302、第一控制单元303。

具体的，第一获取单元301，用于Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；

第一发送单元302，用于将流量配置规则发送至每个控制器对应的代理容器；

第一控制单元303，用于通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，该装置还包括：第一接收单元，用于在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收多个控制器中至少一个控制器发送的数据请求指令；第二接收单元，用于通过代理容器将数据请求指令发送至API服务器，并接收API服务器下发的数据。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，该装置还包括：第三接收单元，用于在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收API服务器触发的数据请求指令；第一响应单元，用于响应数据请求指令，通过代理容器接收API服务器下发的数据。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，第一控制单元303包括：第一处理模块，用于在代理容器中基于流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；第一发送模块，用于将过滤后的数据发送至代理容器对应的控制器。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，第一控制单元303包括：第一接收模块，用于将代理容器接收到的数据发送至代理容器对应的控制器；第一调用模块，用于在代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许代理容器对应的控制器进行数据处理；若不符合，则不允许代理容器对应的控制器进行数据处理。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，流量配置规则中包括：全局限制规则和分片路由规则，将流量配置规则发送至每个控制器对应的代理容器之后，该装置还包括：第二发送单元，用于代理容器对不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,第一判断单元，用于代理容器拦截到来自API服务器的webhook请求；判断webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，该装置还包括：第一设置单元，用于在代理容器中设置安全防护策略，其中，安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

可选地，在本申请实施例二提供的Kubernetes集群的负载均衡的处理装置中，该装置还包括：第一监控单元，用于通过代理容器对控制器与API服务器之间的交互信息进行监控；第一显示单元，用于将监控到的信息在显示界面上进行显示。

此处需要说明的是，上述的第一获取单元301、第一发送单元302、第一控制单元303对应于实施例1中的步骤S201至步骤S203，三个单元与对应的步骤所实现的实例和应用场景相同，但不限于上述实施例一所公开的内容。需要说明的是，上述单元模块作为装置的一部分可以运行在实施例一提供的计算机终端10中。

实施例3

本发明的实施例可以提供一种计算机终端，该计算机终端可以是计算机终端群中的任意一个计算机终端设备。可选地，在本实施例中，上述计算机终端也可以替换为移动终端等终端设备。

可选地，在本实施例中，上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。

在本实施例中，上述计算机终端可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将流量配置规则发送至每个控制器对应的代理容器；通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收多个控制器中至少一个控制器发送的数据请求指令；通过代理容器将数据请求指令发送至API服务器，并接收API服务器下发的数据。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收API服务器触发的数据请求指令；响应数据请求指令，通过代理容器接收API服务器下发的数据。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：在代理容器中基于流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；将过滤后的数据发送至代理容器对应的控制器。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：将代理容器接收到的数据发送至代理容器对应的控制器；在代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许代理容器对应的控制器进行数据处理；若不符合，则不允许代理容器对应的控制器进行数据处理。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：全局限制规则和分片路由规则，将流量配置规则发送至每个控制器对应的代理容器之后，该方法还包括：代理容器对不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,代理容器拦截到来自API服务器的webhook请求；判断webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：在代理容器中设置安全防护策略，其中，安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

上述计算机终端还可以执行应用程序的Kubernetes集群的负载均衡的处理方法中以下步骤的程序代码：通过代理容器对控制器与API服务器之间的交互信息进行监控；将监控到的信息在显示界面上进行显示。

可选地，图9是根据本发明实施例的一种计算机终端的结构框图。如图9所示，该计算机终端可以包括：一个或多个(图9中仅示出一个)处理器、存储器。

其中，存储器可用于存储软件程序以及模块，如本发明实施例中的Kubernetes集群的负载均衡的处理方法和装置对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的Kubernetes集群的负载均衡的处理方法。存储器可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器可以通过传输装置调用存储器存储的信息及应用程序，以执行下述步骤：Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将流量配置规则发送至每个控制器对应的代理容器；通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互。

可选的，上述处理器还可以执行如下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收多个控制器中至少一个控制器发送的数据请求指令；通过代理容器将数据请求指令发送至API服务器，并接收API服务器下发的数据。

可选的，上述处理器还可以执行如下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收API服务器触发的数据请求指令；响应数据请求指令，通过代理容器接收API服务器下发的数据。

可选的，上述处理器还可以执行如下步骤的程序代码：在代理容器中基于流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；将过滤后的数据发送至代理容器对应的控制器。

可选的，上述处理器还可以执行如下步骤的程序代码：将代理容器接收到的数据发送至代理容器对应的控制器；在代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许代理容器对应的控制器进行数据处理；若不符合，则不允许代理容器对应的控制器进行数据处理。

可选的，上述处理器还可以执行如下步骤的程序代码：全局限制规则和分片路由规则，将流量配置规则发送至每个控制器对应的代理容器之后，代理容器对不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,代理容器拦截到来自API服务器的webhook请求；判断webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

可选的，上述处理器还可以执行如下步骤的程序代码：在代理容器中设置安全防护策略，其中，安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

可选的，上述处理器还可以执行如下步骤的程序代码：通过代理容器对控制器与API服务器之间的交互信息进行监控；将监控到的信息在显示界面上进行显示。

采用本发明实施例，提供了一种Kubernetes集群的负载均衡的处理方法的方案。通过采用代理容器根据预先配置的流量配置规则控制API服务器与所述控制器之间的数据交互的方式，具体通过Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将流量配置规则发送至每个控制器对应的代理容器；通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互，达到多个控制器可以同时向API服务器请求数据，同时控制器接收到的数据符合流量配置规则中的规则，从而实现多个控制器并行运行的目的，从而实现了Kubernetes集群中控制器负载均衡的技术效果，进而解决了由于单主问题带来的控制器单点运行，造成难以实现负载均衡的技术问题。

本领域普通技术人员可以理解，图9所示的结构仅为示意，计算机终端也可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌声电脑以及移动互联网设备(MobileInternet Devices，MID)、PAD等终端设备。图9其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图9中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图9所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的Kubernetes集群的负载均衡的处理方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：Kubernetes集群的中心管控组件获取对所述Kubernetes集群中控制器的流量配置规则；将流量配置规则发送至每个控制器对应的代理容器；通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：上述处理器还可以执行如下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收多个控制器中至少一个控制器发送的数据请求指令；通过代理容器将数据请求指令发送至API服务器，并接收API服务器下发的数据。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：在通过代理容器根据流量配置规则，控制API服务器与所述控制器之间的数据交互之前，通过代理容器接收API服务器触发的数据请求指令；响应数据请求指令，通过代理容器接收API服务器下发的数据。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：在代理容器中基于流量配置规则对接收到的数据进行过滤处理，得到过滤后的数据；将过滤后的数据发送至代理容器对应的控制器。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：将代理容器接收到的数据发送至代理容器对应的控制器；在代理容器对应的控制器触发数据处理时，调用所述代理容器的接口判断所述数据是否符合流量配置规则，若符合，则允许代理容器对应的控制器进行数据处理；若不符合，则不允许代理容器对应的控制器进行数据处理。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：全局限制规则和分片路由规则，将流量配置规则发送至每个控制器对应的代理容器之后，代理容器对不符合全局限制规则的请求进行拦截，对符合全局限制规则的请求发送至API服务器；和/或,代理容器拦截到来自API服务器的webhook请求；判断webhook请求是否符合当前实例的分片路由规则；如果符合，则转发给代理容器的本地Webhook处理；如果不符合，则转发给符合规则的实例处理。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：在代理容器中设置安全防护策略，其中，安全防护策略中包括以下至少之一：限流、熔断、一键暂停。

可选地，在本实施例中，存储介质被设置为存储还用于执行以下步骤的程序代码：通过代理容器对控制器与API服务器之间的交互信息进行监控；将监控到的信息在显示界面上进行显示。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。