Information Configuration Method, Device, Request Processing Method, and Device

Abstract

Embodiments of the present invention provide an information configuration method and apparatus, which are applied to the field of information processing technologies. The method is applied to a routing controller in a Kubernetes cluster, and the method includes: obtaining configuration information for the services provided by the Kubernetes cluster; wherein the configuration information at least includes routing rule information for the services; determining a target load balancer belonging to a target customer located in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is used to implement the routing services of each Kubernetes cluster of the target customer; sending the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer. Through this solution, the resource cost of users can be reduced, and at the same time, the management cost of the Kubernetes cluster is also reduced, and the performance and security of routing service access are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of information processing, and particularly to an information configuration method, an apparatus, a request processing method, and an apparatus. Background Art

[0002] The Kubernetes cluster is an open-source container cluster management system used to automatically deploy, scale, and manage containerized applications. As Figure 1 shown, it is a schematic structural diagram of the Kubernetes cluster. Among them, the Kubernetes cluster includes a control plane and several worker nodes. The control plane includes various controllers (Controller) and an APIServer, etc. One or more pods are running on each worker node, where each pod represents a group of running containerized applications.

[0003] For the Kubernetes cluster, each service provided by the Kubernetes cluster is implemented by a group of pods in the worker nodes. Among them, the group of pods can be multiple pods in the same worker node or multiple pods in different worker nodes. The Ingress (routing rule) function of the Kubernetes cluster is a function for managing external requests for accessing services.

[0004] In the related art, for each Ingress service in the Kubernetes cluster, at least one load balancer needs to be configured through a routing controller, so that the at least one load balancer implements the Ingress function. However, for the case where the same customer has multiple Ingress services, a large number of load balancers need to be configured, which undoubtedly causes waste of resources. Summary of the Invention

[0005] The purpose of the embodiments of the present invention is to provide an information configuration method and an apparatus to reduce the resource cost of users. In addition, the embodiments of the present invention also provide a request processing method and an apparatus to implement routing for external requests for accessing services provided by the Kubernetes cluster. The specific technical solutions are as follows:

[0006] In a first aspect, an embodiment of the present invention provides an information configuration method applied to a routing controller in a Kubernetes cluster. The method includes:

[0007] Obtain configuration information for the services provided by the Kubernetes cluster; where the configuration information at least includes routing rule information for the services;

[0008] Determine a target load balancer belonging to a target customer in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is a load balancer used to implement the routing service for each Kubernetes cluster of the target customer;

[0009] Send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

[0010] In one embodiment, the determining a target load balancer belonging to a target customer in a predetermined cloud server includes:

[0011] Detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server;

[0012] If it has been created, determine the target load balancer belonging to the target customer;

[0013] If it has not been created, create a target load balancer belonging to the target user in the predetermined cloud server.

[0014] In one embodiment, the configuration information further includes: first auxiliary information; where the first auxiliary information is used to represent whether the service uses an existing load balancer for routing services;

[0015] Before determining the target load balancer belonging to the target customer in the predetermined cloud server, it further includes:

[0016] Detect whether the first auxiliary information represents that the service uses an existing load balancer for routing services;

[0017] If the first auxiliary information represents that the service uses an existing load balancer for routing services, then perform the step of determining the target load balancer belonging to the target customer in the predetermined cloud server.

[0018] In one embodiment, the method further includes:

[0019] If the first auxiliary information represents that the service does not use an existing load balancer for routing services, then create a load balancer in the predetermined cloud server; where the created load balancer is a load balancer belonging to the target customer and only used for routing services for each service of the Kubernetes cluster;

[0020] Send the routing rule information as the configuration information to be configured for the created load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information for the created load balancer.

[0021] In one embodiment, the configuration information further includes: second auxiliary information; wherein, the second auxiliary information is: network traffic limiting information configured for the public IP of the load balancer utilized by the service.

[0022] The method further includes:

[0023] Determine the public IP of the target load balancer; wherein, the public IP of the target load balancer is: after the target load balancer is created, the public IP assigned by the predetermined cloud server for the target load balancer.

[0024] If it is detected that the network traffic limiting information of the determined public IP is empty, set the network traffic limiting information of the public IP of the target load balancer using the default value.

[0025] If the second auxiliary information exists, utilize the second auxiliary information to set the network traffic limiting information of the public IP of the target load balancer.

[0026] In one embodiment, the network traffic limiting information includes: allowed access bandwidth and / or billing type.

[0027] In a second aspect, an embodiment of the present invention further provides a request processing method, which is applied to any load balancer in a predetermined cloud server; at least one routing rule information of each service provided by at least one Kubernetes cluster is preconfigured in the load balancer according to any method in the first aspect, and the at least one Kubernetes cluster belongs to the same target customer; the method includes:

[0028] Receive a target access request sent by an access end; wherein, the access request carries service information of the service to be accessed; the target access request is: an access request sent by the access end after obtaining the public IP of this load balancer based on the service information of the service to be accessed; the service to be accessed is any one of the services provided by the at least one Kubernetes cluster.

[0029] Forward the target access request based on the routing rule information according to the load balancing principle.

[0030] In one embodiment, the routing rule information includes: the first corresponding relationship between the service information of each service and the worker node group to which the service belongs.

[0031] Forwarding the target access request based on the routing rule information according to the load balancing principle includes:

[0032] Based on the first correspondence, determine a target working node group corresponding to the service information of the service to be accessed;

[0033] Select a working node to be utilized from the target working node group according to the load balancing principle;

[0034] Send the target access request to the working node to be utilized.

[0035] In one embodiment, the routing rule information includes: a second correspondence between the service information of each service and the pod group where the service is deployed;

[0036] Forwarding the target access request based on the routing rule information according to the load balancing principle includes:

[0037] Based on the second correspondence, determine a target pod group corresponding to the service information of the service to be accessed;

[0038] Select a pod to be utilized from the target pod group according to the load balancing principle;

[0039] Forward the target access request to the pod to be utilized.

[0040] In a third aspect, an embodiment of the present invention further provides an information configuration device, which is applied to a routing controller in a Kubernetes cluster. The device includes:

[0041] An information acquisition module, configured to acquire configuration information for services provided by the Kubernetes cluster; wherein, the configuration information at least includes the routing rule information of the service;

[0042] An equalizer determination module, configured to determine a target load balancer belonging to a target customer in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is a load balancer for implementing the routing service of each Kubernetes cluster of the target customer;

[0043] An information configuration module, configured to send the routing rule information as the information to be configured of the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

