Multi-level computing power resource isolation and fine scheduling method and system in K8S environment

Abstract

The invention provides a multi-level computing power resource isolation and fine scheduling method and system in a K8S environment, and belongs to the technical field of distributed computing resource management. Comprising the following steps: S1, deploying an HNC in a K8S cluster, and establishing a father-child hierarchical relationship of a namespace; s2, performing fine-grained division on GPU resources in the cluster by using an MIG technology, and creating GPU instance groups of different specifications; s3, enabling the child namespace to inherit the resource configuration and authority strategy of the parent namespace through a hierarchical namespace controller; and S4, designing a user-defined scheduler, and accurately scheduling the workload to a proper node meeting the resource requirement of the user-defined scheduler. According to the method, the problems that in the prior art, a K8S native resource management mechanism cannot perform fine-grained division and allocation on GPU resources and lacks multi-level resource management and fine scheduling are solved, the resource utilization rate is increased, resource competition and waste are reduced, and natural mapping of an organization structure and resource management is supported.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed computing resource management, and particularly relates to a method and system for multi-level computing power resource isolation and fine-grained scheduling in a K8S environment. Background Art

[0002] With the rapid development of artificial intelligence and big data applications, the demand for high-performance computing resources, especially GPU resources, is increasing day by day. In the environments of large organizations and cloud service providers, multiple teams, departments, or tenants need to share limited GPU computing power resources, which poses great challenges to resource management and scheduling. The traditional Kubernetes (K8S) resource management method adopts a flat namespace structure, which cannot effectively map the hierarchical structure of the organization, resulting in unreasonable resource allocation, complex permission management, and lack of flexibility.

[0003] In a multi-tenant Kubernetes environment, when different teams share cluster resources, the competition for high-value computing power resources such as GPUs is particularly fierce. In the prior art, the native resource management mechanism of Kubernetes cannot achieve fine-grained partitioning and allocation of GPU resources, resulting in low resource utilization. For example, an inference task that requires a small amount of GPU computing power may occupy the entire GPU card, while the remaining computing power resources are idle; or a high-priority AI training task cannot obtain sufficient GPU resources because the resources have been occupied by low-priority tasks.

[0004] In addition, the existing Kubernetes scheduler mainly makes scheduling decisions based on general resources such as CPU and memory, and insufficiently considers the characteristics of heterogeneous computing resources such as GPUs. When the workload has specific requirements for GPU resources (such as a specific model, memory size, or computing power), it is difficult for the scheduler to make an optimal decision, resulting in task delays, resource waste, or scheduling failures.

[0005] Although NVIDIA provides the MIG technology that allows a single physical GPU to be divided into multiple logical GPU instances, Kubernetes natively does not support the fine-grained management and scheduling of these GPU instances. At the same time, although the node pools technology of cloud service providers can manage groups of computing nodes, it lacks deep integration with the Kubernetes hierarchical resource management.

[0006] In response to the above problems, there have been some solutions in the industry. For example, Kubernetes Federation provides multi-cluster management capabilities but lacks fine-grained resource control; NVIDIA's DCGM provides GPU monitoring but does not support resource isolation; while custom schedulers such as Volcano enhance scheduling capabilities but do not consider namespace hierarchies. Currently, there is a lack of a comprehensive solution that can simultaneously address multi-level resource management, fine-grained GPU resource partitioning, and refined scheduling, which severely restricts the improvement of resource utilization efficiency in large-scale AI computing environments and the resource isolation requirements in multi-tenant scenarios. Summary of the Invention

[0007] To solve the above technical problems, the present invention provides a method for multi-level computing power resource isolation and fine scheduling in a K8S environment, including the following steps:

[0008] Step S1: Construct a hierarchical namespace structure: Deploy a hierarchical namespace controller HNC in the Kubernetes cluster, establish a parent-child hierarchical relationship of namespaces, and realize the mapping from the organizational structure to resource management;

[0009] Step S2: Configure GPU resource pool partitioning: Use MIG technology to perform fine-grained partitioning of GPU resources in the cluster, create different specifications of GPU instance groups, and set resource tags for each instance group;

[0010] Step S3: Implement resource inheritance and isolation: Through HNC, the child namespace inherits the resource configuration and permission policies of the parent namespace, while ensuring resource isolation between different levels;

[0011] Step S4: Execute refined resource scheduling: Based on the namespace hierarchy and GPU instance group tags, design a custom scheduler to accurately schedule the workload to an appropriate node that meets its resource requirements.

