CN115412549A - 信息配置方法、装置及请求处理方法、装置 - Google Patents

Abstract

本发明实施例提供了信息配置方法、装置，应用于信息处理技术领域。该方法应用于Kubernetes集群中的路由控制器，该方法包括：获取针对Kubernetes集群所提供业务的配置信息；其中，配置信息至少包括业务的路由规则信息；确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，目标客户为Kubernetes集群所属的客户，目标负载均衡器用于实现目标客户的各Kubernetes集群的路由服务；将所述路由规则信息作为所述目标负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所述目标负载均衡器。通过本方案，可以降低用户的资源成本，同时也降低了Kubernetes集群的管理成本并提高了路由服务访问的性能和安全性。

Description

信息配置方法、装置及请求处理方法、装置

技术领域

本发明涉及信息处理技术领域，特别是涉及信息配置方法、装置及请求处理方法、装置。

背景技术

Kubernetes集群是一种开源容器集群管理系统，用于自动部署、扩展和管理容器化的应用。如图1所示，为Kubernetes集群的结构示意图，其中，Kubernetes集群包含控制面和若干个工作节点，控制面包括多种控制器(Controller)和APIServer等，，每个工作节点中上运行一个或者多个pod，其中，每一pod表示一组正在运行的容器化应用。

对于Kubernetes集群而言，Kubernetes集群提供的每一项业务由工作节点中一组pod实现，其中，该一组pod可以为同一个工作节点中多个pod，也可以为不同工作节点中的多个pod。而Kubernetes集群的Ingress(路由规则)功能是针对访问业务的外部请求进行管理的功能。

相关技术中，Kubernetes集群中的每一个Ingress服务，均需要通过路由控制器来配置至少一个负载均衡器，以由该至少一个负载均衡器实现Ingress功能。但是，针对同一客户拥有多个Ingress服务的情况，则需要配置大量的负载均衡器，这样无疑造成资源的浪费。

发明内容

本发明实施例的目的在于提供信息配置方法及装置，以降低用户的资源成本。另外，本发明实施例还提供了请求处理方法及装置，以实现针对用于访问Kubernetes集群所提供业务的外部请求的路由。具体技术方案如下：

第一方面，本发明实施例提供一种信息配置方法，应用于Kubernetes集群中的路由控制器，所述方法包括：

获取针对所述Kubernetes集群所提供业务的配置信息；其中，所述配置信息至少包括所述业务的路由规则信息；

确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，所述目标客户为所述Kubernetes集群所属的客户，所述目标负载均衡器为用于实现所述目标客户的各Kubernetes集群的路由服务的负载均衡器；

将所述路由规则信息作为所述目标负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所述目标负载均衡器。

在一实施例中，所述确定位于预定云服务端中的属于目标客户的目标负载均衡器，包括：

检测所述预定云服务端中是否已创建有属于所述目标客户的目标负载均衡器；

若已创建，确定出属于所述目标客户的目标负载均衡器；

若未创建，在所述预定云服务端中创建属于所述目标用户的目标负载均衡器。

在一实施例中，所述配置信息还包括：第一辅助信息；其中，所述第一辅助信息用于表征所述业务是否使用已存在的负载均衡器进行路由服务；

在所述确定位于预定云服务端中的属于目标客户的目标负载均衡器之前，还包括：

检测所述第一辅助信息是否表征所述业务使用已存在的负载均衡器进行路由服务；

若所述第一辅助信息表征所述业务使用已存在的负载均衡器进行路由服务，则执行所述确定位于预定云服务端中的属于目标客户的目标负载均衡器的步骤。

在一实施例中，所述方法还包括：

若所述第一辅助信息表征所述业务不使用已存在的负载均衡器进行路由服务，则在所述预定云服务端中创建负载均衡器；其中，所创建的负载均衡器为属于所述目标客户的、仅对所述Kubernetes集群的各业务进行路由服务的负载均衡器；

将所述路由规则信息作为所创建的负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所创建的负载均衡器。

在一实施例中，所述配置信息还包括：第二辅助信息；其中，所述第二辅助信息为：对所述业务所利用的负载均衡器的公网IP所配置的网络限流信息；

所述方法还包括：

确定所述目标负载均衡器的公网IP；其中，所述目标负载均衡器的公网IP为：在所述目标负载均衡器被创建好后，所述预定云服务端为所述目标负载均衡器所分配的；

若检测到所确定的公网IP的网络限流信息为空，则使用默认值设置所述目标负载均衡器的公网IP的网络限流信息；

若所述第二辅助信息存在时，利用所述第二辅助信息，设置所述目标负载均衡器的公网IP的网络限流信息。

在一实施例中，所述网络限流信息包括：允许的访问带宽和/或计费类型。

第二方面，本发明实施例还提供一种请求处理方法，应用于预定云服务端中的任一负载均衡器；所述负载均衡器中按照第一方面任一项方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，所述至少一个Kubernetes集群属于同一目标客户；所述方法包括：

接收访问端发送的目标访问请求；其中，所述访问请求中携带有待访问业务的业务信息；所述目标访问请求为：所述访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；所述待访问业务为所述至少一个Kubernetes集群提供的各业务中的任一业务；

基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求。

在一实施例中，所述路由规则信息包括：关于每一业务的业务信息和该业务所部属于的工作节点组的第一对应关系；

所述基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求，包括：

基于所述第一对应关系，确定与所述待访问业务的业务信息对应的目标工作节点组；

按照负载均衡原则，从所述目标工作节点组中选择待利用工作节点；

将所述目标访问请求发送至所述待利用工作节点。

在一实施例中，所述路由规则信息包括：关于每一业务的业务信息和该业务所部署于的pod组第二对应关系；

所述基于所述路由规则信息，按照负载均衡原则，将所述目标访问请求进行转发，包括：

基于所述第二对应关系，确定与所述待访问业务的业务信息对应的目标pod组；

按照负载均衡原则，从所述目标pod组中选择待利用pod；

