Method and apparatus for implementing service request based on Kubernetes

Abstract

The application discloses a service request implementation method based on Kubernetes, which is applied to a client. After receiving a to-be-served request, a subscription instruction is sent to Kubernetes, wherein the subscription instruction is used to instruct Kubernetes to send a service node list corresponding to the to-be-served request to the client, and the service node list is used to store running information of a plurality of service nodes corresponding to the to-be-served request. The client receives the service node list sent by the Kubernetes, determines at least one target service node corresponding to the to-be-served request in the plurality of service nodes according to the service node list through a load balancer, and sends an execution request to the Kubernetes according to the at least one target service node, wherein the execution request is used to request the Kubernetes to execute the to-be-served request based on the at least one target service node. In this way, the application can implement the to-be-served request between the client and the Kubernetes without modifying the source code corresponding to the to-be-served request.

Description

Technical Field

[0001] This invention relates to the field of container technology, and in particular to a method and apparatus for implementing service requests based on Kubernetes. Background Technology

[0002] In a Kubernetes-based microservice architecture, communication between multiple services typically relies on Kubernetes' built-in Service resources and CoreDNS. Specifically, services are accessed via their virtual IP addresses and domain names, and the service node pod is determined using a default load balancing strategy. However, for specific service requests, such as TCP long-connection service requests, after the above method identifies the service node pod and establishes a connection, subsequent related requests will be consistently routed to the same service node pod. This leads to uneven load distribution across other service nodes, thus impacting overall service efficiency.

[0003] Therefore, to solve the above problems, an independent service registry, such as Zookeeper, Nacos, or Consul, can be introduced. When the service node corresponding to the TCP long-connection service starts, it actively registers with the service registry and deregisters when it goes offline, thereby effectively avoiding the problem of uneven load on other service nodes affecting the overall service efficiency.

[0004] However, using existing technologies, for other established third-party service requests (such as Remote Dictionary Server, Redis), the source code is difficult to modify and cannot be adapted to the client's service registry, resulting in the inability to effectively implement third-party service requests. Summary of the Invention

[0005] The purpose of this invention is to provide a service request implementation method based on Kubernetes, which solves the problem in the prior art that other established third-party service requests (such as Remote Dictionary Server, Redis) cannot be effectively implemented because their source code is difficult to modify and cannot be adapted to the client's service registry.

[0006] To achieve the above objectives, in a first aspect, embodiments of the present invention provide a service request implementation method based on Kubernetes, applied to a client, the method comprising: Upon receiving a pending service request, a subscription instruction is sent to Kubernetes. The subscription instruction instructs Kubernetes to send a list of service nodes corresponding to the pending service request to the client. The list of service nodes is used to store the running information of multiple service nodes corresponding to the pending service request. The system receives the list of service nodes sent by Kubernetes and uses a load balancer to determine at least one target service node corresponding to the request to be served from among the multiple service nodes based on the list of service nodes. An execution request is sent to the Kubernetes based on the at least one target service node, wherein the execution request is used to request the Kubernetes to execute the pending service request based on the at least one target service node.

[0007] In one embodiment, determining at least one target service node corresponding to the request to be served from among the plurality of service nodes by a load balancer based on the service node list includes: The load balancer determines at least one target service node corresponding to the request to be served, based on the service node list and the preset service node scheduling policy.

[0008] In one embodiment, the preset service node scheduling strategy includes: round-robin scheduling, weighted round-robin scheduling, consistent hashing scheduling, broadcast scheduling, and minimum connection count scheduling. The step of determining at least one target service node corresponding to the request to be served, based on the service node list and the preset service node scheduling strategy, through a load balancer, includes: Determine the application business scenario corresponding to the request to be served; Based on the application business scenario, the target service node scheduling strategy is determined using the round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hash scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy. The load balancer determines at least one target service node corresponding to the request to be served, based on the service node list and the target service node scheduling policy.

[0009] In one embodiment, the method further includes: Receive and respond to the change instruction sent by Kubernetes, and update the service node list; After the service node list is updated, the load balancer updates at least one target service node corresponding to the pending request based on the updated service node list.

