Kubernetes cluster capacity evaluation method, device, equipment and medium

Abstract

The invention discloses a Kubernetes cluster capacity evaluation method and device, equipment and a medium, relates to the technical field of computers, is applied to a capacity evaluation simulator, and comprises the steps that when a capacity evaluation command for a Kubernetes cluster to be evaluated is acquired, cluster resource information is mapped to the local; determining a residual resource distributable amount of each cluster node in the to-be-evaluated Kubernetes cluster by using the cluster resource information, obtaining a plurality of to-be-scheduled container groups, and determining a current resource request amount corresponding to each to-be-scheduled container group; wherein the plurality of to-be-scheduled container groups are container groups selected from a cluster container group and / or a user-defined container group; and simulating a scheduling process according to the remaining resource allocatable quantity and the current resource request quantity, so as to evaluate and obtain the maximum container group quantity of each to-be-scheduled container group supported by each cluster node to be scheduled. And determining the maximum number of container groups supported and scheduled by the cluster, and concrete the cluster capacity to improve the accuracy of capacity evaluation.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for assessing the capacity of a Kubernetes cluster. Background Technology

[0002] Currently, as new cluster container groups are scheduled on nodes in a K8S (Kubernetes) cluster, the resources consumed are increasing. At this time, it is very important to monitor or evaluate the available resources in the cluster, because operators can use monitoring to add current resources in a timely manner to prevent all resources from being exhausted, or to take different steps to increase available resources.

[0003] Existing Kubernetes cluster capacity assessments are mostly node-level or cluster-level resource usage analyses, which cannot visualize cluster capacity to improve the accuracy of capacity assessments.

[0004] In summary, how to visualize cluster capacity to improve the accuracy of capacity assessment is an urgent problem to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a Kubernetes cluster capacity assessment method, apparatus, device, and medium that can visualize cluster capacity to improve the accuracy of capacity assessment. The specific solution is as follows:

[0006] Firstly, this application discloses a Kubernetes cluster capacity assessment method, applied to a capacity assessment simulator, including:

[0007] When obtaining the capacity assessment command for the Kubernetes cluster to be assessed, the cluster resource information is mapped to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed.

[0008] The remaining allocable resources for each cluster node in the Kubernetes cluster to be evaluated are determined using cluster resource information. Several container groups to be scheduled are obtained, and the current resource request volume corresponding to each container group to be scheduled is determined. The several container groups to be scheduled are container groups selected from cluster container groups and / or custom container groups.

[0009] The scheduling process is simulated based on the remaining allocable resources and the current resource requests to evaluate the maximum number of container groups that each cluster node can support for scheduling each group of containers to be scheduled.

[0010] Optionally, the step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled includes:

[0011] Based on parallel scheduling logic and the first scheduling order, and simulating the scheduling process according to the remaining allocable resources and the current resource request, the maximum number of container groups that each cluster node can support for scheduling is evaluated.

[0012] The first scheduling order is to schedule container groups one by one in sequence; the process of scheduling container groups one by one in sequence is to schedule the current container group to be scheduled until the current container group to be scheduled cannot be scheduled, and then the next container group to be scheduled is used as the current container group to be scheduled and the scheduling continues; the parallel scheduling logic is the logic that supports multiple cluster nodes to schedule container groups to be scheduled at the same time.

[0013] Optionally, the step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled includes:

[0014] Based on non-parallel scheduling logic and a second scheduling order, and simulating the scheduling process according to the remaining allocable resources and the current resource request, the maximum number of container groups that each cluster node can support for scheduling is evaluated.

[0015] The second scheduling order is alternating scheduling; the alternating scheduling process is a process of repeatedly scheduling containers according to the order of arrangement of several containers to be scheduled; the non-parallel scheduling logic is a logic that does not support multiple cluster nodes scheduling containers to be scheduled at the same time.

[0016] Optionally, determining the remaining allocable resources for each cluster node in the Kubernetes cluster to be evaluated using cluster resource information includes:

[0017] The original allocated resources and actual resource usage of each cluster node are determined from the cluster resource information.

