System and method for accessing k8s based on agent-based heterogeneous computing nodes

Abstract

The application discloses a system and method for accessing K8s based on an agent, relates to the field of cloud native technology, and realizes the full-process automation of agent initialization registration, node queue allocation, hardware information collection and resource pre-inspection, node environment preparation, K8s cluster access, node label updating and post-validation by deploying an access agent Agent, combining a control plane module, a node controller module, a node access workflow module and a network access module to construct an integrated access architecture; the network environment difference is shielded by using Tailscale to construct an Overlay network, the container runtime and acceleration components are adaptively selected based on the hardware collection results, and the node access full-life cycle closed-loop management is realized through a state machine and a task queue. The application supports the unified automatic access of heterogeneous computing power such as multiple types of GPU, physical machine / virtual machine / edge PC / cloud node and the like, and improves the heterogeneous computing power resource scheduling efficiency.

Description

Technical Field

[0001] This invention relates to the field of cloud-native technology, and more specifically, to a system and method for connecting heterogeneous computing nodes to Kubernetes based on agents. Background Technology

[0002] With the rapid development of cloud computing, artificial intelligence, and big data technologies, the application scenarios of heterogeneous computing resources such as CPU, GPU, and NPU are becoming increasingly diverse. Kubernetes, as the mainstream container orchestration platform in the cloud-native field, is widely used to uniformly schedule various heterogeneous computing resources and has become the core infrastructure for enterprise digital transformation and computing resource management.

[0003] In existing technologies, the access methods for Kubernetes heterogeneous computing power nodes mostly rely on manual operations. System administrators need to manually install container runtimes, configure kubelet, edit kubeadm configurations on each machine to be connected, and manually execute the kubeadmjoin command to achieve node access. For different types of heterogeneous nodes, such as data center physical machines, virtual machines, edge PCs, and accelerated nodes equipped with different GPUs such as NVIDIA / Huawei Ascend, there are significant differences in the operating system distributions (such as different Linux distributions based on dnf and apt-get), CPU architectures (x86_64, arm64), GPU vendors, and network environments. Administrators need to write access scripts or operation manuals for different types of nodes, which is cumbersome and requires a high level of expertise.

[0004] However, existing solutions for accessing heterogeneous Kubernetes computing nodes have many technical shortcomings, specifically in the following aspects:

[0005] 1. Low level of automation: The node access process involves multiple steps, such as preparing software sources, installing containerd, installing GPU runtime, configuring sysctl, deploying HAProxy, configuring high-availability APIServer address, and executing kubeadmjoin. The entire process is highly dependent on manual operation. If the operation sequence or parameter configuration is incorrect, it is very easy to cause node access failure, resulting in low access efficiency and high operation and maintenance costs.

[0006] 2. Insufficient support for heterogeneous environments: Existing access scripts are usually written for a single operating system distribution or a single GPU vendor, and have weak adaptability to heterogeneous environments with multiple hardware combinations such as x86 / arm architecture, physical machines / virtual machines, and NVIDIA / Huawei Ascend. At the same time, existing solutions lack a unified abstraction for the network connectivity methods of different types of nodes such as PC nodes, data center nodes, and cloud nodes, making it difficult to achieve stable node access in complex network environments such as cross-public networks, cross-data center, and NAT forwarding.

[0007] 3. Insufficient observability and closed-loop capability in runtime: There is a lack of a unified resource pre-inspection mechanism before node access, and the compliance of core resources such as CPU core count and memory capacity is not judged. After some nodes with insufficient performance or abnormal configuration are accessed, it will affect the computing power scheduling efficiency of the entire Kubernetes cluster. After node access, there is a lack of automated post-verification process, and the runtime status of nodes after access cannot be verified in a timely manner. In addition, the status updates during the node access process are not consistent, and the backend system has difficulty in grasping the process information such as "accessing in progress / access successful / failure reason" in real time, and cannot realize full lifecycle monitoring and problem tracing of the access process.

[0008] 4. Lack of continuous management capabilities: Most existing access solutions are one-time script execution solutions, without deploying long-term running agent components and controller mechanisms. They cannot achieve continuous collection of node hardware information, real-time updates of access status, or continuous monitoring and closed-loop management of the node's operational status after access.

[0009] A thorough analysis of the causes of the above problems reveals the following key points:

[0010] First, the node environments vary greatly. The Linux distributions, package managers, kernel features, security modules (SELinux / AppArmor), and network topologies of different nodes differ significantly, making it difficult to cover all environmental scenarios using a single unified script.

[0011] Second, heterogeneous computing power combinations are diverse, with different GPU suppliers, quantities, and device IDs. The combination of runtime components such as container runtime, GPURuntime, and Kata is complex and difficult to match quickly and accurately manually.

[0012] Third, the network environment is complex and ever-changing. Some nodes are deployed in the data center intranet and can only be accessed through jump boards / tunnels. Some nodes are edge PCs or cloud nodes, which require NAT traversal and secure tunnels. The technical difficulty of designing a unified network connectivity method is high.

[0013] Fourth, the existing solution has architectural flaws, lacking long-term running agent components and distributed controller mechanisms, and cannot support continuous management needs such as node hardware information collection, pre-inspection / post-inspection, and closed-loop status updates. Summary of the Invention

[0014] Therefore, the purpose of this invention is to propose a system and method for agent-based heterogeneous computing power nodes to access Kubernetes, which can realize the automated and unified access of heterogeneous computing power nodes to Kubernetes clusters, adapt to heterogeneous nodes with different hardware architectures, operating systems, and GPU types, shield the differences in complex network environments, realize the automation and observability of the entire node access process, and at the same time have good scalability, adapt to the constantly emerging computing power types and application scenarios, and solve the problems of low automation level of existing Kubernetes heterogeneous computing power node access, poor adaptability to heterogeneous environments, insufficient observability and closed-loop management capabilities in runtime, and difficulty in accessing complex network environments. It is applicable to the automated access scenarios of various types of heterogeneous computing power resources such as data center physical machines, virtual machines, edge PCs, and cloud nodes to Kubernetes clusters.

[0015] This invention provides a system for automatically connecting heterogeneous computing power nodes to Kubernetes based on agents. The system includes a control plane module (ProviderAPIServer), an access agent module, a node controller module (NodeController), a node access workflow module (NodeJoin), and a network access module. The modules cooperate with each other and communicate with each other to build an integrated architecture for automatic access of heterogeneous computing power nodes, realizing the fully automated access of multiple types of heterogeneous computing power nodes to the Kubernetes cluster.