[0044] In one embodiment, the balancer determination module is specifically configured to detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server; if it has been created, determine the target load balancer belonging to the target customer; if it has not been created, create a target load balancer belonging to the target user in the predetermined cloud server.

[0045] In one embodiment, the configuration information further includes: first auxiliary information; wherein, the first auxiliary information is used to represent whether the service uses an existing load balancer for routing services;

[0046] The device further includes:

[0047] An information detection module, configured to detect whether the first auxiliary information represents that the service uses an existing load balancer for routing services before the balancer determination module executes the determination of the target load balancer belonging to the target customer in the predetermined cloud server; if the first auxiliary information represents that the service uses an existing load balancer for routing services, then call the balancer determination module to execute the step of determining the target load balancer belonging to the target customer in the predetermined cloud server.

[0048] In one embodiment, the device further includes:

[0049] A balancer creation module, configured to create a load balancer in the predetermined cloud server if the first auxiliary information represents that the service does not use an existing load balancer for routing services; wherein, the created load balancer is a load balancer belonging to the target customer and only routing services for each service of the Kubernetes cluster; send the routing rule information as the to-be-configured information of the created load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the created load balancer.

[0050] In one embodiment, the configuration information further includes: second auxiliary information; wherein, the second auxiliary information is: network flow limiting information configured for the public IP of the load balancer utilized by the service;

[0051] The device further includes:

[0052] An IP determination module, configured to determine the public IP of the target load balancer; wherein, the public IP of the target load balancer is: after the target load balancer is created, the predetermined cloud server assigns it for the target load balancer; if it is detected that the network flow limiting information of the determined public IP is empty or inconsistent with the second auxiliary information, use the second auxiliary information to set the network flow limiting information of the public IP of the target load balancer.

[0053] In one embodiment, the network traffic limiting information includes: the allowed access bandwidth and / or the charging type.

[0054] In a fourth aspect, an embodiment of the present invention further provides a request processing device, which is applied to any load balancer in a predetermined cloud server; at least one routing rule information of each service provided by a Kubernetes cluster is preconfigured in the load balancer according to any method in the first aspect, and the at least one Kubernetes cluster belongs to the same target customer; the device includes:

[0055] A request receiving module, configured to receive a target access request sent by an access end; wherein, service information of a service to be accessed is carried in the access request; the target access request is: an access request sent by the access end after obtaining the public network IP of the load balancer based on the service information of the service to be accessed; the service to be accessed is any service among the services provided by the at least one Kubernetes cluster;

[0056] A request forwarding module, configured to forward the target access request based on the routing rule information according to the load balancing principle.

[0057] In one embodiment, the routing rule information includes: a first corresponding relationship between the service information of each service and the working node group to which the service belongs;

[0058] The request forwarding module is specifically configured to determine a target working node group corresponding to the service information of the service to be accessed based on the first corresponding relationship; select a working node to be utilized from the target working node group according to the load balancing principle; and send the target access request to the working node to be utilized.

[0059] In one embodiment, the routing rule information includes: a second corresponding relationship between the service information of each service and the pod group in which the service is deployed;

[0060] The request forwarding module is specifically configured to determine a target pod group corresponding to the service information of the service to be accessed based on the second corresponding relationship; select a pod to be utilized from the target pod group according to the load balancing principle; and forward the target access request to the pod to be utilized.

[0061] In a fifth aspect, an embodiment of the present invention further provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0062] The memory is used for storing a computer program;

[0063] A processor, when executing a program stored in a memory, implements any of the method steps in the first aspect or any of the method steps in the second aspect.

[0064] In a sixth aspect, an embodiment of the present invention further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements any of the method steps in the first aspect or any of the method steps in the second aspect.

[0065] Beneficial effects of the embodiments of the present invention:

[0066] In the information configuration method provided by the embodiments of the present invention, a routing controller in a Kubernetes cluster deployed by a target customer can obtain configuration information for the services provided by the Kubernetes cluster, and determine a target load balancer belonging to the target customer located in a predetermined cloud server, and then configure the routing rule information of the above services included in the configuration information in the target load balancer. Since the above target load balancer is a load balancer for implementing the routing services of each Kubernetes cluster of the target customer, therefore, configuring the routing rule information of the above services in the target load balancer can enable the routing service of the above Kubernetes cluster to be implemented through the target load balancer. Thus, for the above Kubernetes cluster, there is no need to configure a separate load balancer to implement the routing service. For the situation where multiple routing services need to be deployed in the same Kubernetes cluster for the same customer, or multiple Kubernetes clusters need to be deployed, since the target load balancer located in the predetermined cloud server can implement the routing services of the same or different Kubernetes clusters of the same customer, the customer does not need to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the situation where the target load balancer is located in a predetermined cloud server provided by a cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0067] Based on the above information configuration method, an embodiment of the present invention further provides a request processing method applied to any load balancer in a predetermined cloud server. Through this request processing method, routing for external requests used to access the services provided by the Kubernetes cluster can be achieved.

[0068] Of course, when implementing any product or method of the present invention, it is not necessarily required to achieve all the above-mentioned advantages simultaneously. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other embodiments can be obtained based on these drawings.

[0070] Figure 1 It is a schematic structural diagram of a Kubernetes cluster;

[0071] Figure 2 It is a schematic diagram of processing external requests through the Ingress function in a Kubernetes cluster;

[0072] Figure 3 It is a flowchart of the information configuration method of the routing controller applied to a Kubernetes cluster provided by an embodiment of the present invention;

[0073] Figure 4 It is another flowchart of the information configuration method of the routing controller applied to a Kubernetes cluster provided by an embodiment of the present invention;

[0074] Figure 5 It is another flowchart of the information configuration method of the routing controller applied to a Kubernetes cluster provided by an embodiment of the present invention;

[0075] Figure 6 It is a schematic diagram of the connection relationship between a predetermined cloud server and a Kubernetes cluster provided by an embodiment of the present invention

[0076] Figure 7 It is a flowchart of the request processing method of any load balancer applied to a predetermined cloud server provided by an embodiment of the present invention;

[0077] Figure 8 It is a schematic diagram of the request processing flow provided by an embodiment of the present invention;

[0078] Figure 9 It is a schematic structural diagram of the information configuration device of the routing controller applied to a Kubernetes cluster provided by an embodiment of the present invention;

[0079] Figure 10 It is a schematic structural diagram of the request processing device of any load balancer applied to a predetermined cloud server provided by an embodiment of the present invention;

[0080] Figure 11 It is a schematic structural diagram of the electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0081] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0082] To more clearly elaborate on the technical solutions provided by the embodiments of the present invention, the Ingress function of the Kubernetes cluster will be further introduced.