[0018] The maximum value between the P95 value of the actual node resource usage and the original allocated resource amount is used as the remaining allocable resource amount of the corresponding cluster node to determine the remaining allocable resource amount of each cluster node in the Kubernetes cluster to be evaluated.

[0019] Optionally, determining the current resource request volume corresponding to each container group to be scheduled includes:

[0020] If the container group to be scheduled is a cluster container group, the actual resource request amount of the cluster container group determined using the cluster resource information will be used as the current resource request amount of the container group to be scheduled.

[0021] If the container group to be scheduled is a custom container group, then extract the custom resource request quantity that comes with the custom container group as the current resource request quantity corresponding to the container group to be scheduled.

[0022] Correspondingly, the methods for determining the actual resource request volume of a cluster container group include:

[0023] The original cluster container group resource request and actual cluster container group resource usage for each cluster container group are determined from the cluster resource information.

[0024] The P95 value of the actual cluster container group resource usage and the maximum value of the original cluster container group resource request are used as the actual resource request of the corresponding cluster container group to determine the actual resource request of each cluster container group in the Kubernetes cluster to be evaluated.

[0025] Optionally, the Kubernetes cluster capacity assessment method further includes:

[0026] Determine the amount of resources that can be allocated after scheduling for each cluster node, identify the resource over-allocated nodes based on the resource allocation amount after scheduling, and issue risk warnings based on the resource over-allocated nodes.

[0027] Optionally, after simulating the scheduling process based on the target scheduling logic to evaluate the maximum number of container groups that each cluster node can support scheduling for each container group to be scheduled based on the remaining allocable resources and the current resource request volume, the process further includes:

[0028] Integrate and evaluate basic information; the basic evaluation information includes evaluation time, total number of cluster nodes, and total number of nodes to be evaluated;

[0029] Determine the amount of resources that can be allocated after scheduling for each cluster node, and identify the resource bottleneck node based on the amount of resources that can be allocated after scheduling.

[0030] The total number of container groups to be scheduled in the Kubernetes cluster to be evaluated is calculated based on the maximum number of container groups.

[0031] An assessment report is constructed based on the assessment baseline information, maximum number of container groups, total number of containers, available resources after scheduling, and resource bottleneck nodes.

[0032] Secondly, this application discloses a Kubernetes cluster capacity assessment device, applied to a capacity assessment simulator, comprising:

[0033] The resource mapping module is used to map cluster resource information to the local machine when obtaining capacity assessment commands for the Kubernetes cluster to be assessed, so that the capacity assessment simulator is consistent with the cluster environment of the Kubernetes cluster to be assessed.

[0034] The resource quantity determination module is used to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated using cluster resource information, obtain several container groups to be scheduled, and determine the current resource request quantity corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from the cluster container groups and / or custom container groups.

[0035] The capacity assessment module is used to simulate the scheduling process based on the remaining allocable resources and the current resource request volume, in order to assess the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled.

[0036] Thirdly, this application discloses an electronic device, including:

[0037] Memory, used to store computer programs;

[0038] A processor for executing the computer program to implement the aforementioned disclosed Kubernetes cluster capacity assessment method.

[0039] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed Kubernetes cluster capacity assessment method.

[0040] As can be seen, when obtaining the capacity assessment command for the Kubernetes cluster to be assessed, this application maps the cluster resource information to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed; it uses the cluster resource information to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be assessed, obtains several container groups to be scheduled, and determines the current resource request volume corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from the cluster container groups and / or custom container groups; the scheduling process is simulated according to the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support scheduling for each container group to be scheduled. Thus, this application sets up a capacity assessment simulator, and through resource mapping, makes the capacity assessment simulator consistent with the Kubernetes cluster to be assessed. The consistent cluster environment of the ubernetes cluster makes the subsequent simulation process more realistic and improves the accuracy of the evaluation results. This application evaluates the capacity of each cluster by assessing the maximum number of container groups that can be scheduled for each schedulable container group supported by the remaining allocable resources of each cluster node. The evaluation process considers the current resource request volume corresponding to each schedulable container group, rather than only evaluating the resources of the nodes and the cluster itself. This quantifies the cluster container groups that resources can be scheduled, making the cluster capacity more concrete and avoiding the situation where resources that cannot support calling cluster container groups are evaluated as cluster capacity, thus improving the depth and accuracy of Kubernetes cluster capacity evaluation. In addition, the schedulable container groups in this application are selected from cluster container groups and / or custom container groups, and are not limited to cluster container groups, improving the applicability of the evaluation method. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0042] Figure 1 This is a flowchart of a Kubernetes cluster capacity assessment method disclosed in this application;