[0010] Secondly, embodiments of the present invention provide a service request implementation method based on Kubernetes, applied to Kubernetes, the method comprising: Receive and respond to the subscription instruction sent by the client, and send the list of service nodes corresponding to the pending service request to the client; Receive and respond to execution requests sent by clients, and execute pending service requests based on at least one target service node.

[0011] In one embodiment, before receiving and responding to the subscription instruction sent by the client and sending the service node list to the client, the method further includes: For the pending service request, create multiple service nodes and a list of service nodes corresponding to the multiple service nodes; Based on the Service resource, the service node list is identified to determine the logical group identifier corresponding to the service node list.

[0012] In one embodiment, receiving and responding to the subscription instruction sent by the client, and sending the service node list to the client, includes: The system receives and responds to subscription instructions sent by the client, determines the list of service nodes corresponding to the pending service request based on the logical group identifier, and sends the list of service nodes to the client.

[0013] In one embodiment, the method further includes: When changes are detected in multiple service nodes corresponding to the pending request, a change instruction is sent to the client. The change instruction is used to indicate to the client that the multiple service nodes corresponding to the current pending request have changed and to update the service node list.

[0014] Thirdly, embodiments of the present invention provide a Kubernetes-based service request implementation apparatus, applied to a client, comprising: The subscription instruction sending module is used to send a subscription instruction to Kubernetes after receiving a service request. The subscription instruction is used to instruct Kubernetes to send a list of service nodes corresponding to the service request to the client. The list of service nodes is used to store the running information of multiple service nodes corresponding to the service request. The target service node determination module is used to receive the service node list sent by Kubernetes, and determine at least one target service node corresponding to the service request from the plurality of service nodes according to the service node list through the load balancer. An execution request sending module is configured to send an execution request to the Kubernetes based on the at least one target service node, wherein the execution request is used to request the Kubernetes to execute the pending service request based on the at least one target service node.

[0015] Fourthly, embodiments of the present invention provide a service request implementation apparatus based on Kubernetes, applied to Kubernetes, comprising: The service node list sending module is used to receive and respond to the subscription instruction sent by the client, and send the service node list corresponding to the service request to the client. The pending service request execution module is used to receive and respond to execution requests sent by clients, and execute pending service requests based on at least one target service node.

[0016] The technical solution provided by the embodiments of the present invention has the following advantages compared with the prior art: This invention provides a Kubernetes-based service request implementation method applied to a client. Upon receiving a service request, the client sends a subscription instruction to Kubernetes. This instruction instructs Kubernetes to send a list of service nodes corresponding to the service request to the client. The service node list stores the runtime information of multiple service nodes corresponding to the service request. The client receives the service node list from Kubernetes and, through a load balancer, determines at least one target service node corresponding to the service request from among the multiple service nodes. Based on the at least one target service node, the client sends an execution request to Kubernetes, requesting Kubernetes to execute the service request based on the at least one target service node. In this way, this invention can implement service requests between the client and Kubernetes without modifying the source code corresponding to the service request. This avoids the problem in existing technologies where, for other established third-party service requests, the source code is difficult to modify and cannot be adapted to the client's service registry, resulting in the inability to effectively implement third-party service requests. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 A flowchart illustrating a service request implementation method based on Kubernetes provided in an embodiment of the present invention; Figure 2A flowchart illustrating another Kubernetes-based service request implementation method provided in this embodiment of the invention; Figure 3 A schematic diagram of a Kubernetes-based service request implementation device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of another Kubernetes-based service request implementation device provided in an embodiment of the present invention. Detailed Implementation

[0018] To facilitate a clear description of the technical solutions in the embodiments of the present invention, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. For example, the first threshold and the second threshold are merely used to distinguish different thresholds and do not limit their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0019] It should be noted that in this invention, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0020] In this invention, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between the associated objects, indicating that three relationships can exist.

[0021] like Figure 1 As shown, Figure 1 This invention provides a flowchart illustrating a Kubernetes-based service request implementation method applied to a client, specifically including the following steps: S10: Upon receiving a service request, send a subscription command to Kubernetes.