[0012] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0013] By introducing a hierarchical namespace structure and fine-grained GPU resource partitioning technology, combined with a resource inheritance and isolation mechanism and a refined scheduling strategy, the present invention effectively solves the management and scheduling problems of high-value computing power resources such as GPUs in a multi-tenant Kubernetes environment.

[0014] (1) The present invention combines the hierarchical namespace controller with fine-grained GPU resource partitioning technology for the first time, realizing the natural mapping from the organizational structure to resource management;

[0015] (2) The present invention proposes a resource inheritance and isolation mechanism based on the namespace hierarchy, solving the problems of resource sharing and isolation in a multi-tenant environment;

[0016] (3) The present invention designs a refined scheduling strategy considering GPU characteristics, which significantly improves resource utilization rate, reduces resource competition and waste, supports the natural mapping of organizational structure and resource management, and is applicable to various scenarios such as large-scale distributed AI training, hybrid load processing, and multi-tenant SaaS platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic flow diagram of a method for multi-level computing power resource isolation and fine scheduling in a K8S environment according to the present invention;

[0018] Figure 2 It is a structural block diagram of a multi-level computing power resource isolation and fine scheduling system in a K8S environment according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0020] Embodiment 1

[0021] As Figure 1 shown, a method for multi-level computing power resource isolation and fine scheduling in a K8S environment provided by an embodiment of the present invention includes the following steps:

[0022] Step S1: Construct a hierarchical namespace structure: Deploy a hierarchical namespace controller HNC in the Kubernetes cluster, establish a parent-child hierarchical relationship of namespaces, and realize the mapping from organizational structure to resource management;

[0023] Step S2: Configure the GPU resource pool division: Use the MIG technology to finely divide the GPU resources in the cluster, create different specifications of GPU instance groups, and set resource labels for each instance group;

[0024] Step S3: Implement resource inheritance and isolation: Through HNC, the child namespace inherits the resource configuration and permission policies of the parent namespace, while ensuring resource isolation between different levels;

[0025] Step S4: Execute refined resource scheduling: Based on the namespace hierarchy and GPU instance group labels, design a custom scheduler to accurately schedule the workload to an appropriate node that meets its resource requirements.

[0026] In one embodiment, the above step S1: Multi-level computing power resource isolation and fine-grained scheduling in the K8S environment specifically includes:

[0027] Step S11: Create a Custom Resource Definition (CRD) to support the hierarchical relationship of namespaces;

[0028] This step is used to deploy the Hierarchical Namespace Controller (HNC). First, install the HNC component through the Helm Chart or Kubernetes Operator method, including the API server, controller, and Webhook components. Create a HierarchicalConfiguration Custom Resource Definition (CRD) to define the parent-child relationship between namespaces. Configure the RBAC permissions of HNC to ensure that it has the permission to manage namespace resources in the cluster.

[0029] Step S12: Design a namespace hierarchy tree according to the organizational structure and create a root namespace as the top-level resource management unit;

[0030] Design a namespace hierarchy tree according to the enterprise organizational structure (such as departments, teams, projects) or resource types (such as development, testing, production). Determine the root namespace as the top-level resource management unit, such as "org-root" or "company-root". Plan the hierarchical structure of sub-namespaces, which can be a two-level structure (such as department - project) or a multi-level structure (such as department - team - project).

[0031] Step S13: Create sub-namespaces under the root namespace, establish a parent-child relationship, and form a multi-level namespace structure;

[0032] Use kubectl or the Kubernetes API to create a root namespace, such as "org-root". Set appropriate labels and annotations for the root namespace for easy identification and management. Create initial resource objects such as resource quotas, limit ranges, and network policies in the root namespace as the inheritance basis for sub-namespaces.

[0033] Create sub-namespaces under the root namespace, such as "department-a", "department-b", etc. By creating a HierarchicalConfiguration object, associate the sub-namespace with the parent namespace to establish a parent-child relationship. For example, create a HierarchicalConfiguration object and specify the parent namespace of "department-a" as "org-root". Repeat this process to create deeper sub-namespaces, such as creating "team-a1", "team-a2", etc. under "department-a" to form a complete multi-level namespace structure.

[0034] Step S14: Configure the resource propagation policy to define the resource types propagated from the parent namespace to the sub-namespace;

[0035] This step defines which resource types can be propagated from the parent namespace to the sub-namespace, such as ResourceQuota, LimitRange, NetworkPolicy, etc. To configure the resource propagation policy of HNC, the global propagation rules can be specified through the Hierarchical Namespace Controller Configuration object, or the propagation rules for a specific namespace can be specified through namespace-level annotations. Set exceptions for resource propagation, as some special resources may need to be excluded from the propagation scope.