将所述目标访问请求转发至所述待利用pod。

第三方面，本发明实施例还提供一种信息配置装置，应用于Kubernetes集群中的路由控制器，所述装置包括：

信息获取模块，用于获取针对所述Kubernetes集群所提供业务的配置信息；其中，所述配置信息至少包括所述业务的路由规则信息；

均衡器确定模块，用于确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，所述目标客户为所述Kubernetes集群所属的客户，所述目标负载均衡器为用于实现所述目标客户的各Kubernetes集群的路由服务的负载均衡器；

信息配置模块，用于将所述路由规则信息作为所述目标负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所述目标负载均衡器。

在一实施例中，所述均衡器确定模块，具体用于检测所述预定云服务端中是否已创建有属于所述目标客户的目标负载均衡器；若已创建，确定出属于所述目标客户的目标负载均衡器；若未创建，在所述预定云服务端中创建属于所述目标用户的目标负载均衡器。

在一实施例中，所述配置信息还包括：第一辅助信息；其中，所述第一辅助信息用于表征所述业务是否使用已存在的负载均衡器进行路由服务；

所述装置还包括：

信息检测模块，用于在所述均衡器确定模块执行所述确定位于预定云服务端中的属于目标客户的目标负载均衡器之前，检测所述第一辅助信息是否表征所述业务使用已存在的负载均衡器进行路由服务；若所述第一辅助信息表征所述业务使用已存在的负载均衡器进行路由服务，则调用所述均衡器确定模块执行所述确定位于预定云服务端中的属于目标客户的目标负载均衡器的步骤。

在一实施例中，所述装置还包括：

均衡器创建模块，用于若所述第一辅助信息表征所述业务不使用已存在的负载均衡器进行路由服务，则在所述预定云服务端中创建负载均衡器；其中，所创建的负载均衡器为属于所述目标客户的、仅对所述Kubernetes集群的各业务进行路由服务的负载均衡器；将所述路由规则信息作为所创建的负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所创建的负载均衡器。

在一实施例中，所述配置信息还包括：第二辅助信息；其中，所述第二辅助信息为：对所述业务所利用的负载均衡器的公网IP所配置的网络限流信息；

所述装置还包括：

IP确定模块，用于确定所述目标负载均衡器的公网IP；其中，所述目标负载均衡器的公网IP为：在所述目标负载均衡器被创建好后，所述预定云服务端为所述目标负载均衡器所分配的；若检测到所确定的公网IP的网络限流信息为空或与所述第二辅助信息不一致时，利用所述第二辅助信息，设置所述目标负载均衡器的公网IP的网络限流信息。

在一实施例中，所述网络限流信息包括：允许的访问带宽和/或计费类型。

第四方面，本发明实施例还提供一种请求处理装置，应用于预定云服务端中的任一负载均衡器；所述负载均衡器中按照第一方面任一项方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，所述至少一个Kubernetes集群属于同一目标客户；所述装置包括：

请求接收模块，用于接收访问端发送的目标访问请求；其中，所述访问请求中携带有待访问业务的业务信息；所述目标访问请求为：所述访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；所述待访问业务为所述至少一个Kubernetes集群提供的各业务中的任一业务；

请求转发模块，用于基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求。

在一实施例中，所述路由规则信息包括：关于每一业务的业务信息和该业务所部属于的工作节点组的第一对应关系；

所述请求转发模块，具体用于基于所述第一对应关系，确定与所述待访问业务的业务信息对应的目标工作节点组；按照负载均衡原则，从所述目标工作节点组中选择待利用工作节点；将所述目标访问请求发送至所述待利用工作节点。

在一实施例中，所述路由规则信息包括：关于每一业务的业务信息和该业务所部署于的pod组第二对应关系；

所述请求转发模块，具体用于基于所述第二对应关系，确定与所述待访问业务的业务信息对应的目标pod组；按照负载均衡原则，从所述目标pod组中选择待利用pod；将所述目标访问请求转发至所述待利用pod。

第五方面，本发明实施例还提供一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现第一方面任一所述的方法步骤，或者，第二方面任一项所述的方法步骤。

第六方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现第一方面任一项所述的方法步骤，或者，第二方面任一项所述的方法步骤。

本发明实施例有益效果：

本发明实施例所提供的信息配置方法中，目标客户部署的Kubernetes集群中的路由控制器可以获取针对该Kubernetes集群所提供业务的配置信息，并确定位于预定云服务端中的属于该目标客户的目标负载均衡器，进而将配置信息中包含的上述业务的路由规则信息配置于目标负载均衡器中。由于上述目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将上述业务的路由规则信息配置于目标负载均衡器中，可以使上述Kubernetes集群的路由服务通过该目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置单独的负载均衡器即可实现路由服务。针对同一客户需要在同一Kubernetes集群中部署多个路由服务，或者部署多个Kubernetes集群的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者不同Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

在上述信息配置方法的基础上，本发明实施例还提供了应用于预定云服务端中的任一负载均衡器的请求处理方法。通过该请求处理方法，可以实现针对用于访问Kubernetes集群所提供业务的外部请求的路由。

当然，实施本发明的任一产品或方法并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。

图1为Kubernetes集群的结构示意图；

图2为Kubernetes集群中通过Ingress功能处理外部请求的示意图；

图3为本发明实施例提供的应用于Kubernetes集群中的路由控制器的信息配置方法的流程图；

图4为本发明实施例提供的应用于Kubernetes集群中的路由控制器的信息配置方法的另一流程图；

图5为本发明实施例提供的应用于Kubernetes集群中的路由控制器的信息配置方法的另一流程图；

图6为本发明实施例提供的预定云服务端和Kubernetes集群连接关系示意图

图7为本发明实施例提供的应用于预定云服务端中的任一负载均衡器的请求处理方法的流程图；

图8为本发明实施例提供的请求处理流程示意图；

图9为本发明实施例提供的应用于Kubernetes集群中的路由控制器的信息配置装置的结构示意图；