[0083] Exemplarily, as Figure 2 , it is a schematic diagram of processing external requests through the Ingress function in the Kubernetes cluster. The Ingress function of the Kubernetes cluster forwards HTTP (Hyper Text Transfer Protocol) requests / HTTPS (Hyper Text Transfer Protocol over Secure Socket Layer) requests from the access side to the pod for the service targeted by the request, and then the pod processes the request.

[0084] The Ingress function of the Kubernetes cluster mainly relies on a load balancer to implement. Exemplarily, the load balancer can be: nginx, traefik, haproxy, etc. Among them, nginx is a high-performance HTTP and reverse proxy server, traefik is an http reverse proxy and load balancing software, and haproxy provides high availability, load balancing, and proxy for TCP and HTTP applications. In the related art, for each Kubernetes cluster, at least one load balancer needs to be configured for the Kubernetes cluster to implement the Ingress function of the Kubernetes cluster. Thus, for the case where multiple Kubernetes clusters need to be deployed for the same customer, a large number of load balancers need to be configured, which undoubtedly results in a relatively high management cost for the Kubernetes cluster.

[0085] To solve the technical problems existing in the related art, that is, to reduce the management cost of the Kubernetes cluster, the embodiments of the present invention provide an information configuration method and device.

[0086] Next, a method for configuring information provided by the embodiments of the present invention will be introduced from the perspective of the routing controller in the Kubernetes cluster.

[0087] It should be noted that, as Figure 1 shown, the routing controller in the Kubernetes cluster (the controller shown in the figure) has been deployed when the customer deploys the Kubernetes cluster. After the Kubernetes cluster is deployed, the included routing controller can listen to the changes of resources in the Kubernetes cluster through the APIServer. Among them, the resources in the above-mentioned Kubernetes cluster refer to resources such as Ingress (routing rules), service, secret, endpoint, and node in the Kubernetes cluster.

[0088] When the customer needs the Kubernetes cluster to provide a specified service externally, it needs to configure a load balancer that provides routing services for this service in the Kubernetes cluster. Optionally, the configuration information of the load balancer to be configured can be recorded through a YAML file, and an Ingress object can be created through the YAML file. When the routing controller in the Kubernetes cluster listens through the APIServer interface and detects the generation of a new Ingress object, it obtains the configuration information of the Ingress object, and then configures a load balancer that provides routing services for the specified service based on the obtained configuration information.

[0089] The routing controller in the Kubernetes cluster applied in the embodiments of the present invention can be a device with data processing capabilities such as a server. Moreover, the information configuration method provided in the embodiments of the present invention can be implemented in a software, hardware, or software-hardware combination manner.

[0090] To reduce the management cost of the Kubernetes cluster, the embodiments of the present invention provide an information configuration method, including:

[0091] Obtain configuration information for the services provided by the Kubernetes cluster; where the configuration information includes at least the routing rule information of the service;

[0092] Determine a target load balancer belonging to the target customer in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is used to implement the routing services of each Kubernetes cluster of the target customer;

[0093] Send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information on the target load balancer.

[0094] In the solution provided in this embodiment, since the target load balancer is a load balancer used to implement the routing service for each Kubernetes cluster of the target customer, therefore, by configuring the routing rule information of the service in the target load balancer, the routing service of the Kubernetes cluster can be implemented through the target load balancer. Thus, for the above-mentioned Kubernetes cluster, there is no need to configure a new load balancer to implement the routing service. For the case where multiple Kubernetes clusters need to be deployed for the same customer, and the case where multiple routing services are deployed in the same Kubernetes cluster, since the target load balancer located in the predetermined cloud server can implement the routing service for the same or cross-Kubernetes clusters of the same customer, the customer does not need to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the case where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0095] As Figure 3 shown, an information configuration method provided by an embodiment of the present invention, which is applied to a routing controller in a Kubernetes cluster, may include the following steps:

[0096] S301, obtain the configuration information for the service provided for the Kubernetes cluster; wherein, the configuration information at least includes the routing rule information of the service;

[0097] The above configuration information is: the information for configuring the load balancer that provides the routing service for the service provided for the Kubernetes cluster. The configuration information at least includes the routing rule information of the service. The service provided by the above Kubernetes cluster may be network services such as access verification, information processing, data transmission, etc., and any service may be a program for implementing a specific function.

[0098] Among them, the routing rule information of a service indicates the routing rule for forwarding requests for accessing the service. In a Kubernetes cluster, there are two ways for each service provided by the Kubernetes cluster to expose the service to the load balancer. One way is pod direct access, and the other way is non-pod direct access. For pod direct access, the load balancer is directly connected to the pod that implements the service. For non-pod direct access, the load balancer is not directly connected to the pod that implements the service, but is connected to the worker node group where the nodes (including worker nodes and control nodes) of the cluster where the pod is located are located. Different ways of exposing the service mean different corresponding routing rule information. For pod direct access, the routing rule information indicates that the request is directly forwarded to the pod that implements the service. For non-pod direct access, the routing rule information indicates that the request is forwarded to the worker node group of the cluster, and then the worker node group forwards it to the pod that implements the service.

[0099] Exemplarily, the Kubernetes cluster provides Service 1 externally, and this service is implemented by Pod1 and Pod2 in Worker Node 1. If the load balancer has direct access to the pod, the routing rule information may include the service information of Service 1 and the corresponding relationship of the pod group where this Service 1 is deployed. If the load balancer has non-direct access to the pod, the routing rule information may include the service information of Service 1 and the corresponding relationship of the worker node group to which this Service 1 belongs. Additionally, exemplarily, the service information of any service may include: the domain name and service path used for accessing corresponding to this service, and this service path may be the service identifier of this service, but of course it is not limited to this.

[0100] S302. Determine the target load balancer belonging to the target customer in the predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is used to implement the routing service of each Kubernetes cluster of the target customer;

[0101] Among them, the predetermined cloud server may be the cloud server provided by the cloud provider. Different customers can configure different load balancers in the predetermined cloud server. For the target customer to which the Kubernetes cluster belongs, the target load balancer belonging to this target customer in the predetermined cloud server can be determined to implement the routing service of each Kubernetes cluster of the target customer through this target load balancer.

[0102] For example, the predetermined cloud server contains the target load balancer 1 of customer 1 and the target load balancer 2 of customer 2. When customer 2 needs to deploy a new Kubernetes cluster or use an existing Kubernetes cluster to provide new services, it needs the load balancer to implement the routing service for the new Kubernetes cluster or new services. At this time, the target load balancer 2 can be determined from the predetermined cloud server.

[0103] S303. Send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