[0043] Figure 2 This is a schematic diagram of the structure of a Kubernetes cluster capacity assessment device disclosed in this application;

[0044] Figure 3 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] Currently, as new cluster container groups are scheduled on nodes in a Kubernetes (K8S) cluster, resource consumption is increasing. Therefore, monitoring and evaluating the available resources in the cluster is crucial. This allows operations personnel to promptly add resources to prevent exhaustion or take different steps to increase available resources. Existing Kubernetes cluster capacity assessments are mostly node-level or cluster-level resource usage analyses, which fail to visualize cluster capacity and improve the accuracy of capacity assessments.

[0047] Therefore, this application proposes a Kubernetes cluster capacity assessment scheme that can visualize cluster capacity to improve the accuracy of capacity assessment.

[0048] This application discloses a method for evaluating the capacity of a Kubernetes cluster. (See also...) Figure 1 As shown, applied to a capacity assessment simulator, the method includes:

[0049] Step S11: When obtaining the capacity assessment command for the Kubernetes cluster to be assessed, map the cluster resource information to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed.

[0050] In this embodiment, the Kubernetes cluster capacity assessment implementation language corresponding to the capacity assessment simulator is Golang.

[0051] In this embodiment, capacity assessment can be performed via command line or through exposed interfaces. It should be noted that the capacity assessment simulator supports command-line operation and can also be called by third parties to perform corresponding capacity assessment operations; it does not generate actual cluster container group scheduling or resource preemption, and the returned results clearly indicate the number of cluster container group instances with the corresponding remaining runnable resource requirements. It should be noted that all commands and parameters need to be registered through Cobra (a popular command-line interface framework in Golang, used to quickly build powerful and well-structured command-line tools) for a unified entry point; parameter parsing and help documentation are automatically generated; configuration files and environment variables are supported in conjunction with Viper; in addition, parameters are encapsulated and validated at each command entry point; the encapsulated parameters are passed to the core simulator interface, and separation is achieved through the interface to support isolation between different schedulers / simulators; process interruption and exception handling are supported; this application can dynamically manage Kubernetes objects, supporting multiple types and multiple sources; it supports general CRUD operations (Create, Read, Update, Delete, which are the core foundation of data operations in computer programming) similar to ORM (Object-Relational Mapping); the underlying general management (reflect, the Go language reflection package) achieves unified management and operation of objects through type assertion and reflection.

[0052] It should be noted that during resource mapping, variables used for statistics and tracking are initialized, and the capacity assessment simulator is initialized according to business configuration. The current kube-scheduler scheduling configuration of the cluster is loaded, and all initial resource objects (such as Pods (resources for storing application services in Kubernetes, which can store one or more containers to run application services) and Nodes (nodes in a Kubernetes cluster, a node is usually a physical machine or a virtual machine) are loaded) to ensure that the simulated environment is consistent with the actual cluster. All commands and parameters are registered through cobra to support interactive parameter input. A RESTful API is exposed through the Golang base net / http (Hypertext Transfer Protocol package under the network module of the Go standard library), which supports passing assessment parameters (templates, constraints, etc.) into the request body, and basic authentication (such as API Key) or RBAC permission verification is integrated for third-party programs to call and execute capacity assessment. Here, REST stands for Representational State Transfer, and API stands for Application Programming Interface. It should be noted that when loading the current cluster node and POD information, this application obtains all attributes of the current cluster node (CPU (Central Processing Unit) / memory / GPU (Graphics Processing Unit) types, over-provisioning policies, tags / taints, etc.), as well as the allocable, allocated, and actual usage of resources, and obtains all attributes of the current cluster POD (affinity tags, priority, etc.), as well as the POD resource request amount and actual usage; among which, resources can be divided into CPU resources, memory resources, and GPU resources, etc. It should be noted that the simulator can be created temporarily during initialization or pre-created.

