Request scheduling method, apparatus, device, and storage medium

Abstract

The application discloses a request scheduling method and device, equipment and storage medium, and relates to the technical field of computers. The request scheduling method comprises the following steps: monitoring a service request sent by a client to a domain name server; determining a main target container cluster and a disaster recovery target container cluster from at least two container clusters according to the service request; sending a first internal domain name of a target service corresponding to the service request in the main target container cluster to the domain name server, so that the domain name server determines an IP address corresponding to the first internal domain name; and when monitoring that a connection between the client and the target service is disconnected, sending a second internal domain name of a disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server, so that the domain name server determines an IP address that corresponds to the second internal domain name. The application can realize high availability, disaster recovery characteristics and continuity of data access.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a request scheduling method, apparatus, device, and storage medium. Background Technology

[0002] Kubernetes is an open-source container orchestration and scheduling system. A Kubernetes system consists of multiple Kubernetes clusters, each containing at least one service, and each service is composed of at least one pod.

[0003] When faced with data access requests, the Kubernetes system achieves disaster recovery for pods within the target cluster through load balancing in the target service, but it also faces the overall disaster recovery requirements of a single Kubernetes cluster. Summary of the Invention

[0004] The main objective of this invention is to provide a request scheduling method, apparatus, device, and storage medium, which aims to solve the technical problem of Kubernetes systems needing to achieve disaster recovery requirements for Kubernetes clusters.

[0005] To achieve the above objectives, the present invention provides a request scheduling method, which includes the following steps:

[0006] Monitor the service requests sent by the client to the domain name server;

[0007] Based on the service request, determine the primary target container cluster and the disaster recovery target container cluster from at least two container clusters; wherein the configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent.

[0008] Send the first internal domain name of the target service corresponding to the service request in the main target container cluster to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name;

[0009] When the connection between the client and the target service is detected to be lost, the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0010] Optionally, both the primary target container cluster and the disaster recovery target container cluster have priority values, and the priority value of the primary target container cluster is greater than that of the disaster recovery target container cluster.

[0011] Upon detecting a disconnection between the client and the target service, the steps of sending the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the second internal domain name, include:

[0012] When the connection between the client and the target service is detected to be lost, the priority value of the disaster recovery target container cluster is adjusted to the maximum to trigger the disaster recovery command to configure the disaster recovery target container cluster as the new primary target container cluster.

[0013] The first internal domain name of the target service corresponding to the service request in the main target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0014] Optionally, before the step of determining the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request, the method further includes:

[0015] Monitor configuration file update information for any of at least two container clusters; wherein the configuration file update information includes at least the internal domain name update information of the service in any of the container clusters.

[0016] Based on the configuration file update information, update the global resource information of at least two container clusters;

[0017] Based on global resource information, the configuration files of all container clusters in at least two container clusters are updated synchronously.

[0018] Optionally, configuration file update information includes:

[0019] Add information to the configuration file; and / or

[0020] Configuration file change information.

[0021] Optionally, after determining the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request, the method further includes:

[0022] Identify the target primary service and target backup service corresponding to the service request in the primary target container cluster, and the disaster recovery target primary service and disaster recovery target backup service corresponding to the service request in the disaster recovery target container cluster;

[0023] Based on the preset load balancing strategy, the target service corresponding to the service request is determined from the target primary service and the target backup service;

[0024] The steps of sending the first internal domain name of the target service corresponding to the service request in the primary target container cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name, include:

[0025] Based on the preset load balancing strategy, the target service corresponding to the service request is determined from the target primary service and the target backup service;

[0026] Send the first internal domain name of the target service to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name;

[0027] When a connection between the client and the target service is detected to be lost, the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name. This includes the following steps:

[0028] When the connection between the client and the target service is detected to be lost, the target disaster recovery service corresponding to the service request is determined from the primary target disaster recovery service and the backup target disaster recovery service according to the preset load balancing strategy.

[0029] Send the second internal domain name of the disaster recovery target service to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0030] Secondly, the present invention provides a request scheduling method for a client, the method comprising the following steps:

[0031] A service request is sent to the domain name server so that the container system can determine the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request. The first internal domain name of the target service corresponding to the service request in the primary target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name. The configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent.

[0032] Receive the IP address corresponding to the first internal domain name and access the target service;

[0033] After the connection with the target service is broken, the IP address corresponding to the second internal domain name sent by the domain name server is received, and the disaster recovery target service in the disaster recovery target container cluster corresponding to the second internal domain name is accessed, where the disaster recovery target service corresponds to the service request.