[0036] In one embodiment, the above Step S2: Configure the GPU resource pool partitioning: Use the MIG technology to perform fine-grained partitioning of the GPU resources in the cluster, create different specifications of GPU instance groups, and set resource tags for each instance group, specifically including:

[0037] Step S21: Identify the GPU devices in the cluster that support the MIG (Multi Instance GPU) technology;

[0038] In the embodiment of the present invention, NVIDIA Data Center GPU Manager (DCGM) or a custom script is used to scan the GPU devices in the cluster to identify the GPU models that support the MIG technology, such as NVIDIA A100, A30, H100, and H800 series GPUs, as well as Bi-v100 of the domestic TianShu Intelligence Chip Group. Collect detailed information about the GPU devices, including device ID, model, memory capacity, computing power, etc. Verify whether the GPU driver version supports the MIG function to ensure that the NVIDIA driver version is not lower than R450 or higher.

[0039] Step S22: Divide the physical GPU into multiple logical GPU instances according to the workload characteristics and resource requirements. Each GPU instance has independent computing resources and memory;

[0040] Analyze historical workload data to understand the GPU resource consumption patterns of different types of workloads. Determine the types and quantities of GPU instances to be created. For example, divide an A100 GPU into instances with various configurations: 1g.5gb (1 GPU computing unit, 5GB video memory), 2g.10gb (2 GPU computing units, 10GB video memory), 3g.20gb (3 GPU computing units, 20GB video memory), etc. Consider the peak and average demands of the workload to ensure that the resource partitioning scheme can meet the business requirements.

[0041] Use the NVIDIA MIG Manager or nvidia-smi command to perform GPU instance partitioning. For example, use the command "nvidia-smi mig -cgi 1g.5gb,2g.10gb,3g.20gb -C" to divide a single A100 GPU into three different specifications of instances. Verify whether the creation of GPU instances is successful and check the computing resources and memory allocation of each instance. Configure the persistence of GPU instances to ensure that the MIG configuration can be automatically restored after the system restarts.

[0042] Step S23: Create GPU instance groups for different specifications of GPU instances, create corresponding node pools for the GPU instance groups, and add corresponding resource tags to the nodes in the node pools;

[0043] Use the Kubernetes label system to add labels to the nodes, such as "gpu-type=a100-1g.5gb", "gpu-type=a100-3g.20gb", etc. Create node affinity rules to ensure that specific types of workloads can be scheduled to nodes with corresponding GPU instances. Configure node Taints and Tolerations to prevent non-GPU workloads from being scheduled to GPU nodes.

[0044] Step S24: Deploy a GPU resource monitoring component to monitor the usage status and health of each GPU instance in real time;

[0045] Deploy the NVIDIA GPU Operator and DCGM Exporter to collect metrics such as GPU utilization, memory occupancy, temperature, etc. Configure Prometheus and Grafana to achieve visual monitoring of GPU resource usage. Set resource usage threshold alerts to trigger alerts when GPU resource usage exceeds the preset threshold. Develop custom monitoring scripts to collect fine-grained usage data of MIG instances, such as the computing utilization and memory usage of each instance.

[0046] Step S25: Implement secure inter-node communication based on TLS to ensure the confidentiality and integrity of GPU resource information transmission.

[0047] Configure the inter-node communication to use the TLS 1.3 protocol to ensure the security of GPU resource information transmission between nodes. Implement an automatic certificate rotation mechanism to update the TLS certificate regularly and improve the system security. Deploy a key management service to securely store and distribute TLS certificates and keys. Configure network policies to limit the transmission scope of GPU resource information and only allow authorized nodes to access this information.

[0048] In one embodiment, the above step S3: Implement resource inheritance and isolation: Through HNC, the child namespace inherits the resource configuration and permission policies of the parent namespace, while ensuring resource isolation between different levels, specifically including:

[0049] Step S31: Create resource quotas, limit ranges, and network policies in the parent namespace;

[0050] Create a ResourceQuota object in the parent namespace to limit the usage of resources such as CPU, memory, and GPU. Create a LimitRange object to set the default resource requests and limits for containers to prevent over-allocation of resources. Create a NetworkPolicy object to define network access rules and control the network communication of Pods within the namespace. Create ConfigMap and Secret objects to store configuration information and sensitive data for inheritance by child namespaces.

[0051] Step S32: Configure resource propagation rules to enable the child namespace to automatically inherit the resource objects of the parent namespace;

