A container group scheduling method and device

Abstract

The present application provides a Pod scheduling method and device. In this method, Pods are divided according to user services, Pods belonging to the same service are assigned to the same service group, service priorities are determined for different service groups, and then the scheduling order of each service group is determined based on different service priorities, and scheduling is performed when the available resources of the cluster meet the resource requirements of the service group. Therefore, the normal operation of the service corresponding to the scheduled service group can be guaranteed, that is, the service availability is guaranteed.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a Pod scheduling method and device. Background Art

[0002] Kurbernetes (also known as k8s) is an open source container cluster management system from Google. It is a complete distributed support platform with complete cluster management capabilities. At the same time, the Kurbernetes system is also a new leading distributed architecture solution based on container technology, providing a series of complete functions such as deployment and operation, resource scheduling, service discovery, and dynamic scaling for containerized applications.

[0003] Kurbernetes is usually deployed in the form of a cluster. Kurbernetes cluster includes multiple nodes, which are divided into management nodes (Master) and worker nodes (Node). Among them, the worker node is used to carry the operation of the assigned (scheduled) container group (Pod).

[0004] Pod is the smallest scheduling unit of the Kurbernetes cluster. A Pod can contain one or more related containers. Multiple containers belonging to the same Pod share network, storage and other resources. Currently, Pod scheduling is mainly based on the order of the Pods to be scheduled in the Pod list, that is, each Pod to be scheduled is assigned a working node for hosting the Pod. However, in actual use, it is found that this scheduling method may cause some services to be unavailable. Summary of the invention

[0005] In view of this, the present application proposes a Pod scheduling method and device to ensure user service availability.

[0006] In order to achieve the above application purpose, this application provides the following technical solutions:

[0007] In a first aspect, the present application provides a Pod scheduling method, which is applied to a Kurbernetes cluster, and the method includes:

[0008] Determine a service priority ranking of N service groups to be scheduled in the cluster, wherein the service group includes at least one Pod for implementing a service corresponding to the service group;

[0009] Selecting M target service groups from the N service groups in descending order of service priority, wherein the total resource demand of the M target service groups is not greater than the available resources of the cluster;

[0010] For each target business group, each Pod in the target business group is scheduled to a working node included in the cluster.

[0011] Optionally, determining the service priority ranking of the N service groups to be scheduled in the cluster includes:

[0012] For each of the N business groups, counting the number of visits of the business group within a preset statistical time period;

[0013] The service priority ranking of the N service groups is determined according to the access volume of each service group, wherein a higher access volume corresponds to a higher service priority.

[0014] Optionally, after determining the service priority ranking of the N service groups according to the traffic of each service group, the method further includes:

[0015] If there are at least two first service groups among the N service groups whose traffic difference between the service groups is less than a preset difference threshold, respectively counting resource occupancy rates of the first service groups;

[0016] The service priority order between the at least two first service groups in the service priority ranking corresponding to the N service groups is updated according to the resource occupancy rate of each first service group, wherein the smaller the resource occupancy rate, the higher the corresponding service priority.

[0017] Optionally, the step of scheduling each Pod in the target business group to a working node included in the cluster includes:

[0018] Determine the calling relationship between the Pods in the target business group;

[0019] For each Pod in the target business group, determine the call level of the Pod in the call relationship;

[0020] In order from deep to shallow calling levels, each Pod is dispatched to the working node included in the cluster in turn.

[0021] Optionally, for each target business group, after scheduling each Pod in the target business group to a working node included in the cluster, the method further includes:

[0022] If there is an unscheduled second business group among the N business groups, and there is an idle target business group whose access volume is less than a preset access volume threshold within a preset time period among the M target business groups, and the resource demand of the second business group is not greater than the sum of the resource demand of the idle target business group and the remaining resources of the cluster, delete each Pod corresponding to the idle target business group in the cluster;

[0023] Schedule each Pod included in the second business group to a working node included in the cluster.

[0024] Optionally, for each target business group, after scheduling each Pod in the target business group to a working node included in the cluster, the method further includes:

[0025] If a newly added working node is detected, and there are idle Pods in the M target business groups whose access volume within a preset time period is less than a preset access volume threshold, the idle Pods are migrated to the newly added working node.

[0026] In a second aspect, the present application provides a Pod scheduling device, which is applied to a Kurbernetes cluster, and the device includes:

[0027] A determination unit, configured to determine a service priority ranking of N service groups to be scheduled in the cluster, wherein the service group includes at least one Pod for implementing a service corresponding to the service group;

[0028] A selection unit, configured to select M target service groups from the N service groups in descending order of service priority, wherein the total resource demand of the M target service groups is not greater than the available resource amount of the cluster;

[0029] The scheduling unit is used to schedule each Pod in each target business group to a working node included in the cluster.

[0030] Optionally, the determining unit determines the service priority ranking of the N service groups to be scheduled in the cluster, including:

[0031] For each of the N business groups, counting the number of visits of the business group within a preset statistical time period;

[0032] The service priority ranking of the N service groups is determined according to the access volume of each service group, wherein a higher access volume corresponds to a higher service priority.

[0033] Optionally, the device further comprises:

[0034] A statistical unit, configured to, after the determining unit determines the service priority ranking of the N service groups according to the access volume of each service group, if there are at least two first service groups among the N service groups whose access volume difference between the service groups is less than a preset difference threshold, respectively count the resource occupancy rate of each first service group;

[0035] An updating unit is used to update the service priority order between the at least two first service groups in the service priority ranking corresponding to the N service groups according to the resource occupancy rate of each first service group, wherein the smaller the resource occupancy rate, the higher the corresponding service priority.

[0036] Optionally, the scheduling unit schedules each Pod in the target service group to a working node included in the cluster, including:

[0037] Determine the calling relationship between the Pods in the target business group;

[0038] For each Pod in the target business group, determine the call level of the Pod in the call relationship;

[0039] In order from deep to shallow calling levels, each Pod is dispatched to the working node included in the cluster in turn.

[0040] Optionally, the device further comprises:

[0041] A deleting unit, configured to, after the scheduling unit schedules each Pod in the target business group to a working node included in the cluster for each target business group, if there is an unscheduled second business group among the N business groups, and there is an idle target business group among the M target business groups whose access volume is less than a preset access volume threshold within a preset time period, and the resource demand of the second business group is not greater than the sum of the resource demand of the idle target business group and the remaining resources of the cluster, delete each Pod corresponding to the idle target business group in the cluster;

[0042] The scheduling unit is further used to schedule each Pod included in the second business group to a working node included in the cluster.

[0043] Optionally, the device further comprises:

[0044] A migration unit is used to migrate the idle Pods to the newly added working nodes if a new working node is detected and there are idle Pods in the M target business groups whose access volume is less than a preset access volume threshold within a preset time period after the scheduling unit schedules each Pod in the target business group to the working nodes included in the cluster.

[0045] It can be seen from the above description that in the embodiment of the present application, Pods are divided according to user services, Pods belonging to the same service are included in the same service group, service priorities are determined for different service groups, and then the scheduling order of each service group is determined based on the different service priorities, and scheduling is performed when the available resources of the cluster meet the resource requirements of the service group. Therefore, the normal operation of the service corresponding to the scheduled service group can be guaranteed, that is, the service availability is guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0047] Figure 1 It is a flow chart of a Pod scheduling method shown in an embodiment of the present application;

[0048] Figure 2 This is an implementation process of step 101 shown in an embodiment of the present application;

[0049] Figure 3 This is a service priority sorting update process shown in an embodiment of the present application;

[0050] Figure 4 This is an implementation process of step 103 shown in an embodiment of the present application;

[0051] Figure 5 This is an example of the calling relationship between Pods in a business group shown in an embodiment of the present application;

[0052] Figure 6 This is a Pod scheduling process shown in an embodiment of the present application;

[0053] Figure 7 It is a structural diagram of a Pod scheduling device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0054] Here, exemplary embodiments will be described in detail, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application.

[0055] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the embodiments of the present application. The singular forms of "a", "said" and "the" used in the embodiments of the present application are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items.