[0034] Thirdly, the present invention provides a request scheduling apparatus, comprising:

[0035] The request detection module is used to monitor service requests sent by the client to the domain name server;

[0036] The cluster determination module is used to determine the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request; wherein the configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent.

[0037] The first sending module is used to send the first internal domain name of the target service corresponding to the service request in the main target container cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0038] The second sending module is used to send the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server when the connection between the client and the target service is detected to be disconnected, so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0039] Fourthly, the present invention provides a request scheduling device for use in a client, the request scheduling device comprising:

[0040] The request sending module is used to send a service request to the domain name server so that the container system can determine the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request, and send the first internal domain name of the target service corresponding to the service request in the primary target container cluster to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name; wherein, the configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent.

[0041] The first receiving module is used to receive the IP address corresponding to the first internal domain name and access the target service;

[0042] The second receiving module is used to receive the IP address corresponding to the second internal domain name sent by the domain name server after the connection with the target service is broken, and to access the disaster recovery target service in the disaster recovery target container cluster corresponding to the second internal domain name; wherein, the disaster recovery target service corresponds to the service request.

[0043] Fifthly, the present invention also provides a request scheduling device, comprising: a memory, a processor, and a request scheduling program stored in the memory and executable on the processor, wherein the processor implements the method described above when performing request scheduling.

[0044] In a sixth aspect, the present invention also provides a computer storage medium storing a request scheduler, wherein when the processor executes the request scheduler, it implements the request scheduling method as described above.

[0045] This invention proposes a request scheduling method that, upon detecting a service request sent by a client to a domain name server, determines a primary target Kubernetes container cluster and a disaster recovery target Kubernetes container cluster from at least two Kubernetes container clusters. Upon detecting a disconnection between the client and the target service, the method sends the second internal domain name of the disaster recovery target service corresponding to the service request from the disaster recovery target Kubernetes container cluster to the domain name server. This allows the domain name server to determine the IP address corresponding to the second internal domain name. Thus, among the at least two Kubernetes container clusters that the client wishes to access, there exists a primary target Kubernetes container cluster and a disaster recovery target Kubernetes container cluster that mutually support each other, thereby achieving high availability and disaster recovery characteristics of the target service, as well as continuity of data access. Attached Figure Description

[0046] Figure 1 This is an adaptive architecture diagram of the system involved in the scheduling method of the present invention;

[0047] Figure 2 This is a schematic diagram of the structure of the scheduling device requested by the present invention;

[0048] Figure 3 This is a flowchart illustrating the first embodiment of the request scheduling method of the present invention;

[0049] Figure 4 This is a flowchart illustrating the second embodiment of the request scheduling method of the present invention;

[0050] Figure 5 This is a flowchart illustrating the third embodiment of the request scheduling method of the present invention;

[0051] Figure 6 This is a flowchart illustrating the fourth embodiment of the request scheduling method of the present invention;

[0052] Figure 7 This is a flowchart illustrating the fifth embodiment of the request scheduling method of the present invention;

[0053] Figure 8 This is a functional module diagram of the first embodiment of the request scheduling device of the present invention;

[0054] Figure 9 This is a schematic diagram of the functional modules of the second embodiment of the request scheduling device of the present invention.

[0055] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0056] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0057] Kubernetes is an open-source container orchestration and scheduling system. A Kubernetes system consists of multiple Kubernetes clusters, each containing at least one service, and each service is composed of at least one pod. However, in related technologies, when clients access the Kubernetes system, the system only considers the high availability and disaster recovery features of the pods within the Kubernetes cluster, but does not consider the high availability and disaster recovery features of the Kubernetes cluster itself.

[0058] To address this, this invention provides a request scheduling method. When a service request sent by a client to a domain name server is detected, a primary target Kubernetes cluster and a disaster recovery target Kubernetes cluster are determined from the Kubernetes system. When the connection between the client and the target service is lost, the client can access the disaster recovery target Kubernetes cluster, thereby achieving high availability and disaster recovery features for the target service.

[0059] The inventive concept of this application will be further illustrated below using a Kubernetes cluster as an example of a container cluster.

[0060] This invention illustrates a first embodiment of a request scheduling method. See also... Figure 3 , Figure 3 This is a flowchart illustrating the first embodiment of the request scheduling method of the present invention.

