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

Abstract

The present invention proposes a multi-level computing power resource isolation and fine scheduling method and system in a K8S environment, which belongs to the field of distributed computing resource management technology. It includes: S1: deploying HNC in the K8S cluster to establish a parent-child hierarchical relationship of namespaces; S2: using MIG technology to perform fine-grained division of GPU resources in the cluster to create GPU instance groups of different specifications; S3: using the hierarchical namespace controller to enable the child namespace to inherit the resource configuration and permission policy of the parent namespace; S4: designing a custom scheduler to accurately schedule the workload to the appropriate node that meets its resource requirements. The present invention solves the problems in the prior art that the K8S native resource management mechanism is unable to perform fine-grained division and allocation of GPU resources and lacks multi-level resource management and fine scheduling, thereby improving resource utilization, reducing resource competition and waste, and supporting the natural mapping of organizational structure and resource management.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed computing resource management, and in particular relates to a multi-level computing resource isolation and fine scheduling method and system 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, particularly GPUs, is growing. In large organizations and cloud service providers, multiple teams, departments, or tenants need to share limited GPU computing resources, which poses significant challenges to resource management and scheduling. Traditional Kubernetes (K8S) resource management uses a flat namespace structure that fails to effectively reflect the organizational hierarchy, resulting in irrational resource allocation, complex permission management, and a lack of flexibility.

[0003] In a multi-tenant Kubernetes environment, where different teams share cluster resources, competition for high-value computing resources like GPUs is particularly fierce. Existing Kubernetes resource management mechanisms are unable to implement fine-grained partitioning and allocation of GPU resources, resulting in poor resource utilization. For example, an inference task requiring a small amount of GPU computing power might occupy the entire GPU card, leaving the remaining computing resources idle. Or, high-priority AI training tasks might not be able to obtain sufficient GPU resources because they are already occupied by lower-priority tasks.

[0004] Furthermore, existing Kubernetes schedulers primarily make scheduling decisions based on generic resources like CPU and memory, and fail to consider the characteristics of heterogeneous computing resources like GPUs. When workloads have specific requirements for GPU resources (such as specific models, memory sizes, or computing power), the scheduler struggles to make optimal decisions, leading to task delays, resource waste, or scheduling failures.

[0005] While NVIDIA provides MIG technology that allows a single physical GPU to be divided into multiple logical GPU instances, Kubernetes does not natively support the fine-grained management and scheduling of these GPU instances. Meanwhile, while cloud service providers' node pools can manage groups of compute nodes, they lack deep integration with Kubernetes-level resource management.

[0006] The industry already has several solutions to these problems. For example, Kubernetes Federation provides multi-cluster management capabilities but lacks fine-grained resource control; NVIDIA's DCGM provides GPU monitoring but lacks resource isolation; and custom schedulers like Volcano enhance scheduling capabilities but fail to consider the namespace hierarchy. Currently, there is a lack of a comprehensive solution that simultaneously addresses multi-level resource management, fine-grained GPU resource partitioning, and refined scheduling. This severely hinders improving 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 multi-level computing resource isolation and fine scheduling method in a K8S environment, comprising the following steps:

[0008] Step S1: Build a hierarchical namespace structure: Deploy a hierarchical namespace controller (HNC) in the Kubernetes cluster to establish a parent-child hierarchical relationship between namespaces and implement a mapping from 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 GPU instance groups of different specifications, and set resource tags for each instance group;

[0010] Step S3: Implement resource inheritance and isolation: Use HNC to enable the child namespace to inherit the resource configuration and permission policy of the parent namespace, while ensuring resource isolation between different levels;

[0011] Step S4: Perform fine-grained resource scheduling: Based on the namespace hierarchy and GPU instance group labels, design a custom scheduler to accurately schedule workloads to appropriate nodes that meet their resource requirements.

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

[0013] This paper introduces a hierarchical namespace structure and fine-grained GPU resource partitioning technology, combines resource inheritance and isolation mechanisms with refined scheduling strategies, and effectively solves the management and scheduling problems of high-value computing resources such as GPUs in a multi-tenant Kubernetes environment.

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

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

[0016] (3) The present invention designs a refined scheduling strategy that takes into account the characteristics of GPUs, significantly improves resource utilization, reduces resource competition and waste, supports the natural mapping of organizational structure and resource management, and is suitable for a variety of scenarios such as large-scale distributed AI training, mixed load processing, and multi-tenant SaaS platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of a multi-level computing resource isolation and fine scheduling method in a K8S environment of the present invention;

