Pod scheduling method based on network affinity

Abstract

The invention provides a pod scheduling method based on network affinity, and the method comprises the steps: obtaining a pod creation request carrying network affinity parameters, and determining an available working node corresponding to the pod creation request, the network affinity parameters comprising timeout seconds, a network target and a weight coefficient corresponding to the network target; the available working nodes are scored based on the network affinity parameters, in the scoring process, the available working nodes sequentially carry out network delay tests on the network targets and record test results, and network affinity scores of the available working nodes are determined according to overtime seconds, the test results and weight coefficients corresponding to the network targets; and determining the available working node with the highest network affinity score as a target working node, and scheduling the pod creation request to the target working node to respond to the pod creation request. According to the invention, the pod is scheduled based on network affinity.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a pod scheduling method based on network affinity. Background Art

[0002] A Kubernetes cluster consists of a control node and multiple worker nodes. The control node is used to manage and schedule cluster resources. The worker node is a resource provider, and the resource unit is pod. When an application publishes a request, the control node reasonably allocates the application's pod to the idle worker nodes based on the idle status of cluster resources, thereby making more reasonable and full use of cluster resources. The specific implementation of pod scheduling depends on the scheduler (i.e., Schedule) deployed on the control node. The main function of Schedule is to schedule pods to appropriate worker nodes based on specific scheduling algorithms and scheduling strategies.

[0003] Most existing scheduling algorithms and scheduling strategies tend to customize based on internal factors such as the resource usage of the working node itself, while ignoring external factors that affect the running speed of the working node, such as the network health status. In actual production scenarios, due to the different network environments in which the Kubernetes cluster is located, the network health status of the pods on different working nodes and the target network that needs to be connected during business operation is also different. Working nodes with poor network health status will affect the business operation speed of the pod. Therefore, there is an urgent need in the prior art for a scheduling strategy for pod scheduling based on network health status. Summary of the invention

[0004] The purpose of the present invention is to solve the problem that the influence of network health status is ignored in the existing pod scheduling strategy, and the working node with poor network health status will affect the running speed of pod business.

[0005] To achieve the above object, the present invention provides a pod scheduling method based on network affinity, comprising:

[0006] Obtain a pod creation request carrying a network affinity parameter, and determine an available working node corresponding to the pod creation request, wherein the network affinity parameter includes: a timeout in seconds, a network target and a weight coefficient corresponding to the network target;

[0007] Scoring the available working nodes based on the network affinity parameters, and in the scoring process, the available working nodes sequentially perform network delay tests on the network targets and record the test results, and determining the network affinity scores of the available working nodes according to the timeout seconds, the test results and the weight coefficients corresponding to the network targets;

[0008] An available working node with the highest network affinity score is determined as a target working node, and the pod creation request is scheduled to the target working node to respond to the pod creation request.

[0009] As a further improvement of the present invention, the obtaining of a pod creation request carrying a network affinity parameter and determining an available working node corresponding to the pod creation request includes:

[0010] The scheduler deployed on the control node monitors the API server in real time, and when a pod creation request is monitored, detects whether the pod creation request carries the network affinity parameter;

[0011] If yes, the scheduler determines the available working node corresponding to the pod creation request;

[0012] If not, the scheduler determines the target working node based on a preset scheduling strategy, and schedules the pod creation request to the target working node to respond to the pod creation request.

[0013] As a further improvement of the present invention, the scheduler determines the available working node corresponding to the pod creation request, including:

[0014] The pod creation request is parsed to obtain resource parameters required for the pod creation request, working nodes are filtered according to the resource parameters, and working nodes that meet the resource parameters are determined as available working nodes.

[0015] As a further improvement of the present invention, the available working nodes sequentially perform network delay tests on the network targets and record test results, including:

[0016] The available working nodes are connected to the network targets in sequence, a network delay time corresponding to a response of the network targets to the available working nodes is tested, and the network delay time is determined as the test result.

[0017] As a further improvement of the present invention, the timeout seconds refers to the maximum time that the available working node waits for the network target response;

[0018] When the available working node is connected to the network target, if the waiting time of the available working node exceeds the timeout seconds, the available working node is not connected to the network target, and the timeout seconds are determined as the test result.