[0061] In this embodiment, the request scheduling method is applied to a Kubernetes system. The Kubernetes system includes at least two Kubernetes clusters, some of which may be deployed on local servers and others on remote servers. For any given service, at least two Kubernetes clusters in the Kubernetes system are configured with that service. The Kubernetes clusters provide services externally through access interfaces. In this embodiment, the Kubernetes system may deploy a remote access controller, which may be an Ingress controller, to serve as the entry point for all traffic from the Kubernetes system.

[0062] In Kubernetes, a cluster refers to a collection of cloud resources required for container operation, comprising several servers, each with a Kubernetes cluster deployed on it. A Pod (instance) consists of one or more related containers that share the same storage and network space. A Node (worker node) is a resource object in a Kubernetes cluster used to manage the creation, scheduling, and automated lifecycle control of Pod replicas. A Service represents a microservice consisting of multiple identically configured Pod instances and the rules governing access to these Pod instances.

[0063] In this embodiment, the request scheduling method is used on an external access controller and includes the following steps:

[0064] Step S101: Monitor the service requests sent by the client to the domain name server.

[0065] The External Access Controller listens for various events across the Kubernetes clusters within the Kubernetes system, including but not limited to external access creation, Pod scaling, and Pod shrinking. It can store these monitored events in its message queue. When a client sends a service request to a domain name server, the External Access Controller can detect the creation of that external access.

[0066] A domain name server can operate independently of the Kubernetes system to obtain the IP addresses corresponding to the internal virtual domain names of services within the Kubernetes cluster. Alternatively, the domain name server can also be the Core DNS server within the Kubernetes system.

[0067] Step S102: Based on the service request, determine the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters.

[0068] The configuration files for the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are identical.

[0069] See Figure 1The external access controller configures disaster recovery for service requests, identifying a primary target Kubernetes cluster and a disaster recovery target Kubernetes cluster from multiple Kubernetes clusters. The configuration files for the primary and disaster recovery target Kubernetes clusters are identical. This consistency means that the interfaces, service members, load balancing strategies, and rules of the two clusters are the same, allowing them to provide the same services. Therefore, the primary and disaster recovery target Kubernetes clusters can act as mutual backups. Generally, a Kubernetes cluster on a local server can be selected as the primary configuration, and a Kubernetes cluster on a remote server can be selected as the disaster recovery configuration.

[0070] It is worth mentioning that there is only one primary target Kubernetes cluster, but the disaster recovery target Kubernetes cluster may include one or more, and this embodiment does not limit this.

[0071] Step S103: Send the first internal domain name of the target service corresponding to the service request in the main target Kubernetes cluster to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0072] Step S104: When the connection between the client and the target service is detected to be disconnected, the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target Kubernetes cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0073] The external access controller first sends the first internal domain name of the target service corresponding to the service request in the primary target Kubernetes cluster to the domain name server. The domain name server then obtains the IP address corresponding to this first internal domain name and returns it to the client, enabling the client to access the target service, which then processes the service request. If the primary target Kubernetes cluster experiences a network outage, power failure, or other unexpected event, the external access controller can still detect the event and respond by sending the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target Kubernetes cluster to the domain name server. The domain name server obtains the IP address corresponding to the second internal domain name and returns the new IP address to the client, enabling the client to access the disaster recovery target service.

[0074] The first or second internal domain name is the VIP (Virtual IP Address) address or VIP PORT (Virtual Interface) address of the service. The domain name server resolves the corresponding IP address based on the VIP address of the target service and returns it to the client. The client then accesses the internal service within the Kubernetes cluster corresponding to that IP address. This initiates disaster recovery configuration, and the Kubernetes system continues to provide service support to the client.

[0075] In one specific embodiment shown, both the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster in the external access controller have priority values, and the priority value of the primary target Kubernetes cluster is greater than that of the disaster recovery target Kubernetes cluster. Among multiple Kubernetes clusters, the Kubernetes cluster with the highest priority is the primary target Kubernetes cluster, and one or more Kubernetes clusters with lower priorities are the disaster recovery target Kubernetes clusters.

[0076] At this point, step S104 includes the following steps:

[0077] Step A10: When the connection between the client and the target service is detected to be lost, adjust the priority value of the disaster recovery target Kubernetes cluster to the maximum to trigger the sending of a disaster recovery command to configure the disaster recovery target Kubernetes cluster as the new primary target Kubernetes cluster.

[0078] When the external access controller detects that the connection between the client and the target service is lost, it stores the information in its own message queue, adjusts the priority of the disaster recovery target Kubernetes cluster to the highest level to trigger the disaster recovery command, thereby changing the disaster recovery target Kubernetes cluster to the new primary target Kubernetes cluster. It can also configure the disaster recovery target service corresponding to the service request in the disaster recovery target Kubernetes cluster as the new target service.