[0056] It should be understood that although the terms first, second, third, etc. may be used to describe various information in the embodiments of the present application, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the embodiments of the present application, the negotiation information may also be referred to as the second information, and similarly, the second information may also be referred to as the negotiation information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determination".

[0057] The present application provides a Pod scheduling method, which schedules Pods based on business groups and can effectively ensure the availability of businesses corresponding to the scheduled business groups.

[0058] In order to make the purpose, technical solution and advantages of the present application clearer, the present application is described in detail below with reference to the accompanying drawings and specific embodiments:

[0059] See also Figure 1 , is a flow chart of a Pod scheduling method shown in an embodiment of the present application, and the flow is applied to a Kurbernetes cluster. The Kurbernetes cluster includes at least one working node (Node), and each working node is used to carry the operation of the Pod scheduled to this node.

[0060] like Figure 1 As shown, the process may include the following steps:

[0061] Step 101: Determine the service priority ranking of N service groups to be scheduled in the cluster.

[0062] In the embodiment of the present application, service groups are divided according to user services, and each service group includes at least one Pod for implementing the service corresponding to the service group.

[0063] This step determines the service priority ranking of each service group for the N service groups to be scheduled currently. The specific process of determining the service priority ranking is described below and will not be described here.

[0064] Step 102 : Select M target service groups from the N service groups in descending order of service priority.

[0065] That is, the first M service groups with higher service priorities are selected. Here, the first M service groups selected are referred to as target service groups. It can be understood that the target service groups are named for the convenience of distinction and are not used for limitation.

[0066] The total resource demand of the selected M target service groups is not greater than the available resources of the cluster, so as to ensure that the M target service groups can operate normally after being scheduled.

[0067] Step 103: for each target business group, schedule each Pod in the target business group to a working node included in the cluster.

[0068] The cluster uses Pod as the basic scheduling unit, and schedules each Pod included in the target business group to each working node of the cluster one by one, and finally completes the scheduling of each target business group.

[0069] During specific scheduling, each Pod can be evenly scheduled to each working node according to the load situation of each working node.

[0070] So far, completed Figure 1 The process shown.

[0071] pass Figure 1 It can be seen from the shown process that in the embodiment of the present application, Pods are divided according to user services, and Pods belonging to the same service are assigned to the same service group. Then, the scheduling order of each service group is determined according to the service priorities of different service groups, and scheduling is performed when the available resources of the cluster meet the resource requirements of the service group, thereby ensuring the normal operation of the service corresponding to the scheduled service group, that is, ensuring service availability.

[0072] The following describes the process of determining the service priority ranking of N service groups in step 101. Figure 2 , an implementation process of step 101 is shown in an embodiment of the present application.

[0073] like Figure 2 As shown, the process may include the following steps:

[0074] Step 201 : for each of the N business groups, the number of visits of the business group within a preset statistical time period is counted.

[0075] Here, the preset statistical time period is usually a time period with concentrated business access. For example, if the access to business 1 is mainly concentrated from 8:00 to 18:00, the statistical time period of the business group corresponding to business 1 can be set to 8:00 to 18:00; if the access to business 2 is mainly concentrated from 20:00 to 24:00, the statistical time period of the business group corresponding to business 2 can be set to 20:00 to 24:00.

[0076] This step determines the access situation of each business group by collecting statistics on each business group during the corresponding access concentrated time period.

[0077] Step 202: Determine the service priority ranking of N service groups according to the visit volume of each service group, wherein a higher visit volume corresponds to a higher service priority.

[0078] Here, four business groups are taken as an example, and the four business groups are Group 1 to Group 4. If it is determined through step 201 that the number of visits to Group 1 is 500,000, the number of visits to Group 2 is 100,000, the number of visits to Group 3 is 300,500, and the number of visits to Group 4 is 300,000, then the business priority ranking (from high to low) of the four business groups is Group 1 → Group 3 → Group 4 → Group 2.

[0079] So far, completed Figure 2 The process shown.

[0080] pass Figure 2 It can be seen from the process shown that the embodiment of the present application determines the service priority ranking of each service group based on the service access volume, thereby ensuring that the service group with large service access volume is scheduled first (especially when cluster resources are insufficient), thereby making cluster resource utilization more reasonable.