[0053] It should be noted that during command startup and parameter parsing, the user enters the capacity assessment command in the command line, and the simulator parses and verifies the input parameters through a command line framework (such as Cobra) to ensure that the information required for the assessment is complete and valid. When loading resource objects, the system loads the resource objects such as Pods and Nodes to be assessed according to the parameter configuration, which can be obtained from local files, cluster snapshots or remote APIs. For capacity assessment initialization, a capacity assessor instance is created and the assessment environment is initialized, including cluster status, scheduling constraints, etc.

[0054] Step S12: Use cluster resource information to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated, obtain several container groups to be scheduled, and determine the current resource request amount corresponding to each container group to be scheduled.

[0055] In this embodiment, the container groups to be scheduled can be multi-source cluster container groups, and the plurality of container groups to be scheduled are several cluster container groups selected from cluster container groups and / or custom container groups. The custom container group can specifically be a workload cluster container group.

[0056] In this embodiment, if the container group to be scheduled is a cluster container group, the actual resource request amount of the cluster container group determined using the cluster resource information will be used as the current resource request amount corresponding to the container group to be scheduled; if the container group to be scheduled is a custom container group, the custom resource request amount of the custom container group will be extracted as the current resource request amount corresponding to the container group to be scheduled.

[0057] It should be noted that it can parse multi-source pod templates and perform standardization processing, unify template format, fill in missing fields (such as default restartPolicy=Always), and verify the legality of scheduling constraints (such as affinity rule syntax). Specifically, for cluster container groups, it automatically extracts the specs of active pods as templates; for custom container groups (templates), it supports importing local files (JSON / YAML) or URLs, retaining the original resource requirements (the format legality needs to be verified, such as whether requests exist). The workload cluster container group (template) supports extracting podTemplateSpec from Deployment / StatefulSet / DaemonSet.

[0058] In this embodiment, it is necessary to recalculate the existing resource request volume and allocation volume to incorporate the actual resource load, making the capacity assessment more reliable. There are two aspects to the recalculation: first, the resource request volume at the pod level needs to be recalculated (which needs to be used for the cluster container group in the container group to be scheduled); second, the resource allocation volume at the node level needs to be recalculated.

[0059] It should be noted that the calculation process for the remaining allocable resources of each cluster node is as follows: Determining the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated using cluster resource information includes: determining the original allocated resources and actual node resource usage of each cluster node from the cluster resource information; and using the maximum value between the P95 value of the actual node resource usage and the original allocated resources as the remaining allocable resources of the corresponding cluster node to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated. Specifically, the node resource allocated amount = max(original node resource allocated amount, P95 value of actual node resource usage), for example, the memory allocated amount of a node in the existing cluster is max(original node memory resource allocated amount, P95 value of actual node memory resource usage).

[0060] It should be noted that the method for calculating the actual resource request volume of a cluster container group includes: determining the original cluster container group resource request volume and the actual cluster container group resource usage for each cluster container group from the cluster resource information; and using the maximum value between the P95 value of the actual cluster container group resource usage and the original cluster container group resource request volume as the actual resource request volume of the corresponding cluster container group to determine the actual resource request volume of each cluster container group in the Kubernetes cluster to be evaluated. Specifically, the actual resource request volume of a pod = max(original pod request volume, P95 value of the actual pod usage). For example, the actual memory resource request volume of a pod in an existing cluster is max(original pod memory request volume, P95 value of the actual pod memory resource usage).

[0061] It should be noted that the P95 value is the 95th percentile in a statistical distribution, indicating that 95% of the values ​​in a dataset are less than or equal to this value, and only 5% of the values ​​are greater than it. It is often used to describe extreme cases in data.

[0062] Step S13: Simulate the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled.