[0079] Step A20: Send the first internal domain name of the target service corresponding to the service request in the primary target Kubernetes cluster to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0080] The external access controller sends the modified first internal domain name of the target service to the domain name server, enabling the domain name server to determine the IP address corresponding to the first internal domain name. At this point, the client can obtain the modified IP address from the domain name server, thus accessing the disaster recovery target service to continue processing service requests. Using priority management for the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster facilitates the management of multiple disaster recovery target Kubernetes clusters.

[0081] In this embodiment, the Kubernetes system configures a primary target Kubernetes cluster and a disaster recovery target Kubernetes cluster for the client's service requests. This not only achieves disaster recovery and high availability within the Kubernetes cluster as described in related technologies, but also achieves disaster recovery and high availability between Kubernetes clusters, ensuring the continuity of the client's access data stream.

[0082] Based on the first embodiment of the request scheduling method of the present invention, a second embodiment of the request scheduling method of the present invention is proposed. (See attached document) Figure 4 , Figure 4 This is a flowchart illustrating the second embodiment of the request scheduling method of the present invention.

[0083] The configuration files for the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are identical. This embodiment illustrates a method to ensure that the Kubernetes system has the ability to select between the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster.

[0084] In this embodiment, the steps preceding step S102 include:

[0085] Step S10: Monitor the configuration file update information of any Kubernetes cluster in the Kubernetes system.

[0086] The configuration file update information includes, but is not limited to, information added to the configuration file and information changed to the configuration file. Information added to the configuration file can be the configuration information of any newly created service within the Kubernetes cluster, such as internal domain names. Information changed to the configuration file can be the internal domain name of any service within the Kubernetes cluster after changes. In addition, the configuration file update information may also include information such as changes to load balancing strategies.

[0087] The external access controller connects to the APIs (Application Programming Interfaces) of multiple Kubernetes clusters. When the Kubernetes cluster API detects the creation of a new service within the Kubernetes cluster, it retrieves the configuration information of the newly created service. Alternatively, when the Kubernetes cluster API detects a change to a service within the Kubernetes cluster, it retrieves the configuration information of the changed service.

[0088] Step S20: Update the global resource information of the Kubernetes system based on the configuration file update information.

[0089] Global information resources include VIPs or ports of services within the Kubernetes system, service members, load balancing policies, rules, and other resources used by a single cluster. The external access controller compares the configuration file update information of any Kubernetes cluster with the global resource information of the Kubernetes system, and then updates the global resource information of the Kubernetes system accordingly.

[0090] If the newly added VIP and VIP PORT are not present in the global resource information, the addition mode will be used to synchronize the global resource information. If the VIP and VIP PORT already exist in the global resource information, the update mode will be used, comparing the global resource information with the configuration file update information to identify differences, and then updating the global resource information based on these differences.

[0091] Step S30: Based on global resource information, synchronously update the configuration files of all Kubernetes clusters in the Kubernetes system.

[0092] After the global resource information is updated, the configuration files of all Kubernetes clusters in the Kubernetes system can be updated. This ensures the consistency of all Kubernetes clusters in the Kubernetes system, providing disaster recovery configuration for client service requests. If any Kubernetes cluster fails and cannot provide service, other Kubernetes clusters can serve as disaster recovery configurations to provide disaster recovery services, realizing multi-cluster service, high availability, and disaster recovery features for external traffic in dual-center or even multi-center Kubernetes clusters.

[0093] Based on the first and second embodiments of the request scheduling method of the present invention, a third embodiment of the request scheduling method of the present invention is proposed. (See also...) Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the request scheduling method of the present invention.

[0094] In this embodiment, the request scheduling method includes the following steps:

[0095] Step S301: Monitor the service requests sent by the client to the domain name server.

[0096] Step S302: Based on the service request, determine the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters.

[0097] Step S303: Determine the target primary service and target backup service in the primary target Kubernetes cluster corresponding to the service request, and the disaster recovery target primary service and disaster recovery target backup service in the disaster recovery target Kubernetes cluster corresponding to the service request.

[0098] See Figure 1 In this step, the external access controller also configures a primary target service and a backup target service on the primary target Kubernetes cluster, with the primary and backup target services acting as each other's primary and backup services. Simultaneously, the external access controller also configures a primary disaster recovery service and a backup disaster recovery service on the disaster recovery target Kubernetes cluster, with the primary and backup disaster recovery target services acting as each other's primary and backup services.