[0018] Figure 2 This is a structural block diagram of a multi-level computing resource isolation and fine scheduling system in a K8S environment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is 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 intended to illustrate the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.

[0020] Example 1

[0021] like Figure 1 As shown, an embodiment of the present invention provides a multi-level computing resource isolation and fine scheduling method in a K8S environment, including the following steps:

[0022] Step S1: Build a hierarchical namespace structure: Deploy a hierarchical namespace controller (HNC) in the Kubernetes cluster to establish a parent-child hierarchical relationship between namespaces and implement a mapping from organizational structure to resource management.

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

[0024] Step S3: Implement resource inheritance and isolation: Use HNC to enable the child namespace to inherit the resource configuration and permission policy of the parent namespace, while ensuring resource isolation between different levels;

[0025] Step S4: Perform fine-grained resource scheduling: Based on the namespace hierarchy and GPU instance group labels, design a custom scheduler to accurately schedule workloads to appropriate nodes that meet their resource requirements.

[0026] In one embodiment, the above step S1: multi-level computing resource isolation and fine-tuning in a K8S environment specifically includes:

[0027] Step S11: Create a custom resource definition (CRD) to support the hierarchical relationship of the namespace;

[0028] This step deploys the Hierarchical Namespace Controller (HNC). First, install the HNC components, including the API server, controller, and webhook components, using a Helm chart or the Kubernetes Operator. Create a HierarchicalConfiguration Custom Resource Definition (CRD) to define the parent-child relationships between namespaces. Configure RBAC permissions for the HNC to ensure it has 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 based on your company's organizational structure (e.g., department, team, project) or resource type (e.g., development, testing, production). Identify a root namespace as the top-level resource management unit, such as "org-root" or "company-root." Plan the hierarchy of subnamespaces, which can be a two-level structure (e.g., department-project) or a multi-level structure (e.g., department-team-project).

[0031] Step S13: Create a child namespace 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 to serve as the foundation for subnamespaces to inherit from.

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

[0034] Step S14: Configure the resource propagation strategy to define the resource types propagated from the parent namespace to the child namespace;

[0035] This step defines which resource types can be propagated from the parent namespace to the child namespace, such as ResourceQuota, LimitRange, and NetworkPolicy. To configure HNC resource propagation policies, you can specify global propagation rules using the Hierarchical Namespace Controller Configuration object or namespace-specific propagation rules using namespace-level annotations. You can also set exceptions for resource propagation; certain special resources may need to be excluded from propagation.

[0036] In one embodiment, the above step S2: configuring GPU resource pool partitioning: using MIG technology to perform fine-grained partitioning of GPU resources in the cluster, creating GPU instance groups of different specifications, and setting resource tags for each instance group, specifically includes:

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

[0038] This embodiment of the present invention uses NVIDIA Data Center GPU Manager (DCGM) or a custom script to scan GPU devices in the cluster and identify GPU models that support MIG technology, such as NVIDIA A100, A30, H100, and H800 series GPUs and the Bi-v100 from Tianshu Zhixin Group. Detailed information about the GPU devices is collected, including device ID, model, memory capacity, and computing power. The GPU driver version is verified to support MIG functionality, ensuring that the NVIDIA driver version is R450 or higher.

[0039] Step S22: Divide the physical GPU into multiple logical GPU instances based on workload characteristics and resource requirements, each GPU instance having independent computing resources and memory;

[0040] Analyze historical workload data to understand GPU resource consumption patterns for different workload types. Determine the type and number of GPU instances to create. For example, partition the A100 GPU into various configurations: 1g.5gb (1 GPU compute unit, 5GB of video memory), 2g.10gb (2 GPU compute units, 10GB of video memory), 3g.20gb (3 GPU compute units, 20GB of video memory), and so on. Consider the peak and average demands of the workload to ensure that the resource allocation plan meets business needs.

[0041] Use the NVIDIA MIG Manager or the nvidia-smi command to partition GPU instances. For example, use the command "nvidia-smi mig -cgi 1g.5gb,2g.10gb,3g.20gb -C" to partition a single A100 GPU into three instances of different specifications. Verify that the GPU instances were created successfully and check the compute resources and memory allocation for each instance. Configure GPU instance persistence to ensure that the MIG configuration is automatically restored after a system restart.

[0042] Step S23: 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;

