A container cluster virtual simulation method and system based on kernel semantic mapping and load prediction

Abstract

The application discloses a container cluster virtual simulation method and system based on kernel semantic mapping and load prediction. The container cluster virtual simulation method first creates a tenant virtual control plane and creates a node carrier in a host container cluster to establish a virtual node resource domain. Then, the node carrier is mapped to a virtual node in the tenant virtual control plane, and the node state and resource capacity are synchronized. The tenant workloads scheduled to the virtual node are translated into host execution copies belonging to the virtual node resource domain, and their running states are written back to the tenant virtual control plane. Finally, the virtual node operation and maintenance operations are responded based on a node operation translation strategy. The application can reduce virtual cluster training resource overhead, improve node simulation authenticity, resource view consistency and training delivery efficiency, thereby improving node-level operation and maintenance training operability and large-scale training environment delivery efficiency while maintaining container-level resource overhead.

Description

Technical Field

[0001] This invention belongs to the field of teaching simulation and cloud computing container orchestration technology, specifically involving a container cluster virtual simulation method and system for constructing a container cluster simulation environment, resource scheduling, kernel semantic mapping and load prediction for teaching and training. Background Technology

[0002] Kubernetes (K8s) cluster operation and maintenance training requires trainees to interact with real or near-real node objects. For example, in training tasks such as node fault diagnosis, kubelet configuration repair, DNS fault location, certificate renewal, node blocking, and workload eviction, trainees need to work with a virtual node that can be viewed, scheduled, fault-tolerant, and recoverable.

[0003] In course teaching, certification exams, corporate training, and comprehensive experimental platforms, the aforementioned cluster training is usually not isolated but triggered by course tasks, exam questions, or experimental procedures. Upper-layer platforms can provide functions such as WebIDE, Notebook, question bank management, AI model training, data analysis, or microservice deployment. However, the underlying common requirement for these functions is to quickly deliver isolated container cluster environments with node semantics to different learners.

[0004] Large-scale simulation training also has delivery constraints that differ from ordinary cloud resource scheduling: the training environment needs to be available before the start of class or exam; after students enter the environment, the system should prioritize keeping the virtual node name, connection entry, and workload ownership unchanged; when the number of concurrent users increases, the system needs to dynamically adjust the quotas of ordinary nodes while ensuring that the resources of key nodes, exam nodes, or demonstration nodes are not compressed; when the host resources are insufficient to meet the needs of all students at once, the system also needs to form an orderly expansion waiting queue, combined with the centralized recycling of completed environments, so that all students can eventually obtain a virtual node environment that can complete the experiment.

[0005] Existing virtual machine-based training solutions can provide independent nodes, but each node requires a complete operating system and an independent kernel, resulting in high resource consumption and long startup time, making them unsuitable for concurrent use by a large number of students.

[0006] Existing training solutions based on shared Kubernetes cluster namespaces are relatively lightweight, but trainees only receive the resource namespace and lack independent Node semantics, making it impossible to practice real-world node-level operations such as kubectl cordon, kubectl drain, and kubelet configuration repair. Furthermore, interfaces such as / proc and / sys / fs / cgroup inside containers may expose host resource views, leading to inconsistencies between observed results and tenant quotas.

[0007] Existing solutions for running the Kubernetes control plane in containers can provide a standalone API server, but without the mapping between host Pods (node ​​carriers) and tenant Nodes, the ownership of host execution replicas, virtual node resource domains, and scheduling semantic translation, it is still difficult to form a stable node training environment.

[0008] Existing virtual kubelet or cloud virtual node solutions are typically used to elastically schedule tenant Pods to external container runtime environments, focusing on expanding runtime resources. Existing virtual cluster synchronization solutions are typically used to provide an independent API server and synchronize objects in the virtual cluster to the host cluster. These solutions do not address node-level training scenarios by treating the host Pod as a virtual Node semantic carrier that students can access, operate, and fault-inject, nor do they provide a virtual node resource domain for aggregating the node carrier Pod and the host execution replica set, nor a node operation and maintenance translation mechanism. Summary of the Invention

[0009] The main technical problem to be solved by this invention is: how to use Pods in the host container cluster to construct node objects in the tenant virtual cluster, and make the node objects have consistent node states, scheduling semantics, workload lifecycles and node operation and maintenance feedback. A container cluster virtual simulation method and system based on kernel semantic mapping and load prediction is proposed.

[0010] In a first aspect, the present invention provides a container cluster virtual simulation method based on kernel semantic mapping and load prediction, the method comprising:

[0011] Receive a virtual cluster construction request, generate a virtual cluster description object, and create a tenant virtual control plane based on the virtual cluster description object;

[0012] In the host container cluster, a node carrier corresponding to the tenant virtual control plane is created, and a virtual node resource domain corresponding to the node carrier is established; wherein, the node carrier is used as the node-side operation entry point of the virtual node in the tenant virtual control plane; the virtual node resource domain is used to maintain the association between the node carrier, the host execution replica set, the resource quota policy, and the mapping policy;

[0013] The node carrier is mapped to a virtual node in the tenant's virtual control plane through a virtual node proxy, and the node status and resource capacity of the virtual node are synchronized to the tenant's virtual control plane.