[0099] Step S304: Based on the preset load balancing strategy, determine the target service corresponding to the service request from the target primary service and the target backup service.

[0100] Step S305: Send the first internal domain name of the target service to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0101] Step S306: When the connection between the client and the target service is detected to be disconnected, the disaster recovery target service corresponding to the service request is determined from the primary disaster recovery target service and the backup disaster recovery target service according to the preset load balancing strategy.

[0102] Step S307: Send the second internal domain name of the disaster recovery target service to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0103] Load balancing strategies include: load averaging, weighted strategies, least connections strategies, round-robin strategies, IPhash strategies, etc.

[0104] Load averaging strategy refers to averaging the load across target services in a Kubernetes cluster; weighted strategy mainly calculates weights based on the response time of target services and selects target services based on the weights, with shorter response times having a higher probability of being selected; least connections strategy load balances based on the current connection status of target services, selecting the target service with the fewest current connections to handle client access data streams; round-robin strategy distributes access data streams to target services in the Kubernetes cluster in turn; IPhash strategy directs access data streams with the same source IP address to the same target service.

[0105] Therefore, the external access controller can determine the target service corresponding to the service request from the target primary service and target backup service when a client accesses the primary target Kubernetes cluster, based on a preset load balancing strategy. Conversely, when the primary target Kubernetes cluster disconnects, it determines the disaster recovery target service corresponding to the service request from the disaster recovery target primary service and disaster recovery target backup service. The target service and the disaster recovery target service then invoke the POD (Point of Deployment) across multiple clusters through load balancing.

[0106] This invention uses an external access controller for multi-cluster central scheduling, which not only enables disaster recovery configuration between multiple Kubernetes clusters, but also enables load balancing of services in multiple Kubernetes clusters. It can distribute client access data streams to multiple clusters, ensuring high availability of services within the Kubernetes cluster and continuity of access data streams.

[0107] Furthermore, this invention also provides a fourth embodiment of the request scheduling method for a client. See also... Figure 6 , Figure 6 This is a flowchart illustrating the fourth embodiment of the present invention.

[0108] In this embodiment, the method includes the following steps:

[0109] Step S401: Send a service request to the domain name server so that the Kubernetes system can determine the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters based on the service request, and send the first internal domain name of the target service corresponding to the service request in the primary target Kubernetes cluster to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0110] The configuration files for the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are identical.

[0111] Step S402: Receive the IP address corresponding to the first internal domain name and access the target service.

[0112] When the primary target Kubernetes cluster is functioning normally, the client can access the target services within the primary target Kubernetes cluster normally.

[0113] Step S403: After the connection with the target service is broken, receive the IP address corresponding to the second internal domain name sent by the domain name server, and access the disaster recovery target service in the disaster recovery target Kubernetes cluster corresponding to the second internal domain name.

[0114] Among them, the disaster recovery target service corresponds to the service request.

[0115] When the primary target Kubernetes cluster becomes unavailable due to unforeseen circumstances, the connection between the client and the target service is lost. At this time, the client can receive the IP address corresponding to the second internal domain name from the domain name server, thereby continuing to access the disaster recovery target service that can provide the same service, thus achieving continuity of data access.

[0116] Furthermore, the present invention also provides a fifth embodiment of the request scheduling method. See also... Figure 7 , Figure 7 This is a flowchart illustrating the fifth embodiment of the present invention.

[0117] In this embodiment, the method includes the following steps:

[0118] Step S501: The client sends a service request to the domain name server.

[0119] In step S502, when the Kubernetes system detects a service request sent by a client to the domain name server, it determines the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters based on the service request. The configuration files of the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are identical.

[0120] Step S503: The Kubernetes system sends the first internal domain name of the target service corresponding to the service request in the primary target Kubernetes cluster to the domain name server.

[0121] Step S504: The domain name server determines the IP address corresponding to the first internal domain name and sends the IP address back to the client.

[0122] Step S505: The client receives the IP address corresponding to the first internal domain name and accesses the target service.

[0123] Step S506: After the connection with the target service is broken, the Kubernetes system sends the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target Kubernetes cluster to the domain name server.

[0124] Step S507: The domain name server determines the IP address corresponding to the second internal domain name and sends the IP address back to the client.

[0125] Step S508: The client receives the IP address and accesses the disaster recovery target service.