[0052] Configure the propagation rules of resource objects through the HNC's propagation strategy. Specify which types of resource objects can be propagated from the parent namespace to the child namespace, such as ResourceQuota, LimitRange, NetworkPolicy, ConfigMap, Secret, etc. Configure exceptions to resource propagation, as some special resources may need to be excluded from the propagation scope. Set the conflict resolution strategy for resource propagation, i.e., how to handle the situation when there are resources with the same name in the parent and child namespaces.

[0053] Step S33: Implement hierarchical allocation of resource quotas, where the resource quotas of the parent namespace can be proportionally allocated to the child namespaces;

[0054] Design an algorithm for hierarchical allocation of resource quotas to proportionally allocate the resource quotas of the parent namespace to the child namespaces. For example, if the parent namespace has 100 CPU cores, they can be allocated to three child namespaces in the proportions of 40%, 30%, and 30%. Implement a dynamic resource quota adjustment mechanism to dynamically adjust the resource quota allocation ratio according to the resource usage of the child namespaces. Develop a resource quota monitoring tool to monitor the resource usage of each hierarchical namespace in real time to ensure the rationality of resource allocation.

[0055] Step S34: Set resource isolation boundaries to ensure resource access control and network isolation between different namespace hierarchies;

[0056] Use NetworkPolicy and ServiceMesh technologies to set network isolation between namespaces to ensure that network access between different hierarchical namespaces is controlled. Configure resource access control policies to restrict the access rights of child namespaces to the resources of the parent namespace. Implement data isolation between namespaces to prevent the leakage of sensitive data between different namespaces. Set up a resource usage monitoring and auditing mechanism to record resource access behaviors across namespaces.

[0057] Step S35: Deploy an RBAC permission control system to achieve fine-grained role-based access control;

[0058] Create Role, RoleBinding, ClusterRole, and ClusterRoleBinding objects to achieve role-based access control. Design a hierarchical permission model where the administrator of the parent namespace has management permissions over the child namespaces, and the administrator of a child namespace can only manage their own namespace. Implement a permission inheritance mechanism where users in the child namespace automatically inherit the basic permissions of the parent namespace. Configure permission auditing and compliance checks to ensure that permission allocation complies with security policies.

[0059] Step S36: Configure PodSecurityPolicy to restrict the security context and privileged operations of Pods.

[0060] Configure PodSecurityPolicy or Pod Security Admission to restrict privileged operations, volume mounts, system calls, etc. of containers. Specifically, implement the principle of least privilege, prohibit containers from running as the root user, restrict the capabilities of containers, such as disabling high-risk permissions like NET_ADMIN and SYS_ADMIN. Set container runtime security policies, such as AppArmor or SELinux configurations, to enhance the security of container runtime. Create different security profiles for workloads with different security levels, such as three levels: "default", "restricted", and "privileged". Implement an image signature verification mechanism to only allow the use of signed container images, and achieve image signature and verification by integrating tools such as Notary or Cosign. Configure security scanning tools, such as Trivy or Clair, to regularly check for security vulnerabilities in container images and the running environment, and automatically trigger the repair process or alarms based on the severity of the vulnerabilities. Implement runtime security monitoring, use tools such as Falco to detect abnormal behaviors during container runtime, such as unauthorized process execution, sensitive file access, etc., and configure an automatic response mechanism.

[0061] In one embodiment, the above steps perform fine-grained resource scheduling: Based on the namespace hierarchy and GPU instance group labels, design a custom scheduler to precisely schedule workloads to appropriate nodes that meet their resource requirements, specifically including:

[0062] Step S41: Develop a custom scheduler plugin to extend the functionality of the Kubernetes default scheduler;

[0063] Use the Kubernetes Scheduler Framework to develop a custom scheduler plugin to implement extension points such as Filter, Score, and Reserve. Implement a GPU resource-aware scheduling algorithm, considering the type, quantity, and usage status of GPU instances. Develop namespace hierarchy-aware scheduling logic to select appropriate nodes based on the namespace hierarchy to which the Pod belongs. Implement a hot-plug mechanism for the scheduling plugin to support updating the scheduling policy without restarting the scheduler.

[0064] Step S42: Implement affinity rules based on the namespace hierarchy to preferentially schedule workloads to resources at the specified level;