[0043] Use the Kubernetes labeling system to label nodes, such as "gpu-type=a100-1g.5gb" and "gpu-type=a100-3g.20gb." Create node affinity rules to ensure that specific workload types are 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 usage, memory usage, and temperature. Configure Prometheus and Grafana to visualize GPU resource usage. Set resource usage threshold alarms to trigger when GPU resource usage exceeds the preset threshold. Develop custom monitoring scripts to collect fine-grained usage data for MIG instances, such as compute utilization and memory usage for each instance.

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

[0047] Configure inter-node communication to use TLS 1.3 to ensure secure transmission of GPU resource information between nodes. Implement an automatic certificate rotation mechanism to regularly update TLS certificates and improve 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, allowing only authorized nodes to access this information.

[0048] In one embodiment, the above step S3: Implementing Resource Inheritance and Isolation: Using HNC to enable the child namespace to inherit the resource configuration and permission policy of the parent namespace, while ensuring resource isolation between different levels, specifically includes:

[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 default resource requests and limits for containers to prevent over-allocation of resources. Create a NetworkPolicy object to define network access rules and control network communication for 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 so that the child namespace automatically inherits the resource objects of the parent namespace;

[0052] Use the HNC propagation policy to configure resource object propagation rules. Specify which resource object types can be propagated from the parent namespace to the child namespace, such as ResourceQuota, LimitRange, NetworkPolicy, ConfigMap, and Secret. Configure exceptions for resource propagation; certain special resources may need to be excluded from propagation. Set the resource propagation conflict resolution policy to determine how to handle resources with the same name in the parent and child namespaces.

[0053] Step S33: Implement hierarchical allocation of resource quotas. The resource quotas of the parent namespace can be allocated to the child namespaces in proportion.

[0054] Design a hierarchical resource quota allocation algorithm to proportionally allocate the resource quota of a parent namespace to its child namespaces. For example, if a parent namespace has 100 CPU cores, it can be allocated to three child namespaces in a ratio of 40%, 30%, and 30%. Implement a dynamic resource quota adjustment mechanism to dynamically adjust the resource quota allocation ratio based on the resource usage of the child namespaces. Develop a resource quota monitoring tool to monitor resource usage at all levels of namespaces in real time to ensure the rationality of resource allocation.

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

[0056] Use NetworkPolicy and ServiceMesh technologies to isolate namespaces and ensure controlled network access between namespaces at different levels. Configure resource access control policies to limit child namespaces' access to parent namespace resources. Implement data isolation between namespaces to prevent sensitive data from leaking between them. Set up resource usage monitoring and auditing mechanisms to record cross-namespace resource access.

[0057] Step S35: deploying the RBAC authority control system to implement role-based fine-grained access control;

[0058] Create Role, RoleBinding, ClusterRole, and ClusterRoleBinding objects to implement role-based access control. Design a hierarchical permissions model where parent namespace administrators have management permissions for child namespaces, while child namespace administrators can only manage their own namespaces. Implement a permissions inheritance mechanism where users in child namespaces automatically inherit the basic permissions of the parent namespace. Configure permissions auditing and compliance checks to ensure that permissions are assigned in accordance with security policies.

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

[0060] Configure PodSecurityPolicy or Pod Security Admission to restrict privileged operations, volume mounts, and system calls in containers. Specifically, implement the principle of least privilege, prohibit containers from running as the root user, and restrict container capabilities, such as disabling high-risk permissions like NET_ADMIN and SYS_ADMIN. Set container runtime security policies, such as AppArmor or SELinux configuration, to improve container runtime security. Create different security profiles for workloads with different security levels, such as "default," "restricted," and "privileged." Implement image signature verification to only allow the use of signed container images. Integrate tools such as Notary or Cosign to perform image signing and verification. Configure security scanning tools, such as Trivy or Clair, to regularly check for security vulnerabilities in container images and the runtime environment, automatically triggering remediation processes or alerts based on vulnerability severity. Implement runtime security monitoring, using tools such as Falco to detect abnormal container runtime behavior, such as unauthorized process execution and sensitive file access, and configure automated response mechanisms.

[0061] In one embodiment, the above steps implement refined resource scheduling: based on the namespace hierarchy and GPU instance group tags, a custom scheduler is designed to precisely schedule workloads to appropriate nodes that meet their resource requirements. Specifically, the following steps are performed:

[0062] Step S41: Develop a custom scheduler plug-in to extend the Kubernetes default scheduler function;

[0063] Develop a custom scheduler plugin using the Kubernetes Scheduler Framework, implementing extension points such as Filter, Score, and Reserve. Implement a GPU-resource-aware scheduling algorithm that considers the type, number, and usage status of GPU instances. Develop namespace-level-aware scheduling logic to select appropriate nodes based on the namespace level to which the Pod belongs. Implement a hot-swappable mechanism for the scheduling plugin, supporting updates to the scheduling policy without restarting the scheduler.

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

[0065] Design the mapping between namespace tiers and node resources, such as prioritizing high-performance resources for higher-level namespaces. Use nodeAffinity and podAffinity rules to prioritize workloads on nodes that match their namespace tiers. Implement a resource borrowing mechanism between namespace tiers so that when resources at one tier are insufficient, resources from other tiers can be temporarily used. Configure the weight and priority of affinity rules to balance resource isolation and utilization requirements.

[0066] Step S43: Matching a GPU instance group with corresponding specifications based on the GPU resource requirements of the workload;

[0067] Develop a GPU resource matching algorithm to select the most appropriate MIG instance type based on the GPU memory and compute power requested by a pod. This ensures precise matching of GPU resources to avoid wasted resources, such as not scheduling a workload requiring a 1g or 5gb instance onto a 3g or 20gb instance. Develop a GPU resource reservation mechanism to reserve specific GPU resource types for critical workloads. Implement time-sharing multiplexing of GPU resources, allowing multiple low-intensity workloads to share the same GPU instance.

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

[0069] Develop a workload status monitoring component to monitor resource usage on 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 workloads from one GPU instance to another, more suitable GPU instance. Implement state preservation and recovery during the migration process to ensure that workloads can continue executing after migration. Configure migration policies, such as migration frequency limits and migration windows, to prevent 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 Pod scheduling priorities. Set different priorities for different workload types to ensure that critical workloads receive resources first. Implement a priority preemption mechanism so that when high-priority workloads cannot be scheduled, they can preempt the resources of lower-priority workloads. Develop a dynamic priority adjustment algorithm to dynamically adjust the priority of workloads based on their execution time and importance. Configure priority inheritance rules so that workloads in child namespaces can inherit the priority settings of their parent namespace.

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

[0073] Collect historical resource usage data and build a resource usage model. Use time series analysis and machine learning algorithms to predict future resource demand. Specifically, the system uses time series prediction models such as LSTM (Long Short-Term Memory) and Prophet, combined with feature engineering for GPU resource usage, to build a prediction model. The prediction model considers periodicity (such as weekday / weekend patterns and daytime / nighttime patterns), trends, and seasonality, and incorporates anomaly detection algorithms to identify resource usage anomalies. Based on the prediction results, resource allocation and adjustments are made in advance to avoid resource competition. Prediction-driven scheduling decisions are implemented to schedule workloads to nodes with less future resource pressure. An automatic update mechanism is configured for the prediction model to continuously optimize the prediction model based on actual resource usage. Using online learning, the model is retrained every 24 hours to ensure prediction accuracy.

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

[0075] Monitor resource usage with a custom ResourceQuota Controller. Set resource usage thresholds to trigger automatic scaling when resource utilization exceeds the upper threshold and automatic scaling when resource utilization falls below the lower threshold. Integrate the Horizontal Pod Autoscaler (HPA) to automatically adjust the number of Pod replicas based on CPU, memory, or custom metrics. Integrate the Vertical Pod Autoscaler (VPA) to automatically adjust Pod resource requests and limits. Implement automatic scaling of cluster nodes, automatically adding or removing nodes based on overall resource demand. Configure scaling policies, such as cooldown time and step limit, to avoid resource fluctuations.

[0076] Through the above steps, a hierarchical namespace structure was built, GPU resource pool division was configured, resource inheritance and isolation were achieved, and refined resource scheduling was performed, improving the utilization efficiency and isolation performance of computing resources in the Kubernetes environment.

[0077] Example 2

[0078] like Figure 2 As shown, the embodiment of the present invention provides a multi-level computing resource isolation and fine scheduling system in a 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 the namespace, and realize the mapping of the organizational structure to resource management;

[0080] The GPU resource pool partitioning module 52 is used to use MIG technology to perform fine-grained partitioning of GPU resources in the cluster, create GPU instance groups of different specifications, and set resource tags for each instance group;

[0081] Resource inheritance and isolation module 53, used to enable the child namespace to inherit the resource configuration and permission policy 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 workloads to appropriate nodes that meet their resource requirements based on the namespace hierarchy and GPU instance group labels.

[0083] The hierarchical namespace management module 51 includes the following modules:

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

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

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

[0087] The propagation strategy configuration unit 514 is used to configure the resource propagation strategy, defining 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] GPU device identification unit 521, used to identify GPU devices in the cluster that support MIG technology;