[0022] The subscription command instructs Kubernetes to send a list of service nodes corresponding to the pending service request to the client. The service node list stores the running information of multiple service nodes corresponding to the pending service request. This running information can be, for example, the Internet Protocol Address (IP address) of each service node pod. It should be noted that multiple service nodes are currently in an idle state, that is, service nodes that can serve pending service requests.

[0023] Specifically, after the client receives the pending service request input by the user, it sends a subscription instruction to Kubernetes in response to the pending service request. This subscription instruction instructs Kubernetes to send the list of service nodes corresponding to the pending service request to the client. Upon receiving and responding to the subscription instruction, Kubernetes sends the list of service nodes corresponding to the pending service request to the client, so that the client can subscribe to the running information of multiple service nodes corresponding to the current pending service request based on the service node list.

[0024] It should be noted that the service node list has a logical group identifier, which is used to identify the current service node list as the service node list corresponding to the pending request. The logical group identifier is created by Kubernetes Service resources for one or more service node pods of the pending request that have been deployed by Kubernetes StatefulSet or Deployment resources.

[0025] S11: Receive the list of service nodes sent by Kubernetes, and determine at least one target service node corresponding to the request to be served from among multiple service nodes based on the list of service nodes through the load balancer.

[0026] A load balancer is a service node deployed on a local client to determine at least one target service node for a request to be served.

[0027] Specifically, after receiving the list of service nodes sent by Kubernetes, the client further uses the load balancer to determine at least one target service node corresponding to the request to be served from among multiple service nodes based on the list of service nodes.

[0028] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S11 may be: S111: Using a load balancer, at least one target service node is determined based on the service node list and the preset service node scheduling policy.

[0029] The preset service node scheduling strategy refers to the strategy that, given multiple service nodes stored in the service node list, can select one or more target service nodes that are most suitable for the pending request. This preset service node scheduling strategy includes: round-robin scheduling, weighted round-robin scheduling, consistent hashing scheduling, broadcast scheduling, and minimum connection count scheduling.

[0030] The above round-robin scheduling strategy distributes pending requests sequentially to different service nodes. The weighted round-robin scheduling strategy assigns different weights based on the performance or load capacity of each service node. The consistent hashing scheduling strategy determines at least one target service node based on the session stickiness of the pending request or the application business scenario of caching the client's local environment. The broadcast scheduling strategy identifies all available target service nodes and sends the pending request to all available target service nodes. The minimum connection number scheduling strategy determines the service node with the fewest current connections as one or more target service nodes for the pending request.

[0031] Specifically, after receiving the list of service nodes sent by Kubernetes, the client further determines one or more target service nodes corresponding to the request to be served from among multiple service nodes based on the load balancer, the list of service nodes, and the preset service node scheduling policy.

[0032] Optionally, based on the above embodiments, since the preset service node scheduling strategy includes: round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hash scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy, in some embodiments of the present invention, one implementation of S111 can be: S1111: Determine the application business scenario corresponding to the request to be served.

[0033] S1112: Based on the application business scenario, determine the target service node scheduling strategy from the round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hash scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy.

[0034] Specifically, for a pending request, the client obtains the application business scenario corresponding to the pending request. Furthermore, after determining the application business scenario corresponding to the pending request, the client determines the target service node scheduling strategy based on the application business scenario, using round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hash scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy.

[0035] S1113: Using a load balancer, determine at least one target service node corresponding to the request to be served, based on the service node list and the target service node scheduling policy.

[0036] Specifically, after obtaining the current target service node scheduling policy for the pending request, the client further determines one or more target service nodes corresponding to the pending request from multiple service nodes based on the load balancer, the service node list, and the target service node scheduling policy.

[0037] S12: Send an execution request to Kubernetes based on at least one target service node.

[0038] The execution request is used to request Kubernetes to execute the service request based on at least one target service node.

[0039] Specifically, after the client determines one or more target service nodes corresponding to the service request among multiple service nodes, it sends an execution request to Kubernetes based on at least one target service node, requesting Kubernetes to execute the service request based on at least one target service node.