[0019] As a further improvement of the present invention, determining the network affinity score of the available working node according to the timeout seconds, the test result and the weight coefficient corresponding to the network target includes:

[0020] Calculate a temporary score corresponding to the available working node according to the timeout seconds, the test result and the weight coefficient, and determine whether the temporary scores corresponding to multiple available working nodes are the same;

[0021] If yes, the network affinity score is calculated based on the temporary score, and the calculation formula is score / 2, where score refers to the temporary score;

[0022] If not, a conversion coefficient is calculated according to the temporary scores corresponding to the multiple available working nodes, and the network affinity score is calculated based on the conversion coefficient and the temporary score.

[0023] As a further improvement of the present invention, the calculation formula of the temporary score is:

[0024] score=x1*(ts-result1)+…+x n *(ts-result n );

[0025] Among them, x n and result n They respectively refer to the weight coefficient and test result corresponding to the nth network target, and ts refers to the timeout seconds.

[0026] As a further improvement of the present invention, the calculation formula of the conversion coefficient is:

[0027] score ratio=score max / (score max -score min );

[0028] Among them, score max It refers to the maximum value of the temporary scores corresponding to multiple available working nodes. min It refers to the minimum value of the temporary scores corresponding to multiple available working nodes, and score ratio refers to the conversion factor.

[0029] As a further improvement of the present invention, the calculation formula for calculating the network affinity score based on the conversion coefficient and the temporary score is:

[0030] NetworkAffinityScore=score ratio*(score-score min );

[0031] Among them, NetworkAffinityScore refers to the network affinity score.

[0032] As a further improvement of the present invention, if there are multiple available working nodes with the highest network affinity scores, an available working node with the highest network affinity score is randomly selected to be determined as the target working node.

[0033] Compared with the prior art, the present invention has the following beneficial effects:

[0034] In the present invention, a scheduling plug-in is deployed on a control node, and a network affinity detector is independently deployed on a working node, a pod creation request carrying a network affinity parameter is obtained, and an available working node corresponding to the pod creation request is determined, and the available working nodes are scored based on the network affinity parameters. In the scoring process, the available working nodes perform network delay tests on the network targets in turn and record the test results, and the network affinity scores of the available working nodes are determined according to the timeout seconds, the test results and the weight coefficients corresponding to the network targets, and the available working node with the highest network affinity score is determined as the target working node, and the pod creation request is scheduled to the target working node to respond to the pod creation request, thereby scheduling the pod based on network affinity, and taking the network health status of the working node as a consideration for pod scheduling, so as to ensure that the pod creation request can be scheduled to the target working node with good network health status, thereby ensuring user experience, and solving the technical problem that the existing pod scheduling strategy ignores the influence of the network health status, and the working node with poor network health status will affect the running speed of the pod business. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 A topological diagram of a computer system shown in the present invention;

[0036] Figure 2 This is a schematic diagram of the steps of the pod scheduling method shown in the present invention;

[0037] Figure 3 A schematic diagram of the specific steps for obtaining a pod creation request with network affinity parameters and determining the available working nodes corresponding to the pod creation request;

[0038] Figure 4 A schematic diagram of specific steps for determining the network affinity score of available working nodes based on the timeout seconds, test results, and weight coefficients corresponding to the network target. DETAILED DESCRIPTION

[0039] The present invention is described in detail below in conjunction with the various embodiments shown in the accompanying drawings, but it should be noted that these embodiments are not limitations of the present invention, and any equivalent transformations or substitutions in functions, methods, or structures made by ordinary technicians in the field based on these embodiments are all within the scope of protection of the present invention.

[0040] Please refer to Figures 1 to 4 As shown, the present invention shows a specific implementation of a pod scheduling method based on network affinity (hereinafter referred to as the "method"), which is used to schedule the pod according to the pod creation request initiated by the user, and especially to schedule the pod creation request carrying the network affinity parameter to the target working node to respond to the pod creation request. The method can be run in a computer system deployed with multiple nodes (including a control node and at least two working nodes), and can also be run in a cloud computing platform deployed with multiple computer systems. The cloud platform can be understood as a service or system formed by a hyper-converged all-in-one machine, a computer, a server, a data center or a portable terminal through virtualization technology. The applicant mainly uses the computer system 100 as an example to illustrate the following, but the scope of protection of the present invention cannot be limited by this.