[0090] An instance partitioning unit 522 is configured to partition a physical GPU into multiple logical GPU instances based on workload characteristics and resource requirements, each GPU instance having independent computing resources and memory;

[0091] The node pool management unit 523 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;

[0092] Resource monitoring unit 524, used to deploy GPU resource monitoring components to monitor the usage status and health of each GPU instance in real time;

[0093] The 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] The 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 the child namespace automatically inherits the resource objects of the parent namespace;

[0097] The quota allocation unit 533 is used to implement hierarchical allocation of resource quotas. The resource quota of the parent namespace can be allocated to the child namespaces in proportion.

[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] The permission control unit 535 is used to deploy the RBAC permission control system to implement role-based fine-grained access control;

[0100] The security policy unit 536 is used to configure the PodSecurityPolicy to limit the security context and privileged operations of the Pod.

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

[0102] Scheduler Plugin Development Unit 541, which is used to develop custom scheduler plugins to extend the functionality of the Kubernetes default scheduler.

[0103] Affinity rule implementation unit 542, for implementing affinity rules based on the namespace hierarchy to prioritize workload scheduling to resources at a specified hierarchy;

[0104] The resource matching unit 543 is used to match GPU instance groups with 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] Automatic repair unit 545, used to detect and recover Pod failures caused by node failures;