[0081] As an embodiment, after executing step 202, the following steps may be performed: Figure 3 The business priority sorting update process is shown in Figure 1. Figure 3 As shown, the process may include the following steps:

[0082] Step 301: If there are at least two first service groups among the N service groups whose traffic difference between the service groups is less than a preset difference threshold, the resource occupancy rate of each first service group is counted respectively.

[0083] Here, at least two service groups in the N service groups whose visit volume difference is less than the preset difference threshold are both called the first service group. It can be understood that the first service group is named only for the convenience of distinction and is not used for limitation.

[0084] The difference in the access volume between the at least two first service groups is less than the preset difference threshold, indicating that the access volume of the at least two first service groups is very close. At this time, the resource occupancy rate of each first service group can be counted respectively.

[0085] For example, the preset difference threshold is 1,000 times. According to the aforementioned access volume of Group 1 to Group 4, the access volume difference between Group 3 and Group 4 (30.05-30=0.05 thousand times) is less than the preset difference threshold (1,000 times). At this time, the resource utilization rates of Group 3 and Group 4 can be counted separately.

[0086] Here, resource utilization mainly includes CPU utilization and memory utilization. The CPU utilization can be the ratio of the total CPU resource demand of each Pod in the business group to the available CPU resources of the cluster; the memory utilization can be the ratio of the total memory resource demand of each Pod in the business group to the available memory resources of the cluster.

[0087] Still taking Group 3 and Group 4 as examples, see Table 1, which is an example of resource requirements of each Pod included in Group 3 shown in an embodiment of the present application.

[0088]

[0089] Table 1 refers to Table 2, which is an example of resource requirements of each Pod included in Group 4 shown in an embodiment of the present application.

[0090]

[0091] Table 2

[0092] The current cluster has available CPU resources of 20m and memory resources of 40Gi. The CPU usage of Group3 is (0.5+1+1+2+0.5+0.5) / 20=27.5%, and the memory usage is (512Mi+1Gi+512Mi+2Gi+512Mi+512Mi) / 40Gi=12.5%; the CPU usage of Group4 is (1+1+0.5+2+0.5+1) / 20=30%, and the memory usage is (1Gi+1Gi+512Mi+1Gi+512Mi+512Mi) / 40Gi=11.25%.

[0093] Step 302: updating the service priority order between at least two first service groups in the service priority ranking determined in step 202 according to the resource occupancy rate of each first service group, wherein the smaller the resource occupancy rate, the higher the corresponding service priority.

[0094] As an example, the service priority order between the at least two first service groups may be determined by comprehensively considering the CPU occupancy rate and the memory occupancy rate of each first service group.

[0095] Still taking Group3 and Group4 as an example, the CPU occupancy of Group3 is 27.5% and the memory occupancy is 12.5%; the CPU occupancy of Group4 is 30% and the memory occupancy is 11.25%. The minimum occupancy among all the above occupancy is 11.25%, and the Group corresponding to the minimum occupancy is Group4. Therefore, it can be determined that the service priority of Group4 is higher than the service priority of Group3. Based on this, the service priority order Group1→Group3→Group4→Group2 determined in the above step 202 is updated to Group1→Group4→Group3→Group2.

[0096] So far, completed Figure 3 The process shown.

[0097] pass Figure 3 It can be seen from the illustrated process that in the embodiment of the present application, the service priority ranking of each service group is determined in combination with the service access volume and resource occupancy rate of each service group, and resource scheduling is performed based on the service priority ranking, which can make cluster resource utilization more reasonable.

[0098] The following describes the process of scheduling each Pod in the target business group to a working node in step 103. Figure 4 , which is an implementation process of step 103 shown in an embodiment of the present application.

[0099] like Figure 4 As shown, the process may include the following steps:

[0100] Step 401, determining the calling relationship between the Pods in the target business group.

[0101] Here, it should be noted that if the target business group has been running normally before this scheduling, the cluster will record the calling relationship of each Pod in the target business group. Figure 5 , which is an example of the calling relationship of each Pod in a business group shown in an embodiment of the present application.