[0016] The control plane module, as the key management and control center of the entire system, is used to maintain cell information, node resource information, and node access state machine. It provides standardized REST interfaces, including / cell / agent, / cell / nodes, / k8s / token, / cell / nodes / collect / {nodeType}, etc. Its main functions are to issue a list of nodes to be processed, receive node hardware information reported by the Agent, store node tags and full-process access status, and provide unified configuration and task management services for the Agent and node controller modules.

[0017] The access agent module runs as an independent process in the access environment of heterogeneous nodes and is the core interaction carrier between the system and the target nodes. Upon startup, it automatically parses local configuration files and command-line parameters, verifies the validity of the authentication token, and completes its own network environment initialization (stopping and disabling the firewall, joining the overlay network, etc.). Internally, it integrates a node controller module, a node access workflow module, a data acquisition module, and a heartbeat and scheduled task module to achieve integrated task scheduling, process execution, data acquisition, and status synchronization. It flexibly selects the command execution method according to the node type: a local command execution terminal is used for PC nodes, while an SSH remote command execution terminal is used for data center DC nodes and hybrid nodes.

[0018] The node controller module, as the core task scheduling unit within the Agent, achieves fine-grained management of node access-related tasks through work queues. The work queues include creating node task queues, cleaning up node task queues, and collecting node task queues. It supports parallel processing by multiple workers, significantly improving the efficiency of simultaneous access for multiple nodes. Its core functions are to initialize the corresponding command client (local client or remote SSH client) according to the node type (PC, DC, Hybrid, Cloud) and node role (worker, network, agent, etc.), download the node access material package from the control plane module, complete the unified scheduling of hardware information collection and access tasks for the target node, and perform retry and fault tolerance processing during task execution.

[0019] The node access workflow module, as the core execution unit for node access, is responsible for completing the entire process of environment preparation and cluster access operations on the target node. Specifically, it includes automatically installing and configuring core components such as container runtime, GPURuntime, network forwarding rules, HAProxy, and kubelet. Based on the configuration issued by the control plane module and the hardware acquisition results of the target node, it adaptively selects the optimal runtime solution (runc, NVIDIAContainerRuntime, AscendRuntime, Kata / UCAN-Kata, etc.). Finally, it calls the kubeadmjoin command to seamlessly connect the target node to the specified Kubernetes cluster and performs real-time monitoring and error reporting on the command execution results.

[0020] The network access module constructs an overlay network based on WireGuard lightweight virtual private network tunneling technology, with Tailscale as the core to achieve secure cross-network connectivity. During Agent initialization, the Tailscale client is automatically started and joined to the specified Tailnet network segment, and a unique Tailnet IP is assigned to the target node. For DC nodes, static routing scripts and scheduled tasks are automatically generated to ensure efficient forwarding of the Tailnet network segment through the Agent's default IP, completely shielding the differences in network environments such as public network / NAT / cross-data center / internal network, and achieving stable, secure, and seamless network connectivity between the control plane module and heterogeneous nodes.

[0021] Furthermore, the data acquisition module is a sub-module within the Agent, used to automatically prepare software sources on the target node (generating corresponding repo files based on the operating system and package manager), install hardware acquisition tools such as tar, lshw, lsblk, ethtool, lspci, and lscpu; run data acquisition logic to comprehensively acquire core hardware information of the target node, such as CPU, memory, disk, network, and GPU; for GPU devices, it reads the pci.ids database to convert the device's vendorId / deviceId into easily identifiable vendor names and product models, and counts the number of GPUs of different models, forming an aggregate description of "quantity × vendor * model"; it uses virtualization detection logic to determine whether the node is a physical machine or a virtual machine; finally, it reports all the collected hardware information to the control plane module through the / cell / nodes interface, providing data support for subsequent runtime selection, resource scheduling, and node label management.

[0022] Furthermore, the control plane module maintains the full-process access status of nodes through a state machine. The node access status includes not connected, connecting, pre-checking, connected, pre-checking failed, and connecting failed. The states are transferred in an orderly manner according to the task execution results. At the same time, the control plane module receives the heartbeat information of the Agent and monitors the Agent's running status in real time to ensure the high availability of the system.

[0023] This invention also provides a method for automatically connecting heterogeneous computing nodes to Kubernetes based on agents. Based on the aforementioned system implementation for automatically connecting heterogeneous computing nodes to Kubernetes based on agents, this method automates the entire process, including agent initialization and registration, node queue allocation, hardware information collection and resource pre-detection, automatic node environment preparation, automatic Kubernetes cluster access, node label update and post-verification. Specifically, it includes the following steps:

[0024] S1. Agent initialization and registration;

[0025] This step is the preparatory stage for node access, implementing the Agent's self-initialization and registration with the control plane module, specifically including:

[0026] S11. After the Agent process starts, it automatically parses the parameters passed in from the local configuration file and command line, extracts core information such as authentication token, node type, and resource pool CellID, and verifies the validity of the authentication token and the legality of the node type.

[0027] S12. Call local system commands to stop and disable firewall services (such as firewalld, iptables) to prevent network communication from being blocked by the system firewall during node access.

[0028] S13. Based on the resource pool (Cell) ID, AgentID and other information in the Token, generate a standardized hostname according to the preset rules, and complete the hostname setting of the target node through the hostnamectl command to achieve standardized management of node naming.

[0029] S14. Initialize the Tailscale client, automatically join the specified Tailnet network segment, complete the access to the Overlay network and obtain a unique Tailnet IP; generate the Agent external access address according to the node type, where DC / Hybrid nodes use direct connection ports, and Cloud nodes achieve port forwarding through proxy paths;

[0030] S15. Through the / cell / agentREST interface provided by the control plane module, report the Agent's running status (online), external access address, and Tailnet IP to the control plane module. At the same time, parse the Agent's geographical information (country, province, city) through the external Region service and report it as well, thus completing the Agent registration process.

[0031] S2, Node queue acquisition and task allocation;

[0032] This step enables the discovery of nodes to be connected and the distributed scheduling of tasks, specifically including:

[0033] S21. The Agent uses its internal heartbeat and timed task module to pull a list of nodes of the corresponding type from the / cell / nodes / collect / {nodeType} interface of the control plane module at a preset period (e.g., 10s).