[0040] Thus, the Kubernetes-based service request implementation method provided in this embodiment is applied to the client. Upon receiving a service request, the client sends a subscription instruction to Kubernetes. This subscription instruction instructs Kubernetes to send a list of service nodes corresponding to the service request to the client. The service node list stores the runtime information of multiple service nodes corresponding to the service request. The client receives the service node list sent by Kubernetes and, through a load balancer, determines at least one target service node corresponding to the service request from among the multiple service nodes. Based on the at least one target service node, the client sends an execution request to Kubernetes, requesting Kubernetes to execute the service request based on the at least one target service node. In this way, the present invention can implement service requests between the client and Kubernetes without modifying the source code corresponding to the service request. This avoids the problem in the prior art where, for other established third-party service requests, the source code is difficult to modify and cannot be adapted to the client's service registry, resulting in the inability to effectively implement third-party service requests.

[0041] Optionally, based on the above embodiments, since service node Pods on Kubernetes can come online, go offline, or have changing states, some embodiments of the present invention further include: S13: Receive and respond to change instructions sent by Kubernetes, and update the list of service nodes.

[0042] The change indication is used to indicate changes to multiple service nodes corresponding to the client's current pending request, and to update the service node list.

[0043] Specifically, the client receives change instructions from Kubernetes. Based on these instructions, it can determine that multiple service nodes corresponding to the current pending request have changed, and then update the current service node list.

[0044] S14: After updating the service node list, the load balancer updates at least one target service node corresponding to the pending request based on the updated service node list.

[0045] Specifically, after updating the list of service nodes corresponding to the service request, the load balancer determines at least one target service node corresponding to the service request based on the updated list of service nodes.

[0046] In this way, this embodiment can obtain the list of service nodes corresponding to the pending service request in real time, and determine at least one target service node corresponding to the pending service request based on the real-time service node list, thereby improving the real-time performance and accuracy of the pending service request and ensuring the correct routing of traffic.

[0047] like Figure 2 As shown, Figure 2 This is a flowchart illustrating another service request implementation method based on Kubernetes provided in an embodiment of the present invention. Applied to Kubernetes, it specifically includes the following steps: S20: Receive and respond to the subscription instruction sent by the client, and send the list of service nodes corresponding to the pending service request to the client.

[0048] Specifically, when Kubernetes receives a subscription command from a client, it responds by sending a list of service nodes corresponding to the pending service request to the client, so that the client can subscribe to the running information of multiple service nodes corresponding to the current pending service request based on the service node list.

[0049] Optionally, based on the above embodiments, in some embodiments of the present invention, the method further includes the following step before performing S20: S30: For pending service requests, create multiple service nodes and a list of service nodes corresponding to those service nodes.

[0050] Specifically, for pending service requests, deployment is carried out using Kubernetes StatefulSet or Deployment resources to create multiple service nodes corresponding to the pending service requests, as well as a service node list that stores the running information of multiple service nodes.

[0051] S31: Based on the Service resource, the service node list is identified to determine the logical group identifier corresponding to the service node list.

[0052] Specifically, after creating multiple service nodes corresponding to the pending service requests and a service node list that stores the running information of multiple service nodes, the Kubernetes Service resource is used to identify the service node list and determine the logical group identifier corresponding to the service node list.

[0053] Optionally, based on the above embodiments, in some embodiments of the present invention, one implementation of S20 may be: S201: Receive and respond to the subscription instruction sent by the client, determine the list of service nodes corresponding to the service request based on the logical group identifier, and send the list of service nodes to the client.

[0054] Specifically, when Kubernetes receives a subscription command from a client and responds to it, it determines the list of service nodes corresponding to the pending service request based on the logical group identifier, and sends the determined list of service nodes corresponding to the pending service request to the client so that the client can subscribe to the running information of multiple service nodes corresponding to the current pending service request based on the service node list.

[0055] S21: Receive and respond to the execution request sent by the client, and execute the pending service request based on at least one target service node.

[0056] Specifically, when Kubernetes receives an execution request from a client and responds to the request, it executes the service request based on executing at least one target service node.