[0102] like Figure 5 As shown in the figure, this figure takes Group4 as an example to show the calling relationship of Pod41 to Pod46 in Group4. Among them, the operation of the upper-level Pod depends on the operation of the lower-level Pod. For example, Figure 5 For example, the operation of Pod44 depends on the operation of Pod45 and Pod46; for another example, the operation of Pod42 depends on the operation of Pod44, and so on.

[0103] Step 402: for each Pod in the target business group, determine the calling level of the Pod in the calling relationship.

[0104] Still Figure 5 Taking the call relationship of Group4 as an example, traversing the call relationship from the business access entrance, we can get the corresponding relationship example between Pod and call level shown in Table 3.

[0105]

[0106] Table 3

[0107] Step 403, schedule each Pod to the working node in order from deep to shallow calling levels.

[0108] Still Figure 5 Take Group 4 as an example, which includes 4 call levels, as shown in Table 3. Among them, the deepest call level is the fourth level, and the shallowest call level is the first level. Then, the Pods are scheduled in order from deep to shallow according to the call levels: Pod 45 and Pod 46 at the fourth level → Pod 44 at the third level → Pod 42 and Pod 43 at the second level → Pod 41 at the first level, so as to ensure that the dependent Pods are scheduled (started) first.

[0109] So far, completed Figure 4 The process shown.

[0110] pass Figure 4 It can be seen from the shown process that in the embodiment of the present application, the dependent Pods are scheduled preferentially according to the calling relationship (dependency) of each Pod in the business group, which can effectively avoid the impact of multiple restarts of the upper-level Pods due to random scheduling, affecting the business startup efficiency. In other words, the embodiment of the present application schedules the Pods of the business group from bottom to top (from deep to shallow) according to the dependency relationship, which can effectively improve the business startup efficiency.

[0111] As an embodiment, after executing step 103, the following steps may be performed: Figure 6 The Pod scheduling process is shown.

[0112] like Figure 6 As shown, the process may include the following steps:

[0113] Step 601: If there is an unscheduled second business group among the N business groups, and there is an idle target business group among the M target business groups whose access volume within the preset time period is less than the preset access volume threshold, and the resource demand of the second business group is not greater than the sum of the resource demand of the idle target business group and the remaining resources of the cluster, then delete the Pods corresponding to the idle target business group in the cluster.

[0114] Here, it should be noted that the second service group can be any unscheduled service group among the N service groups. Preferably, the second service group can be the service group with the highest service priority among the unscheduled service groups. It can be understood that the second service group is named only for the convenience of distinction and is not used for limitation.

[0115] In addition, in the embodiment of the present application, the target service group whose access volume is less than the preset access volume threshold within the preset time period is called an idle target service group. It is understandable that the idle target service group is named only for the convenience of distinction and is not used for limitation.

[0116] The idle target service group is a target service group with extremely small access volume (less than a preset access volume threshold) among the M target service groups. If the idle target service group continues to occupy cluster resources, cluster resources will be wasted.

[0117] To this end, the embodiment of the present application considers releasing the resources occupied by the idle target business group and providing them to the new business group. Specifically, the cluster determines whether the resource demand of the unscheduled second business group is greater than the sum of the resource demand of the idle target business group and the remaining resources of the current cluster. If not, it means that after the corresponding resources of the idle target business group are released, the resources of the cluster can meet the resource demand of the second business group. Therefore, this step deletes each Pod corresponding to the idle target business group in the cluster, that is, releases the resources occupied by the idle target business group, and then goes to step 602.

[0118] Step 602: Schedule each Pod included in the second business group to a working node included in the cluster.

[0119] So far, completed Figure 6 The process shown.

[0120] pass Figure 6 It can be seen from the illustrated process that the embodiment of the present application makes cluster resource utilization higher by allocating resources occupied by relatively idle service groups to unscheduled new service groups.

[0121] As an embodiment, after executing step 103, the cluster may monitor whether there are new working nodes, for example, the cluster expansion leads to an increase in working nodes. When a new working node is detected, it is determined whether there are idle Pods in the scheduled M target business groups, where the idle Pods are Pods whose access volume is less than a preset access volume threshold within a preset time period.