[0063] It should be noted that the evaluation simulator performs a round-robin simulation of Pod scheduling across Nodes, considering application resources and scheduling constraints, and calculating the maximum number of schedulable Pods and the remaining resources on each node. Finally, the evaluation data is compiled, a detailed report is generated, and output to the terminal or file according to the user-specified format (such as tables, JSON (JavaScript Object Notation), or YAML (YAML Ain't Markup Language)).

[0064] In this embodiment, the step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support scheduling for each scheduled container group includes: simulating the scheduling process based on non-parallel scheduling logic and a second scheduling order, and evaluating the maximum number of container groups that each cluster node can support scheduling for each scheduled container group; wherein, the second scheduling order is alternating scheduling; the alternating scheduling process is a process of repeatedly scheduling several scheduled container groups in sequence according to their arrangement order; the non-parallel scheduling logic is logic that does not support multiple cluster nodes simultaneously scheduling scheduled container groups.

[0065] It should be noted that the non-parallel mode supports resource sharing. Assuming there are no dependencies between Pods, the maximum schedulable capacity is evaluated: the number of template Pods that a single node can accommodate is calculated with the recalculated effective available resources of the node as the upper limit (floor(effective available resources / single Pod requirement)), and the global sum is the total capacity.

[0066] In one specific embodiment, if the command parameter format for specifying a pod is: `--pods-from-clusterpodname1 –pods-from-template pod1.yaml`, then both the cluster container group and the custom container group are used simultaneously. Here, `cluster` represents the cluster, `podname1` is the cluster container group, `template` represents the custom template, and `pod1.yaml` represents the custom container group. In this case, if the non-parallel mode supports resource sharing, the specific simulation scheduling steps are as follows: the simulator will first schedule one `podname1`, then schedule one `pod1.yaml`, then schedule another `podname1`, then schedule another `pod1.yaml`, and so on, until there are no resources available for scheduling these two container groups. The number of schedulings for the two container groups can then be calculated.

[0067] In this embodiment, the step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled includes: simulating the scheduling process based on parallel scheduling logic and a first scheduling order, and evaluating the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled; wherein, the first scheduling order is to schedule the container groups to be scheduled one by one in sequence; the process of scheduling the current container group to be scheduled one by one until the current container group to be scheduled cannot be scheduled, and then the next container group to be scheduled is used as the current container group to be scheduled for continued scheduling; the parallel scheduling logic is logic that supports multiple cluster nodes to schedule container groups to be scheduled simultaneously.

[0068] It should be noted that the parallel mode supports dedicated resources: 1. Simulates the real scheduling process, scheduling pods one by one / in batches according to pod constraint rules; 2. Resource deduction: After scheduling a pod, its demand is deducted from the node's available resources (subsequent pods cannot reuse this part of the resources); 3. Parallel optimization: adopts logical parallel scheduling (grouped by node, simultaneously calculating the schedulable quantity of multiple nodes), improving the evaluation efficiency of large clusters; 4. Conflict handling: if a pod fails to schedule due to affinity conflict, the reason for the failure (such as "node without matching label") is recorded and included in the report.

[0069] In another specific embodiment, if the command parameter format for specifying a pod is: `--execution-modeparallel --pods-from-cluster podname1 --pods-from-template pod1.yaml`, then both the cluster container group and the custom container group are used simultaneously. In this case, if the parallel mode supports dedicated resources, the specific simulated scheduling steps are as follows: 1. The simulator continuously allocates available resources to `podname1` until no more resources are available for `podname1`. 2. The simulator continuously allocates the remaining available resources after scheduling `podname1` to `pod1.yaml` until no more resources are available for `pod1.yaml`. Currently, dedicated resources can also be achieved in non-parallel mode, but the scheduling speed is slower compared to parallel mode.

[0070] It should be noted that the core steps of the capacity assessment simulator to reproduce the K8s scheduler are as follows: Filter: Exclude unschedulable nodes based on template constraints (such as insufficient resources or failure to meet affinity); Score: Score the filtered nodes according to the scheduling policy (such as prioritizing nodes with low resource utilization); Bind: Select the node with the highest score to allocate the Pod and update the available resources of the node.

[0071] In this embodiment, a Kubernetes cluster capacity assessment report is finally generated according to a custom output format (JSON / YAML, etc.). The assessment report includes core indicators such as basic information, capacity results, risk warnings, and data comparisons. Specifically, after simulating the scheduling process based on the target scheduling logic to assess the maximum number of container groups that each cluster node can support for scheduling based on the remaining allocable resources and the current resource request volume, the process further includes: integrating basic assessment information; the basic assessment information includes assessment time, total number of cluster nodes, and total number of nodes to be assessed; determining the post-scheduling allocable resources for each cluster node, and determining resource bottleneck nodes based on the post-scheduling allocable resources; calculating the total number of container groups that the Kubernetes cluster to be assessed can support for scheduling based on the maximum number of container groups; and constructing an assessment report based on the basic assessment information, the maximum number of container groups, the total number, the post-scheduling allocable resources, and the resource bottleneck nodes; the resource bottleneck nodes are container groups and nodes that cannot be scheduled.

[0072] It should be noted that the resources that need to be added to the node can be determined based on the maximum number of container groups, the total number of containers, and the amount of resources available after scheduling.

[0073] It should be noted that risk warnings can be issued based on any situation that is unfavorable to scheduling. For example, the amount of resources that can be allocated after scheduling for each cluster node can be determined, and the nodes with over-allocated resources can be identified based on the amount of resources that can be allocated after scheduling. Risk warnings can also be issued based on nodes that are about to reach the scheduling threshold, such as nodes with less than 20% available resources.

[0074] It should be noted that data comparison can be a comparison of the differences between the current assessment results and the previous assessment results (such as changes in the number of schedulable resources or changes in resource utilization).

[0075] It should be noted that after the evaluation process is completed, necessary resource cleanup and log output can be performed to ensure the accuracy of subsequent operations and the stability of the system.

[0076] In summary, this application enables Kubernetes cluster operators to quickly assess the remaining allocable resources of a cluster and analyze its available capacity through simple command calls, even without an intelligent capacity management platform. This allows them to allocate the number of Pod instances with given resource requirements within the cluster, rather than simply performing a macro-level capacity assessment based on the resource allocation rate of a single node or the entire cluster, making the assessment results more concrete. Furthermore, this application automates key aspects of capacity assessment, such as parameter parsing, resource loading, assessment simulation, and result generation, demonstrating the automation and modular implementation of capacity assessment functionality. It should be noted that this solution has the following advantages: 1. It is simple and reliable to use, ready to use out of the box; simply upload the completed binary code file to the service for operation; 2. It provides operators with a clear output of the number of Pods with remaining allocable resources in the cluster, making capacity assessment management more focused and concrete.

[0077] As can be seen, when obtaining the capacity assessment command for the Kubernetes cluster to be assessed, this application maps the cluster resource information to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed; it uses the cluster resource information to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be assessed, obtains several container groups to be scheduled, and determines the current resource request volume corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from the cluster container groups and / or custom container groups; and it simulates the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support scheduling for each container group to be scheduled. Therefore, this application sets up a capacity assessment simulator, and through resource mapping, makes the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed, making the subsequent simulation process more realistic and improving the accuracy of the assessment results. This application assesses the capacity of each cluster by evaluating the maximum number of container groups that each cluster node's remaining allocable resources can support for scheduling each container group to be scheduled. The assessment process considers the current resource request volume corresponding to each container group to be scheduled, rather than only assessing the resources of the nodes and the cluster itself. This allows for the quantification of the cluster container groups that resources can schedule, making the cluster capacity more concrete, and avoiding the situation where resources that cannot support calling cluster container groups are assessed as cluster capacity, thus improving the depth and accuracy of Kubernetes cluster capacity assessment. In addition, the container groups to be scheduled in this application are selected from cluster container groups and / or custom container groups, and are not limited to cluster container groups, improving the applicability of the assessment method. Furthermore, this application considers different scheduling orders for the containers to be scheduled during the assessment.

[0078] Accordingly, this application also discloses a Kubernetes cluster capacity assessment device, applied to a capacity assessment simulator, see [link to relevant documentation]. Figure 2 As shown, the device includes:

[0079] Resource mapping module 11 is used to map cluster resource information to the local machine when obtaining capacity assessment commands for the Kubernetes cluster to be assessed, so that the capacity assessment simulator is consistent with the cluster environment of the Kubernetes cluster to be assessed.

[0080] The resource quantity determination module 12 is used to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated using cluster resource information, obtain several container groups to be scheduled, and determine the current resource request quantity corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from cluster container groups and / or custom container groups.

[0081] The capacity assessment module 13 is used to simulate the scheduling process based on the remaining allocable resources and the current resource request volume, in order to assess the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled.

[0082] The more specific working process of each of the above modules can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0083] As can be seen, when obtaining the capacity assessment command for the Kubernetes cluster to be assessed, this application maps the cluster resource information to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed; it uses the cluster resource information to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be assessed, obtains several container groups to be scheduled, and determines the current resource request volume corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from the cluster container groups and / or custom container groups; the scheduling process is simulated according to the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support scheduling for each container group to be scheduled. Thus, this application sets up a capacity assessment simulator, and through resource mapping, makes the capacity assessment simulator consistent with the Kubernetes cluster to be assessed. The consistent cluster environment of the ubernetes cluster makes the subsequent simulation process more realistic and improves the accuracy of the evaluation results. This application evaluates the capacity of each cluster by assessing the maximum number of container groups that can be scheduled for each schedulable container group supported by the remaining allocable resources of each cluster node. The evaluation process considers the current resource request volume corresponding to each schedulable container group, rather than only evaluating the resources of the nodes and the cluster itself. This quantifies the cluster container groups that resources can be scheduled, making the cluster capacity more concrete and avoiding the situation where resources that cannot support calling cluster container groups are evaluated as cluster capacity, thus improving the depth and accuracy of Kubernetes cluster capacity evaluation. In addition, the schedulable container groups in this application are selected from cluster container groups and / or custom container groups, and are not limited to cluster container groups, improving the applicability of the evaluation method.

[0084] Furthermore, embodiments of this application also provide an electronic device. Figure 3 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0085] Figure 3 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the Kubernetes cluster capacity assessment method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be a computer.