[0014] The tenant workload scheduled to the virtual node is translated into a host execution copy belonging to the virtual node resource domain, and the running status of the host execution copy is written back to the tenant virtual control plane;

[0015] Based on the virtual node resource domain, the resource view, workload affiliation, and node operation feedback of virtual nodes are maintained in a consistent manner.

[0016] Preferably, the virtual node resource domain includes at least one of the following: tenant identifier, virtual cluster identifier, virtual node identifier, node carrier reference, host execution replica reference set, resource quota policy, node conditional projection rule, node operation translation policy, and cleanup status; the virtual node resource domain is used to establish a correspondence between the node carrier, the host execution replica set, the tenant workload, and the virtual nodes in the tenant virtual control plane.

[0017] Preferably, the mapping strategy includes a kernel semantic mapping strategy; the method for maintaining the consistency of the resource view of the virtual node is as follows: according to the kernel semantic mapping strategy, at least one of the tenant resource control group subtree, host execution replica aggregated resource information, tenant process resource information and tenant node working directory corresponding to the virtual node resource domain is mapped to a standard path inside the node carrier, so that the node carrier obtains a resource view corresponding to the virtual node resource domain.

[0018] As a preferred method, the method for maintaining the consistency of the resource view of virtual nodes also includes: identifying write operations on sensitive system paths within the node carrier, and after verifying that the write operations meet the tenant quota policy and training task policy, forwarding the write operations to the host controlled path, or updating the resource policy of the virtual node resource domain according to the write operations.

[0019] Preferably, the resource quota strategy is determined based on the load forecasting results; the load forecasting results are obtained by weighted fusion of real-time load sampling values ​​and historical load fingerprint forecasting values, and are subjected to limit processing according to the minimum operable quota, resource guarantee constraints and quota upper limit to obtain a bounded target resource quota; the bounded target resource quota is used to update the resource quota strategy of the virtual node resource domain, the resource control group quota and the virtual node capacity information in the tenant virtual control plane.

[0020] Preferably, the weights of the real-time load sample value and the historical load fingerprint prediction value are adjusted according to the real-time load volatility; when the quota change does not reach the minimum adjustment range, or the time since the last quota adjustment does not exceed the minimum adjustment interval, the resource quota strategy of the previous period remains unchanged.

[0021] As a preferred method, the method for mapping a node carrier to a virtual node is as follows: create or update a virtual node in the tenant virtual control plane, map at least one of the node carrier's running status, virtual node agent status, probe status, resource pressure status, and host execution replica set status to the node conditions of the virtual node, and map the resource limit of the virtual node's resource domain to the virtual node's capacity information and allocable resource information.

[0022] As a preferred method, the method for translating tenant workloads into host execution replicas is as follows: obtain the tenant workload specification that is bound to the virtual node, convert at least one of the container image, startup command, environment variable, configuration object, key object, storage volume, network identifier, resource request, resource limit, probe configuration and security context in the tenant workload specification into a host execution replica specification, and add tenant identifier, virtual cluster identifier, virtual node identifier, virtual node resource domain identifier and tenant workload identifier to the host execution replica.

[0023] As a preferred method, the consistency maintenance method for node operation feedback of virtual nodes is as follows: when a virtual node is blocked, stop mapping new host execution copies to the corresponding virtual node resource domain; when a virtual node is evicted, delete, migrate, or recreate the host execution copies belonging to the corresponding virtual node resource domain, and write the processing results back to the tenant virtual control plane; when a virtual node is tainted or its tag is updated, update the scheduling mapping policy in the virtual node resource domain; when a virtual node execution node recovers or its configuration is repaired, update the node carrier state, the virtual node resource domain policy, and the virtual node state in the tenant virtual control plane.

[0024] Secondly, the present invention provides a container cluster virtual simulation system based on kernel semantic mapping and load prediction, which is used to execute the above-mentioned container cluster virtual simulation method; the container cluster virtual simulation system includes a host container cluster and a tenant virtual control plane;

[0025] The host container cluster includes a build request processing module, a node carrier management module, a virtual node resource domain management module, a virtual node proxy module, a workload translation module, a kernel semantic mapping module, and a load prediction quota module.

[0026] The build request processing module is used to receive virtual cluster build requests, generate virtual cluster description objects, and create tenant virtual control planes based on virtual cluster description objects.

[0027] The node carrier management module is used to create node carriers corresponding to the tenant's virtual control plane in the host container cluster;

[0028] The virtual node resource domain management module is used to establish virtual node resource domains corresponding to node carriers, and maintain the association between node carriers, host execution replica sets, resource quota policies, and mapping policies.

[0029] The virtual node proxy module is used to map the node carrier to a virtual node in the tenant's virtual control plane, and to synchronize the node status and resource capacity of the virtual node to the tenant's virtual control plane.

[0030] The workload translation module is used to translate the tenant workload scheduled to the virtual node into a host execution copy belonging to the virtual node resource domain, and write back the running status of the host execution copy to the tenant virtual control plane;

[0031] The kernel semantic mapping module is used to maintain the consistency of the resource view of virtual nodes based on the resource domain of virtual nodes;