[0107] Horizontal autoscaling unit 546, used to automatically adjust the number of Pod replicas based on CPU, memory, and GPU utilization;

[0108] Vertical autoscaling unit 547, 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 resource usage history to optimize resource allocation decisions.

[0111] Compared with the existing technology, the multi-level computing resource isolation and fine scheduling method and system in the K8S environment of the present invention solves multiple key problems of computing resource management in the Kubernetes environment by constructing a hierarchical namespace structure, configuring GPU resource pool division, realizing resource inheritance and isolation, and performing fine resource scheduling. The method provided by the present invention realizes multi-level isolation and fine scheduling of computing resources by introducing hierarchical namespace and MIG technology, improves resource utilization efficiency, reduces resource contention risk, and enhances system security, thereby realizing efficient management of computing resources in the Kubernetes environment.

[0112] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features of the present invention.

Claims

1. A multi-level computing resource isolation and fine scheduling method in a K8S environment, characterized in that: include: Step S1: Build a hierarchical namespace structure: Deploy a hierarchical namespace controller (HNC) in the Kubernetes cluster to establish a parent-child hierarchical relationship between namespaces and implement a mapping from organizational structure to resource management. Step S2: Configure GPU resource pool partitioning: Use MIG technology to perform fine-grained partitioning of GPU resources in the cluster, create GPU instance groups of different specifications, and set resource tags for each instance group; Step S3: Implement resource inheritance and isolation: Use HNC to enable the child namespace to inherit the resource configuration and permission policy of the parent namespace, while ensuring resource isolation between different levels; Step S4: Perform refined resource scheduling: Based on the namespace hierarchy and GPU instance group tags, design a custom scheduler to accurately schedule workloads to appropriate nodes that meet their resource requirements. Specifically, this includes: Step S41: Develop a custom scheduler plug-in to extend the Kubernetes default scheduler function; Step S42: Implement affinity rules based on the namespace level to prioritize scheduling workloads to resources at the specified level; Step S43: Matching a GPU instance group with corresponding specifications based on the GPU resource requirements of the workload; Step S44: supporting dynamic migration of workloads 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 resource usage history to optimize resource allocation decisions; Step S47: Monitor resource usage through the ResourceQuota Controller and trigger the automatic expansion and contraction mechanism.

2. The multi-level computing resource isolation and fine scheduling method in the K8S environment according to claim 1 is characterized in that: Step S1: Building a hierarchical namespace structure: deploying a hierarchical namespace controller HNC in the Kubernetes cluster, establishing a parent-child hierarchical relationship of namespaces, and implementing a mapping from organizational structure to resource management, specifically includes: Step S11: Create a custom resource definition (CRD) to support the hierarchical relationship of the namespace; 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 a child namespace under the root namespace, establish a parent-child relationship, and form a multi-level namespace structure; Step S14: Configure the resource propagation strategy to define the resource types propagated from the parent namespace to the child namespace.