[0041] For example, Figure 1In the topology diagram of the computer system 100 shown, the computer system 100 deploys a control node 10 and multiple worker nodes (i.e., worker nodes 21 to 23). The scheduler 11, apiserver 12, and scheduling plug-in 13 are deployed in the control node 10. Each worker node independently deploys a network affinity detector, a kubelet, and a pod, i.e., the worker node 21 deploys a network affinity detector 211 and a kubelet 212, the worker node 22 deploys a network affinity detector 221 and a kubelet 222, and the worker node 23 deploys a network affinity detector 231 and a kubelet 232. The deployment method of the network affinity detector on each worker node may be, for example, deployment in a DaemonSet manner. The user end or business front end 50 and the remote service 60 are deployed externally on the computer system 100. The control node 10 is connected to the user end or business front end 50, and the worker nodes 21 to 23 are connected to the remote service 60, respectively. The user creates a pod creation request at the user end or the service front end 50 and sends it to the API server 12. The scheduler 11 deployed on the control node 10 monitors the API server 12 in real time. When the pod creation request is monitored, it detects whether the pod creation request carries a network affinity parameter. If so, the scheduler 11 calls the scheduling plug-in 13 to score the available working nodes based on the network affinity parameter, and then the scheduler 11 determines the target working node according to the network affinity score, and schedules the pod creation request to the target working node to respond to the pod creation request. If not, the scheduler 11 determines the target working node based on the preset scheduling strategy, and schedules the pod creation request to the target working node to respond to the pod creation request, thereby realizing the scheduling of the pod based on network affinity, and taking the network health status of the working node as a consideration for pod scheduling, so as to ensure that the pod creation request can be scheduled to the target working node with good network health status, thereby ensuring user experience, and solving the problem that the existing pod scheduling strategy ignores the influence of the network health status, and the working node with poor network health status will affect the running speed of the pod business.

[0042] Ginseng Figure 2 As shown, the method includes the following steps S1 to S3.

[0043] Step S1: Obtain a pod creation request carrying a network affinity parameter, and determine an available working node corresponding to the pod creation request.