[0065] Design the mapping relationship between the namespace hierarchy and node resources, such as high-level namespaces preferentially using high-performance resources. Through nodeAffinity and podAffinity rules, schedule the workload to the nodes that match its namespace hierarchy preferentially. Implement a resource borrowing mechanism between namespace hierarchies, allowing a certain hierarchy to temporarily use resources from other hierarchies when its own resources are insufficient. Configure the weights and priorities of the affinity rules to balance the requirements of resource isolation and utilization.

[0066] Step S43: Match the corresponding specification of GPU instance groups according to the GPU resource requirements of the workload;

[0067] Develop a GPU resource matching algorithm. Based on the GPU memory and computing power requested by the Pod, select the most suitable MIG instance type. Achieve precise matching of GPU resources to avoid resource waste, such as not scheduling a workload that requires a 1g.5gb instance to a 3g.20gb instance. Develop a GPU resource reservation mechanism to reserve specific types of GPU resources for critical workloads. Implement time-sharing multiplexing of GPU resources, allowing multiple low-intensity workloads to share the same GPU instance.

[0068] Step S44: Support the dynamic migration of workloads between different GPU instance groups to maximize resource utilization;

[0069] Develop a workload status monitoring component to monitor the resource usage of each node in real time. Implement a resource imbalance detection algorithm to trigger workload migration when resource utilization imbalance is detected. Develop a workload migration controller to safely migrate the workload from one GPU instance to another more suitable GPU instance. Implement the state saving and recovery during the migration process to ensure that the workload can continue to execute after migration. Configure migration policies, such as migration frequency limits and migration windows, to avoid system instability caused by frequent migrations.

[0070] Step S45: Use PriorityQueue to manage the Pods to be scheduled;

[0071] Use Kubernetes native PriorityQueue and PriorityClass to manage the scheduling priorities of Pods. Set different priorities for different types of workloads to ensure that critical workloads obtain resources first. Implement a priority preemption mechanism, allowing high-priority workloads to preempt the resources of low-priority workloads when they cannot be scheduled. Develop a dynamic priority adjustment algorithm to dynamically adjust the priority of the workload according to its execution time and importance. Configure the priority inheritance rule, allowing the workloads in the sub-namespace to inherit the priority settings of the parent namespace.

[0072] Step S46: Implement a prediction algorithm based on historical resource usage to optimize resource allocation decisions;

[0073] Collect historical resource usage data and establish a resource usage model. Use time series analysis and machine learning algorithms to predict future resource requirements. Specifically, the system adopts time series prediction models such as LSTM (Long Short-Term Memory Network) and Prophet, combined with feature engineering of GPU resource usage, to build a prediction model. The prediction model takes into account periodicity (such as weekday / weekend patterns, day / night patterns), trends, and seasonal characteristics, and combines anomaly detection algorithms to identify resource usage anomalies. Based on the prediction results, perform resource allocation and adjustment in advance to avoid resource competition. Implement prediction-driven scheduling decisions and schedule workloads to nodes with less future resource pressure. Configure an automatic update mechanism for the prediction model, continuously optimize the prediction model according to the actual resource usage situation, and adopt an online learning method to retrain the model once every 24 hours to ensure prediction accuracy.

[0074] Step S47: Monitor resource usage through the ResourceQuota Controller and trigger the automatic scaling mechanism.

[0075] Monitor resource usage through a custom ResourceQuota Controller. Set resource usage thresholds. When the resource utilization rate exceeds the upper threshold, trigger automatic scaling out; when the resource utilization rate is below the lower threshold, trigger automatic scaling in. Integrate the Horizontal Pod Autoscaler (HPA) to automatically adjust the number of Pod replicas according to CPU, memory, or custom metrics. Integrate the Vertical Pod Autoscaler (VPA) to automatically adjust the resource requests and limits of Pods. Implement automatic scaling of cluster nodes, automatically add or remove nodes according to the overall resource requirements. Configure scaling policies such as cooldown time and step size limits to avoid resource oscillations.

[0076] Through the above steps, a hierarchical namespace structure is constructed, the GPU resource pool division is configured, resource inheritance and isolation are achieved, refined resource scheduling is executed, and the utilization efficiency and isolation performance of computing power resources in the Kubernetes environment are improved.

[0077] Embodiment 2

[0078] As Figure 2 shown, the embodiment of the present invention provides a multi-level computing power resource isolation and fine scheduling system in the K8S environment, including the following modules:

[0079] The hierarchical namespace management module 51 is used to deploy the hierarchical namespace controller HNC in the Kubernetes cluster, establish the parent-child hierarchical relationship of namespaces, and realize the mapping from the organizational structure to resource management;