[0057] Thus, the Kubernetes-based service request implementation method provided in this embodiment, applied to Kubernetes, receives and responds to subscription instructions sent by clients, and sends a list of service nodes corresponding to the pending service request to the client. It also receives and responds to execution requests sent by clients, executing the pending service request based on at least one target service node. In this way, the present invention can implement pending service requests between the client and Kubernetes without modifying the source code corresponding to the pending service request. This avoids the problem in existing technologies where, for other established third-party service requests, the source code is difficult to modify and cannot be adapted to the client's service registry, resulting in the inability to effectively implement third-party service requests.

[0058] Optionally, based on the above embodiments, since service node Pods on Kubernetes can come online, go offline, or have changing states, some embodiments of the present invention further include: S22: When changes are detected in multiple service nodes corresponding to pending requests, a change instruction is sent to the client.

[0059] The change indication is used to indicate changes to multiple service nodes corresponding to the client's current pending request, and to update the service node list.

[0060] Specifically, when Kubernetes detects changes in multiple service nodes corresponding to a pending request, it sends a change notification to the client, informing the client that the multiple service nodes corresponding to the pending request have changed, and instructing the client to update the list of service nodes corresponding to the pending request.

[0061] In this way, this embodiment enables the client to obtain the list of service nodes corresponding to the pending service request in real time, and determine at least one target service node corresponding to the pending service request based on the real-time service node list, thereby improving the real-time performance and accuracy of the pending service request and ensuring the correct routing of traffic.

[0062] It should be understood that, although Figures 1-2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0063] In one embodiment, such as Figure 3 As shown, a service request implementation device based on Kubernetes is provided for application on a client, including: a subscription instruction sending module 10, a target service node determination module 11, and an execution request sending module 12.

[0064] The subscription instruction sending module 10 is used to send a subscription instruction to Kubernetes after receiving a service request. The subscription instruction is used to instruct Kubernetes to send a list of service nodes corresponding to the service request to the client. The list of service nodes is used to store the running information of multiple service nodes corresponding to the service request.

[0065] The target service node determination module 11 is used to receive a list of service nodes sent by Kubernetes, and determine at least one target service node corresponding to the request to be served from multiple service nodes based on the list of service nodes through the load balancer.

[0066] The execution request sending module 12 is used to send an execution request to Kubernetes based on at least one target service node, wherein the execution request is used to request Kubernetes to execute the service request based on at least one target service node.

[0067] In the above embodiments, after receiving a service request, the subscription instruction sending module sends a subscription instruction to Kubernetes. This subscription instruction instructs Kubernetes to send a list of service nodes corresponding to the service request to the client. The service node list stores the runtime information of multiple service nodes corresponding to the service request. The target service node determination module receives the service node list sent by Kubernetes and, through a load balancer, determines at least one target service node corresponding to the service request from among the multiple service nodes. The execution request sending module sends an execution request to Kubernetes based on the at least one target service node. This execution request requests Kubernetes to execute the service request based on the at least one target service node. In this way, the present invention can implement service requests between the client and Kubernetes without modifying the source code corresponding to the service request. This avoids the problem in existing technologies where, for other established third-party service requests, the source code is difficult to modify and cannot be adapted to the client's service registry, resulting in the inability to effectively implement third-party service requests.

[0068] In one embodiment, such as Figure 4 As shown, another service request implementation device based on Kubernetes is provided, which is applied to Kubernetes and includes: a service node list sending module 20 and a service request execution module 21.

[0069] The service node list sending module 20 is used to receive and respond to the subscription instruction sent by the client, and send the service node list corresponding to the service request to the client.

[0070] The pending service request execution module 21 is used to receive and respond to the execution request sent by the client, and execute the pending service request based on at least one target service node.

[0071] In the above embodiments, the service node list sending module receives and responds to the subscription instruction sent by the client, and sends the service node list corresponding to the pending service request to the client. The pending service request execution module receives and responds to the execution request sent by the client, and executes the pending service request based on at least one target service node. In this way, the present invention can implement pending service requests between the client and Kubernetes without modifying the source code corresponding to the pending service request, avoiding the problem in the prior art where other established third-party service requests cannot be effectively implemented due to the difficulty in modifying their source code and their inability to adapt to the client's service registry.

[0072] For specific limitations regarding the Kubernetes-based service request implementation mechanism, please refer to the limitations of the Kubernetes-based service request implementation method described above, which will not be repeated here. Each module in the aforementioned server can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0073] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static random access memory (SRAM) and dynamic random access memory (DRAM), etc.