[0104] Among them, the routing controller can send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server through the configuration interface provided by the predetermined server, so that the predetermined cloud server configures the received routing rule information in the target load balancer. Among them, the routing rule information can be configured in the target load balancer in the same way as the existing technical means for configuring routing rule information in the load balancer. For example, based on the routing rule information, a listener can be generated in the target load balancer. Since it is the same as the prior art, the embodiments of the present invention will not be elaborated herein.

[0105] In the solution provided in this embodiment, since the target load balancer is a load balancer used to implement the routing service of each Kubernetes cluster of the target customer, therefore, configuring the routing rule information of the service in the target load balancer can enable the routing service of the Kubernetes cluster to be implemented through the target load balancer. Thus, for the above-mentioned Kubernetes cluster, there is no need to configure a new load balancer to implement the routing service. For the situation where the same customer needs to deploy multiple routing services in the same Kubernetes cluster or deploy multiple Kubernetes clusters, since the target load balancer located in the predetermined cloud server can implement the routing service of the same or different Kubernetes clusters of the same customer, it enables the customer not to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the case where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0106] Based on Figure 3 of the embodiment, such as Figure 4As shown in the figure, the information configuration method provided by another embodiment of the present invention, the above S302 may include the following steps:

[0107] S3021, detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server;

[0108] Among them, it is possible to query whether a target load balancer belonging to the target customer has been created in the predetermined cloud server through the query interface provided by the predetermined cloud server. Optionally, through this query interface, a query request for the target load balancer of the target customer is sent to the predetermined cloud server, and a query result indicating whether a target load balancer belonging to the target customer has been created in the predetermined cloud server is received. The above query interface may be the Get interface of the load balancer.

[0109] Optionally, in one implementation, all load balancers of the target customer in the predetermined cloud server may be regarded as the target load balancer. Exemplarily, if 2 load balancers belonging to the target customer are detected in the predetermined cloud server: load balancer 1 and load balancer 2, it can be determined that a target load balancer belonging to the target customer has been created in the predetermined cloud server. On the contrary, if no load balancer belonging to the target customer is detected in the predetermined cloud server, it is determined that no target load balancer belonging to the target customer has been created in the predetermined cloud server.

[0110] Optionally, in another implementation, the target customer may include multiple types of load balancers in the predetermined cloud server. For example, a load balancer that provides routing services for a single service and a load balancer that can provide routing services for multiple services belonging to the target customer at the same time. At this time, different types of load balancers are associated with different type identifiers. For example, a load balancer that can provide routing services for multiple services belonging to the target customer at the same time is associated with a shared identifier, while for a load balancer that provides routing services for a single service, it may be associated with an independent identifier, or it is pre-agreed that a load balancer with an empty type identifier provides routing services for a single service. When it is necessary to detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server, it is possible to judge whether a target load balancer belonging to the target customer has been created in the predetermined cloud server by detecting the shared identifier. For example, if there is a load balancer associated with a shared identifier in the predetermined cloud server, it is determined that there is already a target load balancer belonging to the target customer in the predetermined cloud server. On the contrary, if there is no load balancer associated with a shared identifier in the predetermined cloud server, it is determined that there is no target load balancer belonging to the target customer in the predetermined cloud server.

[0111] Optionally, if a target load balancer belonging to the target customer has been created in the predetermined cloud server, step S3022 is executed. If a target load balancer belonging to the target customer has not been created in the predetermined cloud server, step S3023 is executed.

[0112] S3022, determine the target load balancer belonging to the target customer;

[0113] Among them, when a target load balancer belonging to the target customer has been created in the predetermined cloud server, the target load balancer can be directly determined.

[0114] Optionally, in one implementation, the query result returned by the predetermined cloud server may further include a load balancer identifier of the load balancer belonging to the target customer, and the load balancer indicated by the load balancer identifier can be determined as the target load balancer belonging to the target customer.

[0115] S3023, create a target load balancer belonging to the target user in the predetermined cloud server.

[0116] When a target load balancer belonging to the target customer has not been created in the predetermined cloud server, a target load balancer belonging to the target user needs to be created in the predetermined cloud server. Optionally, in one implementation, the creation interface for the load balancer provided by the predetermined cloud server can be called to create a target load balancer belonging to the target user in the predetermined cloud server.

[0117] In the solution provided in this embodiment, a target load balancer belonging to the target user is created in the predetermined cloud server only when a target load balancer belonging to the target customer has not been created in the predetermined cloud server. If there is a created target load balancer belonging to the target customer in the predetermined cloud server, the target load balancer can be directly determined, so that the customer does not need to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the case where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0118] Optionally, in one embodiment, the above configuration information further includes: first auxiliary information; where the first auxiliary information is used to characterize whether the service uses an existing load balancer for routing services.

[0119] For different requirements of customers, it is possible to configure whether the service uses an existing load balancer for routing services through the first auxiliary information. Among them, the first auxiliary information can be a pre-agreed parameter used to represent whether the service uses an existing load balancer for routing services. For example, if the first auxiliary information is a shared parameter, it indicates that the service uses an existing load balancer for routing services. If the first auxiliary information is an independent parameter, it indicates that the service does not use an existing load balancer for routing services. Among them, the shared parameter and the independent parameter are two different parameters, or one is empty and the other is non-empty, which is acceptable.

[0120] For example, the first auxiliary information is recorded as kubernetes.io / ingress.exist-lb-id. If this parameter is non-empty, it indicates that the service uses an existing load balancer for routing services. If this parameter is empty, it indicates that the service uses a non-existing load balancer for routing services.

[0121] At this time, based on Figure 3 the embodiment of Figure 5 as shown, before the above S302, the information configuration method provided by another embodiment of the present invention further includes:

[0122] S304, detecting whether the first auxiliary information indicates that the service uses an existing load balancer for routing services.

[0123] Among them, from the foregoing content, it is possible to detect whether the first auxiliary information indicates that the service uses an existing load balancer for routing services according to the pre-agreed correspondence between the first auxiliary information and whether to use an existing load balancer for routing services.

[0124] For example, the first auxiliary information is recorded as kubernetes.io / ingress.exist-lb-id. If it is detected that kubernetes.io / ingress.exist-lb-id is non-empty, it is determined that the service uses an existing load balancer for routing services. Conversely, if it is detected that kubernetes.io / ingress.exist-lb-id is empty, it is determined that the service does not use an existing load balancer for routing services.

[0125] If the first auxiliary information indicates that the service uses an existing load balancer for routing services, then perform the step of determining the target load balancer belonging to the target customer located in the predetermined cloud server, that is, perform the above step S302.