图10为本发明实施例提供的应用于预定云服务端中的任一负载均衡器的请求处理装置的结构示意图；

图11为本发明实施例所提供的电子设备的结构示意图。

具体实施方式

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

为了更清楚地阐述本发明实施例所提供的技术方案，对Kubernetes集群的Ingress功能进一步的进行介绍。

示例性的，如图2，为Kubernetes集群中通过Ingress功能处理外部请求的示意图。Kubernetes集群的Ingress功能将来自访问端的HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求/HTTPS(Hyper Text Transfer Protocol over SecureSocket Layer，安全超文本传输协议)请求转发到该请求所针对业务的pod上，进而由该pod处理该请求。

Kubernetes集群的Ingress功能主要依赖负载均衡器实现，示例性的，负载均衡器的可以为：nginx、traefik、haproxy等，其中，nginx为高性能的HTTP和反向代理服务器，traefik为http反向代理和负载均衡软件，haproxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理。相关技术中，针对每一个Kubernetes集群而言，均需要为该Kubernetes集群配置至少一个负载均衡器，以实现该Kubernetes集群的Ingress功能。从而针对同一客户需要部署多个Kubernetes集群的情况，则需要配置大量的负载均衡器，这样无疑造成对于Kubernetes集群的管理成本较高。

为了解决相关技术所存在的技术问题，即为了降低Kubernetes集群的管理成本，本发明实施例提供了信息配置方法及装置。

下面首先从Kubernetes集群中的路由控制器的角度，对本发明实施例所提供的一种信息配置方法进行介绍。

需要说明的是，如图1所示，Kubernetes集群中的路由控制器(图中所示的控制器)是客户在部署Kubernetes集群时即已部署完成的。Kubernetes集群部署完成后，其包含的路由控制器可以通过APIServer监听Kubernetes集群中资源的变化情况。其中，上述所指的Kubernetes集群中资源为Kubernetes集群中Ingress(路由规则)、service(服务)、secret(秘密)、endpoint(端点)以及node等资源。

当客户需要Kubernetes集群对外提供指定业务时，其需要为Kubernetes集群中该业务配置提供路由服务的负载均衡器。可选的，可以通过YAML文件记录所要配置的负载均衡器的配置信息，并且，通过YAML文件来进行创建Ingress对象。当Kubernetes集群中的路由控制器通过APIServer接口监听到新的Ingress对象生成时，以获取Ingress对象的配置信息，进而基于所获取的配置信息为指定业务配置提供路由服务的负载均衡器。

本发明实施例所应用的Kubernetes集群中的路由控制器可以是服务器等具有数据处理能力的设备。并且，本发明实施例提供的信息配置方法可以通过软件、硬件或软硬件结合的方式实现。

为了降低Kubernetes集群的管理成本，本发明实施例提供了一种信息配置方法，包括：

获取针对Kubernetes集群所提供业务的配置信息；其中，配置信息至少包括业务的路由规则信息；

确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，目标客户为Kubernetes集群所属的客户，目标负载均衡器用于实现目标客户的各Kubernetes集群的路由服务；

将路由规则信息作为目标负载均衡器的待配置信息发送至预定云服务端，以使预定云服务端将路由规则信息配置于目标负载均衡器。

本实施例所提供方案中，由于目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将业务的路由规则信息配置于目标负载均衡器中，可以使Kubernetes集群的路由服务通过目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置新的负载均衡器即可实现路由服务。针对同一客户需要部署多个Kubernetes集群的情况、以及同一Kubernetes集群中部署多个路由服务的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者跨Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

如图3所示，本发明实施例提供的一种信息配置方法，应用于Kubernetes集群中的路由控制器，可以包括如下步骤：

S301，获取针对Kubernetes集群所提供业务的配置信息；其中，配置信息至少包括业务的路由规则信息；

上述配置信息为：对为Kubernetes集群所提供业务提供路由服务的负载均衡器进行配置的信息。该配置信息至少包括业务的路由规则信息。上述Kubernetes集群所提供的业务可以为访问验证、信息处理、数据传输等网络业务，任一业务可以为实现特定功能的程序。

其中，业务的路由规则信息指示对访问业务的请求进行转发的路由规则。在Kubernetes集群中，Kubernetes集群所提供的各业务对负载均衡器存在两种暴露业务的方式，一种方式为pod直通，另一种方式为pod非直通。对于pod直通而言，负载均衡器与实现业务的pod直接连接。而对非pod直通而言，负载均衡器与实现业务的pod不直接连接，而是与pod所在的集群的节点(包括工作节点和控制节点)所在的工作节点组连接。暴露业务的方式不同则意味着其对应的路由规则信息不同，对于pod直通而言，路由规则信息指示将请求直接转发至实现业务的pod上，而对于非pod直通而言，路由规则信息则指示将请求转发至集群的工作节点组上，再由工作节点组转发至实现业务的pod上。

示例性的，Kubernetes集群对外提供业务1，该业务通1过工作节点1中的pod1和pod2实现。若负载均衡器与pod直通，则路由规则信息可以包括业务1的业务信息、该业务1所部署于的pod组的对应关系。若负载均衡器与pod非直通，则路由规则信息可以包括业务1的业务信息、该业务1所部属于的工作节点组的对应关系。另外，示例性的，任一业务的业务信息可以包括：该业务对应的用于访问的域名和业务路径，该业务路径该可以是该业务的业务标识，当然并不局限于此。

S302，确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，目标客户为Kubernetes集群所属的客户，目标负载均衡器用于实现目标客户的各Kubernetes集群的路由服务；

其中，预定云服务端可以为云厂商所提供的云服务端。不同的客户在预定云服务端中可以配置不同的负载均衡器。对于Kubernetes集群所属的目标客户而言，可以确定预定云服务端中属于该目标客户的目标负载均衡器，以通过该目标负载均衡器实现目标客户的各Kubernetes集群的路由服务。

