CPU resource allocation management method and device based on k8s cluster and medium
By introducing a CPU manager and CRD files into the Kubernetes cluster, automated management of hardware interrupt binding is achieved, solving the problems of low CPU resource allocation efficiency and poor security in existing technologies, improving configuration efficiency and security, and reducing latency.
Patent Information
- Application Number
- CN202511684299.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-17
- Publication Date
- 2026-02-17
AI Technical Summary
In existing technologies, it is not possible to directly set hardware interrupts to specific CPU cores through native APIs in Kubernetes clusters. This results in CPU resource allocation relying on manual configuration, which is inefficient and error-prone, making it difficult to achieve correct configuration and security management in large-scale clusters.
By introducing a CPU manager into the Kubernetes cluster, the automated management of hardware interrupt-bound CPU resources can be achieved using custom resource definition (CRD) files. This includes automatically allocating target containers to run on specified CPU cores, reducing manual intervention and security risks.
It improves the configuration efficiency of CPU resource allocation, reduces the probability of errors, enhances the management efficiency of cluster security and hardware interrupt affinity, ensures data locality and execution continuity of interrupt handling, and reduces latency.
Smart Images
Figure CN121542035A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Kubernetes cluster technology, and in particular to a method, apparatus, device and medium for CPU resource allocation and management based on a k8s cluster. Background Technology
[0002] With the rapid development of cloud computing and containerization technologies, Kubernetes (k8s) has become the de facto standard for distributed system resource orchestration and management. In high-concurrency, low-latency scenarios, such as high-frequency trading in finance, real-time industrial control, and audio / video streaming, applications place higher demands on the scheduling accuracy and performance stability of computing resources. Among these, the rational allocation and isolation of CPU resources is a core element in ensuring the quality of service for critical business applications.
[0003] In existing technologies, it is not possible to directly bind hardware interrupts to specific CPU cores in a Kubernetes cluster through the native API. Instead, it is often necessary to manually log in to the host node and configure which CPU cores can handle specific hardware interrupts through preset commands.
[0004] It can be seen that the existing CPU resource allocation and management methods rely entirely on manual configuration, which is inefficient. When the cluster and business scale are large, configuration errors are prone to occur and are difficult to troubleshoot. Summary of the Invention
[0005] The purpose of this application is to address the shortcomings of the prior art by providing a CPU resource allocation and management method, apparatus, device, and medium based on a Kubernetes cluster, which can improve configuration efficiency and reduce the probability of errors.
[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, the present invention provides a CPU resource allocation and management method based on a Kubernetes cluster. The method is applied to a CPU manager deployed on each node in the Kubernetes cluster. The Kubernetes cluster further includes a cluster management server, which is communicatively connected to each node. The method includes: Receive a workload request sent by the cluster management server, the workload request carrying the target CPU resource type and target number of CPU cores to be used; Based on the type of target CPU resources requested, the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request based on the hardware interrupt bound CPU resource CRD file, so that the target container can run on the target CPU cores. The hardware interrupt bound CPU resource CRD file is used to indicate the CPU resources on this node that are bound to the hardware interrupt source.
[0007] In an optional implementation, the target CPU resource type requested is either a hardware interrupt first-bound CPU resource or a hardware interrupt second-bound CPU resource. The hardware interrupt is first bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on the same NUMA node; the hardware interrupt is second bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on different NUMA nodes.
[0008] In an optional implementation, the step of exclusively allocating target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request based on the CPU resource CRD file, according to the type of target CPU resources requested, so that the target container runs on the target CPU cores, includes: If the target CPU resource type in the workload request indicates that it occupies the first bound CPU resource of the hardware interrupt, then the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request from the hardware interrupt first bound CPU resource pool indicated by the hardware interrupt bound CPU resource CRD file. If the target CPU resource type in the workload request indicates that it occupies the second bound CPU resource of the hardware interrupt, then the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request from the second bound CPU resource pool of the hardware interrupt indicated by the hardware interrupt bound CPU resource CRD file.
[0009] In an optional implementation, the target CPU resource type occupied by the request is a CPU resource without hardware interrupt binding, which is used for container operation and is not bound to a specified hardware interrupt source. After receiving the workload request sent by the cluster management server, the method further includes: If the target CPU resource type in the workload request indicates that it occupies CPU resources without hardware interrupt binding, then the target CPU cores corresponding to the number of target CPU cores are exclusively allocated from the CPU resource pool without hardware interrupt binding to the target container corresponding to the workload request.
[0010] In an optional implementation, before receiving the workload request sent by the cluster management server, the method further includes: Start the CPU manager and create a shared pool that includes all available CPU resources on this node. All available CPU resources include at least one of the following: CPU resources reserved for system operation, CPU resources without hardware interrupt binding, CPU resources with hardware interrupt first binding, and CPU resources with hardware interrupt second binding. Remove the CPU resources reserved for system operation from the shared pool.
[0011] In an optional implementation, the step of exclusively allocating the target CPU cores corresponding to the target number of CPU cores to the target container corresponding to the workload request based on the CPU resource CRD file, according to the target CPU resource type requested, includes: Based on the type of target CPU resources requested in the workload request, the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request based on the CPU resource CRD file, and the target CPU cores corresponding to the number of target CPU cores are removed from the shared pool. The target container and the target CPU core are bound at the operating system level.
[0012] In an optional implementation, the method further includes: Run the preset monitoring agent to obtain the binding relationship information between hardware interrupt sources and CPU cores in this node; The CPU resource controller updates the binding relationship information between hardware interrupt sources and CPU cores in this node to the corresponding custom resource instance of this node, and generates a hardware interrupt binding CPU resource CRD file and / or a total CPU resource CRD file, so that the cluster management server can visualize the information based on the hardware interrupt binding CPU resource CRD file and / or the total CPU resource CRD file. The total CPU resource CRD file is used to indicate the global CPU resource information of each node in the Kubernetes cluster.
[0013] In an optional implementation, the total CPU resource CRD file includes at least one of the following information: the number of CPU cores in each node, the logical core corresponding to each physical CPU core when hyper-threading is enabled, the number of NUMA nodes in the k8s cluster, the CPU core corresponding to each NUMA node, and the hardware interrupt source corresponding to each NUMA node. The hardware interrupt-bound CPU resource CRD file includes at least one of the following information: The CPU core identifier bound to the hardware interrupt source, and whether the CPU core bound to the hardware interrupt source is effective.
[0014] Secondly, the present invention provides a CPU resource allocation management device based on a Kubernetes cluster. The CPU resource allocation management device is applied to the CPU managers deployed on each node in the Kubernetes cluster. The Kubernetes cluster further includes a cluster management server, which is communicatively connected to each node. The CPU resource allocation management device includes: The receiving module is used to receive workload requests sent by the cluster management server. The workload requests carry the type of target CPU resources to be used and the number of target CPU cores. The allocation module is used to exclusively allocate the target CPU cores corresponding to the target number of CPU cores to the target container corresponding to the workload request based on the target CPU resource type requested and the hardware interrupt bound CPU resource CRD file, so that the target container can run on the target CPU cores. The hardware interrupt bound CPU resource CRD file is used to indicate the CPU resources bound to the hardware interrupt source on this node.
[0015] In an optional implementation, the target CPU resource type requested is either a hardware interrupt first-bound CPU resource or a hardware interrupt second-bound CPU resource. The hardware interrupt is first bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on the same NUMA node; the hardware interrupt is second bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on different NUMA nodes.
[0016] In an optional implementation, the allocation module is specifically used to exclusively allocate the target CPU cores corresponding to the number of target CPU cores from the hardware interrupt first bound CPU resource pool indicated by the hardware interrupt bound CPU resource CRD file to the target container corresponding to the workload request if the target CPU resource type in the workload request indicates that it occupies the hardware interrupt first bound CPU resource. If the target CPU resource type in the workload request indicates that it occupies the second bound CPU resource of the hardware interrupt, then the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request from the second bound CPU resource pool of the hardware interrupt indicated by the hardware interrupt bound CPU resource CRD file.
[0017] In an optional implementation, the target CPU resource type occupied by the request is a CPU resource without hardware interrupt binding, which is used for container operation and is not bound to a specified hardware interrupt source. The receiving module is further configured to, if the target CPU resource type in the workload request indicates that it occupies CPU resources without hardware interrupt binding, exclusively allocate the target CPU cores corresponding to the number of target CPU cores from the CPU resource pool without hardware interrupt binding to the target container corresponding to the workload request.
[0018] In an optional implementation, the receiving module is further configured to start the CPU manager and create a shared pool, the shared pool including all available CPU resources on the local node, the all available CPU resources including at least one of the following: CPU resources reserved for system operation, CPU resources without hardware interrupt binding, CPU resources bound to a first hardware interrupt, and CPU resources bound to a second hardware interrupt. Remove the CPU resources reserved for system operation from the shared pool.
[0019] In an optional implementation, the allocation module is specifically used to allocate the target CPU cores corresponding to the target number of CPU cores to the target container corresponding to the workload request based on the CPU resource CRD file according to the target CPU resource type requested in the workload request, and remove the target CPU cores corresponding to the target number of CPU cores from the shared pool. The target container and the target CPU core are bound at the operating system level.
[0020] In an optional implementation, the device further includes: a processing module, used to run a preset monitoring agent to obtain information on the binding relationship between hardware interrupt sources and CPU cores in this node; The CPU resource controller updates the binding relationship information between hardware interrupt sources and CPU cores in this node to the corresponding custom resource instance of this node, and generates a hardware interrupt binding CPU resource CRD file and / or a total CPU resource CRD file, so that the cluster management server can visualize the information based on the hardware interrupt binding CPU resource CRD file and / or the total CPU resource CRD file. The total CPU resource CRD file is used to indicate the global CPU resource information of each node in the Kubernetes cluster.
[0021] In an optional implementation, the total CPU resource CRD file includes at least one of the following information: the number of CPU cores in each node, the logical core corresponding to each physical CPU core when hyper-threading is enabled, the number of NUMA nodes in the k8s cluster, the CPU core corresponding to each NUMA node, and the hardware interrupt source corresponding to each NUMA node. The hardware interrupt-bound CPU resource CRD file includes at least one of the following information: The CPU core identifier bound to the hardware interrupt source, and whether the CPU core bound to the hardware interrupt source is effective.
[0022] In a second aspect, the present invention provides an electronic device, comprising: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the CPU resource allocation and management method based on a k8s cluster as described in any of the foregoing embodiments.
[0023] Thirdly, the present invention provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the steps of the CPU resource allocation and management method based on any of the foregoing embodiments.
[0024] The beneficial effects of this application are: The CPU resource allocation and management method, apparatus, device, and medium based on a Kubernetes cluster provided in this application include: receiving a workload request sent by a cluster management server, the workload request carrying the type of target CPU resource to be occupied and the number of target CPU cores; according to the type of target CPU resource to be occupied, allocating the target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request exclusively based on a hardware interrupt bound CPU resource CRD file, so that the target container runs on the target CPU cores; the hardware interrupt bound CPU resource CRD file is used to indicate the CPU resources on the node bound to the hardware interrupt source. By applying this application embodiment, hardware interrupt affinity configuration can be achieved without manual tedious hardware interrupt affinity configuration and host node labeling, which can improve the configuration efficiency of hardware interrupt affinity in the Kubernetes cluster and reduce the probability of errors; in addition, it is not necessary to expose all permissions to the target container corresponding to the workload request, the CPU manager on the node can deploy the target container corresponding to the workload request on the CPU core bound to the hardware interrupt, which can improve the security of each node in the Kubernetes cluster. Attached Figure Description
[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0026] Figure 1 A flowchart illustrating a CPU resource allocation and management method based on a Kubernetes cluster, provided for an embodiment of this application; Figure 2 A flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided in this application embodiment; Figure 3 A flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided in this application embodiment; Figure 4 A flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided in this application embodiment; Figure 5 A flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided in this application embodiment; Figure 6 A flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided in this application embodiment; Figure 7 A schematic diagram of the functional modules of a CPU resource allocation and management device based on a Kubernetes cluster, provided for an embodiment of this application; Figure 8 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation
[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0028] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0029] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0030] Before introducing this application, let's first explain the basic principle of hardware interrupt binding to CPU cores: binding a specific hardware interrupt to a specific CPU core is an effective way to improve the performance of latency-sensitive or high-throughput applications. By default, taking Linux as an example, Linux distributes interrupts evenly across all CPU cores. This leads to frequent switching between CPU cores handling interrupts, causing context switching and cache misses, increasing processing latency. However, by binding a specific hardware interrupt to a specific core, the instructions and data required by the interrupt handler are more likely to reside in the local cache of that core, significantly reducing cache misses and thus lowering interrupt response latency. This makes response time more stable and predictable, which is crucial for real-time systems, industrial control, and high-frequency trading scenarios.
[0031] In Kubernetes, it's not possible to directly bind hardware interrupts to specific CPU cores using the native API. Hardware interrupt binding typically needs to be configured at the operating system level or within the node itself. Related technologies primarily use indirect methods to configure hardware interrupt affinity within Kubernetes. Hardware interrupt (IRQ) affinity determines which CPU cores can handle specific hardware interrupts.
[0032] In related technologies, hardware interrupt affinity is often set using the following two methods. The first method includes the following steps: 1. Configure interrupt affinity on the target node.
[0033] 2. Manually log in to the host node.
[0034] 3. Use the / proc / irq / 123 / smp_affinity command (adjust the specific IRQ number and target CPU mask according to the actual situation) to bind the specified hardware interrupt to the desired CPU core.
[0035] 4. Add the configuration command to the node startup script (such as / etc / rc.local) or use a system service (such as systemdservice) to ensure that the binding relationship takes effect every time the host machine starts.
[0036] 5. Add a specific label to the host node that has completed the binding relationship configuration to indicate that the node supports the binding relationship.
[0037] 6. By using node affinity, Pods are scheduled to nodes that have been marked with good binding relationships.
[0038] In addition, some related technologies also use method two for setup, and the setup steps for method two include: 1. Create a privileged Init container and assign it sufficient permissions to modify the host machine's interrupt affinity.
[0039] 2. Execute the binding command / proc / irq / * / smp_affinity in the Init container to bind the specified hardware interrupt to the desired CPU core.
[0040] 3. On the host machine where the Init container is running, run the main application container in the same Pod and complete the interrupt binding configuration.
[0041] As can be seen, Method 1 requires tedious manual configuration of hardware interrupt affinity and host node labeling, making it difficult to fully utilize Kubernetes' automated orchestration capabilities. When the cluster and business scale are large, configuration errors are prone to occur and are difficult to troubleshoot. Method 2, granting privileges to containers, introduces significant security risks, as all permissions of the host kernel are exposed to the business containers. Therefore, it must be used in a highly trusted environment; otherwise, the host machine may be placed in a state of high security risk.
[0042] In view of this, this application provides a CPU resource allocation and management method based on a Kubernetes cluster, which can improve the configuration efficiency of hardware interrupt affinity in the Kubernetes cluster and the security of each node in the Kubernetes cluster.
[0043] Figure 1 A schematic diagram of a CPU resource allocation and management system architecture based on a Kubernetes cluster provided by this invention is shown below. Figure 1 As shown, the system architecture may include a k8s cluster and a cluster management server 11. The k8s cluster may include multiple nodes 20 (i.e., host nodes). Each node 20 is communicatively connected to the cluster management server 11. Optionally, each node 20 may be a physical server, virtual machine, computer, etc., which is not limited here.
[0044] Optionally, such as Figure 1As shown, each node 20 may be equipped with a CPU manager 21 and a CPU resource controller 22. In some embodiments, the CPU manager 21 may allocate CPU resources according to the workload requests sent by the cluster management server 11, and the CPU resource controller 22 may obtain the status information of the total CPU resources and the status information of the CPU resources bound to hardware interrupts and send them to the cluster management server 11. The cluster management server 11 may update the CPU resource information of each node 20 accordingly.
[0045] In some implementations, each node 20 may include multiple CPU cores. Taking the node 20 located in the lower left corner of the figure as an example, this node 20 may include five CPU cores: CPU0, CPU1, CPU2, CPU3, and CPU4. Of course, the number of CPU cores corresponding to each node 20 is not limited to this.
[0046] Optionally, in each node 20, the CPU cores are divided into four categories: CPU resources reserved for the system, CPU resources without hardware interrupts, CPU resources with hardware interrupts first bound to them, and CPU resources with hardware interrupts second bound to them.
[0047] Among them, the system-reserved CPU resources are used for the operation of the host system itself and cannot be allocated for container operation; CPU resources without hardware interrupt binding are used for container operation but are not bound to a specified hardware interrupt source; CPU resources with primary hardware interrupt binding are used for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on the same NUMA node; and CPU resources with weak hardware interrupt binding are used for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on different NUMA nodes.
[0048] Figure 2 This invention provides a flowchart illustrating a CPU resource allocation and management method based on a Kubernetes cluster, which can be applied to CPU managers deployed on each node in a Kubernetes cluster. Figure 2 As shown, the method includes: S101, Receive workload requests sent by the cluster management server.
[0049] The workload request carries the type of target CPU resource to be used and the number of target CPU cores.
[0050] Optionally, users can send workload requests to the CPU manager through the cluster management server. Specifically, the workload request may be a Pod scheduling and resource allocation request, which is used to request the CPU manager to allocate CPU resources.
[0051] In some implementations, the workload request may carry the type of target CPU resource to be used, the number of target CPU cores, etc., and the number of target CPU cores may indicate the number of CPU cores required by the target container corresponding to the workload request.
[0052] Optionally, the target CPU resource type can be a CPU resource without hardware interrupt, a CPU resource bound to a first hardware interrupt, or a CPU resource bound to a second hardware interrupt. There is no limitation here, and the specific type may vary depending on the actual application scenario.
[0053] S102. Based on the type of target CPU resources requested in the workload request, allocate the target CPU cores corresponding to the number of target CPU cores exclusively to the target container corresponding to the workload request based on the hardware interrupt bound CPU resource CRD file, so that the target container runs on the target CPU cores. The hardware interrupt bound CPU resource CRD file is used to indicate the CPU resources on this node that are bound to the hardware interrupt source.
[0054] Custom Resource Definition (CRD) is a mechanism used to extend the Kubernetes (k8s) Application Programming Interface (API), allowing users to define their own resource types, i.e., to create user-defined resource types through the extension mechanism.
[0055] Optionally, the hardware interrupt binding CPU resource CRD file can be used to define, store, and manage the CPU resources bound to hardware interrupt sources on each node in the Kubernetes cluster. The hardware interrupt binding CPU resource CRD file can be written in YAML format, defining the structure and fields of the hardware interrupt bound CPU resource. Optionally, the YAML file corresponding to this hardware interrupt binding CPU resource CRD file can be stored in the main storage of the Kubernetes cluster (e.g., etcd).
[0056] In some implementations, the hardware interrupt binding CPU resource CRD file corresponding to this node can be determined based on the binding relationship information between the hardware interrupt source and the CPU core collected by this node. The hardware interrupt binding CPU resource CRD file includes at least one of the following information: the CPU core identifier bound to the specified hardware interrupt source, and whether the CPU core bound to the specified hardware interrupt source is effective.
[0057] When the CPU manager receives a workload request, it can check the request content to determine the type of target CPU resources and the number of target CPU cores. Based on the type of target CPU resources, it can allocate CPU resources by binding the CPU resource CRD file to the hardware interrupt. Specifically, it can exclusively allocate the requested number of CPU resources to the target container corresponding to the workload request (that is, allocate the target CPU cores corresponding to the target number of CPU cores) to ensure that the target container can only run on the allocated CPU resources.
[0058] By applying the embodiments of this application, for workload requests with real-time processing requirements (i.e., hardware interrupt binding), it is possible to deploy the target container corresponding to the workload request on the CPU core bound to the hardware interrupt through the CPU manager on the node, without exposing all permissions to the target container corresponding to the workload request. This improves the security of each node in the Kubernetes cluster. In addition, it eliminates the need for tedious manual configuration of hardware interrupt affinity and labeling of host nodes, thus improving the configuration efficiency of hardware interrupt affinity in the Kubernetes cluster. It should be noted that the configuration of interrupt affinity can ensure the data locality and execution continuity of the interrupt handling context, thereby reducing cache invalidation and cross-core synchronization overhead, significantly reducing event response latency, and improving the system's throughput for handling high-frequency external events.
[0059] In summary, this application provides a CPU resource allocation and management method based on a Kubernetes cluster. This method is applied to CPU managers deployed on each node in the Kubernetes cluster. The Kubernetes cluster also includes a cluster management server, which communicates with each node. The method includes: receiving a workload request sent by the cluster management server, the workload request carrying the type of target CPU resource to be used and the number of target CPU cores; based on the type of target CPU resource to be used, allocating the target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request exclusively, based on a hardware interrupt-bound CPU resource CRD file, so that the target container can exclusively allocate the target CPU cores to the target container corresponding to the target CPU resource request, thereby enabling the target container to utilize the target CPU cores. Running on the PU core, the hardware interrupt is bound to the CPU resource CRD file, which is used to indicate the CPU resources on this node that are bound to the hardware interrupt source. By applying the embodiments of this application, hardware interrupt affinity configuration can be achieved without manual tedious hardware interrupt affinity configuration and host node labeling, which can improve the configuration efficiency of hardware interrupt affinity in the Kubernetes cluster and reduce the probability of errors. In addition, it is not necessary to expose all permissions to the target container corresponding to the workload request. The target container corresponding to the workload request can be deployed on the CPU core bound to the hardware interrupt through the CPU manager on the node, which can improve the security of each node in the Kubernetes cluster.
[0060] In an optional implementation, the target CPU resource type requested is either a hardware interrupt first-bound CPU resource or a hardware interrupt second-bound CPU resource. The first hardware interrupt is bound to CPU resources for container operation, is bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on the same NUMA node; the second hardware interrupt is bound to CPU resources for container operation, is bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on different NUMA nodes.
[0061] Optionally, the specified hardware interrupt source can be specified by the user, for example, it can be a hardware interrupt source related to communication latency and throughput performance, which is not limited here.
[0062] In some implementations, the specified hardware interrupt source can be a network communication interrupt, an operating system-level interrupt, a security-related interrupt, a peripheral-specific interrupt, etc.; the hardware device that generates the specified hardware interrupt source can be a network card, a disk controller, a USB device, etc., and is not limited here.
[0063] Figure 3 This is a flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided by the present invention. In optional implementations, such as... Figure 3 As shown, the above-mentioned allocation of target CPU cores corresponding to the target CPU cores requested by the target container based on the CPU resource CRD file, according to the type of target CPU resources requested, to enable the target container to run on the target CPU cores, includes: S301. If the target CPU resource type in the workload request indicates that it occupies the first bound CPU resource of the hardware interrupt, then from the hardware interrupt bound CPU resource pool indicated by the hardware interrupt bound CPU resource CRD file, the target CPU cores corresponding to the target container of the workload request are exclusively allocated.
[0064] S302. If the target CPU resource type in the workload request indicates that it occupies the second bound CPU resource of the hardware interrupt, then from the second bound CPU resource pool of the hardware interrupt indicated by the hardware interrupt bound CPU resource CRD file, the target CPU cores corresponding to the target container of the workload request are exclusively allocated.
[0065] Optionally, the hardware interrupt bound CPU resource CRD file can indicate: a first hardware interrupt bound CPU resource pool and a second hardware interrupt bound CPU resource pool. The first hardware interrupt bound CPU resource pool can include all hardware interrupt first bound CPU resources, and the second hardware interrupt bound CPU resource pool can include all hardware interrupt second bound CPU resources.
[0066] In some implementations, the hardware interrupt is first bound to CPU resources, which can also be called a hardware interrupt strongly bound to CPU resources, and the hardware interrupt is second bound to a CPU resource pool, which can also be called a hardware interrupt weakly bound to CPU resources.
[0067] In some implementations, if the workload request indicates that it requires the use of hardware interrupt strongly bound CPU resources, then the requested number of CPU resources corresponding to the target container are exclusively allocated from the hardware interrupt strongly bound CPU resource pool; if the workload request indicates that it requires the use of hardware interrupt weakly bound CPU resources, then the requested number of CPU resources corresponding to the target container are exclusively allocated from the hardware interrupt weakly bound CPU resource pool.
[0068] In an optional implementation, the target CPU resource type requested can also be a CPU resource without hardware interrupt binding, which is used for container operation and is not bound to a specified hardware interrupt source.
[0069] In some implementations, after receiving the workload request sent by the cluster management server, the method further includes: If the target CPU resource type in the workload request indicates that it occupies CPU resources without hardware interrupt binding, then the target CPU cores corresponding to the target CPU cores of the target container corresponding to the workload request will be exclusively allocated from the CPU resource pool without hardware interrupt binding.
[0070] Optionally, each node can also create a pool of CPU resources with and without hardware interrupts. This pool of CPU resources with and without hardware interrupts can include all CPU resources with and without hardware interrupts.
[0071] Of course, in some implementations, the workload request can also indicate the need to occupy CPU resources without hardware interrupt binding. In this case, the CPU manager can exclusively allocate the requested number of CPU resources to the target container corresponding to the workload request from the CPU resource pool without hardware interrupt binding. This allows users to automatically deploy such target containers to CPU cores that are not bound to hardware interrupts without needing to know the specific hardware interrupt binding and occupancy status of each node's CPU cores for target containers without real-time processing requirements. This can improve deployment efficiency.
[0072] By applying the embodiments of this application, it is possible to exclusively allocate corresponding CPU resources to the target container corresponding to the workload request based on the target CPU resource type indicated by the workload request, which can improve the configuration efficiency and configuration flexibility of hardware interrupt affinity in the Kubernetes cluster.
[0073] Figure 4 This is a flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided by the present invention. In optional implementations, such as... Figure 4 As shown, before receiving the workload request sent by the cluster management server based on the CPU resource CRD file, the process also includes: S401. Start the CPU Manager and create a shared pool that includes all available CPU resources on this node.
[0074] All available CPU resources include at least one of the following: CPU resources reserved for system operation, CPU resources without hardware interrupt binding, CPU resources with hardware interrupt first binding, and CPU resources with hardware interrupt second binding. For definitions of each type of resource, please refer to the aforementioned related explanations.
[0075] S402. Remove the CPU resources reserved for system operation from the shared pool.
[0076] In some implementations, when the CPU manager starts, a shared pool can be created, which can contain all available CPU resources (i.e. all available CPU cores) on the node. It is understood that since the CPU resources reserved for system operation are system-specific resources, the CPU resources reserved for system operation can be removed from the shared pool, and subsequent allocation of CPU resources can be based on the removed shared pool.
[0077] Specifically, during the allocation process, the CPU manager can retrieve the requested number of CPU cores from the current shared pool and exclusively allocate them to the target container corresponding to the workload request.
[0078] Figure 5 This is a flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided by the present invention. In optional implementations, such as... Figure 5 As shown, the above-mentioned allocation of the target CPU cores corresponding to the target CPU cores exclusively to the target container corresponding to the workload request, based on the target CPU resource type requested in the workload request, includes: S501. Based on the type of target CPU resources requested in the workload request, exclusively allocate the target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request, and remove the target CPU cores corresponding to the number of target CPU cores from the shared pool.
[0079] S502: Bind the target container and the target CPU core at the operating system level.
[0080] In some implementations, based on the type of target CPU resources requested in the workload request, while exclusively allocating the target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request from the shared pool, the allocated target CPU cores can be removed from the shared pool; binding the target container and the target CPU core at the operating system level ensures that the container process can only run on the allocated core. By applying the embodiments of this application, it can be ensured that the target CPU core can be exclusively allocated to the target CPU core, avoiding the duplicate allocation of the target CPU core, and improving the reliability of the method of this application.
[0081] Figure 6 This is a flowchart illustrating another CPU resource allocation and management method based on a Kubernetes cluster provided by the present invention. In optional implementations, such as... Figure 6 As shown, before receiving the workload request sent by the cluster management server based on the CPU resource CRD file, the process also includes: S601. Run the preset monitoring agent to obtain the binding relationship information between hardware interrupt sources and CPU cores in this node.
[0082] Each node can run a monitoring agent to collect information on the binding relationship between hardware interrupt sources and CPU cores, that is, to collect which hardware interrupt sources on this node are bound to which CPU cores.
[0083] S602. The binding relationship information between hardware interrupt sources and CPU cores in this node is updated to the corresponding custom resource instance of this node through the CPU resource controller, and a hardware interrupt binding CPU resource CRD file and / or a total CPU resource CRD is generated so that the cluster management server can perform visual display based on the hardware interrupt binding CPU resource CRD file and / or the total CPU resource CRD.
[0084] The CPU total resource CRD file is used to indicate the global CPU resource information of each node in the Kubernetes cluster.
[0085] In some implementations, initial CRD instances can also be created in the main memory and on each node of the Kubernetes cluster. These initial CRD instances may include: a total CPU resource initial CRD instance and a hardware interrupt bound CPU resource initial CRD instance. The hardware interrupt bound CPU resource initial CRD instance includes: a first hardware interrupt bound CPU resource initial CRD instance and a second hardware interrupt bound CPU resource initial CRD instance.
[0086] Optionally, each node may also include a CPU resource controller. Based on the CRD file definition, the CPU resource controller can update the binding relationship information between hardware interrupt sources and CPU cores collected by the monitoring agent to the initial CRD instance corresponding to this node, and generate a hardware interrupt binding CPU resource CRD file and / or a total CPU resource CRD file. Optionally, the generated hardware interrupt binding CPU resource CRD file and / or total CPU resource CRD file can be stored in the main memory of the Kubernetes cluster (e.g., etcd).
[0087] In some implementations, the hardware interrupt binding CPU resource CRD file and / or the total CPU resource CRD file can be YAML format files.
[0088] Understandably, at this point, the cluster management server can obtain the number of CPU cores bound to the hardware interrupt and related information on each node based on the YAML file corresponding to the CPU resource CRD file bound to the hardware interrupt, and then display it visually; based on the YAML file corresponding to the total CPU resource CRD file, it can obtain the total CPU resource information on each node and display it visually.
[0089] By applying the embodiments of this application, users can directly obtain the number of CPU cores bound to hard interrupts and related information on different nodes through the cluster management server control interface of the Kubernetes cluster, without having to manually obtain them through Linux commands on each physical host. This significantly simplifies system operation and maintenance configuration operations and improves the applicability and flexibility of the Kubernetes cluster.
[0090] In an optional implementation, the total CPU resource CRD file includes at least one of the following information: the number of CPU cores in each node, the logical core corresponding to each physical CPU core when hyper-threading is enabled, the number of NUMA nodes in the Kubernetes cluster, the CPU core corresponding to each NUMA node, and the hardware interrupt source corresponding to each NUMA node.
[0091] The number of CPU cores contained in each node may be the same or different, which is not limited here; the logical core corresponding to each physical CPU core can be understood as a "virtual core" simulated through hardware virtualization technology (such as hyper-threading).
[0092] Of course, this application does not limit the number of logical cores corresponding to each physical CPU core, the number of NUMA nodes in the k8s cluster, the number of CPU cores corresponding to each NUMA node, or the type and number of hardware interrupt sources corresponding to each NUMA node, which may vary depending on the actual application scenario.
[0093] The CRD file for binding CPU resources to hardware interrupts includes at least one of the following information: the CPU core identifier of the bound hardware interrupt source, and whether the CPU core to which the bound hardware interrupt source is active.
[0094] Based on the CPU core identifier bound to the hardware interrupt source, it can be determined which CPU cores are bound to the hardware interrupt source. Depending on the actual application scenario, the CPU core identifiers bound to the hardware interrupt source in each node can be the same or different. Whether the CPU cores bound to the hardware interrupt source are effective can indicate whether the current binding relationship is valid.
[0095] In summary, this application provides a CPU resource allocation and management method based on a Kubernetes cluster. After receiving a workload request, each CPU manager can bind the CPU resource CRD file based on hardware interrupts, allocate target containers requiring latency sensitivity or high throughput performance to the corresponding host nodes, and complete container creation and startup. This can improve the applicability and flexibility of the method in this application.
[0096] Figure 7 This is a functional module diagram of a CPU resource allocation and management device based on a Kubernetes cluster provided by the present invention. The CPU resource allocation and management device is applied to the CPU managers deployed on each node in the Kubernetes cluster. The Kubernetes cluster also includes a cluster management server, which is communicatively connected to each node. The basic principle and technical effects of this device are the same as those in the aforementioned corresponding method embodiments. For the sake of brevity, parts not mentioned in this embodiment can be referred to the corresponding content in the method embodiments. Figure 7 As shown, the CPU resource allocation management device 100 includes: The receiving module 110 is used to receive a workload request sent by the cluster management server. The workload request carries the type of target CPU resource to be used and the number of target CPU cores. The allocation module 120 is used to allocate the target CPU cores corresponding to the target number of CPU cores to the target container corresponding to the workload request based on the type of target CPU resources requested, and the hardware interrupt bound CPU resource CRD file, so that the target container can run on the target CPU cores. The hardware interrupt bound CPU resource CRD file is used to indicate the CPU resources bound to the hardware interrupt source on this node.
[0097] In an optional implementation, the target CPU resource type requested is either a hardware interrupt first-bound CPU resource or a hardware interrupt second-bound CPU resource. The hardware interrupt is first bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on the same NUMA node; the hardware interrupt is second bound to CPU resources for container operation, bound to a specified hardware interrupt source, and the hardware device that generates the specified hardware interrupt source and the CPU core responsible for handling the specified hardware interrupt source are on different NUMA nodes.
[0098] In an optional implementation, the allocation module 120 is specifically used to exclusively allocate the target CPU cores corresponding to the number of target CPU cores to the target container corresponding to the workload request from the hardware interrupt first bound CPU resource pool indicated by the hardware interrupt bound CPU resource CRD file if the target CPU resource type in the workload request indicates that it occupies the hardware interrupt first bound CPU resource. If the target CPU resource type in the workload request indicates that it occupies the second bound CPU resource of the hardware interrupt, then the target CPU cores corresponding to the number of target CPU cores are exclusively allocated to the target container corresponding to the workload request from the second bound CPU resource pool of the hardware interrupt indicated by the hardware interrupt bound CPU resource CRD file.
[0099] In an optional implementation, the target CPU resource type occupied by the request is a CPU resource without hardware interrupt binding, which is used for container operation and is not bound to a specified hardware interrupt source. The receiving module 110 is further configured to, if the target CPU resource type in the workload request indicates that it occupies CPU resources without hardware interrupt binding, exclusively allocate the target CPU cores corresponding to the number of target CPU cores from the CPU resource pool without hardware interrupt binding to the target container corresponding to the workload request.
[0100] In an optional implementation, the receiving module 110 is further configured to start the CPU manager and create a shared pool, the shared pool including all available CPU resources on the local node, and all available CPU resources including at least one of the following: CPU resources reserved for system operation, CPU resources without hardware interrupt binding, CPU resources bound to a first hardware interrupt, and CPU resources bound to a second hardware interrupt. Remove the CPU resources reserved for system operation from the shared pool.
[0101] In an optional implementation, the allocation module 120 is specifically used to allocate the target CPU cores corresponding to the target CPU core count to the target container corresponding to the workload request based on the CPU resource CRD file according to the target CPU resource type requested in the workload request, and remove the target CPU cores corresponding to the target CPU core count from the shared pool. The target container and the target CPU core are bound at the operating system level.
[0102] In an optional implementation, the device further includes: a processing module, used to run a preset monitoring agent to obtain information on the binding relationship between hardware interrupt sources and CPU cores in this node; The CPU resource controller updates the binding relationship information between hardware interrupt sources and CPU cores in this node to the corresponding custom resource instance of this node, and generates a hardware interrupt binding CPU resource CRD file and / or a total CPU resource CRD file, so that the cluster management server can visualize the information based on the hardware interrupt binding CPU resource CRD file and / or the total CPU resource CRD file. The total CPU resource CRD file is used to indicate the global CPU resource information of each node in the Kubernetes cluster.
[0103] In an optional implementation, the total CPU resource CRD file includes at least one of the following information: the number of CPU cores in each node, the logical core corresponding to each physical CPU core when hyper-threading is enabled, the number of NUMA nodes in the k8s cluster, the CPU core corresponding to each NUMA node, and the hardware interrupt source corresponding to each NUMA node. The hardware interrupt-bound CPU resource CRD file includes at least one of the following information: The CPU core identifier bound to the hardware interrupt source, and whether the CPU core bound to the hardware interrupt source is effective.
[0104] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.
[0105] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more microprocessors, or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).
[0106] Figure 8 This is a schematic diagram of an electronic device provided in an embodiment of this application. This electronic device can be integrated into the aforementioned CPU resource allocation and management device. Figure 8 As shown, the electronic device may include a processor 210, a storage medium 220, and a bus 230. The storage medium 220 stores machine-readable instructions executable by the processor 210. When the electronic device is running, the processor 210 communicates with the storage medium 220 via the bus 230, and the processor 210 executes the machine-readable instructions to perform the steps of the above method embodiment. The specific implementation and technical effects are similar and will not be described in detail here.
[0107] Optionally, this application also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described method embodiments. The specific implementation and technical effects are similar and will not be repeated here.
[0108] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0109] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0110] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.
[0111] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0112] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need further definition and explanation in subsequent figures. The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for managing CPU resource allocation based on a k8s cluster, characterized in that, The method is applied to a CPU manager deployed on each node in a k8s cluster, the k8s cluster further comprises a cluster management server, the cluster management server is in communication connection with each node, and the method comprises: receiving a workload request sent by the cluster management server, the workload request carrying a target CPU resource type occupied by a request and a target CPU core number; allocating, according to the target CPU resource type occupied by the request, a target CPU core corresponding to a target CPU core number to a target container corresponding to the workload request based on a hardware interrupt binding CPU resource CRD file, so that the target container runs on the target CPU core, the hardware interrupt binding CPU resource CRD file being used for indicating a CPU resource bound with a hardware interrupt source on the node.
2. The method of claim 1, wherein, The target CPU resource type occupied by the request is a hardware interrupt first binding CPU resource or a hardware interrupt second binding CPU resource. The hardware interrupt first binding CPU resource is used for container running, is bound with a specified hardware interrupt source, and a hardware device generating the specified hardware interrupt source and a CPU core responsible for processing the specified hardware interrupt source are on the same NUMA node; and the hardware interrupt second binding CPU resource is used for container running, is bound with a specified hardware interrupt source, and a hardware device generating the specified hardware interrupt source and a CPU core responsible for processing the specified hardware interrupt source are on different NUMA nodes.
3. The method of claim 2, wherein, The method according to the target CPU resource type occupied by the request, allocating, based on the CPU resource CRD file, a target CPU core corresponding to a target CPU core number to a target container corresponding to the workload request, so that the target container runs on the target CPU core, comprises: If the target CPU resource type in the workload request indicates occupation of the hardware interrupt first binding CPU resource, a target CPU core corresponding to the target CPU core number is allocated to the target container corresponding to the workload request from a hardware interrupt first binding CPU resource pool indicated by the hardware interrupt binding CPU resource CRD file; If the target CPU resource type in the workload request indicates occupation of the hardware interrupt second binding CPU resource, a target CPU core corresponding to the target CPU core number is allocated to the target container corresponding to the workload request from a hardware interrupt second binding CPU resource pool indicated by the hardware interrupt binding CPU resource CRD file.
4. The method of claim 1, wherein, The target CPU resource type occupied by the request is a hardware interrupt first binding CPU resource or a hardware interrupt second binding CPU resource. After receiving the workload request sent by the cluster management server, the method further comprises: If the target CPU resource type in the workload request indicates occupation of the hardware interrupt first binding CPU resource, a target CPU core corresponding to the target CPU core number is allocated to the target container corresponding to the workload request from a hardware interrupt first binding CPU resource pool indicated by the hardware interrupt binding CPU resource CRD file; If the target CPU resource type in the workload request indicates occupation of the hardware interrupt second binding CPU resource, a target CPU core corresponding to the target CPU core number is allocated to the target container corresponding to the workload request from a hardware interrupt second binding CPU resource pool indicated by the hardware interrupt binding CPU resource CRD file.
5. The method of claim 1, wherein, Before receiving the workload request sent by the cluster management server, the method further comprises: starting a CPU manager and creating a shared pool, the shared pool comprising all available CPU resources on the node, the all available CPU resources comprising at least one of the following: a system running reserved CPU resource, a hardware interrupt unbound CPU resource, a hardware interrupt first bound CPU resource, and a hardware interrupt second bound CPU resource; removing the system running reserved CPU resource from the shared pool.
6. The method of claim 5, wherein, allocating, based on the CPU resource CRD file, a target number of target CPU cores to the target container corresponding to the workload request according to the target CPU resource type requested to be occupied in the workload request, and removing the target number of target CPU cores from the shared pool; allocating, based on the CPU resource CRD file, a target number of target CPU cores to the target container corresponding to the workload request according to the target CPU resource type requested to be occupied in the workload request, and removing the target number of target CPU cores from the shared pool; binding the target container and the target CPU core at an operating system level.
7. The method according to any one of claims 1 to 6, characterized in that, The method further comprises: running a preset monitoring agent to obtain binding relationship information of a hardware interrupt source and a CPU core in the node; updating, by a CPU resource controller, the binding relationship information of the hardware interrupt source and the CPU core in the node to a custom resource instance corresponding to the node, and generating a hardware interrupt bound CPU resource CRD file and / or a CPU total resource CRD file, so that the cluster management server visually displays according to the hardware interrupt bound CPU resource CRD file and / or the CPU total resource CRD file, the CPU total resource CRD file being used to indicate global CPU resource information of each node in the k8s cluster.
8. The method of claim 7, wherein, The CPU total resource CRD file comprises at least one of the following information: a number of CPU cores contained by each node, a logical core corresponding to each physical CPU core in the case of opening hyper-threading, a number of NUMA nodes in the k8s cluster, a CPU core corresponding to each NUMA node, and a hardware interrupt source corresponding to each NUMA node; The hardware interrupt bound CPU resource CRD file comprises at least one of the following information: a CPU core identifier bound to a hardware interrupt source, and whether the CPU core bound to the hardware interrupt source is effective.
9. An electronic device, comprising: comprises: a processor, a storage medium, and a bus, the storage medium storing machine readable instructions executable by the processor, the processor and the storage medium communicating through the bus when the electronic device is running, and the processor executing the machine readable instructions to perform the steps of the k8s cluster based CPU resource allocation management method according to any one of claims 1-8.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the steps of the k8s cluster based CPU resource allocation management method according to any one of claims 1-8.