[0126] If the first auxiliary information indicates that the service does not use an existing load balancer for routing services, a new load balancer needs to be generated. At this time, step S305 can be executed.

[0127] S305. Create a load balancer in a predetermined cloud server; among them, the created load balancer belongs to the target customer and is a load balancer that only routes services for each service of the Kubernetes cluster.

[0128] Among them, a load balancer of an independent type can be created in the predetermined cloud server. Its specific creation method is similar to that of creating the target load balancer, that is, creating a listener of the independent type, and the specific process will not be elaborated here.

[0129] S306. Send the routing rule information as the information to be configured of the created load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the created load balancer.

[0130] It is the same as or similar to step S303 and will not be elaborated here.

[0131] In the solution provided in this embodiment, since the above target load balancer is a load balancer used to implement the routing services of each Kubernetes cluster of the target customer, therefore, configuring the routing rule information of the above service in the target load balancer can enable the routing services of the above Kubernetes cluster to be implemented through this target load balancer. Thus, for the above Kubernetes cluster, it is no longer necessary to configure a separate load balancer to implement the routing service. For the situation where multiple routing services need to be deployed in the same Kubernetes cluster for the same customer, or multiple Kubernetes clusters are deployed, since the target load balancer located in the predetermined cloud server can implement the routing services of the same or different Kubernetes clusters of the same customer, it enables the customer not to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the situation where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0132] Optionally, in an embodiment, the above configuration information further includes: second auxiliary information; among them, the second auxiliary information is: network traffic limiting information configured for the public network IP of the load balancer utilized by the service.

[0133] The above network traffic limiting information may include information such as the allowed access bandwidth and / or billing type of the public network IP of the utilized load balancer.

[0134] At this time, in another embodiment of the present invention, the information configuration method further includes:

[0135] Determine the public network IP of the target load balancer; wherein, the public network IP of the target load balancer is: after the target load balancer is created, the predetermined cloud server assigns it for the target load balancer;

[0136] If it is detected that the second auxiliary information is empty, use the default value to set the network traffic limiting information of the public network IP of the target load balancer;

[0137] If the second auxiliary information exists, use the second auxiliary information to set the network traffic limiting information of the public network IP of the target load balancer.

[0138] Among them, the default value can be the default network traffic limiting value.

[0139] The above public network IP of the target load balancer can be assigned by the predetermined cloud server. For example, such as 36.7.72.139.

[0140] Optionally, if the determined network traffic limiting information of the public network IP is empty or inconsistent with the second auxiliary information, it indicates that the target load balancer may be newly created or modified. Then, according to the second auxiliary information in the configuration information, use the second auxiliary information to set the network traffic limiting information of the public network IP of the target load balancer.

[0141] For example, the network traffic limiting information of the public network IP of this target load balancer in the configuration information is: the allowed access bandwidth is 100M, and the billing type is billing by traffic. If it is detected that the network traffic limiting information of the public network IP of the target load balancer does not match the configuration information, then set the access bandwidth of the public network IP of the target load balancer to 100M, and the billing type is billing by traffic.

[0142] The predetermined cloud server can implement network traffic limiting processing on the load balancer with this public network IP by setting the network traffic limiting information for this public network IP.

[0143] In the solution provided in this embodiment, since the above-mentioned target load balancer is a load balancer used to implement the routing services of each Kubernetes cluster of the target customer, therefore, configuring the routing rule information of the above-mentioned service in the target load balancer can enable the routing services of the above-mentioned Kubernetes clusters to be implemented through this target load balancer. Thus, for the above-mentioned Kubernetes clusters, there is no need to configure a separate load balancer to implement the routing service. For the situation where multiple routing services need to be deployed in the same Kubernetes cluster for the same customer, or multiple Kubernetes clusters are deployed, since the target load balancer located in the predetermined cloud server can implement the routing services of the same or different Kubernetes clusters of the same customer, it enables the customer not to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of users can be reduced, and at the same time, the management cost of Kubernetes clusters can also be reduced. In addition, for the situation where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0144] Furthermore, by configuring network traffic limiting information for the load balancer, the predetermined cloud server can perform network traffic limiting processing on the load balancer with this public network IP through the network traffic limiting information set for this public network IP, so as to make full use of the advantageous functions such as traffic control of the predetermined cloud server, enhancing the management ability of the load balancer.

[0145] To more clearly elaborate on the technical solution of the embodiments of the present invention, the embodiments of the present invention will be further described below with examples.

[0146] Optionally, in one embodiment, the above-mentioned configuration information can be implemented through a YAML file. Optionally, the code in the configured YAML file is as follows:

[0147] apiVersion:extensions / v1beta1

[0148] kind:Ingress

[0149] metadata:

[0150] annotations:

[0151] kubernetes.io / ingress.class:ksyun

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

[0153] kubernetes.io / ingress.eip - charge - type: PostPaidByPeak

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

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

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

[0157] "80"}}]'

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

[0159] "servicePort": "80"}}]'

[0160] kubernetes.io / ingress.public: "false"

[0161] name: ingress001

[0162] namespace: default

[0163] spec:

[0164] rules:

[0165] - host: test111.com

[0166] http:

[0167] paths:

[0168] -backend:

[0169] serviceName:nginx

[0170] servicePort:80

[0171] path: /

[0172] -host:test222.com

[0173] http:

[0174] paths:

[0175] -backend:

[0176] serviceName:tomcat

[0177] servicePort:80

[0178] path: /

[0179] The first auxiliary information referred to in the embodiments of the present invention may include the above kubernetes.io / ingress.exist-lb-id parameter. If it is detected that kubernetes.io / ingress.exist-lb-id is non-empty, it is determined that the service uses an existing load balancer for routing services. Conversely, if it is detected that kubernetes.io / ingress.exist-lb-id is empty, it is determined that the service does not use an existing load balancer for routing services.

[0180] The second auxiliary information referred to in the embodiments of the present invention may include the above kubernetes.io / ingress.eip-bandwidth-in-mbp parameter and kubernetes.io / ingress.eip-charge-type parameter. Among them, the kubernetes.io / ingress.eip-bandwidth-in-mbp parameter is used to set the allowable bandwidth of the load balancer. The above kubernetes.io / ingress.eip-charge-type parameter is used to set the billing type of the public network bandwidth of the load balancer.

[0181] Optionally, the configuration information may further include parameters of kubernetes.io / ingress.http-rules: and kubernetes.io / ingress.https-rules: to distinguish whether the access type of the access request is HTTP or HTTPS, and both access types are also supported.