[0044] Specifically, the user creates a pod creation request through the user end or the business front end 50, and sends the pod creation request to the api server 12 deployed on the control node 10, and the scheduler 11 deployed on the control node 10 monitors the apiserver 12 in real time. When the user creates a pod creation request, if the user has special requirements for the network health status of the working node where the pod is located, the network affinity parameters will be added to the yaml file contained in the pod creation request, thereby forming a pod creation request carrying the network affinity parameters, and sending it to the api server 12 like an ordinary pod creation request (that is, a pod creation request that does not carry the network affinity parameters). Among them, the network affinity parameters include: timeout seconds, network target and its corresponding weight coefficient, the timeout seconds refers to the maximum time that the available working node waits for the network target to respond, and the network target refers to the remote service that the pod needs to connect to (for example, Figure 1 The weight coefficient refers to the weight of the network target in the subsequent scoring. If the pod creation request does not carry the network affinity parameter, it means that the user has no special requirements for the network health status of the working node where the pod is located. The scheduler 11 schedules the pod creation request based on the preset scheduling strategy. The preset scheduling strategy can be any scheduling strategy in the prior art, and this embodiment does not specifically limit this.

[0045] For example, an example of a network affinity parameter is as follows:

[0046]

[0047]

[0048] Among them, timeoutSeconds refers to the maximum time that an available working node waits for a response from the network target (i.e., timeout seconds), and the specific value corresponding to timeoutSeconds is ts; affinityTerms refers to a network affinity list, which contains network targets and their corresponding weight coefficients; target refers to the network target, and weight refers to the weight coefficient corresponding to the network target. The network target can be an IP address or a domain name address.

[0049] In one embodiment, Figure 3 As shown, obtaining a pod creation request carrying a network affinity parameter and determining an available working node corresponding to the pod creation request include the following steps S31 to S32.

[0050] Step S31, the scheduler deployed on the control node monitors the API server in real time. When a pod creation request is monitored, it detects whether the pod creation request carries a network affinity parameter; if so, execute step S32; if not, execute step S33.

[0051] Step S32: The scheduler determines the available working node corresponding to the pod creation request.

[0052] Step S33: The scheduler determines the target working node based on the preset scheduling strategy, and schedules the pod creation request to the target working node in response to the pod creation request.

[0053] Among them, in step S32, the scheduler 11 determines the available working nodes corresponding to the pod creation request, including: parsing the pod creation request, obtaining the resource parameters required for the pod creation request, filtering the working nodes according to the resource parameters, and determining the working nodes that meet the resource parameters as available working nodes. Perform a first filtering on multiple working nodes according to the resource parameters required for the pod creation request, thereby ensuring that the network is healthy while also ensuring that the resources in the working nodes meet the resource parameters required for the pod creation request, and reducing the amount of calculation for subsequent scoring through the first filtering. For example, Figure 1 The working nodes 22 and 23 shown in are determined as available working nodes. In addition, when filtering working nodes according to resource parameters, if there is no working node that meets the resource parameters, the scheduling is determined as a scheduling failure, and the failure result is returned to the user.

[0054] Step S2: score the available working nodes based on the network affinity parameters. During the scoring process, the available working nodes perform network card delay tests on the network targets in turn and record the test results. The network affinity scores of the available working nodes are determined according to the timeout seconds, the test results and the weight coefficients corresponding to the network targets.

[0055] Specifically, after the scheduler 11 determines the available working node corresponding to the pod creation request carrying the network affinity parameters, the scheduler 11 calls the scheduling plug-in 13 to send the network affinity request of the pod to the network affinity detector deployed on the available working node, and the network affinity request contains the network affinity parameters carried by the pod creation request. The network affinity detector performs network delay tests on the network targets in the network affinity parameters in turn and records the test results, calculates the temporary score of the available working node according to the timeout seconds, the test results and the weight coefficient corresponding to the network target, and returns the temporary score to the scheduling plug-in 13. The scheduling plug-in 13 calculates the network affinity score of the available working node based on the temporary score, thereby scoring the available working nodes based on the network affinity parameters, and after calculating the network affinity score, returns the network affinity score to the scheduler 11.

[0056] In one embodiment, the available working nodes sequentially perform a network delay test on the network target and record the test results, including: the available working nodes sequentially connect to the network target, test the network delay time corresponding to the network target response to the available working nodes, and determine the network delay time as the test result. For example, the timeout seconds are 1 second, the working node 22 connects to the remote service 60, and tests the network delay time corresponding to the remote service 60 responding to the working node 22. If the delay time is 0.1 seconds, 0.1 seconds is determined as the test result. When the available working node connects to the network target, if the waiting time of the available working node exceeds the timeout seconds (including the timeout seconds), the response of the network target is no longer waited, and it is determined that the available working node is not connected to the network target, and the timeout seconds are determined as the test result to shorten the overall scoring speed. For example, if the timeout seconds are 1 second, the working node 22 connects to the remote service 60, and tests the network delay time corresponding to the remote service 60 responding to the working node 22. If the remote service 60 does not respond to the working node 22 after waiting for 1 second, 1 second is determined as the test result. In the present invention, the timeout seconds may correspond to a single network target or may correspond to multiple network targets at the same time.

[0057] In one embodiment, Figure 4 As shown, the network affinity score of the available working node is determined according to the timeout seconds, the test result and the weight coefficient corresponding to the network target, including the following steps S41 to S43.

[0058] Step S41, calculate the temporary score corresponding to the available working node according to the timeout seconds, the test result and the weight coefficient, and determine whether the temporary scores corresponding to multiple available working nodes are the same; if so, execute step S42; if not, execute step S43.

[0059] Step S42: Calculate the network affinity score based on the temporary score.

[0060] Step S43: Calculate a conversion coefficient according to the temporary scores corresponding to the multiple available working nodes, and calculate a network affinity score based on the conversion coefficient and the temporary score.

[0061] Specifically, the network affinity detector responds to the network affinity request issued by the scheduling plug-in 13, performs network delay tests on the network targets in turn to obtain test results, and calculates the temporary scores corresponding to the available working nodes according to the timeout seconds, test results and weight coefficients. After obtaining the temporary scores, the temporary scores are returned to the scheduling plug-in 13. The scheduling plug-in 13 determines whether the temporary scores corresponding to multiple available working nodes are the same. If they are the same, the network affinity score is directly calculated based on the temporary score, thereby eliminating the need to calculate the conversion coefficient, saving calculation amount, and increasing calculation speed. The calculation formula for calculating the network affinity score based on the temporary score is score / 2, where score refers to the temporary score; if they are different, the conversion coefficient is calculated based on the temporary scores corresponding to multiple available working nodes, and the network affinity score is calculated based on the conversion coefficient and the temporary score.

[0062] It should be noted that the calculation formula for the temporary score is:

[0063] score=x1*(ts-result1)+…+x n *(ts-result n );

[0064] Among them, x n and result n They respectively refer to the weight coefficient and test result corresponding to the nth network target, and ts refers to the timeout seconds.

[0065] The conversion factor is calculated as follows:

[0066] score ratio=score max / (score max -score min );

[0067] Among them, score max It refers to the maximum value of the temporary scores corresponding to multiple available working nodes. min It refers to the minimum value of the temporary scores corresponding to multiple available working nodes, and score ratio refers to the conversion factor.

[0068] The calculation formula for calculating the network affinity score based on the conversion factor and the temporary score is:

[0069] NetworkAffinityScore=score ratio*(score-score min );

[0070] Among them, NetworkAffinityScore refers to the network affinity score.

[0071] For example, the network affinity parameters include network target a and network target b, the weight corresponding to network target a is 1, the weight corresponding to network target b is 2, and the timeout seconds is 1 second. At the same time, working nodes 21, 22, and 23 are all available working nodes. Working node 21 connects to network target a and network target b in sequence, and the network delay time corresponding to network target a responding to working node 21 is 0.1 second, and the network delay time corresponding to network target b responding to working node 23 is 0.1 second. Working node 22 connects to network target a and network target b in sequence, and the network delay time corresponding to network target a responding to working node 22 is 0.1 second, and the network delay time corresponding to network target b responding to working node 23 is 0.2 second. Working node 23 connects to network target a and network target b in sequence, and the network delay time corresponding to network target a responding to working node 22 is 0.2 second. After waiting for 1 second, network target b does not get a response from network target b, and 1 second is used as the test result.

[0072] Based on this, the temporary score of worker node 21 is

[0073] score 21 =1*(1-0.1)+2*(1-0.1)=2.7;

[0074] The temporary score of worker node 22 is:

[0075] score 22 =1*(1-0.1)+2*(1-0.2)=2.5;

[0076] The temporary score of worker node 23 is:

[0077] score 23 =1*(1-0.2)+2*(1-1)=0.8;

[0078] The conversion factor is:

[0079] score ratio=2.7 / (2.7-0.8)≈1.42;

[0080] The affinity score of worker node 21 is:

[0081] NetworkAffinityScore 21 =1.42*(2.7-0.8)=2.689;

[0082] The affinity score for worker node 22 is:

[0083] NetworkAffinityScore 22 =1.42*(2.5-0.8)=2.414;

[0084] The affinity score for worker node 23 is:

[0085] NetworkAffinityScore 23 =1.42*(0.8-0.8)=0.

[0086] Step S3: determine the available working node with the highest network affinity score as the target working node, and schedule the pod creation request to the target working node to respond to the pod creation request.

[0087] Specifically, after calculating the network affinity score of the available work node based on the temporary score, the scheduling plug-in 13 returns the network affinity score to the scheduler 11. The scheduler 11 determines the available work node with the highest network affinity score as the target work node, and schedules the pod creation request to the target work node in response to the pod creation request, and the kubelet deployed on the target work node creates and runs the pod. For example, in the above example, the affinity score of work node 21 is 2.689, the affinity score of work node 22 is 2.414, and the affinity score of work node 23 is 0. It can be seen that the affinity score of work node 21 is the highest. Work node 21 is used as the target work node, and the pod creation request is scheduled to work node 21. The kubelet 212 deployed on work node 21 creates and runs the pod. If there are multiple available work nodes with the highest network affinity scores, an available work node with the highest network affinity score is randomly selected and determined as the target work node.

[0088] The series of detailed descriptions listed above are only specific descriptions of feasible implementation methods of the present invention. They are not intended to limit the scope of protection of the present invention. Any equivalent implementation methods or changes that do not deviate from the technical spirit of the present invention should be included in the scope of protection of the present invention.

[0089] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0090] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A pod scheduling method based on network affinity, characterized in that: include: Obtain a pod creation request carrying a network affinity parameter, and determine an available working node corresponding to the pod creation request, wherein the network affinity parameter includes: a timeout in seconds, a network target and a weight coefficient corresponding to the network target; Scoring the available working nodes based on the network affinity parameters, and in the scoring process, the available working nodes sequentially perform network delay tests on the network targets and record the test results, and determining the network affinity scores of the available working nodes according to the timeout seconds, the test results and the weight coefficients corresponding to the network targets; An available working node with the highest network affinity score is determined as a target working node, and the pod creation request is scheduled to the target working node to respond to the pod creation request.