[0034] S22. Encapsulate the retrieved nodes to be collected or connected into a standardized NodeJoinRequet data structure, and put them into the corresponding work queue (create node task queue / collect node task queue) according to node type and priority.

[0035] S23. For new nodes in the Hybrid resource pool or PC resource pool, the Agent obtains initialization information such as node ID, node name, and AgentID from the control plane module in advance through the / cell / nodes / agent or / cell / nodes / join_init interface.

[0036] S24. The node controller module reads node tasks from the work queue and automatically initializes the corresponding command client according to the node type (PC / DC / Hybrid / Cloud) and role (worker / network / agent): it initializes the local command client for PC nodes and the remote SSH client for DC / Hybrid / Cloud nodes, and performs SSH connectivity detection and automatic retry according to the system configuration to ensure the smooth operation of the command execution channel.

[0037] S3, Node hardware information collection and resource pre-inspection;

[0038] This step enables fully automated collection of target node hardware information and pre-access resource compliance verification, preventing nodes with insufficient performance from joining the cluster. Specifically, it includes:

[0039] S31. The node controller module automatically performs software source preparation operations on the target node. Based on the target node's operating system distribution and package manager (dnf / yum / apt-get), it generates and configures the corresponding repo file to ensure the normal download of the software package.

[0040] S32. Automatically install hardware acquisition tools such as tar, lshw, lsblk, ethtool, lspci, and lscpu on the target node. If the tools already exist, skip the installation.

[0041] S33. Download the access material package from the control plane module and decompress it on the target node. Run the data acquisition logic in the material package to fully obtain the hardware information of the target node, including: CPU architecture, number of cores, and clock speed; memory capacity and memory type; disk capacity, partitions, and read / write speed; network card, IP address, and bandwidth; GPU supplier, model, and quantity; node virtualization type (physical machine / virtual machine), etc.

[0042] S34. Standardize the GPU device information by reading the pci.ids database, converting the GPU's vendorId / deviceId into the vendor name (such as NVIDIA, Huawei) and product model (such as A100, Ascend910), and counting the number of GPUs of different models to form an aggregated description of "quantity × vendor * model".

[0043] S35. The collected full hardware information is reported to the control plane module through the / cell / nodes interface. The control plane module stores and parses the hardware information to provide data support for subsequent runtime selection and node label management.

[0044] S36. If the system has enabled the resource pre-inspection function, the core resources of the target node are judged according to the preset minimum access requirements (such as CPU cores ≥ 2 cores, memory capacity ≥ 16GB). If the requirements are met, the subsequent access process continues. If the requirements are not met, the node status is updated to "pre-inspection failed" and reported to the control plane module. At the same time, the access process of the node is terminated and the reason for failure is recorded.

[0045] S4. Automatic node environment preparation;

[0046] This step automates the entire environment configuration process before the target node is connected to the Kubernetes cluster, adaptively matching core components based on the node's hardware information. Specifically, it includes:

[0047] S41. If the target node is a network node, IP forwarding will be enabled automatically, sysctl core parameters will be configured (e.g., net.ipv4.ip_forward=1), and the parameter configuration will be persisted. If the target node is missing network components such as iptables and ipset, the default firewall policy will be installed and configured automatically to ensure the normal implementation of network forwarding.

[0048] S42. Based on the system configuration or the hardware acquisition results of the target node, automatically install and enable the containerd runtime on the target node. If other container runtimes are already installed on the target node, perform compatibility processing. If it is necessary to clean up the original CNI configuration, automatically perform the cleanup operation to ensure the normal operation of containerd.

[0049] S43. Based on the target node's type and hardware information, adaptively select and configure the corresponding runtime scheme, specifically as follows:

[0050] For general nodes without GPUs, runc is used as the default runtime, and the default BinaryName parameter is injected into the containerd configuration.

[0051] For nodes equipped with NVIDIA GPUs, the nvidia-container-toolkit is automatically installed, and the NVIDIA container runtime is registered and enabled in the containerd configuration.

[0052] For nodes equipped with Huawei Ascend, the corresponding version of AscendDockerRuntime is automatically downloaded and installed according to the node's CPU architecture (x86_64 / arm64). The corresponding Runtime path is specified in the containerd configuration to achieve Ascend computing power adaptation.

[0053] For data center physical nodes that meet the preset requirements, the Kata / UCAN-Kata virtualization runtime is automatically installed and configured, Kata-related runtime configuration files are generated, necessary binary soft links are created, and secure isolation of computing resources is achieved.

[0054] S44. Automatically install kubeadm, kubelet, and the required IPVS components on the target node to ensure the normal operation of the Kubernetes core components; automatically configure HAProxy using the preset configuration template, add the addresses of multiple Kubernetes master nodes to the HAProxy backend server list to form a local high-availability APIServer access entry point; at the same time, write the APIServer's domain name and IP mapping into the / etc / hosts file on the target node to achieve domain name access.

[0055] S5 nodes automatically join the Kubernetes cluster;

[0056] This step enables fully automated connection of the target node to the Kubernetes cluster, ensuring the correctness and stability of the node connection. Specifically, it includes:

[0057] S51. Before executing the kubeadmjoin command, perform a full cleanup of the old environment of the target node to avoid the old configuration affecting the access process. The cleanup operations include: stopping the containerd service, resetting the original Kubernetes cluster state (kubeadmreset), cleaning up the old Kata runtime directory, deleting old network routing rules and scheduled tasks, etc.

[0058] S52. Parse the cell-id and node type information in the authentication token, dynamically generate Kubernetes node tags according to preset rules, including osgalaxy.io / cell-id (resource pool ID), osgalaxy.io / type (node ​​type), osgalaxy.io / role-{role} (node ​​role), etc., and inject the node tags into the kubelet startup parameters to achieve fine-grained tag management of nodes;

[0059] S53. Configure the node-ip parameter of kubelet according to the node type to achieve standardized management of node IPs: For PC nodes, TailscaleIP is used as the node-ip to ensure cross-network accessibility; for DC / Hybrid / Cloud nodes, the default route exit IP of the node is automatically detected and configured as the node-ip to ensure normal communication of the node within the cluster.

[0060] S54. Permanently disable the swap partition on the target node and disable swap-related services through system configuration to prevent kubelet from malfunctioning due to the swap partition being enabled;