举例而言，预定云服务端中包含客户1的目标负载均衡1、客户2的目标负载均衡器2。当客户2需要部署新的Kubernetes集群或使用已有Kubernetes集群提供新的业务时，其需要负载均衡器实现该新的Kubernetes集群或新的业务的路由服务，此时，可以从预定云服务端中确定目标负载均衡器2。

S303，将路由规则信息作为目标负载均衡器的待配置信息发送至预定云服务端，以使预定云服务端将路由规则信息配置于目标负载均衡器。

其中，路由控制器可以通过该预定服务端提供的配置接口，将该路由规则信息作为该目标负载均衡器的待配置信息发送给预定云服务端，以使得预定云服务端将接收到的该路由规则信息配置于该目标负载均衡器。其中，将路由规则信息配置于目标负载均衡器中可以采用与现有的在负载均衡器中配置路由规则信息的技术手段相同方式，将上路由规则信息配置于目标负载均衡器中。例如，可以基于该路由规则信息，在目标负载均衡器生成监听器。由于与现有技术相同，本发明实施例在此不再赘述。

本实施例所提供方案中，由于目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将业务的路由规则信息配置于目标负载均衡器中，可以使Kubernetes集群的路由服务通过目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置新的负载均衡器即可实现路由服务。针对同一客户需要在同一Kubernetes集群中部署多个路由服务，或者部署多个Kubernetes集群的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者不同Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

基于图3的实施例，如图4所示，本发明的另一实施例所提供的信息配置方法，上述的S302可以包括如下步骤：

S3021，检测预定云服务端中是否已创建有属于目标客户的目标负载均衡器；

其中，可以通过预定云服务端所提供的查询接口，查询预定云服务端中是否已创建有属于目标客户的目标负载均衡器。可选的，通过该查询接口，向预定云服务端发送目标客户的目标负载均衡器的查询请求，并接收预定云服务端反馈的指示预定云服务端中是否已创建有属于目标客户的目标负载均衡器的查询结果。上述查询接口可以为负载均衡器的Get接口。

可选的，在一种实现方式中，可以将目标客户在预定云服务端中的负载均衡器均认为是目标负载均衡器。示例性的，若在预定云服务端中检测到属于目标客户的2台负载均衡器：负载均衡器1和负载均衡器2，则可判定预定云服务端中是已创建有属于目标客户的目标负载均衡器。反之，在预定云服务端未检测到属于目标客户的负载均衡器，则判定预定云服务端中是未创建有属于目标客户的目标负载均衡器。

可选的，在另一种实现方式中，目标客户在预定云服务端中可以包含多种类型的负载均衡器。例如只为单一业务提供路由服务的负载均衡器和可同时为属于目标客户的多个业务提供路由服务的负载均衡器。此时，不同的类型负载均衡器对应关联不同的类型标识，如对于可同时为属于目标客户的多个业务提供路由服务的负载均衡器对应关联共享标识，而对于只为单一业务提供路由服务的负载均衡器而言，则可以对应关联独立标识，或，预先约定类型标识为空的负载均衡器为单一业务提供路由服务。当需要检测预定云服务端中是否已创建有属于目标客户的目标负载均衡器时，可以通过检测共享标识的方式，判断预定云服务端中是否已创建有属于目标客户的目标负载均衡器。例如，预定云服务端中存在对应关联共享标识的负载均衡器，则判定预定云服务端中已存在属于目标客户的目标负载均衡器。反之，预定云服务端中不存在对应关联共享标识的负载均衡器，则判定预定云服务端中未存在属于目标客户的目标负载均衡器。

可选的，若预定云服务端中已创建有属于目标客户的目标负载均衡器，则执行步骤S3022。若预定云服务端中未创建有属于目标客户的目标负载均衡器，则执行步骤S3023。

S3022，确定出属于目标客户的目标负载均衡器；

其中，在预定云服务端中已创建有属于目标客户的目标负载均衡器时，可以直接确定出该目标负载均衡器。

可选的，在一种实现方式中，在预定云服务端返回的查询结果中还可以包括属于目标客户的负载均衡器的负载均衡器标识，则可以将该负载均衡器标识所指示的负载均衡器确定为属于目标客户的目标负载均衡器。

S3023，在预定云服务端中创建属于目标用户的目标负载均衡器。

在预定云服务端中未创建有属于目标客户的目标负载均衡器时，则需要在预定云服务端中创建属于目标用户的目标负载均衡器。可选的，在一种实现方式中，可以调用预定云服务端所提供的针对负载均衡器的创建接口，在预定云服务端中创建属于目标用户的目标负载均衡器。

本实施例所提供方案中，仅在预定云服务端中未创建属于目标客户的目标负载均衡器，才在预定云服务端中创建属于目标用户的目标负载均衡器。而若预定云服务端中存在已创建的属于目标客户的目标负载均衡器时，则可以直接确定出该目标负载均衡器，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

可选的，在一种实施例中，上述配置信息还包括：第一辅助信息；其中，第一辅助信息用于表征业务是否使用已存在的负载均衡器进行路由服务。

针对客户不同的需求，可以通过第一辅助信息配置业务是否使用已存在的负载均衡器进行路由服务。其中，第一辅助信息可以为预先约定的用于表征业务是否使用已存在的负载均衡器进行路由服务的参数。举例而言，若第一辅助信息为共享参数，则表征业务使用已存在的负载均衡器进行路由服务，若第一辅助信息为独立参数，则表征业务不适用已存在的负载均衡器进行路由服务。其中，共享参数和独立参数是不同两个参数，或一个为空一个未非空，这都是可以的。

举例而言，第一辅助信息记录为kubernetes.io/ingress.exist-lb-id，若该参数为非空，则表征业务使用已存在的负载均衡器进行路由服务，若该参数为空，则表征业务使用不存在的负载均衡器进行路由服务。

此时，基于图3的实施例，如图5所示，本发明的另一实施例所提供的信息配置方法，在上述S302之前，还包括：

S304，检测第一辅助信息是否表征业务使用已存在的负载均衡器进行路由服务。