[0032] The load forecasting quota module is used to update the resource quota strategy of the virtual node resource domain based on the load forecasting results.

[0033] Thirdly, the present invention provides a service device including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described container cluster virtual simulation method.

[0034] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described container cluster virtual simulation method.

[0035] The beneficial effects of this invention are:

[0036] 1. This invention maps the host side to virtual nodes in the tenant's virtual control plane through the collaboration of node carriers, virtual node proxies, and virtual node resource domains. This enables container-level runtime units to possess node status, node capacity, and node operation and maintenance semantics, thereby improving the realism of virtual cluster node simulation. At the same time, this invention maintains the affiliation relationship between node carriers and host execution replica sets through virtual node resource domains. This allows tenant workloads to appear as running on corresponding virtual nodes on the tenant side without having to run entirely within the node carriers, thus improving the flexibility of workload carrying methods and system scalability.

[0037] 2. This invention, through a node operation translation strategy, converts tenant-side operations on virtual nodes, such as blocking, eviction, taint setting, label updating, and recovery, into host-side resource domain policies or host-executed replica mapping updates, thereby improving the operability and feedback consistency of node-level operation and maintenance training. Simultaneously, this invention calculates bounded target resource quotas using real-time load, historical load fingerprints, dynamic confidence coefficients, buffer size, and upper and lower bound constraints, and synchronizes these quotas to resource control groups, virtual node resource domains, or tenant-side capacity mapping information, thereby improving the stability of resource adjustment and peak load response capabilities.

[0038] 3. This invention uses fault scenario objects, audit logs, node-side operation trajectories, event object streams, and probe detection results to perform semantic node matching on trainees' troubleshooting behavior. This enables the system to verify the fault location, root cause analysis, repair execution, and result verification process, improving the completeness of technical verification. At the same time, this invention uses a residual cleanup and centralized recycling mechanism to centrally process node carriers, host execution copies, mount points, namespaces, resource control group subtrees, temporary directories, and residual file handles. This reduces the risk of resource leakage after environment destruction and improves the reuse efficiency of subsequent training environments. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the container cluster virtual simulation system architecture in this invention.

[0040] Figure 2 This is an overall flowchart of the container cluster virtual simulation method in this invention.

[0041] Figure 3 This is a flowchart of the sensitive kernel interface read / write mapping and controlled forwarding process in this invention.

[0042] Figure 4 This is a flowchart illustrating the node carrier destruction, residue cleanup, and rapid recovery process in this invention.

[0043] Figure 5 This is a flowchart of the training capacity arrangement and queue expansion process in this invention. Detailed Implementation

[0044] The present invention will be further described below with reference to the accompanying drawings.

[0045] Example 1

[0046] like Figure 1As shown, a container cluster virtual simulation system based on kernel semantic mapping and load prediction includes a host container cluster and a tenant virtual control plane. The host container cluster provides real physical resources. The tenant virtual control plane provides an independent API Server, Scheduler, Controller Manager, and state store for each student or each training task.

[0047] The host container cluster comprises a host management plane, node carriers, virtual node resource domains, a set of host execution replicas, and a kernel semantic mapping proxy module. The host management plane provides host compute, network, storage, and constrained semantic mapping channels. Node carriers serve as the semantic carriers of tenant virtual nodes and the entry point for node-side operations. The virtual node resource domain aggregates the node carriers and the set of host execution replicas belonging to that virtual node, forming a unified resource, state, operation translation, and lifecycle boundary for the tenant-side virtual nodes. The kernel semantic mapping proxy module performs resource view mapping and load prediction quota updates, ensuring that resource viewing results are consistent with tenant quotas.

[0048] The virtual node resource domain includes tenant identifier, virtual cluster identifier, virtual node identifier, node carrier reference, host execution replica reference set, resource quota policy, node condition projection rules, node operation translation policy, and cleanup status. Node condition projection rules are used to translate the node carrier Pod, host execution replica set, and fault status into Node Condition in the tenant control plane; the node operation translation policy is used to translate node operation and maintenance operations such as cordon, drain, taint, and recovery into host-side execution actions; and the cleanup status records the recycling progress of mount points, resource control group subtrees, temporary directories, and host execution replicas.

[0049] Example 2

[0050] A virtual simulation method for container clusters based on kernel semantic mapping and load prediction includes the following steps:

[0051] Step 1: Task Receiving

[0052] Upon receiving a virtual cluster construction request, a virtual cluster description object is generated and submitted to the host API Server. The virtual cluster construction request includes tenant identifier, training type, number of nodes, and node specifications. For course batches that include a start time or number of registered participants, a training batch description object is generated, including batch window, course time, exam time, number of registered participants, number of virtual nodes, node specifications, whitelist node identifiers, resource guarantee level, historical load fingerprint, and estimated recovery time. Based on the training batch description object, the maximum resource requirement for that training batch is predicted.

[0053] After receiving a virtual cluster construction request, the system ingress gateway does not directly create node carriers. Instead, it generates a VirtualCluster custom resource object and submits it to the host API Server. The VirtualCluster custom resource object describes the construction mode, resource specifications, network identifier, resource domain boundary, number of virtual nodes, and optional fault scenario strategies of the virtual tenant cluster to be created.