[0061] S55. Automatically execute the kubeadmjoin command on the target node to connect the node to the specified Kubernetes cluster. Monitor the execution status in real time during the command execution process. If the execution is successful, continue the subsequent process. If the execution fails, encapsulate and format the error information in a unified manner, report the reason for failure through the interface of the control plane module, and mark the node status as "connection failed".

[0062] S6, Node Label Update and Post-Verification;

[0063] This step involves updating the tag, verifying the running status, and performing cleanup operations after the node is connected, completing the entire lifecycle of node connection. Specifically, it includes:

[0064] S61. After the node successfully executes the kubeadmjoin command, the node controller module uses the hardware information (such as GPU model, CPU architecture, and memory capacity) collected in step S3 as a custom node label. This information is then updated to the control plane module through the / cell / nodes / {id} / labels interface. This combines the node hardware information with Kubernetes labels, facilitating fine-grained scheduling of computing resources based on hardware attributes and ensuring optimal utilization of different types of heterogeneous computing resources.

[0065] S62. If the system enables the post-check function, the node PostCheck task is started through the / cell / nodes / {id} / post_check interface of the control plane module. The node controller module polls the execution status of the PostCheck task until the task is completed. The node status is updated according to the execution result of the PostCheck task: if the check passes, it is marked as "connection successful"; if the check fails, a clear error description is given (such as kubelet running abnormally, Pod scheduling failure) and reported to the control plane module.

[0066] S63, the node controller module executes a set of configurable post-scripts on the target node. This set of scripts allows users to customize the configuration according to different deployment environments, enabling personalized cleanup operations, such as installing node monitoring components, configuring computing resource quotas, and adding nodes to specified Kubernetes namespaces.

[0067] S64. After completing all the final operations, the node controller module updates the access status of the target node to the final state, including "access completed" and "conversion successful", and reports the final state information to the control plane module. The state machine of the control plane module completes the final update of the node state. At this point, the automatic access process of heterogeneous computing power nodes is completed.

[0068] Furthermore, throughout the entire process of steps S1-S6 above, the Agent maintains periodic communication with the control plane module through its internal heartbeat and timed task modules, reporting its own running status and the task execution progress of node access in real time. The control plane module maintains the node access status in real time through a state machine, realizing visualized monitoring of the entire node access process. Operation and maintenance personnel can query the node access status, execution progress, and failure reasons in real time through the interface of the control plane module, enabling rapid location and troubleshooting of problems.

[0069] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, it implements the steps of the method for automatically connecting heterogeneous computing power nodes to Kubernetes based on the agent described above.

[0070] The present invention also provides a computer device, the computer device including a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the steps of the method for accessing K8s based on agent as described above.

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

[0072] The system and method for accessing heterogeneous computing power nodes to Kubernetes based on Agent provided by this invention utilizes a three-layer architecture design of Agent + NodeController + NodeJoin. This architecture unifies heterogeneous computing power resources from different types of nodes (PC nodes, data center nodes, hybrid nodes, cloud nodes, etc.), different CPU architectures (x86_64 / arm64, etc.), and different GPU vendors (NVIDIA / Huawei Ascend, etc.) into a single access framework. This achieves unified and automatic access to heterogeneous computing power, eliminating reliance on manual operation, significantly reducing maintenance costs, and improving node access efficiency. Furthermore, by building an Overlay network based on Tailscale and combining static routing scripts with scheduled tasks, the differences in complex network environments such as public network / NAT / cross-data center / internal network are completely masked, allowing the control plane module to directly monitor the physical location and network of nodes. It achieves topology-awareness, enabling stable and secure access for heterogeneous nodes in any network environment. Through fully automated collection of target node hardware information and parsing of the pci.ids database, it adaptively selects and configures the corresponding container runtime, GPURuntime, and virtualization runtime based on node type, GPU vendor, CPU architecture, and other conditions, avoiding errors caused by manual judgment and configuration, and significantly improving the correctness and adaptability of node access. It integrates the entire process of node discovery → material distribution → hardware collection → resource pre-inspection → environment preparation → kubeadmjoin → tag update → post-check into a unified automated workflow. Combined with state machine and task queue, it realizes real-time updating and flow of node access status. With unified reporting and storage of error reasons, it achieves observability, monitoring, and traceability of the entire lifecycle of node access, facilitating unified management and auditing by operation and maintenance personnel.

[0073] The system's access process adopts a configuration and template-driven design philosophy. Runtime selection, HAProxy configuration, post-scripts, and hardware collection rules are all defined through configuration files. This allows for support for new GPU vendors (such as AMD and Intel), new operating system distributions, and new network solutions without modifying the core code. It boasts excellent scalability and supports various deployment models, including single-node multi-instance deployment and bypass deployment of agents, adapting to different enterprise computing power management needs. Through a resource pre-inspection mechanism before access, nodes with insufficient performance or abnormal configurations are filtered out, preventing unqualified nodes from affecting the overall computing power scheduling of the cluster and effectively improving the computing power scheduling efficiency of the Kubernetes cluster. Attached Figure Description

[0074] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0075] In the attached diagram:

[0076] Figure 1 This is a schematic diagram of the overall architecture of a system for connecting heterogeneous computing power nodes to K8s based on an agent, according to an embodiment of the present invention.

[0077] Figure 2 This is a schematic diagram of the Agent initialization and registration process according to an embodiment of the present invention;

[0078] Figure 3 This is a schematic diagram of the overall process of automatic node access according to an embodiment of the present invention;

[0079] Figure 4 This is a schematic diagram of the selection process during heterogeneous computing power operation according to an embodiment of the present invention;

[0080] Figure 5 This is a schematic diagram of the node state machine and task queue in an embodiment of the present invention;

[0081] Figure 6 This is a schematic diagram of the configuration of a computer device according to an embodiment of the present invention. Detailed Implementation

[0082] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of systems and products consistent with some aspects of this disclosure as detailed in the appended claims.

[0083] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0084] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0085] The embodiments of the present invention will be described in further detail below.

[0086] Example

[0087] This invention provides a system for heterogeneous computing nodes to access Kubernetes based on an agent, including: a control plane module, an access agent module, a node controller module, a node access workflow module, and a network access module. The modules work together to achieve automatic access of heterogeneous computing nodes to the Kubernetes cluster.

[0088] The control plane module is ProviderAPIServer, which is used to maintain cell information, node resource information and state machine, provide REST interface, issue node list, receive node hardware information, and store node tags and access status;