[0126] In this embodiment of the invention, when a client accesses the Kubernetes system, the invention performs multi-cluster central scheduling through an external access controller in the Kubernetes system. This provides the client's service request with a primary target Kubernetes cluster that has load balancing, while simultaneously configuring a disaster recovery target Kubernetes cluster that provides the same service and has load balancing for failed service requests. This not only enables disaster recovery configuration between multiple Kubernetes clusters but also achieves load balancing of services within multiple Kubernetes clusters. It can distribute the client's access data stream across multiple clusters, ensuring high availability of services within the Kubernetes cluster and continuity of access data streams.

[0127] Reference Figure 8 This invention provides a first embodiment of a request scheduling device. This request scheduling device is deployed on a Kubernetes system. In this embodiment, the request scheduling device includes:

[0128] Request detection module 11 is used to monitor service requests sent by the client to the domain name server;

[0129] Cluster determination module 12 is used to determine the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters based on the service request; wherein the configuration files of the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are consistent.

[0130] The first sending module 13 is used to send the first internal domain name of the target service corresponding to the service request in the main target Kubernetes cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0131] The second sending module 14 is used to send the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target Kubernetes cluster to the domain name server when the connection between the client and the target service is detected to be disconnected, so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0132] As one option in this embodiment, both the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster in the Kubernetes system have priority values, and the priority value of the primary target Kubernetes cluster is greater than the priority value of the disaster recovery target Kubernetes cluster.

[0133] The second transmitting module 14 includes:

[0134] The adjustment module 141 is used to adjust the priority value of the disaster recovery target Kubernetes cluster to the maximum when the connection between the client and the target service is detected to be disconnected, so as to trigger the disaster recovery command to configure the disaster recovery target Kubernetes cluster as the new primary target Kubernetes cluster.

[0135] The domain name sending module 142 is used to send the first internal domain name of the target service corresponding to the service request in the main target Kubernetes cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0136] As an alternative to this embodiment, the request scheduling device further includes:

[0137] The internal monitoring module 15 is used to monitor the configuration file update information of any Kubernetes cluster in the Kubernetes system; the configuration file update information includes: configuration file addition information; and / or configuration file change information.

[0138] Resource update module 16 is used to update the global resource information of the Kubernetes system based on the configuration file update information;

[0139] System update module 17 is used to synchronously update the configuration files of all Kubernetes clusters in the Kubernetes system based on global resource information.

[0140] As an alternative to this embodiment, the request scheduling device further includes:

[0141] The service determination module is used to determine the target primary service and target backup service in the primary target Kubernetes cluster corresponding to the service request, as well as the disaster recovery target primary service and disaster recovery target backup service in the disaster recovery target Kubernetes cluster corresponding to the service request.

[0142] The first transmitting module 13 includes:

[0143] The first load balancing module 131 is used to determine the target service corresponding to the service request from the target primary service and the target backup service according to the preset load balancing strategy.

[0144] The second domain name sending module 132 is used to send the first internal domain name of the target service to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

[0145] The second transmitting module 14 includes:

[0146] The second load balancing module 143, when detecting that the connection between the client and the target service is broken, determines the disaster recovery target service corresponding to the service request from the disaster recovery target primary service and the disaster recovery target backup service according to the preset load balancing strategy.

[0147] The third domain name sending module 144 sends the second internal domain name of the disaster recovery target service to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

[0148] Reference Figure 9 The present invention provides a second embodiment of a request scheduling device. This request scheduling device is deployed on an external client.

[0149] The request sending module 21 is used to send a service request to the domain name server, so that the Kubernetes system can determine the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster from at least two Kubernetes clusters based on the service request, and send the first internal domain name of the target service corresponding to the service request in the primary target Kubernetes cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name; wherein, the configuration files of the primary target Kubernetes cluster and the disaster recovery target Kubernetes cluster are consistent;

[0150] The first receiving module 22 is used to receive the IP address corresponding to the first internal domain name and access the target service;

[0151] The second receiving module 23 is used to receive the IP address corresponding to the second internal domain name sent by the domain name server after the connection with the target service is broken, and to access the disaster recovery target service in the disaster recovery target Kubernetes cluster corresponding to the second internal domain name, wherein the disaster recovery target service corresponds to the service request.

[0152] Reference Figure 2 , Figure 2This is a schematic diagram of the recommended device structure for the request scheduling method involved in the embodiments of the present invention.

[0153] The blockchain-based key processing device includes at least one processor 301, a memory 302, and a request scheduler stored in the memory and executable on the processor, the request scheduler being configured to implement the steps of the request scheduling method as described above.

[0154] Processor 301 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 301 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 301 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 301 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen.