[0122] If there are idle Pods, they will be migrated to the newly added worker nodes to balance the burden of each worker node in the cluster as much as possible. At the same time, since only idle Pods are migrated, the impact on the running business can be effectively reduced.

[0123] The method provided in the embodiment of the present application is described above. The Pod scheduling device provided in the embodiment of the present application is described below:

[0124] See also Figure 7 , is a structural diagram of a Pod scheduling device provided in an embodiment of the present application, the device is applied to a Kubernetes cluster, the device includes: a determination unit 701, a selection unit 702 and a scheduling unit 703, wherein:

[0125] A determining unit 701 is used to determine the service priority ranking of N service groups to be scheduled in the cluster, where the service group includes at least one Pod for implementing a service corresponding to the service group;

[0126] A selection unit 702 is configured to select M target service groups from the N service groups in descending order of service priority, wherein the total resource demand of the M target service groups is not greater than the available resources of the cluster;

[0127] The scheduling unit 703 is used to schedule each Pod in each target business group to a working node included in the cluster.

[0128] As an embodiment, the determining unit 701 determines the service priority ranking of the N service groups to be scheduled in the cluster, including:

[0129] For each of the N business groups, counting the number of visits of the business group within a preset statistical time period;

[0130] The service priority ranking of the N service groups is determined according to the access volume of each service group, wherein a higher access volume corresponds to a higher service priority.

[0131] As an embodiment, the device further includes:

[0132] A statistical unit, configured to, after the determining unit 701 determines the service priority ranking of the N service groups according to the traffic of each service group, if there are at least two first service groups among the N service groups whose traffic difference between the service groups is less than a preset difference threshold, respectively count the resource occupancy rate of each first service group;

[0133] An updating unit is used to update the service priority order between the at least two first service groups in the service priority ranking corresponding to the N service groups according to the resource occupancy rate of each first service group, wherein the smaller the resource occupancy rate, the higher the corresponding service priority.

[0134] As an embodiment, the scheduling unit 703 schedules each Pod in the target service group to a working node included in the cluster, including:

[0135] Determine the calling relationship between the Pods in the target business group;

[0136] For each Pod in the target business group, determine the call level of the Pod in the call relationship;

[0137] In order from deep to shallow calling levels, each Pod is dispatched to the working node included in the cluster in turn.

[0138] As an embodiment, the device further includes:

[0139] A deleting unit, for after the scheduling unit 703 schedules each Pod in the target business group to a working node included in the cluster for each target business group, if there is an unscheduled second business group among the N business groups, and there is an idle target business group among the M target business groups whose access volume is less than a preset access volume threshold within a preset time period, and the resource demand of the second business group is not greater than the sum of the resource demand of the idle target business group and the remaining resources of the cluster, deleting each Pod corresponding to the idle target business group in the cluster;

[0140] The scheduling unit 703 is further configured to schedule each Pod included in the second service group to a working node included in the cluster.

[0141] As an embodiment, the device further includes:

[0142] A migration unit is used to schedule each Pod in the target business group to a working node included in the cluster for each target business group in the scheduling unit 703. If a new working node is detected and there are idle Pods in the M target business groups whose access volume is less than a preset access volume threshold within a preset time period, the idle Pods are migrated to the newly added working node.

[0143] So far, completed Figure 7 In the embodiment of the present application, Pods are divided according to user services, and Pods belonging to the same service are placed in the same service group. Then, the scheduling order of each service group is determined according to the service priorities of different service groups, and scheduling is performed when the available resources of the cluster meet the resource requirements of the service group, thereby ensuring the normal operation of the service corresponding to the scheduled service group, that is, ensuring service availability.

[0144] The above description is only a preferred embodiment of the embodiments of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the present application.

Claims