其中，由前述内容可知，可以根据预先约定的第一辅助信息与是否使用已存在的负载均衡器进行路由服务的对应关系，检测第一辅助信息是否表征业务使用已存在的负载均衡器进行路由服务。

举例而言，第一辅助信息记录为kubernetes.io/ingress.exist-lb-id，若检测到kubernetes.io/ingress.exist-lb-id为非空，则判定业务使用已存在的负载均衡器进行路由服务。反之，若检测到kubernetes.io/ingress.exist-lb-id为空，则判定业务不使用已存在的负载均衡器进行路由服务。

若第一辅助信息表征业务使用已存在的负载均衡器进行路由服务，则执行确定位于预定云服务端中的属于目标客户的目标负载均衡器的步骤，即执行上述步骤S302。

若第一辅助信息表征业务不使用已存在的负载均衡器进行路由服务，则需要生成新的负载均衡器，此时，可以执行步骤S305。

S305，在预定云服务端中创建负载均衡器；其中，所创建的负载均衡器为属于目标客户的、仅对Kubernetes集群的各业务进行路由服务的负载均衡器。

其中，可以在预定云服务端中创建类型为独立类型的负载均衡器。其具体创建方式与创建目标负载均衡器相似，即创建独立类型的监听器，具体过程不再赘述。

S306，将路由规则信息作为所创建负载均衡器的待配置信息发送至预定云服务端，以使预定云服务端将路由规则信息配置于所创建的负载均衡器。

与步骤S303相同或相似，在此不再赘述。

本实施例所提供方案中，由于上述目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将上述业务的路由规则信息配置于目标负载均衡器中，可以使上述Kubernetes集群的路由服务通过该目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置单独的负载均衡器即可实现路由服务。针对同一客户需要在同一Kubernetes集群中部署多个路由服务，或者部署多个Kubernetes集群的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者不同Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

可选的，在一种实施例中，上述配置信息还包括：第二辅助信息；其中，第二辅助信息为：对业务所利用的负载均衡器的公网IP所配置的网络限流信息。

上述网络限流信息可以包括所利用的负载均衡器的公网IP的允许的访问带宽和/或计费类型等信息。

此时，在本发明的另一实施例中，信息配置方法还包括：

确定目标负载均衡器的公网IP；其中，目标负载均衡器的公网IP为：在目标负载均衡器被创建好后，预定云服务端为目标负载均衡器所分配的；

若检测到第二辅助信息为空，则使用默认值设置所述目标负载均衡器的公网IP的网络限流信息；

若第二辅助信息存在时，利用第二辅助信息，设置目标负载均衡器的公网IP的网络限流信息。

其中，默认值可以为默认的网络限流值。

上述目标负载均衡器的公网IP可以为预定云服务端所分配的。举例而言，如36.7.72.139。

可选的，所确定的公网IP的网络限流信息为空或与第二辅助信息不一致，则说明目标负载均衡器可能为新建的，或修改的。则需要根据配置信息中的第二辅助信息，利用第二辅助信息，设置目标负载均衡器的公网IP的网络限流信息。

举例而言，配置信息中该目标负载均衡器的公网IP的网络限流信息为：允许的访问带宽为100M，计费类型为按流量计费。若检测到目标负载均衡器的公网IP的网络限流信息与配置信息不符，则将目标负载均衡器的公网IP访问带宽设置为100M，计费类型为按流量计费。

预定云服务端可以通过为该公网IP设置的网络限流信息，来实现对具有该公网IP的负载均衡器进行网络限流处理。

本实施例所提供方案中，由于上述目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将上述业务的路由规则信息配置于目标负载均衡器中，可以使上述Kubernetes集群的路由服务通过该目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置单独的负载均衡器即可实现路由服务。针对同一客户需要在同一Kubernetes集群中部署多个路由服务，或者部署多个Kubernetes集群的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者不同Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

进一步的，通过为负载均衡器配置网络限流信息，预定云服务端可以通过为该公网IP设置的网络限流信息，来实现对具有该公网IP的负载均衡器进行网络限流处理，从而可以充分利用预定云服务端流量管控等优势功能，增强了对负载均衡器的管理能力。

为了更清楚的阐述本发明实施例的技术方案，下面结合示例进一步的对本发明实施例进行说明。

可选的，在一个实施例中，上述配置信息可以通过YAML文件实现，可选的，所配置的YAML文件中代码如下：

apiVersion:extensions/v1beta1

kind:Ingress

metadata:

annotations:

kubernetes.io/ingress.class:ksyun

kubernetes.io/ingress.eip-bandwidth-in-mbps:"25"

kubernetes.io/ingress.eip-charge-type:PostPaidByPeak

kubernetes.io/ingress.exist-lb-id:cf77de3a-2742-4f90-91de-0ff83a5b6c48

kubernetes.io/ingress.http-rules:'[{"host":"test111.com","path":"/","backend":{"serviceName":"nginx-1",

"servicePort":"80"}},{"host":"test222.com","path":"/","backend":{"serviceName":"nginx-1","servicePort":

"80"}}]'

kubernetes.io/ingress.https-rules:'[{"host":"test111.com","path":"/","backend":{"serviceName":"nginx-1",

"servicePort":"80"}}]'

kubernetes.io/ingress.public:"false"

name:ingress001

namespace:default

spec:

rules:

-host:test111.com

http:

paths:

-backend:

serviceName:nginx

servicePort:80

path:/

-host:test222.com

http:

paths:

-backend:

serviceName:tomcat

servicePort:80

path:/

本发明实施例所指第一辅助信息可以包括上述kubernetes.io/ingre ss.exist-lb-id参数，若检测到kubernetes.io/ingress.exist-lb-id为非空，则判定业务使用已存在的负载均衡器进行路由服务。反之，若检测到kubernetes.io/ingre ss.exist-lb-id为空，则判定业务不使用已存在的负载均衡器进行路由服务。