[0155] The memory 302 may include one or more computer-readable storage media, which may be non-transitory. The memory 302 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 302 are used to store at least one instruction, which is executed by the processor 301 to implement the request scheduling method provided in the method embodiments of this application.

[0156] Recommended equipment also includes a communication interface 303. The processor 301, memory 302, and communication interface 303 can be connected via a bus or signal lines. Various peripheral devices can be connected to the communication interface 303 via a bus, signal lines, or circuit boards.

[0157] The communication interface 303 can be used to connect at least one I / O (Input / Output) related peripheral device to the processor 301 and the memory 302. In some embodiments, the processor 301, the memory 302, and the communication interface 303 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 301, the memory 302, and the communication interface 303 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0158] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a limitation on the request scheduling device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0159] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a request scheduler, which, when executed by a processor, implements the steps of the request scheduling method described above. Therefore, further details will not be repeated here. Additionally, the beneficial effects of employing the same method will not be repeated. For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed to execute on a single computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0160] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0161] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0162] Through the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware, and of course, it can also be implemented by special hardware including application-specific integrated circuits, special CPUs, special memory, special components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for the present invention, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

Claims

1. A request scheduling method, characterized in that, The request scheduling method includes the following steps: Monitor the service requests sent by the client to the domain name server; Monitor the configuration file update information of any one of the container clusters in at least two container clusters. The container system contains several servers during runtime, and each server has at least two of the container clusters deployed on it. The global resource information of the container system is compared with the update information of the configuration file through an external accessor to obtain the difference items. The global resource information is updated through the difference items. The global resource information is a resource used by a single cluster. The container system includes at least two container clusters. Based on the updated global resource information, the configuration files of all container clusters in at least two container clusters are synchronously updated to ensure consistency among all container clusters in the container system. If any container cluster fails and cannot provide disaster recovery services, the other container clusters serve as disaster recovery configurations to provide disaster recovery services. Based on the service request, a primary target container cluster and a disaster recovery target container cluster are determined from at least two container clusters; wherein the configuration files of the primary target container cluster and the disaster recovery target container cluster are identical; The first internal domain name of the target service corresponding to the service request in the main target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name. When the connection between the client and the target service is detected to be broken, the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster is sent to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name. Wherein, both the primary target container cluster and the disaster recovery target container cluster have priority values, and the priority value of the primary target container cluster is greater than that of the disaster recovery target container cluster; the step of sending the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server when the connection between the client and the target service is detected to be disconnected includes: When the connection between the client and the target service is detected to be broken, the priority value of the disaster recovery target container cluster is adjusted to the maximum to trigger a disaster recovery instruction to configure the disaster recovery target container cluster as the new primary target container cluster, and the disaster recovery target service corresponding to the service request in the new primary target container cluster is configured as the new target service. The first internal domain name corresponding to the new service request is sent to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name.

2. The request scheduling method according to claim 1, characterized in that, The configuration file update information includes: Add information to the configuration file; and / or Configuration file change information.

3. The request scheduling method according to claim 1, characterized in that, After the step of determining the primary target container cluster and the disaster recovery target container cluster from at least two container clusters based on the service request, the method further includes: Identify the target primary service and target backup service in the primary target container cluster corresponding to the service request, and the disaster recovery target primary service and disaster recovery target backup service in the disaster recovery target container cluster corresponding to the service request; The step of sending the first internal domain name of the target service corresponding to the service request in the main target container cluster to the domain name server, so that the domain name server determines the IP address corresponding to the first internal domain name, includes: According to the preset load balancing strategy, the target service corresponding to the service request is determined from the target primary service and the target backup service; The first internal domain name of the target service is sent to the domain name server so that the domain name server can determine the IP address corresponding to the first internal domain name. The step of sending the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server when the connection between the client and the target service is detected to be disconnected, so that the domain name server can determine the IP address corresponding to the second internal domain name, includes: When the connection between the client and the target service is detected to be disconnected, the disaster recovery target service corresponding to the service request is determined from the primary disaster recovery target service and the backup disaster recovery target service according to the preset load balancing strategy. The second internal domain name of the disaster recovery target service is sent to the domain name server so that the domain name server can determine the IP address corresponding to the second internal domain name.