[0080] The GPU resource pool partitioning module 52 is used to finely partition the GPU resources in the cluster using the MIG technology, create GPU instance groups of different specifications, and set resource labels for each instance group;

[0081] The resource inheritance and isolation module 53 is used to enable the child namespace to inherit the resource configuration and permission policies of the parent namespace through HNC, while ensuring resource isolation between different levels;

[0082] The refined resource scheduling module 54 is used to accurately schedule the workload to the appropriate nodes that meet its resource requirements based on the namespace hierarchy and GPU instance group labels.

[0083] Among them, the hierarchical namespace management module 51 includes the following modules:

[0084] The controller deployment unit 511 is used to deploy the hierarchical namespace controller and create custom resource definitions to support the hierarchical relationship of namespaces;

[0085] The hierarchical structure design unit 512 is used to design the namespace hierarchy tree according to the organizational structure and create the root namespace as the top-level resource management unit;

[0086] The namespace creation unit 513 is used to create child namespaces under the root namespace, establish the parent-child relationship, and form a multi-level namespace structure;

[0087] The propagation policy configuration unit 514 is used to configure the resource propagation policy and define which resource types can be propagated from the parent namespace to the child namespace.

[0088] The GPU resource pool partitioning module 52 includes the following modules:

[0089] The GPU device identification unit 521 is used to identify the GPU devices in the cluster that support the MIG technology;

[0090] The instance partitioning unit 522 is used to divide the physical GPU into multiple logical GPU instances according to the workload characteristics and resource requirements, and each GPU instance has independent computing resources and memory;

[0091] The node pool management unit 523 is used to create GPU instance groups for different specifications of GPU instances, create corresponding node pools for the GPU instance groups, and add corresponding resource labels to the nodes in the node pools;

[0092] A resource monitoring unit 524 is used to deploy a GPU resource monitoring component to monitor the usage status and health of each GPU instance in real time;

[0093] A secure communication unit 525 is used to implement secure communication between nodes based on TLS to ensure the confidentiality and integrity of GPU resource information transmission.

[0094] The resource inheritance and isolation module 53 includes the following modules:

[0095] A resource object creation unit 531 is used to create resource objects such as resource quotas, limit ranges, and network policies in the parent namespace;

[0096] A propagation rule configuration unit 532 is used to configure resource propagation rules so that child namespaces automatically inherit resource objects from the parent namespace;

[0097] A quota allocation unit 533 is used to implement hierarchical allocation of resource quotas, and the resource quotas of the parent namespace can be proportionally allocated to child namespaces;

[0098] An isolation boundary setting unit 534 is used to set resource isolation boundaries to ensure resource access control and network isolation between different namespace levels;

[0099] A permission control unit 535 is used to deploy an RBAC permission control system to implement fine-grained access control based on roles;

[0100] A security policy unit 536 is used to configure PodSecurityPolicy to restrict the security context and privileged operations of Pods.

[0101] The refined resource scheduling module 54 includes the following modules:

[0102] A scheduler plugin development unit 541 is used to develop custom scheduler plugins to extend the functions of the Kubernetes default scheduler;

[0103] An affinity rule implementation unit 542 is used to implement affinity rules based on the namespace level to preferentially schedule workloads to resources at the specified level;

[0104] A resource matching unit 543 is used to match GPU instance groups of corresponding specifications according to the GPU resource requirements of the workload;

[0105] A load migration unit 544 is used to support dynamic migration of workloads between different GPU instance groups to maximize resource utilization;

[0106] An automatic repair unit 545 is used to detect and recover Pod failures caused by node failures;

[0107] The horizontal auto-scaling unit 546 is used to automatically adjust the number of Pod replicas based on CPU, memory, and GPU utilization;

[0108] The vertical auto-scaling unit 547 is used to dynamically adjust the resource requests and limits of Pods;

[0109] The priority queue management unit 548 is used to manage the Pods to be scheduled using PriorityQueue;

[0110] The prediction algorithm unit 549 is used to implement a prediction algorithm based on the resource usage history to optimize resource allocation decisions.

[0111] For the multi-level computing power resource isolation and fine-grained scheduling method and system in the K8S environment of the present invention, compared with the prior art, the present invention constructs a hierarchical namespace structure, configures the division of GPU resource pools, realizes resource inheritance and isolation, and executes fine-grained resource scheduling, solving multiple key problems in the management of computing power resources in the Kubernetes environment. The method provided by the present invention realizes multi-level isolation and fine-grained scheduling of computing power resources by introducing hierarchical namespaces and MIG technology, improves resource utilization efficiency, reduces the risk of resource contention, enhances system security, and thus realizes the efficient management of computing power resources in the Kubernetes environment.