本发明实施例所指第二辅助信息可以包括上述kubernetes.io/ingre ss.eip-bandwidth-in-mbp参数和kubernetes.io/in gress.eip-charge-type参数。其中kubernetes.io/ingre ss.eip-bandwidth-in-mbp参数用于设置负载均衡器的可允许带宽。上述kubernetes.io/ingress.eip-charge-type参数用于设置负载均衡器公网带宽的计费类型。

可选的，配置信息中还可以包括kubernetes.io/ingress.http-rules:参数和kubernetes.io/ingress.https-rules:参数参数，用于区分访问请的访问类型是HTTP还是HTTPS，也支持两种访问类型并存。

如图6所述，为本发明实施例提供的预定云服务端和Kubernetes集群连接关系示意图。客户在通过上述YAML文件创建Ingress之后，路由控制器可以通过APISever监听到该Ingress对象的生成，并在预定云服务端配置新的负载均衡器作为目标负载均衡器或配置已存在的目标负载均衡器。从而实现负载均衡器的自动部署。

下面从预定云服务端中的任一负载均衡器的角度，对本发明实施例所提供的一种请求处理方法进行介绍。

负载均衡器中按照上述信息配置方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，至少一个Kubernetes集群属于同一目标客户。

如图7所示，本发明实施例提供的一种信息配置方法，方法包括：

S701，接收访问端发送的目标访问请求；其中，访问请求中携带有待访问业务的业务信息；目标访问请求为：访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；待访问业务为至少一个Kubernetes集群提供的各业务中的任一业务；

其中，目标访问请求为：访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求。可选的，访问端访问域名时，DNS(Domain Name System，域名系统)服务可以根据预先建立的域名与公网IP之间的对应关系，确定该域名对应的公网IP，即所获取到该负载均衡器的公网IP。进而基于所确定的公网IP发送目标访问请求。

示例性的，任一业务的业务信息可以包括：该业务对应的用于访问的域名，以及该业务的业务路径，可选地，该业务路径可以为业务标识，当然并不局限于此。

S702，基于路由规则信息，按照负载均衡原则，转发目标访问请求。

需要说明的是，前述已提及，路由规则信息可以为业务与工作节点组之间的对应关系，或业务与实现业务的pod组之间的对应关系。

可选的，在一种实现方式中，当路由规则信息为与工作节点之间的对应关系时，上述路由规则信息包括：关于每一业务的业务信息和该业务所部属于的工作节点组的第一对应关系。

需要说明的是，工作节点组中包括至少一个工作节点，该工作节点组在第一对应关系中的表征形式可以为：该工作节点组中各个工作节点的标识和各个工作节点的访问路径的组合内容。业务信息可以包括访问该业务的域名和该业务的业务路径，例如，上述业务路径可以为业务标识，如前述示例中的业务1。业务所部署的工作节点组为实现该业务的pod所在节点的组合。以前述示例中业务1为例，业务1通过工作节点组1中的工作节点1中的pod1和pod2实现，则第一对应关系为业务1与工作节点组1之间的对应关系。

此时，上述步骤S702，可以包括：

基于第一对应关系，确定与待访问业务的业务信息对应的目标工作节点组；

按照负载均衡原则，从目标工作节点组中选择待利用工作节点；

将目标访问请求发送至待利用工作节点。

示例性的，Kubernetes集群对外提供业务2，该业务2可以通过工作节点组1中的工作节点2中的pod3、pod4、以及工作节点组2中的节点3中的pod5实现。则第一对应关系中记录业务2与工作节点组2之间的对应关系，从而可以基于第一对应关系确定工作节点组2为目标工作节点组。进一步的，按照负载均衡原则，从目标工作节点组中选择待利用工作节点，即从工作节点组2中选择待利用工作节点。若选择工作节点2为待利用工作节点，则将目标访问请求发送至工作节点2。

示例性的，待利用工作节点可以通过Kubernetes集群内部的针对Pod的负载均衡器，选择待处理该目标访问请求的待利用pod，将请求转发至待利用pod，以通过待利用pod来完成目标访问请求的响应。

可选的，在另一种实现方式中，当路由规则信息为业务与pod组之间的对应关系时，上述路由规则信息包括：关于每一业务的业务信息和该业务所部署于的pod组第二对应关系。其中，该业务所部署于的pod组，在第二对应关系中的表征形式可以为：该pod组中各个pod的标识和各个pod的访问路径的组合内容。

需要说明的是，pod组中包括至少一个pod。业务所部署于的pod组为实现该业务的pod的组合。以前述示例中业务2为例，业务2可以通过工作节点2中的pod3、pod4、以及节点3中的pod5实现，则业务2部署于pod3、pod4和pod5上，即业务2所部署于的pod组1包含pod3、pod4和pod5。则第二对应关系为业务2与pod组1之间的对应关系。

此时，上述步骤S702，可以包括：

基于第二对应关系，确定与待访问业务的业务信息对应的目标pod组；

按照负载均衡原则，从目标pod组中选择待利用pod；

将所述目标访问请求转发至所述待利用pod。

示例性的，以业务2为例，第二对应关系中记录业务2所属的pod为pod3、pod4和pod5。pod3、pod4和pod5位于pod组1，则第二对应关系为业务2与pod组1之间的对应关系，进而确定出目标pod组1为目标pod组。进一步的，按照负载均衡原则，从pod组1中选择待利用工作节点，即从pod3、pod4和pod5中选择待利用pod。若选择pod4为待利用pod，则将目标访问请求转发至pod4。

本实施例所提供方案中，可以实现针对用于访问Kubernetes集群所提供业务的外部请求的路由。另外由于负载均衡器中预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，使得负载均衡器可以同时为多个业务提供路由服务，进而客户不需要为每个Kubernetes集群均配置新的负载均衡器，减小了目标客户需要管理的负载均衡器。

为了更清楚的阐述本发明实施例的技术方案，下面结合实际案例进一步的对本发明实施例进行说明。