[0182] As Figure 6 shown, it is a schematic diagram of the connection relationship between the predetermined cloud server and the Kubernetes cluster provided by the embodiment of the present invention. After the customer creates an Ingress through the above YAML file, the routing controller can monitor the generation of the Ingress object through the APISever, and configure a new load balancer as the target load balancer or configure an existing target load balancer on the predetermined cloud server. Thus, the automatic deployment of the load balancer is realized.

[0183] Next, from the perspective of any load balancer in the predetermined cloud server, a request processing method provided by the embodiment of the present invention will be introduced.

[0184] In the load balancer, routing rule information of each service provided by at least one Kubernetes cluster is pre-configured according to the above information configuration method, and at least one Kubernetes cluster belongs to the same target customer.

[0185] As Figure 7 shown, an information configuration method provided by the embodiment of the present invention includes:

[0186] S701, receiving a target access request sent by an access end; wherein, service information of a service to be accessed is carried in the access request; the target access request is: an access request sent by the access end after obtaining the public network IP of the load balancer based on the service information of the service to be accessed; the service to be accessed is any service among the services provided by at least one Kubernetes cluster;

[0187] Wherein, the target access request is: an access request sent by the access end after obtaining the public network IP of the load balancer based on the service information of the service to be accessed. Optionally, when the access end accesses a domain name, the DNS (Domain Name System) service can determine the public network IP corresponding to the domain name according to the pre-established correspondence between the domain name and the public network IP, that is, the obtained public network IP of the load balancer. Then, a target access request is sent based on the determined public network IP.

[0188] Exemplarily, the service information of any service may include: the domain name used for accessing corresponding to the service, and the service path of the service. Optionally, the service path may be a service identifier, but of course it is not limited thereto.

[0189] S702. Forward the target access request based on the routing rule information according to the load balancing principle.

[0190] It should be noted that as mentioned above, the routing rule information may be the corresponding relationship between the service and the working node group, or the corresponding relationship between the service and the pod group implementing the service.

[0191] Optionally, in one implementation, when the routing rule information is the corresponding relationship with the working nodes, the above routing rule information includes: the first corresponding relationship between the service information of each service and the working node group to which the service belongs.

[0192] It should be noted that the working node group includes at least one working node. The representation form of the working node group in the first corresponding relationship may be: the combined content of the identifiers of each working node in the working node group and the access paths of each working node. The service information may include the domain name for accessing the service and the service path of the service. For example, the above service path may be a service identifier, such as Service 1 in the previous example. The working node group where the service is deployed is the combination of the nodes where the pods implementing the service are located. Taking Service 1 in the previous example as an example, Service 1 is implemented by pod1 and pod2 in Working Node 1 of Working Node Group 1, then the first corresponding relationship is the corresponding relationship between Service 1 and Working Node Group 1.

[0193] At this time, the above step S702 may include:

[0194] Determine the target working node group corresponding to the service information of the service to be accessed based on the first corresponding relationship;

[0195] Select the working node to be utilized from the target working node group according to the load balancing principle;

[0196] Send the target access request to the working node to be utilized.

[0197] Exemplarily, the Kubernetes cluster provides Service 2 externally, and this Service 2 can be implemented by Pods 3 and 4 in Worker Node 2 in Worker Node Group 1 and Pod 5 in Node 3 in Worker Node Group 2. Then, the first correspondence records the correspondence between Service 2 and Worker Node Group 2, so that the target worker node group can be determined based on the first correspondence. Further, according to the load balancing principle, a to-be-utilized worker node is selected from the target worker node group, that is, a to-be-utilized worker node is selected from Worker Node Group 2. If Worker Node 2 is selected as the to-be-utilized worker node, the target access request is sent to Worker Node 2.

[0198] Exemplarily, the to-be-utilized worker node can select a to-be-processed to-be-utilized Pod for this target access request through the load balancer for Pods inside the Kubernetes cluster, and forward the request to the to-be-utilized Pod to complete the response to the target access request through the to-be-utilized Pod.

[0199] Optionally, in another implementation manner, when the routing rule information is the correspondence between a service and a Pod group, the above routing rule information includes: service information about each service and a second correspondence between the Pod group where the service is deployed. Among them, the Pod group where the service is deployed can be represented in the second correspondence as: the combined content of the identifiers of each Pod in the Pod group and the access paths of each Pod.

[0200] It should be noted that the Pod group includes at least one Pod. The Pod group where the service is deployed is a combination of Pods that implement the service. Taking Service 2 in the previous example as an example, Service 2 can be implemented by Pods 3 and 4 in Worker Node 2 and Pod 5 in Node 3, then Service 2 is deployed on Pods 3, 4, and 5, that is, the Pod group 1 where Service 2 is deployed includes Pods 3, 4, and 5. Then the second correspondence is the correspondence between Service 2 and Pod group 1.

[0201] At this time, the above step S702 may include:

[0202] Based on the second correspondence, determine the target Pod group corresponding to the service information of the to-be-accessed service;

[0203] According to the load balancing principle, select a to-be-utilized Pod from the target Pod group;

[0204] Forward the target access request to the to-be-utilized Pod.

[0205] Exemplarily, taking Service 2 as an example, the pods to which Service 2 belongs recorded in the second corresponding relationship are Pod3, Pod4, and Pod5. Pod3, Pod4, and Pod5 are located in Pod Group 1. Then, the second corresponding relationship is the corresponding relationship between Service 2 and Pod Group 1, and thus the target Pod Group 1 is determined as the target pod group. Further, according to the load balancing principle, the to-be-utilized working nodes are selected from Pod Group 1, that is, the to-be-utilized pods are selected from Pod3, Pod4, and Pod5. If Pod4 is selected as the to-be-utilized pod, the target access request is forwarded to Pod4.

[0206] In the solution provided in this embodiment, it is possible to implement the routing of external requests for accessing the services provided by the Kubernetes cluster. Additionally, since the load balancer is preconfigured with the routing rule information of each service provided by at least one Kubernetes cluster, the load balancer can provide routing services for multiple services simultaneously. Thus, the customer does not need to configure a new load balancer for each Kubernetes cluster, reducing the number of load balancers that the target customer needs to manage.

[0207] To more clearly illustrate the technical solution of the embodiments of the present invention, the embodiments of the present invention are further described below with reference to actual cases.

[0208] Figure 8 This is a schematic diagram of the request processing flow provided by the embodiments of the present invention. In the figure, the shared load server is any load balancer in the predetermined cloud server. After the access end enters the access protocol + domain name + path (such as https: / / www.application1.com / app) in the browser, the DNS service resolves the domain name into the public network IP + port number of the load balancer, so that the load balancer can receive the access request from the access end, and then determine the to-be-utilized working node or to-be-utilized pod according to the service to be accessed by the access end, and forward the access request to the utilized working node or to-be-utilized pod.