[0112] The above are only specific embodiments of the present invention, enabling those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present invention will not be limited to these embodiments shown herein, but will conform to the broadest scope consistent with the principles and novel features claimed herein.

Claims

1. A multi-level computing power resource isolation and fine-grained scheduling method in a K8S environment, characterized in that Including: Step S1: Construct a hierarchical namespace structure: Deploy a hierarchical namespace controller HNC in the Kubernetes cluster, establish a parent-child hierarchical relationship of namespaces, and realize the mapping from the organizational structure to resource management; Step S2: Configure the GPU resource pool partitioning: Use the MIG technology to finely partition the GPU resources in the cluster, create GPU instance groups of different specifications, and set resource labels for each instance group; Step S3: Implement resource inheritance and isolation: Through HNC, enable the child namespace to inherit the resource configuration and permission policies of the parent namespace, while ensuring resource isolation between different levels; Step S4: Execute refined resource scheduling: Based on the namespace hierarchy and GPU instance group labels, design a custom scheduler to accurately schedule the workload to the appropriate nodes that meet its resource requirements.

2. The method for multi-level computing power resource isolation and fine-grained scheduling in the K8S environment according to claim 1, characterized in that The said Step S1: Construct a hierarchical namespace structure: Deploy a hierarchical namespace controller HNC in the Kubernetes cluster, establish a parent-child hierarchical relationship of namespaces, and realize the mapping from the organizational structure to resource management, specifically including: Step S11: Create a custom resource definition CRD to support the hierarchical relationship of namespaces; Step S12: Design a namespace hierarchy tree according to the organizational structure, and create a root namespace as the top-level resource management unit; Step S13: Create child namespaces under the root namespace, establish a parent-child relationship, and form a multi-level namespace structure; Step S14: Configure the resource propagation policy and define the resource types propagated from the parent namespace to the child namespace.

3. The method for multi-level computing power resource isolation and fine-grained scheduling in the K8S environment according to claim 1, wherein The said Step S2: Configure the GPU resource pool partitioning: Use the MIG technology to finely partition the GPU resources in the cluster, create GPU instance groups of different specifications, and set resource labels for each instance group, specifically including: Step S21: Identify the GPU devices in the cluster that support the MIG technology; Step S22: According to the workload characteristics and resource requirements, divide the physical GPU into multiple logical GPU instances, and each GPU instance has independent computing resources and memory; Step S23: Create GPU instance groups for different specifications of GPU instances, create corresponding node pools for the GPU instance groups, and add corresponding resource labels to the nodes in the node pools; Step S24: Deploy a GPU resource monitoring component to monitor the usage status and health of each GPU instance in real time; Step S25: Implement secure communication between nodes based on TLS to ensure the confidentiality and integrity of GPU resource information transmission.

4. The method for multi-level computing power resource isolation and fine-grained scheduling in the K8S environment according to claim 1, wherein The said Step S3: Implement resource inheritance and isolation: Through HNC, enable the child namespace to inherit the resource configuration and permission policies of the parent namespace, while ensuring resource isolation between different levels, specifically including: Step S31: Create resource quotas, limit ranges, and network policies in the parent namespace; Step S32: Configure the resource propagation rules to enable the child namespace to automatically inherit the resource objects of the parent namespace; Step S33: Implement hierarchical allocation of resource quotas, and the resource quotas of the parent namespace can be proportionally allocated to the child namespaces. Step S34: Set resource isolation boundaries to ensure resource access control and network isolation between different namespace levels; Step S35: Deploy the RBAC permission control system to achieve fine-grained role-based access control; Step S36: Configure PodSecurityPolicy to restrict the security context and privileged operations of Pods.

5. The method for multi-level computing power resource isolation and fine-grained scheduling in the K8S environment according to claim 1, characterized in that, The said Step S4: Perform refined resource scheduling: Based on the namespace level and GPU instance group labels, design a custom scheduler to accurately schedule the workload to appropriate nodes that meet its resource requirements, specifically including: Step S41: Develop a custom scheduler plugin to extend the functionality of the Kubernetes default scheduler; Step S42: Implement affinity rules based on the namespace level to preferentially schedule the workload to resources at the specified level; Step S43: Match the corresponding GPU instance group according to the GPU resource requirements of the workload; Step S44: Support the dynamic migration of the workload between different GPU instance groups to maximize resource utilization; Step S45: Use PriorityQueue to manage the Pods to be scheduled; Step S46: Implement a prediction algorithm based on the resource usage history to optimize resource allocation decisions; Step S47: Monitor the resource usage through the ResourceQuota Controller to trigger the automatic scaling mechanism.