图8为本发明实施例所提供的请求处理流程示意图。图中共享负载服务器为预定云服务端中的任一负载均衡器。访问端在浏览器中输入访问协议+域名+路径(比如https://www.application1.com/app)后，DNS服务将域名解析为负载均衡器的公网IP+端口号，从而使得负载均衡器可以接收到访问端的访问请求，进而根据访问端所要访问的待访问业务，确定出待利用工作节点或待利用pod，并将访问请求转发至利用工作节点或待利用pod中。

相应于上述从Kubernetes集群中的路由控制器角度所提供的信息配置方法，如图9所示，本发明实施例还提供了一种信息配置装置，应用于Kubernetes集群中的路由控制器，装置包括：

信息获取模块901，用于获取针对Kubernetes集群所提供业务的配置信息；其中，配置信息至少包括业务的路由规则信息；

均衡器确定模块902，用于确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，目标客户为Kubernetes集群所属的客户，目标负载均衡器为用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器；

信息配置模块903，用于将路由规则信息作为目标负载均衡器的待配置信息发送至预定云服务端，以使预定云服务端将路由规则信息配置于目标负载均衡器。

在一实施例中，均衡器确定模块，具体用于检测预定云服务端中是否已创建有属于目标客户的目标负载均衡器；若已创建，确定出属于目标客户的目标负载均衡器；若未创建，在预定云服务端中创建属于目标用户的目标负载均衡器。

在一实施例中，配置信息还包括：第一辅助信息；其中，第一辅助信息用于表征业务是否使用已存在的负载均衡器进行路由服务；

装置还包括：

信息检测模块，用于在均衡器确定模块执行确定位于预定云服务端中的属于目标客户的目标负载均衡器之前，检测第一辅助信息是否表征业务使用已存在的负载均衡器进行路由服务；若第一辅助信息表征业务使用已存在的负载均衡器进行路由服务，则调用均衡器确定模块执行确定位于预定云服务端中的属于目标客户的目标负载均衡器的步骤。

在一实施例中，装置还包括：

均衡器创建模块，用于若第一辅助信息表征业务不使用已存在的负载均衡器进行路由服务，则在预定云服务端中创建负载均衡器；其中，所创建的负载均衡器为属于目标客户的、仅对Kubernetes集群的各业务进行路由服务的负载均衡器；将路由规则信息作为所创建的负载均衡器的待配置信息发送至预定云服务端，以使预定云服务端将路由规则信息配置于所创建的负载均衡器。

在一实施例中，配置信息还包括：第二辅助信息；其中，第二辅助信息为：对业务所利用的负载均衡器的公网IP所配置的网络限流信息；

装置还包括：

IP确定模块，用于确定目标负载均衡器的公网IP；其中，目标负载均衡器的公网IP为：在目标负载均衡器被创建好后，预定云服务端为目标负载均衡器所分配的；若检测到所确定的公网IP的网络限流信息为空或与第二辅助信息不一致时，利用第二辅助信息，设置目标负载均衡器的公网IP的网络限流信息。

在一实施例中，网络限流信息包括：允许的访问带宽和/或计费类型。

本实施例所提供方案中，由于上述目标负载均衡器是用于实现目标客户的各Kubernetes集群的路由服务的负载均衡器，因此，将上述业务的路由规则信息配置于目标负载均衡器中，可以使上述Kubernetes集群的路由服务通过该目标负载均衡器实现，从而对于上述Kubernetes集群而言，不再需要配置单独的负载均衡器即可实现路由服务。针对同一客户需要在同一Kubernetes集群中部署多个路由服务，或者部署多个Kubernetes集群的情况，由于位于预定云服务端的目标负载均衡器可以实现同一客户的同一或者不同Kubernetes集群的路由服务，使得该客户不需要为每个Kubernetes集群均配置单独的负载均衡器，大大减少了负载均衡器的数量。可见，通过本方案，可以降低用户的资源成本，同时也降低Kubernetes集群的管理成本。另外，针对目标负载均衡器位于云厂商提供的预定云服务端的情况，目标负载均衡器的安全性和稳定性可以具有较好的保障，且维护成本也可大大降低。

相应于上述从预定云服务端中的任一负载均衡器角度所提供的请求处理方法，如图10所示，本发明实施例还提供了一种请求处理装置，应用于Kubernetes集群中的路由控制器，负载均衡器中按照上述信息配置方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，至少一个Kubernetes集群属于同一目标客户；方法包括。装置包括：

请求接收模块1001，用于接收访问端发送的目标访问请求；其中，访问请求中携带有待访问业务的业务信息；目标访问请求为：访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；待访问业务为至少一个Kubernetes集群提供的各业务中的任一业务；

请求转发模块1002，用于基于路由规则信息，按照负载均衡原则，转发目标访问请求。

在一实施例中，路由规则信息包括：关于每一业务的业务信息和该业务所部属于的工作节点组的第一对应关系；

请求转发模块，具体用于基于第一对应关系，确定与待访问业务的业务信息对应的目标工作节点组；按照负载均衡原则，从目标工作节点组中选择待利用工作节点；将目标访问请求发送至待利用工作节点。

在一实施例中，路由规则信息包括：关于每一业务的业务信息和该业务所部署于的pod组第二对应关系；

请求转发模块，具体用于基于第二对应关系，确定与待访问业务的业务信息对应的目标pod组；按照负载均衡原则，从目标pod组中选择待利用pod；将目标访问请求转发至待利用pod。

本实施例所提供方案中，可以实现针对用于访问Kubernetes集群所提供业务的外部请求的路由。另一方面，由于负载均衡器中预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，使得负载均衡器可以同时为多个业务提供路由服务，进而客户不需要为每个Kubernetes集群均配置新的负载均衡器，减小了目标客户需要管理的负载均衡器。

本发明实施例还提供了一种电子设备，如图11所示，包括处理器1101、通信接口1102、存储器1103和通信总线1104，其中，处理器1101，通信接口1102，存储器1103通过通信总线1104完成相互间的通信，

存储器1103，用于存放计算机程序；

处理器1101，用于执行存储器1103上所存放的程序时，实现上述从Kubernetes集群中的路由控制器的角度所提供的信息配置方法步骤，或从预定云服务端中的任一负载均衡器的角度所提供的请求处理方法步骤。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在本发明提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一信息配置方法或任一请求处理方法的步骤。

在本发明提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一信息配置方法或任一请求处理方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (13)

1.一种信息配置方法，其特征在于，应用于Kubernetes集群中的路由控制器，所述方法包括：

获取针对所述Kubernetes集群所提供业务的配置信息；其中，所述配置信息至少包括所述业务的路由规则信息；

确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，所述目标客户为所述Kubernetes集群所属的客户，所述目标负载均衡器为用于实现所述目标客户的各Kubernetes集群的路由服务的负载均衡器；

将所述路由规则信息作为所述目标负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所述目标负载均衡器。

2.根据权利要求1所述的方法，其特征在于，所述确定位于预定云服务端中的属于目标客户的目标负载均衡器，包括：

检测所述预定云服务端中是否已创建有属于所述目标客户的目标负载均衡器；

若已创建，确定出属于所述目标客户的目标负载均衡器；

若未创建，在所述预定云服务端中创建属于所述目标用户的目标负载均衡器。

3.根据权利要求1或2所述的方法，其特征在于，所述配置信息还包括：第一辅助信息；其中，所述第一辅助信息用于表征所述业务是否使用已存在的负载均衡器进行路由服务；

在所述确定位于预定云服务端中的属于目标客户的目标负载均衡器之前，还包括：

检测所述第一辅助信息是否表征所述业务使用已存在的负载均衡器进行路由服务；

若所述第一辅助信息表征所述业务使用已存在的负载均衡器进行路由服务，则执行所述确定位于预定云服务端中的属于目标客户的目标负载均衡器的步骤。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述第一辅助信息表征所述业务不使用已存在的负载均衡器进行路由服务，则在所述预定云服务端中创建负载均衡器；其中，所创建的负载均衡器为属于所述目标客户的、仅对所述Kubernetes集群的各业务进行路由服务的负载均衡器；

将所述路由规则信息作为所创建的负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所创建的负载均衡器。

5.根据权利要求2所述的方法，其特征在于，所述配置信息还包括：第二辅助信息；其中，所述第二辅助信息为：对所述业务所利用的负载均衡器的公网IP所配置的网络限流信息；

所述方法还包括：

确定所述目标负载均衡器的公网IP；其中，所述目标负载均衡器的公网IP为：在所述目标负载均衡器被创建好后，所述预定云服务端为所述目标负载均衡器所分配的；

若检测到所确定的公网IP的网络限流信息为空，则使用默认值设置所述目标负载均衡器的公网IP的网络限流信息；

若所述第二辅助信息存在时，利用所述第二辅助信息，设置所述目标负载均衡器的公网IP的网络限流信息。

6.根据权利要求5所述的方法，其特征在于，所述网络限流信息包括：允许的访问带宽和/或计费类型。

7.一种请求处理方法，其特征在于，应用于预定云服务端中的任一负载均衡器；所述负载均衡器中按照权利要求1-6任一项方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，所述至少一个Kubernetes集群属于同一目标客户；所述方法包括：

接收访问端发送的目标访问请求；其中，所述访问请求中携带有待访问业务的业务信息；所述目标访问请求为：所述访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；所述待访问业务为所述至少一个Kubernetes集群提供的各业务中的任一业务；

基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求。

8.根据权利要求7所述的方法，其特征在于，所述路由规则信息包括：关于每一业务的业务信息和该业务所部属于的工作节点组的第一对应关系；

所述基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求，包括：

基于所述第一对应关系，确定与所述待访问业务的业务信息对应的目标工作节点组；

按照负载均衡原则，从所述目标工作节点组中选择待利用工作节点；

将所述目标访问请求发送至所述待利用工作节点。

9.根据权利要求7所述的方法，其特征在于，所述路由规则信息包括：关于每一业务的业务信息和该业务所部署于的pod组第二对应关系；

所述基于所述路由规则信息，按照负载均衡原则，将所述目标访问请求进行转发，包括：

基于所述第二对应关系，确定与所述待访问业务的业务信息对应的目标pod组；

按照负载均衡原则，从所述目标pod组中选择待利用pod；

将所述目标访问请求转发至所述待利用pod。

10.一种信息配置装置，其特征在于，应用于Kubernetes集群中的路由控制器，所述装置包括：

信息获取模块，用于获取针对所述Kubernetes集群所提供业务的配置信息；其中，所述配置信息至少包括所述业务的路由规则信息；

均衡器确定模块，用于确定位于预定云服务端中的属于目标客户的目标负载均衡器，其中，所述目标客户为所述Kubernetes集群所属的客户，所述目标负载均衡器为用于实现所述目标客户的各Kubernetes集群的路由服务的负载均衡器；

信息配置模块，用于将所述路由规则信息作为所述目标负载均衡器的待配置信息发送至所述预定云服务端，以使所述预定云服务端将所述路由规则信息配置于所述目标负载均衡器。

11.一种请求处理装置，其特征在于，应用于预定云服务端中的任一负载均衡器；所述负载均衡器中按照权利要求1-6任一项方法预先配置有至少一个Kubernetes集群提供的各业务的路由规则信息，所述至少一个Kubernetes集群属于同一目标客户；所述装置包括：

请求接收模块，用于接收访问端发送的目标访问请求；其中，所述访问请求中携带有待访问业务的业务信息；所述目标访问请求为：所述访问端在基于待访问业务的业务信息获取到该负载均衡器的公网IP后，发送的访问请求；所述待访问业务为所述至少一个Kubernetes集群提供的各业务中的任一业务；

请求转发模块，用于基于所述路由规则信息，按照负载均衡原则，转发所述目标访问请求。

12.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1-6任一所述的方法步骤，或者，权利要求7-8任一项所述的方法步骤。

13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-6任一项所述的方法步骤，或者，权利要求7-8任一项所述的方法步骤。

Images