[0054] Step 2: Pattern Determination

[0055] Parse the virtual cluster build request to determine the build mode of the target simulation unit; the build modes include image backfill mode and component self-bootstrapping mode.

[0056] In image backfilling mode, read-only storage tiers, pre-warmed images, offline tiered snapshots, or template file systems containing the container cluster's binary component set are mapped to the root file system of the virtual tenant cluster through cloning, mounting, or backfilling. This mode is suitable for scenarios requiring rapid delivery of virtual cluster environments, such as courses, exams, or batch drills, and can shorten environment initialization waiting time.

[0057] In the component self-bootstrapping mode, the controller or intelligent operation and maintenance control unit injects certificate generation logic, configuration rendering parameters, and component startup script streams into the target simulation unit, enabling the virtual API Server, virtual Scheduler, virtual Controller Manager, virtual Etcd, virtual kubelet, node semantic proxy, or other equivalent components to complete self-initialization within the target simulation unit. This mode is suitable for in-depth training scenarios that require training on component installation, certificate generation, parameter configuration, and startup processes.

[0058] After determining the build mode, the controller prepares the corresponding storage, network, and runtime resources. For image backfill mode, the controller calls the storage interface to clone or mount a preheated image, offline layered snapshot, or template file system. For component self-booting mode, the controller prepares the basic runtime environment and injects the certificate generation logic, configuration rendering parameters, and component startup script stream into the target simulation unit, causing the target simulation unit to enter a state awaiting self-initialization.

[0059] The pattern determination step enables switching between rapid delivery and in-depth installation training, without limiting virtual cluster creation to a single initialization method.

[0060] Step 3: Kernel Mapping Strategy Preparation

[0061] like Figure 3As shown, since the node carrier is essentially still a container within the host cluster, and the tenant's workload may run as a host execution replica, without processing the kernel view, the student might see the host's entire CPU, memory, cgroups, and file system paths, or only see the node carrier's own resources without seeing the owner execution replica. This invention solves this problem through "read view mapping" and "controlled forwarding of write operations" in the virtual node resource domain. The kernel semantic mapping agent maintains the path mapping policy. The path mapping policy includes the tenant identifier, virtual node resource domain identifier, standard paths within the container, host-controlled paths, access type, verification rules, and auditing actions. For example, read paths include / proc / cpuinfo, / proc / meminfo, / sys / fs / cgroup, and / var / lib / kubelet; write paths include cgroups quota files, authorized sysctl parameters, and the virtual kubelet working directory. Each access determines the set of visible resources or the writable host-controlled path based on the virtual node resource domain identifier.

[0062] For read operations, the tenant resource control group subtree corresponding to the virtual node resource domain and the host execution replica aggregate usage are mapped to the standard cgroups path within the node carrier, and tenantized views are generated for information such as CPU, memory, and storage. Therefore, when a resource viewing command is executed within the node carrier, the resources allocated and used by the virtual node resource domain are displayed, rather than the host system's overall resources or the node carrier's local resources.

[0063] For write operations, sensitive paths are forwarded in a controlled manner. When a process inside a Pod attempting to write to cgroups quotas, sysctl parameters, or the kubelet working directory, the kernel semantic mapping agent first identifies the source and destination paths of the write operation, and then verifies whether it falls within the authorized scope of the virtual node's resource domain. If the verification passes, the agent forwards the write operation to the host's controlled path or updates the resource domain policy; if the verification fails, the system rejects the write and logs an audit event.

[0064] In one implementation, the system employs a kernel event collection mechanism to identify sensitive write operations. This kernel event collection mechanism can be implemented using an eBPF program, which submits write events to a user-space agent, which then performs policy verification and writes to the host path. In environments where kernel event collection is not used, equivalent mapping can be achieved using system call notifications, file system agents, or mount view agents.

[0065] Step 4: Node Startup

[0066] Node carriers are created according to the construction pattern, and virtual node agents, node semantic agents, virtual kubelets, and node-side operation acquisition agents are loaded into the node carriers; virtual nodes are created or updated by virtual node agents in the tenant virtual control plane.

[0067] After the node carrier starts, the virtual node agent reads the node identifier, tenant identifier, virtual cluster identifier, resource quota, virtual node resource domain identifier, and status mapping rules, and creates or updates the corresponding virtual node to the tenant virtual API Server. This virtual node includes the node name, tag, taint, capacity, allocable resources, Ready status, node conditions, and heartbeat time.

[0068] The virtual node agent periodically collects the Pod Phase, probe status, virtual kubelet status, node semantic agent status, resource pressure status, and host execution replica set status of the node carrier, and converts these statuses into tenant-side Node Conditions according to node condition projection rules. For example, when the node carrier is in the Running state, the virtual node agent's heartbeat is normal, and the critical probes pass, the virtual node agent will update the corresponding virtual node to Ready; when the node carrier exits abnormally, the virtual node agent's heartbeat is interrupted, or the fault scenario strategy requires simulating node abnormality, the virtual node agent will update the corresponding virtual node to NotReady or attach the corresponding fault conditions.