[0209] Corresponding to the information configuration method provided from the perspective of the routing controller in the Kubernetes cluster as described above, as Figure 9 shown, the embodiments of the present invention further provide an information configuration device applied to the routing controller in the Kubernetes cluster. The device includes:

[0210] An information acquisition module 901, configured to acquire the configuration information for the services provided by the Kubernetes cluster; wherein, the configuration information at least includes the routing rule information of the service.

[0211] An equalizer determination module 902, configured to determine a target load balancer belonging to a target customer in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is a load balancer used to implement the routing service for each Kubernetes cluster of the target customer;

[0212] An information configuration module 903, configured to send routing rule information as information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

[0213] In one embodiment, the equalizer determination module is specifically configured to detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server; if it has been created, determine the target load balancer belonging to the target customer; if it has not been created, create a target load balancer belonging to the target user in the predetermined cloud server.

[0214] In one embodiment, the configuration information further includes: first auxiliary information; where the first auxiliary information is used to indicate whether the service uses an existing load balancer for routing services;

[0215] The apparatus further includes:

[0216] An information detection module, configured to detect whether the first auxiliary information indicates that the service uses an existing load balancer for routing services before the equalizer determination module executes the determination of the target load balancer belonging to the target customer in the predetermined cloud server; if the first auxiliary information indicates that the service uses an existing load balancer for routing services, then call the equalizer determination module to execute the step of determining the target load balancer belonging to the target customer in the predetermined cloud server.

[0217] In one embodiment, the apparatus further includes:

[0218] An equalizer creation module, configured to, if the first auxiliary information indicates that the service does not use an existing load balancer for routing services, create a load balancer in the predetermined cloud server; where the created load balancer is a load balancer belonging to the target customer and only used for routing services for each service of the Kubernetes cluster; send the routing rule information as information to be configured for the created load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the created load balancer.

[0219] In one embodiment, the configuration information further includes: second auxiliary information; where the second auxiliary information is: network flow limiting information configured for the public IP of the load balancer used by the service;

[0220] The apparatus further includes:

[0221] An IP determination module is used to determine the public network IP of the target load balancer; wherein, the public network IP of the target load balancer is: after the target load balancer is created, the predetermined cloud server assigns it to the target load balancer; if it is detected that the network throttling information of the determined public network IP is empty or inconsistent with the second auxiliary information, the network throttling information of the public network IP of the target load balancer is set by using the second auxiliary information.

[0222] In one embodiment, the network throttling information includes: the allowed access bandwidth and / or the charging type.

[0223] In the solution provided in this embodiment, since the above-mentioned target load balancer is a load balancer used to implement the routing services of each Kubernetes cluster of the target customer, therefore, by configuring the routing rule information of the above-mentioned service in the target load balancer, the routing services of the above-mentioned Kubernetes cluster can be realized through the target load balancer. Thus, for the above-mentioned Kubernetes cluster, there is no need to configure a separate load balancer to realize the routing service. For the situation where multiple routing services need to be deployed in the same Kubernetes cluster for the same customer, or multiple Kubernetes clusters need to be deployed, since the target load balancer located in the predetermined cloud server can realize the routing services of the same or different Kubernetes clusters of the same customer, the customer does not need to configure a separate load balancer for each Kubernetes cluster, greatly reducing the number of load balancers. It can be seen that through this solution, the resource cost of the user can be reduced, and at the same time, the management cost of the Kubernetes cluster can also be reduced. In addition, for the situation where the target load balancer is located in the predetermined cloud server provided by the cloud provider, the security and stability of the target load balancer can be better guaranteed, and the maintenance cost can also be greatly reduced.

[0224] Corresponding to the request processing method provided from the perspective of any load balancer in the predetermined cloud server as described above, as Figure 10 shown, the embodiment of the present invention further provides a request processing device, which is applied to a routing controller in a Kubernetes cluster. The load balancer is pre-configured with the routing rule information of each service provided by at least one Kubernetes cluster according to the above information configuration method, and at least one Kubernetes cluster belongs to the same target customer; the method includes. The device includes:

[0225] A request receiving module 1001, configured to receive a target access request sent by an access end; wherein, service information of a service to be accessed is carried in the access request; the target access request is: an access request sent by the access end after obtaining the public network IP of the load balancer based on the service information of the service to be accessed; the service to be accessed is any one of the services provided by at least one Kubernetes cluster.

[0226] A request forwarding module 1002, configured to forward the target access request based on routing rule information according to the load balancing principle.

[0227] In one embodiment, the routing rule information includes: a first correspondence between the service information of each service and the working node group to which the service belongs.

[0228] Specifically, the request forwarding module is configured to determine a target working node group corresponding to the service information of the service to be accessed based on the first correspondence; select a working node to be utilized from the target working node group according to the load balancing principle; and send the target access request to the working node to be utilized.

[0229] In one embodiment, the routing rule information includes: a second correspondence between the service information of each service and the pod group in which the service is deployed.

[0230] Specifically, the request forwarding module is configured to determine a target pod group corresponding to the service information of the service to be accessed based on the second correspondence; select a pod to be utilized from the target pod group according to the load balancing principle; and forward the target access request to the pod to be utilized.

[0231] In the solution provided in this embodiment, routing for external requests used to access the services provided by the Kubernetes cluster can be implemented. On the other hand, since the routing rule information of the services provided by at least one Kubernetes cluster is pre-configured in the load balancer, the load balancer can provide routing services for multiple services at the same time. Furthermore, the customer does not need to configure a new load balancer for each Kubernetes cluster, reducing the number of load balancers that the target customer needs to manage.

[0232] An embodiment of the present invention further provides an electronic device, as Figure 11 shown, including a processor 1101, a communication interface 1102, a memory 1103, and a communication bus 1104. Among them, the processor 1101, the communication interface 1102, and the memory 1103 complete communication with each other through the communication bus 1104.

[0233] The memory 1103 is used to store a computer program.

[0234] The processor 1101, when executing the program stored in the memory 1103, implements the steps of the above-mentioned information configuration method provided from the perspective of the routing controller in the Kubernetes cluster, or the steps of the request processing method provided from the perspective of any load balancer in the predetermined cloud server.

[0235] The communication bus mentioned in the above electronic device may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity, only a thick line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0236] The communication interface is used for communication between the above electronic device and other devices.

[0237] The memory may include Random Access Memory (RAM), and may also include Non-Volatile Memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located far from the aforementioned processor.