[0086] In this embodiment, the power supply 26 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 25 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 24 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0087] Furthermore, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. The computer programs 221 may include, in addition to computer programs capable of performing the Kubernetes cluster capacity assessment method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, computer programs capable of performing other specific tasks.

[0088] Furthermore, embodiments of this application also disclose a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed Kubernetes cluster capacity assessment method.

[0089] The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0090] The various embodiments in this application are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. For the same or similar parts between the various embodiments, refer to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and relevant parts can be referred to in the method section.

[0091] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0092] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0093] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0094] The foregoing has provided a detailed description of a Kubernetes cluster capacity assessment method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for evaluating the capacity of a Kubernetes cluster, characterized in that, Applied to capacity assessment simulators, including: When obtaining the capacity assessment command for the Kubernetes cluster to be assessed, the cluster resource information is mapped to the local machine to make the capacity assessment simulator consistent with the cluster environment of the Kubernetes cluster to be assessed. The remaining allocable resources for each cluster node in the Kubernetes cluster to be evaluated are determined using cluster resource information. Several container groups to be scheduled are obtained, and the current resource request volume corresponding to each container group to be scheduled is determined. The several container groups to be scheduled are container groups selected from cluster container groups and / or custom container groups. The scheduling process is simulated based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled.

2. The Kubernetes cluster capacity assessment method according to claim 1, characterized in that, The step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled includes: Based on parallel scheduling logic and the first scheduling order, and simulating the scheduling process according to the remaining allocable resources and the current resource request, the maximum number of container groups that each cluster node can support for scheduling is evaluated. The first scheduling order is to schedule container groups one by one in sequence; the process of scheduling container groups one by one in sequence is to schedule the current container group to be scheduled until the current container group to be scheduled cannot be scheduled, and then the next container group to be scheduled is used as the current container group to be scheduled and the scheduling continues; the parallel scheduling logic is the logic that supports multiple cluster nodes to schedule container groups to be scheduled at the same time.