6. A multi-level computing power resource isolation and fine-grained scheduling system in a K8S environment, characterized in that, It includes the following modules: Hierarchical namespace management module, used to deploy the hierarchical namespace controller HNC in the Kubernetes cluster, establish the parent-child hierarchical relationship of namespaces, and realize the mapping from the organizational structure to resource management; GPU resource pool partitioning module, used to use MIG technology to perform fine-grained partitioning of the GPU resources in the cluster, create different specifications of GPU instance groups, and set resource labels for each instance group; Resource inheritance and isolation module, used to enable the child namespace to inherit the resource configuration and permission policies of the parent namespace through HNC, while ensuring resource isolation between different levels; Refined resource scheduling module, used to accurately schedule the workload to appropriate nodes that meet its resource requirements based on the namespace level and GPU instance group labels.

7. The multi-level computing power resource isolation and fine-grained scheduling system in the K8S environment according to claim 6, characterized in that, The said hierarchical namespace management module includes the following modules: Controller deployment unit, used to deploy the hierarchical namespace controller and create custom resource definitions to support the hierarchical relationship of namespaces; Hierarchical structure design unit, used to design the namespace hierarchical tree according to the organizational structure and create the root namespace as the top-level resource management unit; Namespace creation unit, used to create child namespaces under the root namespace, establish the parent-child relationship, and form a multi-level namespace structure; Propagation policy configuration unit, used to configure the resource propagation policy and define which resource types can be propagated from the parent namespace to the child namespace.

8. The multi-level computing power resource isolation and fine-grained scheduling system in the K8S environment according to claim 6, characterized in that, The said GPU resource pool partitioning module includes the following modules: GPU device identification unit, used to identify the GPU devices in the cluster that support MIG technology; Instance partitioning unit, which is used to partition a physical GPU into multiple logical GPU instances according to workload characteristics and resource requirements, and each GPU instance has independent computing resources and memory; Node pool management unit, which is used to create GPU instance groups for GPU instances of different specifications, create corresponding node pools for the GPU instance groups, and add corresponding resource tags to the nodes in the node pools; Resource monitoring unit, which is used to deploy GPU resource monitoring components to monitor the usage status and health of each GPU instance in real time; Secure communication unit, which is used to implement secure communication between nodes based on TLS to ensure the confidentiality and integrity of GPU resource information transmission.

9. The multi-level computing power resource isolation and fine-grained scheduling system in the K8S environment according to claim 6, characterized in that, The resource inheritance and isolation module includes the following modules: Resource object creation unit, which is used to create resource objects such as resource quotas, limit ranges, and network policies in the parent namespace; Propagation rule configuration unit, which is used to configure resource propagation rules to enable child namespaces to automatically inherit resource objects from the parent namespace; Quota allocation unit, which is used to implement hierarchical allocation of resource quotas, and the resource quotas of the parent namespace can be proportionally allocated to child namespaces; Isolation boundary setting unit, which is used to set resource isolation boundaries to ensure resource access control and network isolation between different namespace levels; Permission control unit, which is used to deploy an RBAC permission control system to implement fine-grained access control based on roles; Security policy unit, which is used to configure PodSecurityPolicy to restrict the security context and privileged operations of Pods.

10. The multi-level computing power resource isolation and fine-grained scheduling system in the K8S environment according to claim 6, wherein, The refined resource scheduling module includes the following modules: Scheduler plugin development unit, which is used to develop custom scheduler plugins to extend the functions of the Kubernetes default scheduler; Affinity rule implementation unit, which is used to implement affinity rules based on the namespace level to preferentially schedule workloads to resources at the specified level; Resource matching unit, which is used to match corresponding GPU instance groups according to the GPU resource requirements of the workload; Load migration unit, which is used to support the dynamic migration of workloads between different GPU instance groups to maximize resource utilization; Automatic repair unit, which is used to detect and recover Pod failures caused by node failures; Horizontal auto-scaling unit, which is used to automatically adjust the number of Pod replicas based on CPU, memory, and GPU utilization; Vertical auto-scaling unit, which is used to dynamically adjust the resource requests and limits of Pods; Priority queue management unit, which is used to manage Pods to be scheduled using PriorityQueue; Prediction algorithm unit, which is used to implement a prediction algorithm based on historical resource usage to optimize resource allocation decisions.

Images