[0074] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0075] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A service request implementation method based on Kubernetes, characterized in that, Applied to a client, the method includes: Upon receiving a pending service request, a subscription instruction is sent to Kubernetes. The subscription instruction instructs Kubernetes to send a list of service nodes corresponding to the pending service request to the client. The list of service nodes is used to store the running information of multiple service nodes corresponding to the pending service request. The system receives the list of service nodes sent by Kubernetes and uses a load balancer to determine at least one target service node corresponding to the request to be served from among the multiple service nodes based on the list of service nodes. An execution request is sent to the Kubernetes based on the at least one target service node, wherein the execution request is used to request the Kubernetes to execute the pending service request based on the at least one target service node.

2. The method according to claim 1, characterized in that, The step of determining at least one target service node corresponding to the request to be served from among the plurality of service nodes by the load balancer according to the service node list includes: The load balancer determines at least one target service node corresponding to the request to be served, based on the service node list and the preset service node scheduling policy.

3. The method according to claim 2, characterized in that, The preset service node scheduling strategy includes: round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hashing scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy. The step of determining at least one target service node corresponding to the request to be served by the load balancer based on the service node list and the preset service node scheduling strategy includes: Determine the application business scenario corresponding to the request to be served; Based on the application business scenario, the target service node scheduling strategy is determined using the round-robin scheduling strategy, weighted round-robin scheduling strategy, consistent hash scheduling strategy, broadcast scheduling strategy, and minimum connection number scheduling strategy. The load balancer determines at least one target service node corresponding to the request to be served, based on the service node list and the target service node scheduling policy.

4. The method according to claim 1, characterized in that, The method further includes: Receive and respond to the change instruction sent by Kubernetes, and update the service node list; After the service node list is updated, the load balancer updates at least one target service node corresponding to the pending request based on the updated service node list.

5. A method for implementing service requests based on Kubernetes, characterized in that, When applied to Kubernetes, the method includes: Receive and respond to the subscription instruction sent by the client, and send the list of service nodes corresponding to the pending service request to the client; Receive and respond to execution requests sent by clients, and execute pending service requests based on at least one target service node.

6. The method according to claim 5, characterized in that, Before receiving and responding to the subscription instruction sent by the client and sending the service node list to the client, the method further includes: For the pending service request, create multiple service nodes and a list of service nodes corresponding to the multiple service nodes; Based on the Service resource, the service node list is identified to determine the logical group identifier corresponding to the service node list.

7. The method according to claim 6, characterized in that, The step of receiving and responding to the subscription instruction sent by the client, and sending the service node list to the client, includes: The system receives and responds to subscription instructions sent by the client, determines the list of service nodes corresponding to the pending service request based on the logical group identifier, and sends the list of service nodes to the client.

8. The method according to claim 7, characterized in that, The method further includes: When changes are detected in multiple service nodes corresponding to the pending request, a change instruction is sent to the client. The change instruction is used to indicate to the client that the multiple service nodes corresponding to the current pending request have changed and to update the service node list.

9. A service request implementation device based on Kubernetes, characterized in that, Applied to the client side, including: The subscription instruction sending module is used to send a subscription instruction to Kubernetes after receiving a service request. The subscription instruction is used to instruct Kubernetes to send a list of service nodes corresponding to the service request to the client. The list of service nodes is used to store the running information of multiple service nodes corresponding to the service request. The target service node determination module is used to receive the service node list sent by Kubernetes, and determine at least one target service node corresponding to the service request from the plurality of service nodes according to the service node list through the load balancer. An execution request sending module is configured to send an execution request to the Kubernetes based on the at least one target service node, wherein the execution request is used to request the Kubernetes to execute the pending service request based on the at least one target service node.

10. A service request implementation device based on Kubernetes, characterized in that, Applied to Kubernetes, including: The service node list sending module is used to receive and respond to the subscription instruction sent by the client, and send the service node list corresponding to the service request to the client. The pending service request execution module is used to receive and respond to execution requests sent by clients, and execute pending service requests based on at least one target service node.

Images