[0089] The access agent module runs as a process in the access environment. When it starts, it parses the configuration and authentication token and completes the network environment initialization. It integrates a node controller module, a node access workflow module, a data acquisition module, and a heartbeat and scheduled task module. It selects a local or remote SSH command execution terminal according to the node type.

[0090] The node controller module manages node access-related tasks through a work queue, supports parallel processing by multiple workers, initializes the command client according to the node type and role, downloads the node access material package, and completes hardware information collection and access task scheduling. The work queue includes creating a node task queue, clearing a node task queue, and collecting a node task queue. The node types include PC nodes, data center (DC) nodes, hybrid nodes, and cloud nodes. The node roles include worker, network, and agent. The runtime solutions include runc, NVIDIA Container Runtime, Ascend Runtime, and Kata / UCAN-Kata.

[0091] The node access workflow module automatically completes the configuration of container runtime, GPURuntime, network forwarding, HAProxy and kubelet on the target node, and calls the kubeadmjoin command to realize the node's access to the Kubernetes cluster, and adaptively selects the runtime scheme based on the hardware acquisition results.

[0092] The network access module constructs an overlay network based on WireGuard's tunneling technology, assigns Tailnet IPs to nodes, generates static routing scripts and scheduled tasks, and achieves stable network connectivity between the control plane and heterogeneous nodes. Specifically, the network access module uses Tailscale to construct the overlay network. During Agent initialization, the Tailscale client is started and joined to the specified Tailnet network segment. For DC nodes, the network access module generates static routing scripts and scheduled tasks to ensure that the Tailnet network segment is forwarded through the Agent's default IP.

[0093] The data acquisition module is used to install acquisition tools and run data acquisition logic on the target node to obtain CPU, memory, disk, network, and GPU device information. It converts the GPU's vendorId / deviceId into the supplier name and product model and counts the number. It uses virtualization detection to determine whether the node is a physical machine or a virtual machine and reports the acquired hardware information to the control plane module.

[0094] The REST interfaces provided by the control plane module include / cell / agent, / cell / nodes, / k8s / token, / cell / nodes / collect / {nodeType}, / cell / nodes / agent, / cell / nodes / join_init, / cell / nodes / {id} / labels, and / cell / nodes / {id} / post_check, which respectively implement Agent status update, node information interaction, token acquisition, retrieval of the list of nodes to be processed, acquisition of node initialization information, node label update, and node post-check startup functions.

[0095] This invention also provides a method for connecting heterogeneous computing nodes to Kubernetes based on agents. The system implementation for connecting heterogeneous computing nodes to Kubernetes based on agents, as described above, includes the following steps:

[0096] S1. Agent Initialization and Registration: After the Agent process starts, it parses the configuration and authentication token, verifies the validity, completes the network environment initialization, sets the standardized hostname, joins the Overlay network to obtain the TailnetIP, and reports the Agent status, address and geographical information to the control plane module.

[0097] Network environment initialization includes stopping and disabling the firewall service. The geographical information is obtained through parsing an external Region service, including country, province, and city information. The standardized hostname is generated according to the resource pool CellID and AgentID in the Token according to rules, and is set using the hostnamectl command.

[0098] S2. Node queue acquisition and task allocation: The Agent periodically pulls a list of nodes to be processed from the control plane module, encapsulates the nodes into a NodeJoinRequet structure and puts them into the work queue. The node controller module initializes the command client according to the node type and role and completes the connectivity detection.

[0099] S3. Node Hardware Information Acquisition and Resource Pre-inspection: The node controller module automatically prepares the software source and installs the acquisition tool on the target node, runs the data acquisition logic to obtain hardware information and reports it to the control plane module. If resource pre-inspection is enabled, it determines whether the node meets the access requirements. If it does not meet the requirements, it is marked as pre-inspection failure.

[0100] The data collection tools include tar, lshw, lsblk, ethtool, lspci, and lscpu. The hardware information includes the number of CPU cores, memory capacity, disk information, network information, GPU supplier, model and quantity, and node virtualization type. The minimum access requirements for resource pre-inspection are a CPU core count ≥ 2 cores and a memory capacity ≥ 16GB.

[0101] S4. Automatic preparation of node environment: Configure network forwarding and sysctl on network nodes, install and configure containerd container runtime, adaptively select the runtime according to the node type and install the corresponding GPURuntime or virtualization runtime, install kubeadm, kubelet and IPVS components and configure HAProxy to achieve high availability access to Kubernetes APIServer.

[0102] The adaptive runtime selection method is as follows: general nodes use the runc runtime; NVIDIA GPU nodes install nvidia-container-toolkit and configure the NVIDIA container runtime; Huawei Ascend nodes download and install the AscendDockerRuntime for the corresponding architecture, specifying the runtime path in the containerd configuration; and qualified DC physical nodes install and configure Kata / UCAN-Kata, generate the relevant runtime configuration, and create binary soft links.

[0103] S5. Automatically add nodes to the Kubernetes cluster: Clean up the old environment of the nodes, dynamically generate Kubernetes node labels based on the token and inject them into the kubelet startup parameters, configure the node-ip of the kubelet, and after closing the swap partition, execute the kubeadmjoin command to connect the nodes to the Kubernetes cluster. Error encapsulation and reporting are performed for execution failures.

[0104] S6. Node Label Update and Post-Verification: The collected hardware information is used as node labels to update the control plane module. If post-check is enabled, the PostCheck task is started and the node status is updated according to the results. The post-script is executed to complete the cleanup operation and update the node status to the final state.

[0105] The final state includes "connection completed" and "conversion successful". The post-check is implemented by polling the execution status of the PostCheck task. If the post-check fails, a clear error description is given. The post-script is a set of configurable custom scripts that can be adapted to the finishing needs of different deployment environments.

[0106] In steps S1-S6, the Agent communicates periodically with the control plane module through the heartbeat and timed task module. The control plane module maintains the access status of the node through a state machine. The access status includes not connected, connecting, pre-checking, connected, pre-checking failed, and connection failed.

[0107] Figure 1 It illustrates the hierarchical relationship and data interaction methods between the control plane module, agent module, NodeController module, NodeJoin workflow module, tunnel network (Tailnet), and Kubernetes cluster;

[0108] Figure 2 This demonstrates the complete sequence of events for the Agent, from process startup, configuration parsing, firewall disabling, Tailscale joining the network, to reporting its status to the control plane.