[0238] The above-mentioned processor may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0239] In another embodiment provided by the present invention, there is also provided a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the steps of any of the above-mentioned information configuration methods or any of the request processing methods are implemented.

[0240] In another embodiment provided by the present invention, there is also provided a computer program product containing instructions, which when running on a computer, causes the computer to execute any of the information configuration methods or any of the request processing methods in the above embodiments.

[0241] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

[0242] It should be noted that, in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including", or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or device that includes a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "including a..." does not exclude the presence of additional identical elements in the process, method, article, or device that includes the element.

[0243] Each embodiment in this specification is described in a related manner. For the same or similar parts between the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for device, equipment, and system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and reference can be made to the corresponding parts of the method embodiments for the relevant content.

[0244] The above are only the preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included within the protection scope of the present invention.

Claims

1. An information configuration method, characterized in that, A routing controller applied to a Kubernetes cluster, the method comprising: Obtain configuration information for the services provided by the Kubernetes cluster; wherein, the configuration information at least includes routing rule information for the services; Determine a target load balancer belonging to a target customer located in a predetermined cloud server, wherein the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is a load balancer for implementing the routing services of each Kubernetes cluster of the target customer; the predetermined cloud server is a cloud server provided by a cloud provider, and different customers configure different load balancers in the predetermined cloud server; Send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

2. The method according to claim 1, wherein The determining a target load balancer belonging to a target customer located in a predetermined cloud server includes: Detect whether a target load balancer belonging to the target customer has been created in the predetermined cloud server; If it has been created, determine the target load balancer belonging to the target customer; If it has not been created, create a target load balancer belonging to the target user in the predetermined cloud server.

3. The method according to claim 1 or 2, characterized in that, The configuration information further includes: first auxiliary information; wherein, the first auxiliary information is used to characterize whether the service uses an existing load balancer for routing services; Before the determining a target load balancer belonging to a target customer located in a predetermined cloud server, it further includes: Detect whether the first auxiliary information characterizes that the service uses an existing load balancer for routing services; If the first auxiliary information characterizes that the service uses an existing load balancer for routing services, then perform the step of determining a target load balancer belonging to a target customer located in a predetermined cloud server.

4. The method according to claim 3, characterized in that, The method further includes: If the first auxiliary information characterizes that the service does not use an existing load balancer for routing services, then create a load balancer in the predetermined cloud server; wherein, the created load balancer is a load balancer belonging to the target customer and only used for routing services for each service of the Kubernetes cluster; Send the routing rule information as the information to be configured for the created load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the created load balancer.

5. The method according to claim 2, characterized in that, The configuration information further includes: second auxiliary information; wherein, the second auxiliary information is network traffic limiting information configured for the public IP of the load balancer utilized by the service; The method further includes: Determine the public IP of the target load balancer; wherein, the public IP of the target load balancer is: after the target load balancer is created, the predetermined cloud server assigns it for the target load balancer; If the network traffic limiting information of the determined public network IP is empty, the network traffic limiting information of the public network IP of the target load balancer is set using the default value; When the second auxiliary information exists, the network traffic limiting information of the public network IP of the target load balancer is set using the second auxiliary information.

6. The method according to claim 5, wherein The network traffic limiting information includes: the allowed access bandwidth and / or the billing type.

7. A request processing method, characterized in that, Applied to any load balancer in a predetermined cloud server; the predetermined cloud server is a cloud server provided by a cloud provider, and different customers configure different load balancers in the predetermined cloud server; the load balancer is pre-configured with the routing rule information of each service provided by at least one Kubernetes cluster according to any one of claims 1-6, and the at least one Kubernetes cluster belongs to the same target customer; the method includes: Receiving a target access request sent by an access end; wherein, the access request carries the service information of the service to be accessed; the target access request is: the access request sent by the access end after obtaining the public network IP of the load balancer based on the service information of the service to be accessed; the service to be accessed is any one of the services provided by the at least one Kubernetes cluster; Based on the routing rule information, forwarding the target access request according to the load balancing principle.

8. The method according to claim 7, wherein The routing rule information includes: the first correspondence between the service information of each service and the working node group to which the service belongs; The forwarding the target access request according to the load balancing principle based on the routing rule information includes: Based on the first correspondence, determining the target working node group corresponding to the service information of the service to be accessed; Selecting the working node to be utilized from the target working node group according to the load balancing principle; Sending the target access request to the working node to be utilized.

9. The method according to claim 7, characterized in that The routing rule information includes: the second correspondence between the service information of each service and the pod group in which the service is deployed; The forwarding the target access request according to the load balancing principle based on the routing rule information includes: Based on the second correspondence, determining the target pod group corresponding to the service information of the service to be accessed; Selecting the pod to be utilized from the target pod group according to the load balancing principle; Forwarding the target access request to the pod to be utilized.

10. An information configuration device, characterized in that, Applied to a routing controller in a Kubernetes cluster, the device includes: An information acquisition module, configured to acquire the configuration information for the services provided by the Kubernetes cluster; wherein, the configuration information at least includes the routing rule information of the services. An equalizer determination module, configured to determine a target load balancer belonging to a target customer in a predetermined cloud server, where the target customer is the customer to which the Kubernetes cluster belongs, and the target load balancer is a load balancer for implementing the routing services of each Kubernetes cluster of the target customer; the predetermined cloud server is a cloud server provided by a cloud provider, and different customers configure different load balancers in the predetermined cloud server; an information configuration module, configured to send the routing rule information as the information to be configured for the target load balancer to the predetermined cloud server, so that the predetermined cloud server configures the routing rule information in the target load balancer.

11. A request processing device, characterized in that, Applied to any load balancer in a predetermined cloud server; the predetermined cloud server is a cloud server provided by a cloud provider, and different customers configure different load balancers in the predetermined cloud server; the load balancer is preconfigured with the routing rule information of each service provided by at least one Kubernetes cluster according to any one of the methods in claims 1-6, and the at least one Kubernetes cluster belongs to the same target customer; the apparatus includes: A request receiving module, configured to receive a target access request sent by an access end; where the access request carries service information of the service to be accessed; the target access request is: an access request sent by the access end after obtaining the public IP of the load balancer based on the service information of the service to be accessed; the service to be accessed is any one of the services provided by the at least one Kubernetes cluster. A request forwarding module, configured to forward the target access request based on the routing rule information according to the load balancing principle.

12. An electronic device, characterized in that, Including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus; The memory is used to store a computer program; The processor, when executing the program stored in the memory, implements the method steps of any one of claims 1-6, or the method steps of any one of claims 7-8.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, it implements the method steps of any one of claims 1-6, or the method steps of any one of claims 7-8.

Images