[0069] When a tenant virtual scheduler schedules a tenant workload to a virtual node, the virtual node agent listens to the tenant workloads already bound to that virtual node and converts the tenant workload specifications into host execution replica specifications. Specification conversion includes: converting container images, startup commands, environment variables, ConfigMaps, Secrets, storage volumes, network identifiers, resource requests, resource limits, probe configurations, and security contexts in the tenant workload into corresponding fields in the host execution replica object; adding tenant identifiers, virtual cluster identifiers, virtual node identifiers, virtual node resource domain identifiers, and tenant workload identifiers to the host execution replica; and establishing associations between the host execution replica object and the node carrier, virtual node resource domain, tenant virtual control plane, and tenant workload.

[0070] After the host execution replica is created, the virtual node agent continuously monitors the host execution replica's Phase, ContainerStatus, RestartCount, event object, failure reason, exit code, and probe results, and synchronizes these states to the tenant workload, event object, and corresponding virtual node status. Therefore, what actually runs on the host side is the host execution replica, while on the tenant side, it still appears as if the tenant's workload is running on the scheduled virtual node.

[0071] For tenant-side node operation and maintenance tasks such as cordon, drain, taint, label update, node recovery, or configuration repair for virtual nodes, the virtual node agent performs translation based on the node operation translation policy in the virtual node resource domain. When a virtual node is blocked, the system stops mapping new host execution replicas to that virtual node resource domain; when a virtual node is evicted, the system deletes it and triggers a scheduling mechanism to recreate it, or migrates the host execution replicas belonging to that virtual node resource domain according to a preset migration policy, and writes the results back to the tenant control plane; when a virtual node is tainted or its label is updated, the system updates the scheduling mapping policy in the virtual node resource domain; when a virtual node performs a recovery operation, the system updates the node carrier state, the virtual node resource domain policy, and the tenant-side Node Condition.

[0072] Once a virtual node enters the Ready state or another schedulable state, the system continues to execute the control plane component deployment or tenant workload translation process. Through the node startup step, the system stably maps the host-side node carrier Pod to the tenant-side virtual node, and maintains the correspondence between node status, resource capacity, scheduling affiliation, and node operation and maintenance through the virtual node resource domain.

[0073] Step 5: Environment Deployment

[0074] Deploy a virtual API Server, virtual Controller Manager, virtual Scheduler, virtual Etcd, or equivalent control components in the target simulation unit or virtual control plane runtime environment.

[0075] For certificate initialization, an independent Root CA is generated for each tenant, and apiserver.crt, etcd-peer.crt, kubelet client certificates, or other control plane communication certificates are issued. These certificates can be encapsulated as Kubernetes Secrets for subsequent node carriers to mount upon startup, thereby achieving credential isolation and encrypted communication isolation between different tenants.

[0076] For control plane deployment, StatefulSet, Deployment, node carrier, or other orchestration manifest files are generated. For v-apiserver Pods or other virtual control plane components, a restricted semantic mapping proxy plugin and a Syncer Agent can be injected. The restricted semantic mapping proxy plugin handles kernel resource view reads within the authorized scope, sensitive system path write verification, and resource domain policy update requests. The Syncer Agent is used to synchronize the host execution state, tenant object state, or host execution replica state.

[0077] If a component self-booting mode is used, the startup command for the virtual control plane component or node component can be overridden to `kubeadm init –config / etc / kubeadm.yaml` or other component initialization commands, thereby executing the initialization logic within the virtual environment. The log stream generated during the initialization process can be used as observation data for the training process, allowing students to view the component installation, certificate generation, configuration rendering, and component startup processes.

[0078] Regarding tenant workload deployment, objects such as node carriers, Deployments, DaemonSets, StatefulSets, Jobs, Services, ConfigMaps, Secrets, and PVCs submitted by students or upper-layer systems are received by the tenant virtual control plane. After the tenant virtual scheduler schedules the tenant workload to a virtual node, the virtual node agent translates it into a host execution replica and maintains the affiliation between the host execution replica and the target virtual node through the virtual node resource domain.

[0079] Regarding the deployment of the node-side operation entry point, the node carrier provides a terminal, a WebIDE connection entry point, or a controlled shell environment. After entering this entry point, trainees can perform node-level operations such as log viewing, configuration file inspection, virtual kubelet status inspection, process status viewing, file repair, and probe verification. The node-side operation collects and records shell commands, file changes, process status, and virtual kubelet / node semantic agent status, and uses this information as input for subsequent technical verification.

[0080] Through the environment deployment steps, the system completes the deployment of the virtual tenant cluster control plane, virtual node semantic plane, host execution plane, and node-side operation entry point, enabling the tenant side to obtain an independent control plane and node-level operation experience.

[0081] Step Six: Injecting the Intelligent Operation and Maintenance Control Unit

[0082] Deploy an autonomous intelligent operation and maintenance operator within each virtual tenant cluster. The intelligent operation and maintenance operator collects the operational load characteristics of the tenant cluster in real time and combines them with a pre-stored historical load fingerprint operational resource arbitration algorithm (load prediction algorithm) to calculate the dynamic resource gain quota for the target scheduling period. The specific process of the resource arbitration algorithm is as follows:

[0083] Based on tenant real-time load and historical usage profiles, the optimal resource quota Q(t) for the next scheduling cycle is predicted, achieving precise resource allocation and dynamic adjustment. The expression for the optimal resource quota Q(t) is:

[0084]

[0085] in, Dynamic resource allocation for the target period; For dynamic confidence coefficients, when When the value approaches 1, the system trusts real-time data more, responds more sensitively, but fluctuates more. When the value is close to 0, the system relies more on historical predictions, resulting in a smoother but potentially lagging performance. This is the current real-time load sample value; These are historical fingerprint prediction values.

[0086] Historical fingerprints The weighted moving average, calculated based on data from the same period over the past 7 days, is expressed as follows:

[0087]

[0088] Among them, among them, These are the weighting coefficients. (Recent data has higher weight) .

[0089] In this embodiment, the weighting coefficient .

[0090] The dynamic confidence coefficient α is used to adjust the weights of the real-time load sample value R(t) and the historical load fingerprint prediction value P(t) in quota calculation. It is based on the real-time load volatility. The adjustment methods are shown in Table 1.

[0091] Table 1 Dynamic Confidence Coefficients State Machine Adjustment Strategy Table

[0092]

[0093] The intelligent operation and maintenance control unit responds to training task instructions by executing fault injection simulations and performs semantic consistency determination of troubleshooting behaviors based on the audit trajectory of the virtual tenant cluster, thereby performing technical verification and outputting the technical verification results. The semantic consistency determination is implemented as follows: the intelligent operation and maintenance control unit listens to the event object stream of the virtual API Server, parses the instruction sequence corresponding to the trainee's operation behavior; matches the parsed instruction sequence with a preset standard troubleshooting semantic model, and updates the task's technical status based on probe detection results. The fault injection simulation supports full-stack fault simulation from the application layer to the kernel layer. The entire verification process is a rigorous logical closed loop, and its specific process is as follows:

[0094] (1) The Fault Injection Operator reads the pre-set FaultScenario CRD and triggers a fault action (such as kubectl scale deployment coredns --replicas=0). At this time, the system automatically locks the task status to "In Progress" and starts a timer.

[0095] (2) Audit Logging: During the fault period, the Operator continuously listens to the Audit Log stream of the virtual API Server. All student operations (kubectl get, kubectl logs, kubectledit) are recorded and timestamped.

[0096] (3) Semantic Verification: When a student submits a repair command (such as kubectl apply), the Operator initiates the core judgment logic: 1. Static matching: Checks whether the command parameters conform to the standard answer regular expression (such as configmap / coredns). 2. Dynamic probe: Starts a temporary BusyBox Pod and executes nslookup within the tenant network. Only when both static and dynamic checks pass is the fault determined to be repaired.

[0097] (4) Status Reset and Scoring After the repair is confirmed, the system undoes all injected faults (restores the number of copies), unlocks subsequent tasks, and outputs a scoring report based on the time taken and the number of operation steps.

[0098] Example of a failure scenario:

[0099] 1. Network layer failure - Service cannot be resolved

[0100] Injection methods: The intelligent operation and maintenance control unit rewrites the Service selector, EndpointSlice, NetworkPolicy, DNS configuration, or equivalent forwarding rules of kube-dns or CoreDNS within the authorized scope, causing DNS resolution requests to be forwarded to unreachable endpoints or blocked by policies; in implementations that require modification of Service clusterIP, the method of deleting and rebuilding the Service is used instead of requiring direct modification of immutable fields.

[0101] Phenomenon: nslookup timed out within the node carrier.

[0102] Recovery conditions: The relevant Service address is restored to the preset value, the parsing probe passes, and the status of the associated node carrier returns to normal.

[0103] Taking DNS failure as an example: The system first points the CoreDNS Service selector or EndpointSlice to an unreachable endpoint, causing the probe Pod within the tenant to time out when executing `nslookup kubernetes.default`. Then, it continuously collects virtual API Server audit logs, event object streams, and probe detection results. If the user sequentially performs operations such as service discovery, EndpointSlice check, CoreDNS log viewing, configuration recovery, and resolution verification, the system converts these operations into semantic nodes for fault location, root cause analysis, repair execution, and result verification. When the target object, operation type, and recovery result all meet preset rules, and the DNS resolution probe recovers successfully, it outputs key technical steps coverage. If the final resolution is recovered but lacks location or result verification nodes, it outputs partial key technical steps coverage; if the probe fails to recover or key repair nodes are missing, it outputs that technical verification failed.

[0104] 2. Storage layer failure - PV mounted as read-only

[0105] Injection method: On the host node, the Operator uses `mount -o remount,ro` to force the tenant's PV mount point to be set to read-only.

[0106] Phenomenon: The node carrier log reports a Read-only file system error, and CrashLoopBackOff is applied.

[0107] Recovery conditions: The relevant storage path is restored to a writable state, the workload exits the CrashLoopBackOff state, and the storage read / write probe passes.

[0108] 3. Certificate layer failure - Etcd two-way authentication failed.