[0109] Figure 3 It shows the detailed steps and node state transitions from when a node is added to the work queue, through hardware acquisition, resource pre-inspection, environment preparation, kubeadmjoin, label update to post-inspection;

[0110] Figure 4 The system demonstrates its decision-making logic and process for automatically selecting different runtime combinations such as containerd+runc, NVIDIARuntime, AscendRuntime, and Kata / UCAN-Kata based on conditions such as node type, GPU vendor, CPU architecture, and virtualization type.

[0111] Figure 5 It shows the state transition relationship of a node from "Not connected" to "Connecting", "Pre-inspection", and then to "Connected / Pre-inspection failed / Connection failed", as well as the task processing and collaboration relationship of creating a node task queue, cleaning up a node task queue, and collecting data from a node task queue.

[0112] Application examples

[0113] This invention is applied to the heterogeneous computing resource management scenario of enterprise-level data centers. The heterogeneous nodes to be connected include: data center physical machines with x86_64 architecture (equipped with NVIDIA A100 GPU), cloud virtual machines with arm64 architecture (without GPU), edge PC nodes (x86_64 architecture), and AI acceleration nodes equipped with Huawei Ascend 910 (x86_64 architecture). The operating systems of the nodes include CentOS 7 (dnf package manager) and Ubuntu 20.04 (apt-get package manager). The network environment includes data center intranet, public network NAT, and cross-data center dedicated lines.

[0114] The system includes a control plane module (ProviderAPIServer), an access agent module, a node controller module, a node access workflow module, and a network access module. The control plane module is deployed on the core server of the enterprise data center, using a high-availability cluster deployment method. It provides REST interfaces such as / cell / agent, / cell / nodes, and / k8s / token, maintains Cell resource pool information (this embodiment configures one Cell resource pool with ID CELL-001), a node access state machine, and stores node hardware information and tags.

[0115] The access agent module is deployed as an independent process developed in Go on the access environment of each heterogeneous node. It supports multiple Linux distributions. The process startup parameters include authentication token (TOKEN-CELL-001), node type, and Tailnet network segment (100.64.0.0 / 10).

[0116] The network access module uses Tailscale to build an overlay network. The Tailnet network segment is configured as 100.64.0.0 / 10. A unique Tailscale IP is assigned to each heterogeneous node. Static routing scripts are generated for physical machines in the data center, and a scheduled task (executed every 5 minutes) is configured via crontab to maintain route forwarding.

[0117] The node controller module is integrated inside the Agent, and is configured with 3 worker threads to achieve parallel task processing. The work queue includes a node task creation queue, a node task cleanup queue, and a node task collection queue. The SSH client timeout is configured to be 30 seconds and the number of retries is 3.

[0118] The node access workflow module is integrated inside the Agent. The default version of the container runtime is containerd 1.7.0, the Kubernetes core component version is 1.28.0, the HAProxy configuration template is a custom haproxy.cfg.tpl, and the minimum access requirements for resource pre-check are CPU ≥ 2 cores and memory ≥ 16GB.

[0119] The steps for automatically connecting heterogeneous computing nodes to Kubernetes are as follows:

[0120] S1. Agent initialization and registration;

[0121] After the Agent process on each heterogeneous node starts, it parses the authentication token (TOKEN-CELL-001) and node type parameters in the configuration file. After verifying the token's validity, it calls the commands `systemctl stopfirewalld && systemctl disablefirewalld` to stop and disable the firewall. It then generates a standardized hostname based on the CellID (CELL-001) and AgentID, such as CELL-001-AGENT-001, and completes the setting using `hostnamectl set -hostnameCELL-001-AGENT-001`. Finally, it initializes the Agent process. In the ilscale client, execute the command `tailscaleup --join-node=CELL-001` to join the Tailnet network segment and obtain the Tailscale IP (e.g., 100.64.1.2). Generate an external access address based on the node type, such as 100.64.1.2:8080 for data center physical machines and proxy.example.com / 100.64.1.3:8080 for cloud virtual machines. Report the Agent status as online, address as 100.64.1.2:8080, and geographical information as a province and city to the control plane module through the ` / cell / agent` interface, thus completing Agent registration.

[0122] S2, Node queue acquisition and task allocation;

[0123] The Agent pulls a list of nodes to be processed from the / cell / nodes / collect / all interface of the control plane module every 10 seconds. In this application example, four nodes to be connected are pulled and encapsulated into NodeJoinRequet structures and placed into the node creation task queue. The node controller module reads the tasks from the queue and initializes the command client according to the node type: edge PC nodes initialize local command clients, data center physical machines, cloud virtual machines, and AI acceleration nodes initialize remote SSH clients. After completing the SSH connectivity test, the hardware acquisition stage begins.

[0124] S3, Node hardware information collection and resource pre-inspection;

[0125] The node controller module automatically prepares software sources on each target node: yumrepo for CentOS7 nodes and aptrepo for Ubuntu 20.04 nodes; it installs data acquisition tools such as lshw, lspci, and lscpu, runs the data acquisition logic, and obtains hardware information.

[0126] Data center physical machine: x86_64, 80-core CPU, 512GB memory, NVIDIA A100×8, physical machine;

[0127] Cloud virtual machine: arm64, quad-core CPU, 32GB memory, no GPU, virtual machine;

[0128] Edge PC node: x86_64, 8-core CPU, 32GB memory, no GPU, physical machine;

[0129] AI acceleration nodes: x86_64, 64-core CPU, 256GB memory, Huawei Ascend 910 x 4, physical machine.

[0130] After reporting the above hardware information to the control plane module and enabling resource pre-check, all four nodes meet the requirements of CPU ≥ 2 cores and memory ≥ 16GB, and enter the environment preparation stage.

[0131] S4. Automatic node environment preparation;

[0132] On the nodes with the network role, execute `sysctl -wnet.ipv4.ip_forward=1` and write the parameter to ` / etc / sysctl.conf`. Install iptables and configure the default policy. Install and enable containerd 1.7.0 on all nodes, and adaptively select the runtime based on hardware information.

[0133] Cloud virtual machines and edge PC nodes: use runc runtime;

[0134] Data center physical machines: Install nvidia-container-toolkit and configure NVIDIA container runtime;

[0135] AI acceleration node: Download the x86_64 version of AscendDockerRuntime, install it, and configure the Runtime path in containerd;