4. A request scheduling method, characterized in that, For use on a client, the method includes the following steps: A service request is sent to a domain name server, enabling the container system to determine a primary target container cluster and a disaster recovery target container cluster from at least two container clusters based on the service request. The primary target container cluster then sends the first internal domain name of the target service corresponding to the service request to the domain name server, allowing the domain name server to determine the IP address corresponding to the first internal domain name. The configuration files of the primary target container cluster and the disaster recovery target container cluster are identical. Before receiving the service request, the container system monitors the configuration file update information of any one of the at least two container clusters. The global resource information of the container system is compared with the configuration file update information using an external accessor to obtain differences. The global resource information is updated based on these differences. The global resource information is a resource used by a single cluster. The container system includes at least two container clusters. Based on the updated global resource information, the configuration files of all container clusters in the at least two container clusters are synchronously updated. The container system executes the request scheduling method as described in claim 1. Receive the IP address corresponding to the first internal domain name and access the target service; After the connection with the target service is broken, the system receives the IP address corresponding to the second internal domain name sent by the domain name server and accesses the disaster recovery target service in the disaster recovery target container cluster corresponding to the second internal domain name; wherein, the disaster recovery target service corresponds to the service request.

5. A request scheduling device, characterized in that, include: The request detection module is used to monitor service requests sent by the client to the domain name server; An internal monitoring module monitors the configuration file update information of any one of the at least two container clusters. The container system includes several servers during runtime, and each server has at least two of the container clusters deployed on it. The resource update module compares the global resource information of the container system with the update information of the configuration file through an external accessor to obtain the differences, and updates the global resource information based on the differences. The global resource information is a resource used by a single cluster, and the container system includes at least two container clusters. The system update module is used to synchronously update the configuration files of all container clusters in at least two container clusters based on the updated global resource information, so that all container clusters in the container system are consistent. When any container cluster fails and cannot provide disaster recovery services, the other container clusters serve as disaster recovery configurations to provide disaster recovery services. The cluster determination module is used to determine a primary target container cluster and a disaster recovery target container cluster from at least two container clusters based on the service request; wherein the configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent. The first sending module is used to send the first internal domain name of the target service corresponding to the service request in the main target container cluster to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name. The second sending module is used to send the second internal domain name of the disaster recovery target service corresponding to the service request in the disaster recovery target container cluster to the domain name server when the connection between the client and the target service is detected to be disconnected, so that the domain name server can determine the IP address corresponding to the second internal domain name. Wherein, both the primary target container cluster and the disaster recovery target container cluster have priority values, and the priority value of the primary target container cluster is greater than the priority value of the disaster recovery target container cluster; the second sending module includes: The adjustment module is used to adjust the priority value of the disaster recovery target container cluster to the maximum when it detects that the connection between the client and the target service is broken, so as to trigger a disaster recovery instruction to configure the disaster recovery target container cluster as a new primary target container cluster, and configure the disaster recovery target service corresponding to the service request in the new primary target container cluster as the new target service. The domain name sending module is used to send the first internal domain name corresponding to the new service request to the domain name server, so that the domain name server can determine the IP address corresponding to the first internal domain name.

6. A request scheduling device, characterized in that, For use in a client, the request scheduling device includes: A request sending module is configured to send a service request to a domain name server, so that the container system determines a primary target container cluster and a disaster recovery target container cluster from at least two container clusters based on the service request, and sends the first internal domain name of the target service corresponding to the service request in the primary target container cluster to the domain name server, so that the domain name server determines the IP address corresponding to the first internal domain name; wherein the configuration files of the primary target container cluster and the disaster recovery target container cluster are consistent; wherein, before receiving the service request, the container system monitors the configuration file update information of any one of the at least two container clusters; compares the global resource information of the container system with the configuration file update information through an external accessor to obtain differences, updates the global resource information through the differences, wherein the global information resources are resources used by a single cluster, and the container system includes at least two container clusters; based on the updated global resource information, synchronously updates the configuration files of all container clusters in the at least two container clusters, and the container system executes the request scheduling method as described in claim 1; The first receiving module is used to receive the IP address corresponding to the first internal domain name and access the target service; The second receiving module is used to receive the IP address corresponding to the second internal domain name sent by the domain name server after the connection with the target service is broken, and to access the disaster recovery target service in the disaster recovery target container cluster corresponding to the second internal domain name; wherein the disaster recovery target service corresponds to the service request.

7. A request scheduling device, characterized in that, include: A memory, a processor, and a request scheduler stored in the memory and executable on the processor, wherein the processor, when executing the request scheduler, implements the request scheduling method as described in any one of claims 1 to 4.

8. A computer storage medium, characterized in that, The computer storage medium stores a request scheduler, wherein when the processor executes the request scheduler, it implements the request scheduling method as described in any one of claims 1-4.

Images