2. The pod scheduling method based on network affinity according to claim 1 is characterized in that: The obtaining of the pod creation request carrying the network affinity parameter and determining the available working node corresponding to the pod creation request includes: The scheduler deployed on the control node monitors the API server in real time, and when a pod creation request is monitored, detects whether the pod creation request carries the network affinity parameter; If yes, the scheduler determines the available working node corresponding to the pod creation request; If not, the scheduler determines the target working node based on a preset scheduling strategy, and schedules the pod creation request to the target working node to respond to the pod creation request.

3. The pod scheduling method based on network affinity according to claim 2 is characterized in that: The scheduler determining the available working node corresponding to the pod creation request includes: The pod creation request is parsed to obtain resource parameters required for the pod creation request, working nodes are filtered according to the resource parameters, and working nodes that meet the resource parameters are determined as available working nodes.

4. The pod scheduling method based on network affinity according to claim 1 is characterized in that: The available working nodes sequentially perform network delay tests on the network targets and record test results, including: The available working nodes are connected to the network targets in sequence, a network delay time corresponding to a response of the network targets to the available working nodes is tested, and the network delay time is determined as the test result.

5. The pod scheduling method based on network affinity according to claim 4 is characterized in that: The timeout seconds refers to the maximum time that the available working node waits for the network target to respond; When the available working node is connected to the network target, if the waiting time of the available working node exceeds the timeout seconds, the available working node is not connected to the network target, and the timeout seconds are determined as the test result.