[0109] Injection method: Replace / etc / kubernetes / pki / etcd / peer.crt with an incorrect certificate file.

[0110] Symptom: The API Server fails to start, and the log shows error x509: certificate signed by unknown authority.

[0111] Recovery conditions: The relevant certificate is restored to a valid certificate, the API Server or Etcd component resumes communication, and the component health probe passes.

[0112] A semantic node-based technical verification algorithm: The intelligent operation and maintenance control unit can define the standard repair process as a standard semantic node sequence S={S1,S2,S3,S4}; where S1 is the fault location node; S2 is the root cause analysis node; S3 is the repair execution node; and S4 is the result verification node. The trainee's actual operation sequence is converted into an actual semantic node sequence A. S and A are compared using at least one of rule matching, state machine matching, or longest common subsequence matching, and the technical verification result is output in conjunction with the probe results. If all key semantic nodes are covered and the probe passes, the key technical steps are output as covered; if some key semantic nodes are missing but the fault state is restored, the key technical steps are output as partially covered; if the fault state is not restored or key repair nodes are missing, the technical verification fails.

[0113] In some embodiments, the intelligent operation and maintenance control unit executes low-activity state resource de-allocation logic: periodically collecting the load activity index of each training component in the virtual tenant cluster; marking components with load activity below a preset threshold and lasting longer than the silent window as cold; switching the marked cold components to a suspended state, and reclaiming their occupied physical resource quota to the host global resource pool for reallocation, thereby achieving time-division multiplexing and high-density load bearing of resources. The specific process is as follows:

[0114] For each component C, if the average load over 5 minutes... and == 0 and duration > Then, mark component C as "cold" and perform resource compression: Limit(C) = ,Recycle To the host resource pool; among which, The threshold for determining the cold state; This represents the number of external connections. This refers to the duration of the silent window. Minimum guaranteed quota. Resource recycling. The formula is as follows:

[0115]

[0116] For example, if there are three cold-state components, each occupying 500 mCPU, and after compression each retains 50 mCPU, then resource reclamation is achieved. .

[0117] Step 7: Residual Cleanup and Centralized Recycling Mechanism

[0118] like Figure 4 As shown, when the training ends, the training times out, the virtual cluster is destroyed, a virtual node malfunctions, or a batch switch occurs, the system executes a residual cleanup and centralized recycling mechanism. The specific process is as follows:

[0119] (1) Graceful termination

[0120] Send a termination signal to the relevant node carriers within the virtual cluster and wait for a preset graceful exit window, such as 30 seconds.

[0121] (2) Mounting point processing

[0122] Release or delay the release of the bound mount point associated with the virtual node resource domain, and record any unreleased references.

[0123] (3) Namespace and resource control group cleanup

[0124] Locate the associated process and namespace reference, terminate or migrate the associated process, and clean up the corresponding resource control group subtree.

[0125] (4) Handle handling

[0126] via / proc / <pid> / fd scans for residual file descriptors and performs at least one of the following actions based on the process state: waiting for release, terminating associated processes, migration and cleanup tasks, or logging alarms.

[0127] (5) Storage cleanup

[0128] Based on the training data retention policy, delete, archive, or migrate PVCs and associated storage data.

[0129] Step 8: Delivery Confirmation

[0130] like Figure 5 As shown, when the virtual control plane is accessible, node objects enter a schedulable state, restricted semantic mapping takes effect, the initial probe passes, and the intelligent operation and maintenance control unit begins executing the load-aware control loop, the system confirms that the virtual tenant cluster has entered a deliverable state. The VirtualCluster object, virtual node resource domain policy, and tenant-side capacity mapping status are updated to Ready, Delivered, or other states indicating deliverability. The system then returns the access entry point, tenant kubeconfig, node status summary, and optional technology verification initialization results to the upper-level course system, examination system, or experimental platform. If any condition is not met, the system proceeds according to the failure type, entering a retry, waiting for expansion, exception handling, or recycling process, and records the reason for the failure.

[0131] Through the delivery confirmation step, the system conducts a unified confirmation of the virtual control plane, virtual nodes, resource views, intelligent operation and maintenance control loop, and basic probes before officially opening the training environment to students or examinees, thus avoiding the premature delivery of an environment that has not been fully initialized or whose resource views are inconsistent.< / pid>

Claims

1. A container cluster virtual simulation method based on kernel semantic mapping and load prediction, characterized in that: The method includes: Receive a virtual cluster construction request, generate a virtual cluster description object, and create a tenant virtual control plane based on the virtual cluster description object; In the host container cluster, a node carrier corresponding to the tenant virtual control plane is created, and a virtual node resource domain corresponding to the node carrier is established; wherein, the node carrier is used as the node-side operation entry point of the virtual node in the tenant virtual control plane; the virtual node resource domain is used to maintain the association between the node carrier, the host execution replica set, the resource quota policy, and the mapping policy; The node carrier is mapped to a virtual node in the tenant's virtual control plane through a virtual node proxy, and the node status and resource capacity of the virtual node are synchronized to the tenant's virtual control plane. The tenant workload scheduled to the virtual node is translated into a host execution copy belonging to the virtual node resource domain, and the running status of the host execution copy is written back to the tenant virtual control plane; Based on the virtual node resource domain, the resource view, workload affiliation, and node operation feedback of virtual nodes are maintained in a consistent manner.

2. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The virtual node resource domain includes at least one of the following: tenant identifier, virtual cluster identifier, virtual node identifier, node carrier reference, host execution replica reference set, resource quota policy, node conditional projection rule, node operation translation policy, and cleanup status; the virtual node resource domain is used to establish a correspondence between the node carrier, the host execution replica set, the tenant workload, and the virtual nodes in the tenant virtual control plane.

3. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The mapping strategy includes a kernel semantic mapping strategy; the method for maintaining the consistency of the resource view of the virtual node is as follows: according to the kernel semantic mapping strategy, at least one of the following is mapped to the standard path inside the node carrier: the tenant resource control group subtree corresponding to the virtual node resource domain, the host execution replica aggregated resource information, the tenant process resource information, and the tenant node working directory, so that the node carrier obtains the resource view corresponding to the virtual node resource domain.

4. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 3, characterized in that: The method for maintaining consistency of the resource view of virtual nodes also includes: identifying write operations on sensitive system paths within the node carrier, and after verifying that the write operations meet the tenant quota policy and training task policy, forwarding the write operations to the host controlled path, or updating the resource policy of the virtual node resource domain according to the write operations.

5. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The resource quota strategy is determined based on the load forecasting results. The load forecasting results are obtained by weighted fusion of real-time load sampling values ​​and historical load fingerprint forecasting values, and are subjected to limit processing according to the minimum operable quota, resource guarantee constraints and quota upper limit to obtain the bounded target resource quota. The bounded target resource quota is used to update the resource quota policy of the virtual node resource domain, the resource control group quota, and the virtual node capacity information in the tenant virtual control plane.

6. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 5, characterized in that: The weights of the real-time load sample value and the historical load fingerprint prediction value are adjusted according to the real-time load volatility. When the quota change does not reach the minimum adjustment range, or the time since the last quota adjustment does not exceed the minimum adjustment interval, the resource quota strategy of the previous cycle remains unchanged.

7. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The method for mapping node carriers to virtual nodes is as follows: create or update virtual nodes in the tenant virtual control plane, map at least one of the node carrier's running status, virtual node agent status, probe status, resource pressure status, and host execution replica set status to the node conditions of the virtual node, and map the resource limit of the virtual node resource domain to the capacity information and allocable resource information of the virtual node.

8. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The method for translating tenant workloads into host execution replicas is as follows: obtain the tenant workload specification that is bound to the virtual node, convert at least one of the container image, startup command, environment variable, configuration object, key object, storage volume, network identifier, resource request, resource limit, probe configuration and security context in the tenant workload specification into a host execution replica specification, and add tenant identifier, virtual cluster identifier, virtual node identifier, virtual node resource domain identifier and tenant workload identifier to the host execution replica.

9. The container cluster virtual simulation method based on kernel semantic mapping and load prediction according to claim 1, characterized in that: The method for maintaining consistency in node operation feedback of virtual nodes is as follows: when a virtual node is blocked, stop mapping new host execution replicas to the corresponding virtual node resource domain; When a virtual node is evicted, the host execution copy belonging to the corresponding virtual node resource domain is deleted, migrated, or recreated, and the processing result is written back to the tenant virtual control plane. When a virtual node is tainted or its tag is updated, the scheduling mapping policy in the virtual node's resource domain is updated. When a virtual node performs node recovery or configuration repair, it updates the node carrier state, virtual node resource domain policy, and virtual node state in the tenant virtual control plane.

10. A container cluster virtual simulation system based on kernel semantic mapping and load prediction, characterized in that: A container cluster virtual simulation method based on kernel semantic mapping and load prediction, as described in any one of claims 1 to 9, wherein the container cluster virtual simulation system includes a host container cluster and a tenant virtual control plane; The host container cluster includes a build request processing module, a node carrier management module, a virtual node resource domain management module, a virtual node proxy module, a workload translation module, a kernel semantic mapping module, and a load prediction quota module. The build request processing module is used to receive virtual cluster build requests, generate virtual cluster description objects, and create tenant virtual control planes based on virtual cluster description objects. The node carrier management module is used to create node carriers corresponding to the tenant's virtual control plane in the host container cluster; The virtual node resource domain management module is used to establish virtual node resource domains corresponding to node carriers, and maintain the association between node carriers, host execution replica sets, resource quota policies, and mapping policies. The virtual node proxy module is used to map the node carrier to a virtual node in the tenant's virtual control plane, and to synchronize the node status and resource capacity of the virtual node to the tenant's virtual control plane. The workload translation module is used to translate the tenant workload scheduled to the virtual node into a host execution copy belonging to the virtual node resource domain, and write back the running status of the host execution copy to the tenant virtual control plane; The kernel semantic mapping module is used to maintain the consistency of the resource view of virtual nodes based on the resource domain of virtual nodes; The load forecasting quota module is used to update the resource quota strategy of the virtual node resource domain based on the load forecasting results.

Images