[0136] Install kubeadm 1.28.0, kubelet 1.28.0, and IPVS components on all nodes. Configure HAProxy to add the three Kubernetes master nodes (192.168.1.10, 192.168.1.11, and 192.168.1.12) to the backend server list. Write k8s-api.example.com127.0.0.1 to / etc / hosts.

[0137] S5 nodes automatically join the Kubernetes cluster;

[0138] Execute the `kubeadmreset` command to reset the old node environment, stop containerd, and clean up the old CNI configuration; parse CELL-001 from the token to generate node labels `osgalaxy.io / cell-id=CELL-001`, `osgalaxy.io / type=physical / virtual / pc / ai`, and `osgalaxy.io / role-worker`; configure the kubelet's node-ip: the edge PC node is set to Tailscale IP 100.64.1.4, and other nodes are set to the default route egress IP; execute `swapoff -a && sed -i ' / swap / s / ^ / # / ' / etc / fstab` to permanently disable swap; finally, execute the `kubeadmjoink8s-api.example.com:6443 --tokenxxx --discovery-token-ca-cert-hashsha256:xxx` command to connect all 4 nodes to the Kubernetes cluster.

[0139] S6, Node Label Update and Post-Verification;

[0140] The collected hardware information is updated to the control plane module as custom tags, such as nvidia.com / gpu=A100, huawei.com / ascend=910, cpu.arch=x86_64 / arm64; a post-check is enabled, and a PostCheck task is started to poll the kubelet status and Pod scheduling capability. All four nodes pass the check; a post-script is executed to install the prometheus-node-exporter monitoring component and add the nodes to the k8s-compute namespace; the node status is updated to "connection completed" and reported to the control plane module, completing the entire connection process.

[0141] In this application example, the four heterogeneous computing nodes, under different network environments, hardware architectures, and GPU configurations, all achieved fully automated access to the Kubernetes cluster. The access process required no manual intervention and achieved a 100% success rate. Compared with the traditional manual access method, the access efficiency was greatly improved, and the operation and maintenance costs were reduced. At the same time, by combining hardware information with node tags, fine-grained computing power scheduling based on GPU model and CPU architecture was achieved, which greatly improved the utilization efficiency of the enterprise's heterogeneous computing resources.

[0142] Furthermore, the technical solution of the present invention can be modified and extended in various ways, all of which fall within the protection scope of the present invention, as shown in the following examples:

[0143] Network subsystem transformation: Tailscale is used to build the overlay network, which can be replaced by a self-developed tunnel service based on WireGuard or IPsec, or open-source VPN systems such as OpenVPN and StrongSwan. Only the corresponding network initialization and IP allocation logic needs to be adapted. The route maintenance method can be replaced by systemd dynamic units or BGP / FRR kernel route advertisement protocol to achieve automatic route synchronization.

[0144] Runtime component transformation: containerd is used as the default container runtime, which can be replaced with CRI-O, DockerEngine and other CRI-compliant runtimes. Only the corresponding configuration template and service management commands need to be modified. The GPU runtime can be extended to AMD, Intel GPUs or other AI accelerator cards. Only the corresponding vendor logic needs to be added to the pci.ids mapping and installation script. Kata / UCAN-Kata can be replaced with lightweight virtualization solutions such as gVisor and Firecracker to achieve alternative security isolation capabilities.

[0145] The data acquisition module has been modified: it uses commands such as lshw and lspci to collect hardware information, which can be replaced by directly reading kernel export information from the / sys and / proc file systems, or obtaining hardware data through the vendor's SDK and IPMI / BMC interface, thereby improving the accuracy of acquisition and the coverage of indicators.

[0146] Control protocol variations: Communication between the control plane and the agent is implemented using an HTTP / JSON REST API, which can be replaced with gRPC, Kafka / RedisStream message queues, or WebSocket long connections to meet the requirements of different scenarios for communication latency and reliability; the work queue of the node controller can be replaced with a distributed queue system to achieve cross-agent task scheduling and high availability;

[0147] Agent deployment variations: Agents can be deployed using a single-node multi-instance deployment, with multiple Agent instances deployed on the same physical machine to correspond to different Kubernetes clusters or different tenants, achieving isolated management of multiple clusters / tenants; alternatively, a bypass deployment method can be used, deploying the Agent on a jump host machine on the same Layer 2 network as the target node, and executing the access process through JumpHost, which is suitable for scenarios where it is not possible to install a local agent on the target node.

[0148] This invention also provides a computer device. Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention; see the accompanying drawings. Figure 6 As shown, the computer device includes: an input device 23, an output device 24, a memory 22, and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the agent-based heterogeneous computing node access to Kubernetes method provided in the above embodiments; wherein the input device 23, the output device 24, the memory 22, and the processor 21 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0149] The memory 22, as a read / write storage medium for computing devices, can be used to store software programs and computer-executable programs, such as the program instructions corresponding to the agent-based heterogeneous computing node access to Kubernetes method described in this embodiment of the invention. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on device usage. Furthermore, the memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 22 may further include memory remotely located relative to the processor 21, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0150] Input device 23 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function control of the device; output device 24 may include display devices such as a display screen.

[0151] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby realizing the above-mentioned method of connecting heterogeneous computing nodes to K8s based on agents.

[0152] The computer equipment provided above can be used to execute the agent-based heterogeneous computing nodes accessing K8s method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0153] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the agent-based heterogeneous computing node access to Kubernetes method provided in the above embodiments. The storage medium can be any type of memory device or storage device, including: mounting media such as CD-ROM, floppy disk, or magnetic tape; computer system memory or random access memory such as DRAM, DDRRAM, SRAM, EDORAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory components; the storage medium may also include other types of memory or combinations thereof; furthermore, the storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet); the second computer system can provide program instructions to the first computer for execution. The storage medium includes two or more storage media that can reside in different locations (e.g., in different computer systems connected via a network). The storage medium can store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0154] Of course, the storage medium containing computer-executable instructions provided in the embodiments of the present invention is not limited to the method for accessing K8s based on agent-based heterogeneous computing nodes as described in the above embodiments, but can also perform related operations in the method for accessing K8s based on agent-based heterogeneous computing nodes provided in any embodiment of the present invention.