6. The pod scheduling method based on network affinity according to claim 5 is characterized in that: The determining the network affinity score of the available working node according to the timeout seconds, the test result and the weight coefficient corresponding to the network target includes: Calculate a temporary score corresponding to the available working node according to the timeout seconds, the test result and the weight coefficient, and determine whether the temporary scores corresponding to multiple available working nodes are the same; If yes, the network affinity score is calculated based on the temporary score, and the calculation formula is score / 2, where score refers to the temporary score; If not, a conversion coefficient is calculated according to the temporary scores corresponding to the multiple available working nodes, and the network affinity score is calculated based on the conversion coefficient and the temporary score.

7. The pod scheduling method based on network affinity according to claim 6 is characterized in that: The calculation formula of the temporary score is: score=x1*(ts-result1)+…+x n *(ts-result n ); Among them, x n and result n They respectively refer to the weight coefficient and test result corresponding to the nth network target, and ts refers to the timeout seconds.

8. The pod scheduling method based on network affinity according to claim 7 is characterized in that: The calculation formula of the conversion factor is: score ratio=score max / (score max -score min ); Among them, score max It refers to the maximum value of the temporary scores corresponding to multiple available working nodes. min It refers to the minimum value of the temporary scores corresponding to multiple available working nodes, and score ratio refers to the conversion factor.

9. The pod scheduling method based on network affinity according to claim 8 is characterized in that: The calculation formula for calculating the network affinity score based on the conversion coefficient and the temporary score is: Network AffinityScore=score ratio*(score-score min ); Among them, Network AffinityScore refers to the network affinity score.

10. The pod scheduling method based on network affinity according to claim 6, characterized in that: If there are multiple available working nodes with the highest network affinity scores, an available working node with the highest network affinity score is randomly selected as the target working node.

Images