1. A container group Pod scheduling method, characterized in that: Applied to a Kurbernetes cluster, the method includes: Determine a service priority ranking of N service groups to be scheduled in the cluster, wherein the service group includes at least one Pod for implementing a service corresponding to the service group; Selecting M target service groups from the N service groups in descending order of service priority, wherein the total resource demand of the M target service groups is not greater than the available resources of the cluster; For each target business group, schedule each Pod in the target business group to a working node included in the cluster; The determining of the service priority ranking of the N service groups to be scheduled in the cluster includes: For each of the N business groups, counting the number of visits of the business group within a preset statistical time period; Determine the service priority ranking of the N service groups according to the traffic of each service group, wherein a higher traffic corresponds to a higher service priority; If there are at least two first service groups among the N service groups whose traffic difference between the service groups is less than a preset difference threshold, respectively counting resource occupancy rates of the first service groups; According to the resource occupancy rate of each first service group, updating the service priority order between the at least two first service groups in the service priority ranking corresponding to the N service groups, wherein the smaller the resource occupancy rate, the higher the corresponding service priority; The resource occupancy rate includes CPU occupancy rate and memory occupancy rate; the CPU occupancy rate is the ratio of the total CPU resource demand of each Pod in the business group to the available CPU resources of the cluster; the memory occupancy rate can be the ratio of the total memory resource demand of each Pod in the business group to the available memory resources of the cluster.

2. The method according to claim 1, characterized in that The step of scheduling each Pod in the target business group to a working node included in the cluster includes: Determine the calling relationship between the Pods in the target business group; For each Pod in the target business group, determine the call level of the Pod in the call relationship; In order from deep to shallow calling levels, each Pod is dispatched to the working node included in the cluster in turn.

3. The method according to claim 1, characterized in that After scheduling each Pod in the target business group to a working node included in the cluster for each target business group, the method further includes: If there is an unscheduled second business group among the N business groups, and there is an idle target business group whose access volume is less than a preset access volume threshold within a preset time period among the M target business groups, and the resource demand of the second business group is not greater than the sum of the resource demand of the idle target business group and the remaining resources of the cluster, delete each Pod corresponding to the idle target business group in the cluster; Schedule each Pod included in the second business group to a working node included in the cluster.

4. The method according to claim 1, characterized in that After scheduling each Pod in the target business group to a working node included in the cluster for each target business group, the method further includes: If a newly added working node is detected, and there are idle Pods in the M target business groups whose access volume within a preset time period is less than a preset access volume threshold, the idle Pods are migrated to the newly added working node.

5. A container group Pod scheduling device, characterized in that: Applied to a Kurbernetes cluster, the device comprises: A determination unit, configured to determine a service priority ranking of N service groups to be scheduled in the cluster, wherein the service group includes at least one Pod for implementing a service corresponding to the service group; A selection unit, configured to select M target service groups from the N service groups in descending order of service priority, wherein the total resource demand of the M target service groups is not greater than the available resource amount of the cluster; A scheduling unit, configured to schedule, for each target business group, each Pod in the target business group to a working node included in the cluster; The determining of the service priority ranking of the N service groups to be scheduled in the cluster includes: For each of the N business groups, counting the number of visits of the business group within a preset statistical time period; Determine the service priority ranking of the N service groups according to the traffic of each service group, wherein a higher traffic corresponds to a higher service priority; If there are at least two first service groups among the N service groups whose traffic difference between the service groups is less than a preset difference threshold, respectively counting resource occupancy rates of the first service groups; According to the resource occupancy rate of each first service group, updating the service priority order between the at least two first service groups in the service priority ranking corresponding to the N service groups, wherein the smaller the resource occupancy rate, the higher the corresponding service priority; The resource occupancy rate includes CPU occupancy rate and memory occupancy rate; the CPU occupancy rate is the ratio of the total CPU resource demand of each Pod in the business group to the available CPU resources of the cluster; the memory occupancy rate can be the ratio of the total memory resource demand of each Pod in the business group to the available memory resources of the cluster.

6. The device according to claim 5, characterized in that The scheduling unit schedules each Pod in the target service group to a working node included in the cluster, including: Determine the calling relationship between the Pods in the target business group; For each Pod in the target business group, determine the call level of the Pod in the call relationship; In order from deep to shallow calling levels, each Pod is dispatched to the working node included in the cluster in turn.

Images