[0155] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0156] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A system for connecting heterogeneous computing nodes to Kubernetes based on agents, characterized in that, include: The control plane module, access agent module, node controller module, node access workflow module, and network access module work together to enable heterogeneous computing power nodes to automatically access the Kubernetes cluster. The control plane module is ProviderAPIServer, which is used to maintain unit cell information, node resource information and state machine, provide REST interface, send out node list, receive node hardware information, and store node tags and access status. The access agent module runs as a process in the access environment. When it starts, it parses the configuration and authentication token and completes the network environment initialization. It integrates a node controller module, a node access workflow module, a data acquisition module, and a heartbeat and scheduled task module. It selects a local or remote SSH command execution terminal according to the node type. The node controller module manages node access-related tasks through a work queue, supports parallel processing by multiple workers, initializes the command client according to the node type and role, downloads the node access material package, and completes hardware information collection and access task scheduling. The node access workflow module automatically completes the configuration of container runtime, GPURuntime, network forwarding, HAProxy and kubelet on the target node, and calls the kubeadmjoin command to realize the node's access to the Kubernetes cluster, and adaptively selects the runtime scheme based on the hardware acquisition results. The network access module constructs an overlay network based on WireGuard's tunneling technology, assigns TailnetIPs to nodes, generates static routing scripts and timed tasks, and achieves stable network connectivity between the control plane and heterogeneous nodes.

2. The agent-based heterogeneous computing nodes accessing Kubernetes as described in claim 1, characterized in that, The work queue includes a node creation task queue, a node cleanup task queue, and a node collection task queue. The node types include PC nodes, data center (DC) nodes, hybrid nodes, and cloud nodes. The node roles include worker, network, and agent. The runtime scheme includes one or more combinations of runc, NVIDIA Container Runtime, Ascend Runtime, and Kata / UCAN-Kata.

3. The system for accessing heterogeneous computing nodes to Kubernetes based on Agent 1 according to claim 1, characterized in that, The network access module uses Tailscale to build an overlay network. When the Agent is initialized, the Tailscale client is started and the Agent is added to the specified Tailnet network segment. For DC nodes, the network access module generates static routing scripts and scheduled tasks, and forwards the Tailnet network segment through the Agent's default IP.

4. The agent-based heterogeneous computing power node access Kubernetes system according to claim 1, characterized in that, The data acquisition module is used to install acquisition tools and run data acquisition logic on the target node, obtain CPU, memory, disk, network, and GPU device information, convert the GPU vendorId / deviceId into supplier name and product model and count the quantity, determine whether the node is a physical machine or a virtual machine through virtualization detection, and report the acquired hardware information to the control plane module.

5. The agent-based heterogeneous computing nodes accessing Kubernetes as described in claim 1, characterized in that, The REST interfaces provided by the control plane module include / cell / agent, / cell / nodes, / k8s / token, / cell / nodes / collect / {nodeType}, / cell / nodes / agent, / cell / nodes / join_init, / cell / nodes / {id} / labels, and / cell / nodes / {id} / post_check, which respectively implement Agent status update, node information interaction, token acquisition, retrieval of the list of nodes to be processed, acquisition of node initialization information, node label update, and node post-check startup functions.

6. A method for connecting heterogeneous computing nodes to Kubernetes based on agents, implemented based on the system for connecting heterogeneous computing nodes to Kubernetes based on agents according to any one of claims 1-5, characterized in that, Includes the following steps: S1. After the Agent process starts, it parses the configuration and authentication token, verifies the validity, completes the network environment initialization, sets the standardized hostname, joins the Overlay network to obtain the TailnetIP, and reports the Agent status, address and geographical information to the control plane module. S2. The Agent periodically pulls a list of nodes to be processed from the control plane module, encapsulates the nodes into a NodeJoinRequet structure and puts them into the work queue. The node controller module initializes the command client according to the node type and role and completes the connectivity detection. S3, the node controller module automatically prepares the software source and installs the acquisition tool on the target node, runs the data acquisition logic to obtain hardware information and reports it to the control plane module. If resource pre-inspection is enabled, it determines whether the node meets the access requirements. If it does not meet the requirements, it is marked as pre-inspection failure. S4. Configure network forwarding and sysctl on network nodes, install and configure containerd container runtime, adaptively select the runtime according to the node type and install the corresponding GPURuntime or virtualization runtime, install kubeadm, kubelet and IPVS components and configure HAProxy to achieve high availability access to Kubernetes APIServer; S5. Clean up the old environment of the node, dynamically generate Kubernetes node labels based on the token and inject them into the kubelet startup parameters, configure the node-ip of kubelet, and after closing the swap partition, execute the kubeadmjoin command to connect the node to the Kubernetes cluster. Perform error encapsulation and reporting for execution failures. S6. Update the collected hardware information as node labels to the control plane module. If post-check is enabled, start the PostCheck task and update the node status according to the results. Execute the post-script to complete the cleanup operation and update the node status to the final state.

7. The method for connecting heterogeneous computing power nodes to Kubernetes based on Agent 6, characterized in that, The network environment initialization in step S1 includes stopping and disabling the firewall service. The geographical information is obtained by parsing through an external Region service, including country, province, and city information. The standardized hostname is generated according to the resource pool CellID and AgentID in the Token according to rules, and is set by the hostnamectl command.

8. The method for connecting heterogeneous computing power nodes to Kubernetes based on Agent 6, characterized in that, The acquisition tools in step S3 include tar, lshw, lsblk, ethtool, lspci, and lscpu. The hardware information includes the number of CPU cores, memory capacity, disk information, network information, GPU supplier, model and quantity, and node virtualization type. The minimum access requirement for resource pre-detection is a CPU core count ≥ 2 cores and a memory capacity ≥ 16GB.

9. The method for connecting heterogeneous computing power nodes to Kubernetes based on Agent 6, characterized in that, The adaptive runtime selection method in step S4 is as follows: general nodes use the runc runtime; NVIDIA GPU nodes install nvidia-container-toolkit and configure the NVIDIA container runtime; Huawei Ascend nodes download and install the AscendDockerRuntime for the corresponding architecture, specifying the runtime path in the containerd configuration; and DC physical nodes that meet the requirements install and configure Kata / UCAN-Kata, generate the relevant runtime configuration, and create binary soft links.

10. The method for connecting heterogeneous computing power nodes to Kubernetes based on Agent 6, characterized in that, The final state in step S6 includes "access completed" and "conversion successful". The post-check is implemented by polling the execution status of the PostCheck task. If the post-check fails, a clear error description is given. The post-script is a set of configurable custom scripts that can adapt to the finishing needs of different deployment environments.

Images