3. The multi-level computing resource isolation and fine scheduling method in the K8S environment according to claim 1 is characterized in that: Step S2: Configuring GPU resource pool partitioning: Using MIG technology to perform fine-grained partitioning of GPU resources in the cluster, creating GPU instance groups of different specifications, and setting resource tags for each instance group, specifically including: Step S21: Identify GPU devices in the cluster that support MIG technology; Step S22: Divide the physical GPU into multiple logical GPU instances based on workload characteristics and resource requirements, each GPU instance having independent computing resources and memory; Step S23: 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; 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 multi-level computing resource isolation and fine scheduling method in the K8S environment according to claim 1 is characterized in that: Step S3: Implementing resource inheritance and isolation: Using HNC, the child namespace inherits the resource configuration and permission policy 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 resource propagation rules so that the child namespace automatically inherits the resource objects of the parent namespace; Step S33: Implement hierarchical allocation of resource quotas. The resource quotas of the parent namespace can be allocated to the child namespaces in proportion. Step S34: Setting resource isolation boundaries to ensure resource access control and network isolation between different namespace levels; Step S35: deploying the RBAC authority control system to implement role-based fine-grained access control; Step S36: Configure PodSecurityPolicy to limit the security context and privileged operations of the Pod.

5. A multi-level computing resource isolation and fine scheduling system in a K8S environment, characterized by: Includes the following modules: The hierarchical namespace management module 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 of organizational structure to resource management; The GPU resource pool partitioning module is used to use MIG technology to perform fine-grained partitioning of GPU resources in the cluster, create GPU instance groups of different specifications, and set resource tags for each instance group; The resource inheritance and isolation module is used to enable child namespaces to inherit the resource configuration and permission policies of the parent namespace through HNC, while ensuring resource isolation between different levels; The refined resource scheduling module is used to precisely schedule workloads to appropriate nodes that meet their resource requirements based on namespace levels and GPU instance group labels. Specifically, it includes: Step S41: Develop a custom scheduler plug-in to extend the Kubernetes default scheduler function; Step S42: Implement affinity rules based on the namespace level to prioritize scheduling workloads to resources at the specified level; Step S43: Matching a GPU instance group with corresponding specifications based on the GPU resource requirements of the workload; Step S44: supporting dynamic migration of workloads 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 resource usage history to optimize resource allocation decisions; Step S47: Monitor resource usage through the ResourceQuota Controller and trigger the automatic expansion and contraction mechanism.

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

7. The multi-level computing resource isolation and fine scheduling system in the K8S environment according to claim 5 is characterized in that: The GPU resource pool partitioning module includes the following modules: GPU device identification unit, used to identify GPU devices in the cluster that support MIG technology; The instance partitioning unit is used to divide the physical GPU into multiple logical GPU instances based on workload characteristics and resource requirements. Each GPU instance has independent computing resources and memory. The node pool management unit 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; The resource monitoring unit is used to deploy GPU resource monitoring components and monitor the usage status and health of each GPU instance in real time; The secure communication unit is used to implement secure communication between nodes based on TLS, ensuring the confidentiality and integrity of GPU resource information transmission.

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

9. The multi-level computing resource isolation and fine scheduling system in the K8S environment according to claim 5 is characterized in that: The refined resource scheduling module includes the following modules: Scheduler plugin development unit, used to develop custom scheduler plugins to extend the functionality of the Kubernetes default scheduler; Affinity rule implementation unit, used to implement affinity rules based on the namespace level, and prioritize workload scheduling to resources at the specified level; The resource matching unit is used to match GPU instance groups with corresponding specifications based on the GPU resource requirements of the workload; A load migration unit, which supports dynamic migration of workloads between different GPU instance groups to maximize resource utilization; Automatic repair unit, used to detect and recover Pod failures caused by node failures; Horizontal autoscaling unit, which automatically adjusts the number of Pod replicas based on CPU, memory, and GPU utilization; Vertical autoscaling unit, used to dynamically adjust Pod resource requests and limits; Priority queue management unit, used to manage Pods to be scheduled using PriorityQueue; The prediction algorithm unit is used to implement a prediction algorithm based on resource usage history and optimize resource allocation decisions.

Images