3. The Kubernetes cluster capacity assessment method according to claim 1, characterized in that, The step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled includes: Based on non-parallel scheduling logic and a second scheduling order, and simulating the scheduling process according to the remaining allocable resources and the current resource request, the maximum number of container groups that each cluster node can support for scheduling is evaluated. The second scheduling order is alternating scheduling; the alternating scheduling process is a process of repeatedly scheduling containers according to the order of arrangement of several containers to be scheduled; the non-parallel scheduling logic is a logic that does not support multiple cluster nodes scheduling containers to be scheduled at the same time.

4. The Kubernetes cluster capacity assessment method according to claim 1, characterized in that, The process of determining the remaining allocable resources for each cluster node in the Kubernetes cluster to be evaluated using cluster resource information includes: The original allocated resources and actual resource usage of each cluster node are determined from the cluster resource information. The maximum value between the P95 value of the actual node resource usage and the original allocated resource amount is used as the remaining allocable resource amount of the corresponding cluster node to determine the remaining allocable resource amount of each cluster node in the Kubernetes cluster to be evaluated.

5. The Kubernetes cluster capacity assessment method according to claim 1, characterized in that, Determining the current resource request volume corresponding to each container group to be scheduled includes: If the container group to be scheduled is a cluster container group, the actual resource request amount of the cluster container group determined using the cluster resource information will be used as the current resource request amount of the container group to be scheduled. If the container group to be scheduled is a custom container group, then extract the custom resource request quantity that comes with the custom container group as the current resource request quantity corresponding to the container group to be scheduled. Correspondingly, the methods for determining the actual resource request volume of a cluster container group include: The original cluster container group resource request and actual cluster container group resource usage for each cluster container group are determined from the cluster resource information. The P95 value of the actual cluster container group resource usage and the maximum value of the original cluster container group resource request are used as the actual resource request of the corresponding cluster container group to determine the actual resource request of each cluster container group in the Kubernetes cluster to be evaluated.

6. The Kubernetes cluster capacity assessment method according to claim 1, characterized in that, Also includes: Determine the amount of resources that can be allocated after scheduling for each cluster node, identify the resource over-allocated nodes based on the resource allocation amount after scheduling, and issue risk warnings based on the resource over-allocated nodes.

7. The Kubernetes cluster capacity assessment method according to any one of claims 1 to 6, characterized in that, The step of simulating the scheduling process based on the remaining allocable resources and the current resource request volume to evaluate and obtain the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled also includes: Integrate and evaluate basic information; the basic evaluation information includes evaluation time, total number of cluster nodes, and total number of nodes to be evaluated; Determine the amount of resources that can be allocated after scheduling for each cluster node, and identify the resource bottleneck node based on the amount of resources that can be allocated after scheduling. The total number of container groups to be scheduled in the Kubernetes cluster to be evaluated is calculated based on the maximum number of container groups. An assessment report is constructed based on the assessment baseline information, maximum number of container groups, total number of containers, available resources after scheduling, and resource bottleneck nodes.

8. A Kubernetes cluster capacity assessment device, characterized in that, Applied to capacity assessment simulators, including: The resource mapping module is used to map cluster resource information to the local machine when obtaining capacity assessment commands for the Kubernetes cluster to be assessed, so that the capacity assessment simulator is consistent with the cluster environment of the Kubernetes cluster to be assessed. The resource quantity determination module is used to determine the remaining allocable resources of each cluster node in the Kubernetes cluster to be evaluated using cluster resource information, obtain several container groups to be scheduled, and determine the current resource request quantity corresponding to each container group to be scheduled; wherein, the several container groups to be scheduled are container groups selected from the cluster container groups and / or custom container groups. The capacity assessment module is used to simulate the scheduling process based on the remaining allocable resources and the current resource request volume, in order to assess the maximum number of container groups that each cluster node can support for scheduling each container group to be scheduled.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the Kubernetes cluster capacity assessment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein, when the computer program is executed by a processor, it implements the Kubernetes cluster capacity assessment method as described in any one of claims 1 to 7.

Images