A method and device for automatic unpacking of a smart integrated machine

Abstract

The application provides a method and device for automatic unpacking and use of an intelligent computing all-in-one machine, and belongs to the technical field of cloud-native cluster automatic management. The method comprises the following steps: presetting a proxy component in each node of a cluster composed of the intelligent computing all-in-one machine, the proxy component being set to start at boot, and a cloud-native cluster component being set not to start at boot; after the intelligent computing all-in-one machine is booted, the proxy component of a main control node starts a server, and the proxy components of other nodes are connected to the server as clients through an IP discovery mode; the IP address change of a current network environment is detected, and a configuration update operation is performed when the IP address change is detected; the cloud-native cluster components are started in turn, and the cloud-native cluster components are set to start at boot; the cloud-native cluster state is monitored, and integrated testing is automatically run to verify platform availability when all nodes reach an available state. The scheme optimizes the out-of-box process of the intelligent computing all-in-one machine, and improves the efficiency of on-site deployment of customers and user experience.

Description

Technical Field

[0001] This application relates to the field of cloud-native cluster automated management technology, and in particular to a method and apparatus for an intelligent computing all-in-one machine to be automatically ready to use out of the box. Background Technology

[0002] An intelligent computing appliance should be defined as a dedicated hardware and software integrated device that integrates artificial intelligence (AI) computing capabilities (i.e., "intelligent computing"), cloud-native infrastructure, and hardware resources. Its purpose is to provide users with a ready-to-use, highly integrated, and autonomously operating intelligent computing service environment. The intelligent computing appliance scenario refers to a hardware and software integrated deployment environment that highly integrates AI computing capabilities (i.e., "intelligent computing") with cloud-native infrastructure. In this scenario, the server equipment (i.e., the intelligent computing appliance) comes pre-installed with a complete software stack including a Kubernetes cloud-native cluster and its upper-layer intelligent computing platform, aiming to achieve out-of-the-box usability—that is, once the server is powered on in the customer's environment, the cloud-native cluster is ready to use and can function normally with its intelligent computing platform.

[0003] However, existing intelligent computing appliances cannot achieve true out-of-the-box usability due to the IP address sensitivity of cloud-native Kubernetes clusters. Kubernetes has a strong dependency on node IP addresses. When the network IP obtained by the intelligent computing appliance during actual operation at the customer's site differs from the factory default or initial IP, control plane certificates will become invalid, node communication will be interrupted, and the availability of the entire cloud-native cluster and the upper-layer intelligent computing platform will be affected. Furthermore, in Kubernetes clusters, container networking functionality is implemented by CNI network plugins, and some plugins (such as Flannel and Calico) heavily rely on the host IP address of nodes during initialization or runtime to build Pod routes, tunnel endpoints, or network policies. When the actual operating IP of the intelligent computing appliance at the customer's site differs from the initial IP, if the network plugin fails to dynamically detect and update this change, Pod network routing between nodes will fail or tunnels will be interrupted, preventing cross-node business applications from communicating. This problem further exacerbates the "out-of-the-box" obstacle caused by IP sensitivity, indicating that simply solving the control plane certificate issue is insufficient to guarantee end-to-end cluster availability.

[0004] Traditional solutions require maintenance personnel to go to the customer's site to manually complete installation, certificate updates, configuration and other debugging work, which is labor-intensive and fails to achieve the original design intention of out-of-the-box use, resulting in a poor customer experience.

[0005] Therefore, there is a need to provide an improved technical solution that addresses the shortcomings of the existing technology. Summary of the Invention

[0006] The purpose of this application is to provide a method and apparatus for automatically opening and using an intelligent computing all-in-one machine, so as to solve or alleviate the problems existing in the prior art.

[0007] To achieve the above objectives, this application provides the following technical solution:

[0008] In a first aspect, this application provides a method for automatically turning on and off a smart computing all-in-one machine, including:

[0009] S1, In each node of the cluster composed of intelligent computing all-in-one machines, a proxy component is pre-installed. The proxy component is set to start on boot, and the cloud-native cluster component is set not to start on boot.

[0010] S2, After the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery.

[0011] S3 detects changes in IP addresses in the current network environment. When a change in IP address is detected, a configuration update operation is performed.

[0012] S4, each node sequentially starts the cloud-native cluster component and sets the cloud-native cluster component to start on boot;

[0013] S5 monitors the status of cloud-native clusters and automatically runs integration tests to verify platform availability once all nodes are in an available state.

[0014] In conjunction with the first aspect, in some possible implementations, in S3, the configuration update operation includes:

[0015] Back up the master control node's configuration files and certificate directory, and regenerate the certificates and configuration files based on the new IP addresses; distribute the certificates and configuration files required by other nodes from the master control node to the other nodes.

[0016] Each other node receives the configuration file and performs local backup and replacement operations.

[0017] In conjunction with the first aspect, in some possible implementations, in S2, the IP discovery method includes two modes: broadcast discovery and unicast configuration.

[0018] The broadcast discovery mode is as follows: the master control node listens for broadcast messages on a specified port, other nodes send information to the broadcast address, and after receiving the broadcast information, the master control node sends its own IP address as a response message to the requester.

[0019] The unicast configuration mode is as follows: the IP address of the master control node is set through a preset configuration file or command line, and other nodes directly connect to the specified master control node.

[0020] In conjunction with the first aspect, in some possible implementations, the proxy components communicate with each other via the WebSocket protocol and employ a built-in public / private key mechanism to ensure communication security.

[0021] In conjunction with the first aspect, in some possible implementations, the startup process of the cloud-native cluster component includes:

[0022] Start the container runtime and kubelet service;

[0023] Automatically start existing container workloads through the controller mechanism;

[0024] Update the IP address in the ConfigMap configuration resource under the kube-system namespace and restart the corresponding Pod.

[0025] In conjunction with the first aspect, among some possible implementation methods, the integration test adopts an e2e testing framework, which achieves automated testing and verification by calling the open API interface of the intelligent computing platform.

[0026] In conjunction with the first aspect, some possible implementation methods also include a result feedback step: in a networked environment, the test results are sent to a designated department via email, and in an offline environment, a command-line query interface is provided for users to obtain the test results.

[0027] Secondly, this embodiment provides a device for automatically opening and using an all-in-one intelligent computing machine. This device is used to execute the method for automatically opening and using an all-in-one intelligent computing machine provided in any of the above embodiments, including:

[0028] The proxy component module is pre-installed in each node of the intelligent computing appliance and is set to start on boot, while the cloud-native cluster component is set not to start on boot.

[0029] The connection establishment module is used so that after the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery.

[0030] The IP detection module is used to detect changes in IP addresses in the current network environment. When a change in IP address is detected, a configuration update operation is performed.

[0031] The cluster management module sequentially starts the cloud-native cluster components on each node and sets the cloud-native cluster components to start on boot.

[0032] The testing and verification module is used to monitor the status of the cloud-native cluster. Once all nodes are in an available state, it automatically runs integration tests to verify the platform's availability.

[0033] Thirdly, this embodiment provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the above embodiments.

[0034] Fourthly, this embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in any of the above embodiments.

[0035] Beneficial effects:

[0036] By pre-installing agent components in each node of the cluster composed of intelligent computing all-in-one machines, the installation and debugging of the cloud-native intelligent computing platform are completed before leaving the factory. With an independent agent component as the startup entry point, the delayed startup and guidance of cloud-native cluster components are realized. This enables the intelligent computing all-in-one machine to automatically complete cluster reconstruction in an unattended environment or with only simple configuration of the main control node. This optimizes the all-in-one machine's factory exit process, and users can use the platform simply by turning it on, greatly improving delivery efficiency and user experience. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the structure of an electronic device provided according to some embodiments of this application.

[0038] Figure 2 This is a schematic diagram of the manufacturing process of an intelligent computing all-in-one machine in the existing technology.

[0039] Figure 3 A schematic diagram of the optimized intelligent computing all-in-one machine's factory exit process provided in this application.

[0040] Figure 4 This is a schematic diagram of the original cluster structure of the optimized intelligent computing all-in-one machine cloud.

[0041] Figure 5 This is a schematic diagram of the overall technical process of the method for automatically opening and using the intelligent computing all-in-one machine provided in this embodiment. Detailed Implementation

[0042] The embodiments of this application will now be described with reference to the accompanying drawings.

[0043] The embodiments of this application can be applied to Figure 1Among the electronic devices shown, the electronic devices may be, but are not limited to, mobile terminals such as mobile phones, tablets, handheld computers, and personal digital assistants (PDAs), smart home devices such as smart TVs and smart cameras, wearable devices such as smart bracelets, smartwatches, and smart glasses, or other computer devices such as desktop, laptop, notebook, ultra-mobile personal computer (UMPC), netbook, and smart screen.

[0044] like Figure 1 As shown, the electronic device 200 may include one or more of the following components: a processor 201, a memory 203, a communication interface 202, and a communication bus 204. The memory 203 can be connected to the processor 201 via the bus 204. The bus can transfer data between the processor 201 and the memory 203. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0045] Processor 201 may include one or more processing cores. Processor 201 can connect to various parts within the electronic device 200 using various interfaces and lines. It performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 203, and by calling data stored in memory 203. For example, processor 201 may include an application processor (AP), a modem processor, a CPU, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic array (PLA), and / or a neural network processing unit (NPU). The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed; the NPU implements artificial intelligence (AI) functions; and the modem handles wireless communication. Different processing units can be independent devices or integrated into one or more processors. For example, the multiple processing units shown above are all integrated into a single SoC, or the AP is a separate semiconductor chip, while other processing units are integrated into a single SoC. This application does not limit this to any particular type.

[0046] The memory 203 may include random access memory (RAM), read-only memory (ROM), or non-transitory computer-readable storage medium. The memory 203 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 203 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system or instructions for at least one function, such as a method for automatic out-of-the-box operation of an all-in-one computer. The data storage area may store data created based on the use of the electronic device 200, such as configuration files and certificates.

[0047] In addition, those skilled in the art will understand that the structure of the electronic device 200 shown in the above figures does not constitute a limitation on the electronic device 200. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device 200 may also include components such as a microphone, speaker, radio frequency circuit, sensor, audio circuit, power supply, and Bluetooth module, which will not be described in detail here.

[0048] This embodiment provides a method for automatically opening and using an all-in-one intelligent computing machine, which includes the following steps:

[0049] S1, In each node of the cluster composed of intelligent computing all-in-one machines, a proxy component is pre-installed. The proxy component is set to start on boot, and the cloud-native cluster component is set not to start on boot.

[0050] S2, After the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery.

[0051] S3 detects changes in IP addresses in the current network environment. When a change in IP address is detected, a configuration update operation is performed.

[0052] S4, each node sequentially starts the cloud-native cluster component and sets the cloud-native cluster component to start on boot;

[0053] S5 monitors the status of cloud-native clusters and automatically runs integration tests to verify platform availability once all nodes are in an available state.

[0054] In this embodiment, the cluster composed of intelligent computing all-in-one machines refers to a Kubernetes cluster deployment form in which one or more nodes (including control nodes and / or worker nodes) in the cluster are composed of intelligent computing all-in-one machines, forming a unified platform (i.e. intelligent computing platform) to provide services to end users.

[0055] Among them, the intelligent computing all-in-one machine is a dedicated server device with highly integrated hardware and software. It comes pre-installed with an operating system, Kubernetes components, AI computing framework and supporting services, and is optimized for artificial intelligence workloads.

[0056] It's important to note that Kubernetes is an open-source system for container orchestration in clusters. Here, a cluster refers to a distributed system composed of multiple interconnected compute nodes that work together to provide unified computing, storage, and scheduling capabilities. In cloud-native architectures, a cluster specifically refers to a container orchestration cluster built on Kubernetes, typically including one or more control plane nodes and multiple worker nodes. Control plane nodes are responsible for managing cluster resources, while worker nodes are responsible for running containerized applications, managing node resources within the cluster, and automating the deployment, scaling, and management of containerized applications. Further, control plane nodes are divided into master control nodes and other control nodes. In this embodiment, since startup is guided by the master control node, the other control nodes and worker nodes in the cluster are collectively referred to as other nodes. Control plane nodes run Kubernetes control plane components. For example, the core control plane component kube-apiserver is responsible for processing all API requests and managing resources both inside and outside the cluster, serving as the central gateway for Kubernetes. Other Kubernetes control plane components may include etcd, kube-scheduler, etc., which will not be elaborated upon here.

[0057] Figure 2 The existing outbound process for intelligent computing appliance clusters is illustrated. Before outbound, the intelligent computing appliance requires the following preparations: first, prepare bare metal; then, install an operating system (such as Linux) on the bare metal; and finally, install the intelligent computing cloud native platform (e.g., install the Kubernetes platform before outbound) or prepare the Kubernetes installation package for the cloud native platform. After outbound, operations personnel at the customer's site need to perform the following configurations: modify IP-related configurations or install the intelligent computing cloud native platform on-site, verify and debug the system, and complete the entire outbound process. In the original process, during the installation of the cloud native Kubernetes cluster, the control node is initialized first. During initialization, a two-way TLS certificate between each control plane component is generated using the local machine's IP address. Then, other nodes join the cluster by calling the kube-apiserver of the initialized control node.

[0058] Two-way TLS authentication is a security mechanism that establishes two-way authentication between the client and the server. It uses digital certificates to achieve trusted authentication and encrypted data transmission between the two communicating parties. The IP address is a manifestation of identity.

[0059] Due to the IP sensitivity and certificate dependency of the cloud platform, for the master control node, the Kubernetes control plane component generates a two-way TLS certificate based on the node's IP address during initialization. When the intelligent computing appliance is first powered on at the customer's site and obtains its actual operating IP, if this IP is inconsistent with the preset or initial IP, the certificate will become invalid, leading to control plane communication interruptions, node registration failures, and other problems, preventing the control plane component from functioning properly. For other nodes, since each node typically reports its own IP address to the control node periodically, and the control node dynamically maintains node network information accordingly, when worker node IPs change, the cluster can adapt to the change through an automatic re-registration mechanism, resulting in a small impact and self-healing capability. Furthermore, some network plugins used on certain nodes also heavily rely on the host's IP address; changes in IP addresses may prevent customer business applications from communicating with each other.

[0060] To avoid certificate invalidation due to changes in the customer's on-site IP, the traditional outbound process typically requires maintenance personnel to accompany the machine (intelligent computing appliance) to the customer's site to modify the IP-related configuration changes, or to install the installation program built into the intelligent computing appliance and power it on-site to install the intelligent computing cloud-native platform before it can be used normally. This solution requires the intelligent computing appliance supplier to send maintenance personnel to the site, which greatly increases the supplier's labor costs. At the same time, the repeated verification work before and after the outbound process also brings more time costs, and the user experience is poor for users who expect to use it out of the box.

[0061] In this embodiment, to alleviate the problem that IP changes prevent the intelligent computing all-in-one machine from being used out of the box, such as... Figure 3 As shown, the process of sending the intelligent computing all-in-one machine out of the factory has been optimized. Before leaving the factory, a new agent component (hereinafter referred to as Agent) is pre-installed in each node of the cluster composed of intelligent computing all-in-one machines (i.e., each intelligent computing all-in-one machine node). The Agent component has the ability to automatically detect IP under the cloud-native cluster and automatically update the IP-related configuration in the cloud-native cluster. This optimizes the process by placing the installation and debugging of the cloud-native intelligent computing platform in the pre-factory preparation work and achieves true out-of-the-box usability.

[0062] Specifically, the Agent component is a binary program that manages services through Linux's Systemd. This component is used to solve all the problems encountered out of the box.

[0063] During appliance initialization, all cloud-native cluster components are configured not to start automatically at boot, except for the agent component. In other words, to ensure the controllability and security of the system startup process, all cloud-native cluster components related to the intelligent computing platform (including but not limited to kube-apiserver, etcd, kubelet, container runtime, and CNI network plugins) are configured at the factory not to start automatically with the system by default. Conversely, only the Agent component is configured to start automatically at boot. This configuration is achieved through the Linux systemd service management mechanism, specifically as follows: a corresponding systemd unit file (e.g., agent.service) is created for the Agent in the system service directory (e.g., / etc / systemd / system / ), and its startup attribute is enabled (e.g., executing systemctl enable agent.service); while the startup of each component service of the cloud-native cluster is explicitly disabled.

[0064] In step S2, when the intelligent computing all-in-one machine is powered on and started for the first time at the customer's site, after the operating system is loaded, only the Agent component is automatically activated and running, while the components of the cloud-native cluster are in an unstarted state.

[0065] Furthermore, after the intelligent computing appliance cluster powers on and starts up, the pre-installed agent components in each node automatically execute differentiated initialization logic based on the role of their respective nodes. Specifically, during the startup process of the intelligent computing appliance designated as the master node, its agent component first completes local environment awareness (e.g., obtaining the current actual IP address), and then starts a dedicated server process within the local machine. This server listens on a preset network port and receives registration requests and configuration interactions from other nodes in the cluster. Its communication protocol can be based on HTTP / HTTPS, gRPC, or a custom binary protocol, and the specific form is not limited.

[0066] Meanwhile, after the intelligent computing machines of the remaining nodes (Worker Nodes) are started, their Agent components run as clients. These clients connect to the main control node's services through the built-in IP discovery method, inform the main control node of their node roles (other control nodes or worker nodes), and conduct subsequent business interactions.

[0067] Furthermore, to achieve true out-of-the-box usability, after powering on, the Agent component of the main control node of the intelligent computing appliance can perceive its new, actual IP address and the real network status. In S3, the Agent component of the main control node detects changes in the IP address of the current network environment. For example, it can detect the actual network configuration of the current node (including IP address, hostname, network interface status, etc.). When a change in IP address is detected, configuration update operations are performed based on the real operating environment, such as dynamically generating or updating the two-way TLS certificate, configuration files, and network plugin parameters required by the Kubernetes control plane.

[0068] After the master control node completes its IP configuration adjustments, other nodes need to obtain the latest master control node IP through the IP discovery mechanism and update the certificates and IP addresses required for mutual access between the master control nodes. Furthermore, to adapt to different network deployment environments, the agent component in S2 supports two node IP discovery modes, used by other nodes to locate the service address of the master control node at startup, thereby establishing subsequent communication connections. Specifically, the IP discovery methods include broadcast discovery and unicast configuration. In broadcast discovery mode, the master control node listens for broadcast messages on a specified port, other nodes send information to the broadcast address, and the master control node, upon receiving the broadcast information, sends its own IP address as a response message to the requester. In unicast configuration mode, the master control node's IP address is set through a preset configuration file or command line, and other nodes directly connect to the specified master control node. By providing two IP discovery methods, users can choose one mode according to the actual network topology, enabling the agent component to adaptively locate the master control node under different network conditions, providing a reliable network discovery foundation for the intelligent computing all-in-one machine cluster to be used out of the box at the customer's site.

[0069] The two IP discovery methods are explained in detail below.

[0070] The first IP discovery method is broadcast discovery mode, which automatically discovers the IPs of each smart computing appliance node through intra-domain broadcasting. This is suitable for scenarios where the cluster is on the same network segment (broadcasting is not possible between different subnets). In this mode, all smart computing appliance nodes are located within the same local area network subnet and support Layer 2 broadcast communication.

[0071] In this mode, after the intelligent computing all-in-one machine is powered on, the Agent component of each node first reads the current network configuration of the local machine (including IP address and subnet mask), and calculates the broadcast address of the local subnet accordingly. The calculation formula is as follows:

[0072] Broadcast address = IP address | ( (subnet mask)

[0073] The "|" operator represents a bitwise OR operation. " indicates bitwise inversion.

[0074] After startup, the Agent component of the master control node listens for broadcast messages through a preset port (e.g., UDP 9000). At the same time, the Agent components of other nodes send broadcast messages containing information (such as their own node identifier and role information) to the specified port of the broadcast address.

[0075] When the Agent component of the master control node receives a broadcast message from any other node, it returns a response message to the source IP address of the broadcast message, which contains the master control node's own actual IP address. Upon receiving this response, each node can determine the reachable address of the master control node and establish a WebSocket connection with the master control node's server-side Agent accordingly, thus entering the subsequent initialization process.

[0076] Since this mode does not require pre-configuration of IP information, it is suitable for plug-and-play scenarios where the network environment is unknown but the nodes are in the same subnet.

[0077] The second IP discovery method is the unicast configuration mode, which discovers the IPs of each working node (the intelligent computing all-in-one node that is not the control node) by configuring the IP address of the master control node.

[0078] If unicast IP configuration is used, the Agent components on nodes other than the master control node will first check the pre-configured local configuration file (e.g., / etc / agent / config.yaml) or use the command-line tool provided by the Agent component (e.g., agent set-master-ip) after booting up. <ip>Obtain the IP address of the main control node that has been set. This IP address is set by the customer in advance according to the actual network plan after purchasing the all-in-one machine.

[0079] After obtaining the IP address of the master control node, the Agent components of other nodes directly initiate a connection request (such as a WebSocket handshake) to the specified server at that IP address, attempting to establish communication with the Agent component server of the master control node. If the connection is successful, the node registration and cluster initialization process continues; if the connection fails, the Agent component can enter a retry or waiting state until the network connection is successful.

[0080] Other nodes' Agent clients, after completing local IP discovery and obtaining the master control node's address through either of the two IP discovery methods mentioned above, reconnect to the master control node. After reconnecting to the master control node, each node re-reports its IP address to the master control node and establishes a persistent connection with the master control node's Agent component via the WebSocket protocol. This connection is used to transmit critical control plane messages such as node registration information, cluster configuration commands, certificate distribution data, status heartbeats, and initialization progress. This mode is suitable for production environments with complex network architectures, nodes deployed across subnets, or security policies prohibiting broadcasting, offering greater controllability and flexibility.

[0081] By providing an IP discovery mechanism, the cluster can achieve automatic discovery, role declaration, and collaborative initialization between the master control node and other nodes without on-site operation by maintenance personnel, laying the communication foundation for the adaptive deployment of the cloud-native cluster.

[0082] Preferably, all node proxy components communicate with each other via the WebSocket protocol, and a built-in public / private key mechanism is used to ensure communication security.

[0083] In this embodiment, the server started by the agent component of the main control node establishes a long-lived communication channel with the clients run by the agent components of other nodes via the WebSocket protocol to achieve efficient, low-latency, bidirectional real-time interaction. The WebSocket protocol is an application-layer communication protocol based on TCP, specifically designed for fully bidirectional communication between clients and servers.

[0084] To ensure the security of the communication process and prevent man-in-the-middle attacks, data eavesdropping, or forged node access, this embodiment introduces a built-in public / private key mechanism on top of the WebSocket communication layer. Specifically, each proxy component is pre-configured with a unique public / private key pair (e.g., generated based on RSA or ECDSA algorithms) before leaving the factory. The private key is securely stored locally (e.g., in a permission-protected configuration directory or trusted execution environment), while the public key can be publicly distributed or exchanged during the initial handshake. This public / private key pair can function independently of the Kubernetes cluster's own TLS certificate system, serving as a dedicated secure communication infrastructure between proxy components. This ensures trusted interaction between nodes even in the early stages when the cluster has not yet completed initialization and the native Kubernetes authentication mechanism is unavailable. By employing the WebSocket protocol combined with the built-in public / private key mechanism, the security and trust issues of intelligent computing all-in-one machines during initial networking in unknown network environments are effectively solved while ensuring real-time communication, providing a reliable security foundation for "out-of-the-box" functionality.

[0085] As mentioned earlier, after the intelligent computing all-in-one machine is powered on, the Agent component on the main control node can detect its new IP address and back up and update existing certificates.

[0086] Once all other node agent components are interconnected with the master control node agent component, the agent components on each node begin configuring the cloud-native cluster. In other words, after all node agent components successfully establish communication connections with the master control node agent component, the cluster enters a configuration adaptation phase. The agent components on each node collaboratively execute configuration update operations for the cloud-native cluster (such as Kubernetes) to ensure that cluster components can operate correctly based on the current actual network environment (especially the real IP addresses of each node).

[0087] Specifically, the configuration update operation includes two parts: configuration update of the master control node and configuration update of each other node. The specific process is as follows: back up the configuration file and certificate directory of the master control node, and regenerate the certificate and configuration file based on the new IP address; distribute the certificates and configuration files required by other nodes from the master control node to each other node; after receiving the configuration file, each other node performs local backup and replacement operations.

[0088] When the master control node's configuration is updated, its Agent component first performs a full backup of the existing cloud-native cluster configuration files (such as kubeadm.conf, kube-apiserver.yaml, etc.) and certificate directory (usually located at / etc / kubernetes / pki / ). The backup path can be a subdirectory named with a local timestamp (such as / etc / kubernetes / backup_20240601_120000 / ) to ensure a quick rollback in case of configuration anomalies. Subsequently, the master control node's Agent component calls the official Kubernetes lifecycle management tool kubeadm to perform a certificate regeneration operation. Specifically, the master control node's Agent component regenerates a two-way TLS certificate system that conforms to Kubernetes security requirements based on the local machine's current IP address. The process includes: 1) regenerating the CA certificate (if necessary) or reusing an existing CA; 2) generating new server certificates for components such as kube-apiserver, etcd, kubelet, etc., where the SubjectAlternative Name (SAN) field contains the actual IP address and hostname of the current master node; 3) generating new client certificates and kubeconfig files for inter-component authentication; 4) updating the IP references in all relevant configuration files (such as advertise-address, etcd endpoints, API server URL, etc.) to the real IP of the current master node.

[0089] The configuration distribution and updates for other nodes include: After the Agent component of the master control node completes its own configuration update, it distributes the certificates (such as kubelet client certificates, CA certificates) and configuration files (such as kubelet.conf, bootstrap-kubeconfig, etc.) required by other nodes to the Agent components of each node through the established secure communication channel (such as the aforementioned connection based on WebSocket and public / private key mechanism).

[0090] After receiving the configuration data, the Agent component on each node performs the following operations: 1) Back up the existing local certificate ( / etc / kubernetes) and configuration file (e.g., store them in the / etc / kubernetes / backup / directory); 2) Write the newly received certificate and configuration file to the corresponding standard path (e.g., / etc / kubernetes / ); 3) Verify file integrity and permissions (e.g., set 600 permissions to protect the private key); 4) Once ready, report the configuration update completion status to the master control node.

[0091] After completing the above configuration update, in S4, the Agent components of each node (i.e. all intelligent computing machine nodes) can start the cloud-native cluster components in the order of dependency, thereby ensuring that the entire cluster can complete bootstrapping based on real IP addresses and valid security credentials, and achieve end-to-end availability.

[0092] Specifically, the startup process of cloud-native cluster components includes: starting the container runtime and kubelet service; automatically starting existing container workloads through the controller mechanism; updating the IP addresses in the ConfigMap configuration resources under the kube-system namespace and restarting the corresponding Pods.

[0093] (1) Start the container runtime and kubelet service.

[0094] First, the Agent component starts the underlying container runtime, such as containerd or CRI-O, on each node, ensuring it is ready. Then, the Agent component starts the kubelet service and loads the updated kubeconfig file and certificates, enabling the kubelet to successfully register with the kube-apiserver on the master control node via mutual TLS authentication. After starting, the kubelet reports its node status to the control plane and prepares to receive Pod scheduling commands.

[0095] (2) Automatically restore existing container workloads through the controller mechanism.

[0096] In the Kubernetes architecture, workloads (such as Deployments, DaemonSets, and StatefulSets) are continuously monitored and maintained in their desired state by their corresponding controllers. Once the kubelet establishes a connection with the control plane, the controllers in the control plane (such as the Deployment Controller and DaemonSet Controller) automatically detect that the nodes are ready and, based on the persistent declarative configuration in etcd, reschedule or restore the previously defined containerized workloads. This process requires no manual intervention, enabling automatic recovery of business applications.

[0097] (3) Update the IP address in the ConfigMap configuration resource under the kube-system namespace and restart the corresponding Pod.

[0098] Some control plane components (such as CoreDNS, kube-proxy, and CNI plugins) rely on ConfigMap resources in the kube-system namespace to obtain cluster network parameters. These resources may contain the API Server address or service gateway IP of the master control node. If these addresses are still the old IPs from initialization, it will cause component malfunctions. Therefore, after starting the control plane components, the agent component on the master control node proactively checks and updates the IP address fields in the relevant ConfigMaps (such as kubeadm-config, coredns, and kube-proxy), replacing them with the actual IP of the current master control node. After the update, the agent component triggers a rolling restart of the Pod containing the corresponding control plane component (e.g., by deleting the Pod so that it is automatically rebuilt by the controller) to ensure the new configuration takes effect. For example, after deleting the CoreDNS Pod under the kube-system namespace, the Deployment controller will create a new Pod using the new ConfigMap, thus ensuring that the DNS service can correctly resolve services within the cluster.

[0099] Through the above startup process, the cloud-native cluster not only completes the initialization of basic components, but also achieves end-to-end adaptive recovery of system configuration and business load, ensuring that the intelligent computing appliance can provide complete and usable intelligent computing services after the first power-on at the customer site.

[0100] As an example, the configuration update operation and the startup process of cloud-native cluster components can be performed in the following steps:

[0101] 1) Use the Agent component to back up the Kubernetes configuration files and certificates in the / etc / kubernetes directory of the control node;

[0102] 2) On the control node, use kubeadm to generate a new certificate. kubeadm is the Kubernetes lifecycle management tool, and its commands support certificate regeneration. For example, you can call "kubeadm init phasecerts all --config=" through the Agent component. <updated-config>"or equivalent command, kubeadm regenerates the TLS certificates required by all control plane components (such as kube-apiserver, etcd, kube-controller-manager, etc.) based on the actual IP address of the current node (instead of the factory default address), and ensures that the Subject Alternative Name (SAN) field of the new certificate contains the currently valid IP address and hostname.

[0103] 3) In the control node, the Agent component calls the kubeadm command to generate a new kubelet.conf configuration file adapted to the current network environment. This file contains the client certificate reference and APIServer address used by kubelet to connect to kube-apiserver, ensuring that kubelet can successfully complete the TLS handshake and node registration based on the real IP.

[0104] 4) In the control node, use kubeadm to generate a new kubeconfig file and overwrite the configuration file $HOME / .kube / config in the user's directory. This ensures that the command-line tool can immediately use the updated cluster credentials, making it easier for operations and maintenance personnel to access the cluster through the kubectl command-line tool.

[0105] 5) Distribute configuration and certificates to worker nodes: The master control node sends the certificates, kubeconfig, and kubelet.conf required by the worker nodes to the Agent component on each worker node through an established secure communication channel (such as a connection based on WebSocket and public / private key mechanism). After receiving the files, the Agent component on the worker node backs up and replaces the local files. That is, it first backs up the original files in the local / etc / kubernetes directory, and then writes the newly received files to the corresponding path to complete the configuration replacement.

[0106] 6) Start and enable container runtime and kubelet services: After the configuration update is completed, the Agent components of all nodes (including the master control node and other nodes) start the underlying container runtime (Docker, Containerd, etc.) and kubelet respectively, and set them to start on boot. Both kubelet and container runtime are binary files, managed and implemented by Linux's Systemd.

[0107] To further ensure the platform's functional integrity, the Agent component of the master control node also performs a final calibration of the system-level configuration, which involves updating the IP addresses in the ConfigMap configuration resources under the kube-system namespace and restarting the corresponding Pods. Specifically, the master control node calls kube-apiserver to replace the IP addresses in all ConfigMap configuration resources under the kube-system namespace of the Kubernetes cluster. After replacement, the corresponding Pod is started; only a restart of the Pod will make the changes effective. At this point, the startup and operation phase of the intelligent computing all-in-one machine platform is complete. In detail, the Agent component of the master control node calls kube-apiserver to traverse all ConfigMap resources (such as kubeadm-config, coredns, kube-proxy, etc.) under the kube-system namespace, replacing the hard-coded old IP addresses with the actual IP address of the current master control node. Since the content of the ConfigMap resources only takes effect when the Pod starts, after the Agent component completes the update, the Kubernetes cluster will proactively delete the Pods containing the affected control plane components (such as CoreDNS, kube-proxy, etc.), triggering the corresponding controller to automatically rebuild the Pods. The above steps of hot-updating configurations and restarting affected Pods ensure that the new configurations take effect on running instances.

[0108] Through the above process, when the intelligent computing all-in-one machine cluster is first deployed to the customer's site, it can dynamically complete the reconstruction of control plane certificates, update configuration files, secure distribution between nodes and activation of core services based on the actual network environment, completely solving the cluster unavailability problem caused by IP address changes and truly achieving the product goal of "out-of-the-box use".

[0109] In step S5, after completing the configuration update and service startup of the cloud-native cluster components, the agent component of the master control node continuously monitors the overall operating status of all nodes in the cluster to determine whether the platform availability conditions have been met.

[0110] Specifically, the Agent component periodically queries the Ready status of all intelligent computing appliance nodes by calling the node status interface of kube-apiserver (such as / api / v1 / nodes). In Kubernetes, a node is marked as Ready when its kubelet is successfully registered, its network plugin is ready, it is runtime-available, and its resources are sufficient. Only when all nodes in the cluster (including the master control node and worker nodes) are in the Ready state does the Agent component determine that the cluster has entered a stable and available phase.

[0111] Once all nodes are available (in the Ready state), the existing container workloads on the platform will start all container applications. Kubernetes achieves dynamic startup and scaling of containers through automation mechanisms. Its core principle is based on the continuous monitoring of system status by controllers (such as Deployment and StatefulSet). When a Pod is detected to be in a non-running state, kubelet will call the container runtime (such as Containerd) to perform the startup operation.

[0112] In other words, when all nodes are in the Ready state, Kubernetes' built-in controller mechanisms (such as Deployment Controller, StatefulSet Controller, DaemonSet Controller, etc.) automatically trigger the recovery process of pre-configured container workloads. These workloads are persistently stored in etcd as declarative resource objects before cluster initialization. The controller continuously compares the current actual state with the expected state. Once it finds that the target Pod is not running or is missing, it allocates a node through the scheduler and notifies the kubelet of the corresponding node to call the container runtime (such as containerd) to pull the image and start the container. As a result, containerized services such as intelligent computing applications, monitoring components, and log services pre-integrated in the platform will automatically start and enter the running state.

[0113] The Agent component in the main control node of the all-in-one machine waits for all pre-integrated core component Pods and intelligent computing application Pods, as well as other containerized services, to automatically start and enter the running state. After detecting that all container workload components of the intelligent computing platform are running, it runs e2e to perform smoke tests. Since all API interfaces of the built-in intelligent computing platform are open interfaces, e2e can achieve its testing objectives by calling these interfaces. The platform component backend technologies primarily use the Golang development language; therefore, Ginkgo was chosen as the e2e testing framework.

[0114] In short, after all nodes in the Kubernetes cluster have reached the Ready state, the system-level Pods (which run the core components of the cloud-native cluster, including the control plane components and the management components of each worker node) have been rebuilt, and the pre-built containerized workloads have been automatically started by the controller mechanism, the agent component of the main control node further performs integration testing to ensure platform-level availability verification. The integration testing adopts an e2e (end-to-end) testing framework and achieves automated testing verification by calling the open API interface of the intelligent computing platform.

[0115] The Agent component on the main control node continuously monitors and polls the Pod status corresponding to the container workload components of the intelligent computing platform until it confirms that all nodes have reached the Ready state, all system-level Pods and critical business containers (business Pods, such as AI tasks) are in the Running state, and the Readiness Probe has passed. Integration testing is then executed. The Running state of a Pod can be determined by querying the Pod list under the corresponding namespace in the kube-apiserver.

[0116] Furthermore, the Agent component automatically triggers end-to-end (e2e) smoke tests to verify the overall usability of the intelligent computing platform. Since the intelligent computing platform integrated in this embodiment adopts an open API design, all its core functions (such as model deployment, inference requests, task submission, and resource queries) are exposed through standardized RESTful or gRPC interfaces. e2e testing can directly simulate real user operations by calling these interfaces to verify the platform's response correctness, service connectivity, and the completeness of its basic functions.

[0117] Considering that the backend services of the intelligent computing platform are mainly developed based on the Golang language, in order to maintain the consistency of the technology stack and improve the efficiency of test development, this embodiment selects Ginkgo as the e2e test framework.

[0118] Ginkgo is a BDD (Behavior-Driven Development) testing framework designed specifically for Golang, supporting concurrent testing, rich assertion mechanisms, and deep integration with Kubernetes client libraries (such as client-go).

[0119] The test cases are either embedded in the Agent component as code or pre-installed as independent test images in the all-in-one machine, and can be executed locally without external dependencies. If all test cases pass, the Agent component marks the platform status as "ready"; otherwise, it records detailed error logs and can trigger alarms or self-diagnostic processes.

[0120] As an optional embodiment, after running the e2e smoke test, a result feedback step is also included: in an online environment, the test results are sent to a designated department via email, and in an offline environment, a command-line query interface is provided for users to obtain the test results.

[0121] In other words, if the main control node of the intelligent computing all-in-one machine can connect to the external network, the test results can be sent back to the designated department, such as the company's pre-sales department, via email. In an offline environment, customers can also query the results using commands provided by the Agent component, and contact customer service for support if any issues arise.

[0122] Figure 4 A schematic diagram of the original cluster structure of the intelligent computing all-in-one cloud is shown. For example... Figure 4 As shown, the intelligent computing all-in-one machine cloud-native cluster (composed of intelligent computing all-in-one machines) includes at least one control node and at least one worker node. The control node is configured with agent 301, configuration and certificate 302, kube-apiserver 303, and kubelet 304; the worker node is configured with agent 301, kube-apiserver 303, kubelet 304, and configuration file 305. The descriptions of each part are as follows:

[0123] Agent 301 (a newly developed component, i.e., the Agent component) is built into all nodes (including all control nodes and worker nodes) and is used to perform related operations to solve all technical problems encountered. This component includes the ability to perform IP discovery updates, certificate updates, configuration updates, enable platform components to start automatically at boot, and integrate with the test platform. Agent components can exchange new IP information and new certificates. Specifically, agent 301 in the master control node is used to detect network environment information, update configurations, and refresh certificates when the node starts up, and communicates with agent 301 in other nodes (here referring to worker nodes). Agent 301 in worker nodes connects to agent 301 in the control node when the node starts up and modifies local configuration files according to information issued by the control node.

[0124] Configuration and Certificate 302, located on the all-in-one machine control node, is used to store the configuration files and certificates required by the control node, including all relevant configuration files in the control node and server and client certificates of the components.

[0125] kube-apiserver 303, deployed on the control node of the integrated machine, is a core control plane component of Kubernetes. It is used as the core gateway of the cluster control plane to provide resource services and implements two-way TLS certificate verification through certificate files.

[0126] Kubelet 304 is a core component of Kubernetes. Each node (including the control node and worker nodes) has a kubelet, which is used to interact with the kube-apiserver. When resources need to be scheduled to a node, the kube-apiserver will call the kubelet interface to issue the resources. When the resource status is updated, the kubelet will call the kube-apiserver to report the resource status. The interaction between the two is based on mutual TLS certificates.

[0127] Configuration file 305 specifically refers to the configuration file of the worker node, which contains the kubeconfig configuration used to connect to the kube-apiserver and the kubelet's own configuration file.

[0128] Figure 4 In the cloud-native cluster of the intelligent computing all-in-one machine shown, when the all-in-one machine is powered on, agent 301 starts first, while other components in the cloud-native cluster are set not to start upon startup. Agent 301 on the control node detects and handles changes in its local IP address, modifies and updates the configuration file and certificate according to the actual IP address, and then starts kubelet and kube-apiserver sequentially. Agent 301 on the worker nodes connects to the control node through the IP discovery mechanism, modifies its local configuration file according to the information issued by the control node, and then starts the underlying container runtime (Docker, Containerd, etc.), kubelet, and other components (such as network components) sequentially. This ensures that the cloud-native cluster can still achieve automatic startup and availability verification even when the IP address changes, achieving true out-of-the-box usability.

[0129] Figure 5 This diagram illustrates the overall technical process of the automatic out-of-the-box operation of the intelligent computing appliance provided in this embodiment. It shows how, in an intelligent computing appliance scenario, a Kubernetes cluster automatically detects, updates certificates, rebuilds services, and performs platform self-checks after a node IP address changes, all through a built-in Agent component. The entire process involves three roles: the main control node, several other control nodes, and several worker nodes, who collaborate to achieve adaptive cluster recovery. The following refers to... Figure 5 The process of the method provided in this embodiment will be described in exemplary detail, including the following steps:

[0130] Start-up phase:

[0131] Step 1: Power on each node and start the Agent component.

[0132] Master control node: Automatically starts the Agent component after power-on and acts as a server to connect with other nodes;

[0133] Other control nodes: After powering on, start the Agent component and attempt to connect to the services provided by the main control node;

[0134] Worker node: After booting up, the Agent component starts and attempts to connect to the services provided by the main control node.

[0135] It is important to note that during the startup phase of each node, only the Agent component is set to start automatically at boot, while the other Kubernetes components are initially in a non-started state to ensure security and controllability.

[0136] Node interconnection and role confirmation phase:

[0137] Step 2: Start the built-in services on the master control node.

[0138] The Agent component on the master control node starts a listening service (such as a WebSocket service) and waits for other nodes to connect; the IP supports two discovery mechanisms: broadcast discovery mode and unicast configuration mode.

[0139] Step 3: All control nodes are connected.

[0140] All control nodes (including the master control node and other control nodes) successfully connect to the agent service of the master control node; the master control node records the roles and network information of each control node and prepares to enter the configuration update phase. At this time, the master control node can determine that "all control nodes are ready" and trigger the next operation.

[0141] Configuration update and component initialization phase:

[0142] Step 4: Update certificates, binaries, and static Pod configurations to ensure that all control plane components establish secure communication using the latest IP addresses.

[0143] (1) The master control node performs the following operations:

[0144] 1) Back up critical configurations such as certificates, kubeconfig, and manifests in the original / etc / kubernetes directory;

[0145] 2) Use the "kubeadm certs renew" command to regenerate the TLS certificate containing the new IP address;

[0146] 3) Use "kubeadm init phase kubeconfig all" to generate new kubelet.conf and admin.conf;

[0147] 4) Update the user directory $HOME / .kube / config to make the local kubectl accessible to the new cluster;

[0148] 5) Distribute the new certificate, kubeconfig, kubelet.conf and other files to other control nodes and worker nodes through a secure channel (WebSocket + encryption).

[0149] (2) Other control nodes and worker nodes receive and replace the local configuration file, and update their own certificates and configurations.

[0150] Step 5: Start the container runtime with Kubelet.

[0151] Once all appliance nodes in the cloud-native cluster have completed their configuration updates, the components are started sequentially and registered for automatic startup. Specifically, all control nodes start the container runtime (such as containerd) and kubelet service sequentially and register them for automatic startup. After receiving the new configuration from the master node, all worker nodes start the container runtime and kubelet, register their own information with the master node, and at this point, each node begins reporting its status to the kube-apiserver, gradually entering the "Ready" state.

[0152] Platform service hot update phase:

[0153] Step 6: Modify the ConfigMap and restart the relevant workloads.

[0154] After the master control node detects that all control nodes have been updated, it executes:

[0155] 1) Traverse all ConfigMaps under the kube-system namespace and look for fields containing old IP addresses;

[0156] 2) Replace with the new IP address;

[0157] 3) Delete the affected Pods (such as kube-proxy, coredns, etcd, etc.), and the controller will automatically rebuild them and load the new configuration.

[0158] It should be noted that for platform services affected by IP address, the new configuration will only take effect after restarting the Pod.

[0159] Node status synchronization and platform readiness confirmation phase:

[0160] Step 7: All working nodes are connected.

[0161] After the worker nodes complete the configuration update and start the kubelet, they successfully register with the master node. The master node monitors the status of all nodes and confirms that all nodes have reported "Ready". At this point, the cluster infrastructure layer has been fully restored and can bear the business load.

[0162] Step 8: If all nodes are in the Ready state, run the smoke test.

[0163] Once the intelligent computing cloud-native platform installed in the intelligent computing appliance has started, it will automatically run integration tests to verify the platform's availability. If the verification passes, the intelligent computing cloud-native platform can be considered to be usable. If any issues arise, customers can submit a support ticket to find operations and customer service support. Specifically, after the main control node Agent detects that all nodes are in a Ready state, it automatically triggers an end-to-end (e2e) smoke test; the test framework uses Ginkgo, written in Go, and is adapted to the platform's backend technology stack.

[0164] Test content may include: creating test Pods and verifying scheduling and operation; calling the open API of the intelligent computing platform to verify the availability of functions; verifying GPU resource allocation; and checking whether the network plugin is forwarding traffic normally.

[0165] Step 9: Feedback Results.

[0166] If the test passes, in an online environment, the test report will be sent to the company's pre-sales / technical support department via email. In an offline environment, customers can query the results using commands such as agent status or agent logs. If the test fails, a detailed error log will be recorded, and the customer will be guided to submit a support ticket and contact customer service for remote support.

[0167] In summary, this application pre-installs a lightweight, self-starting Agent component at the factory, which acts as a coordinator during the initial startup of the cluster. This Agent is responsible for the following operations: automatically discovering new IPs for each node; coordinating the automatic re-signing and distribution of certificates and configurations; starting the Kubernetes control plane and worker nodes; and performing end-to-end smoke tests to verify platform availability. This ensures that the intelligent computing appliance can be used immediately upon startup without human intervention, allowing customers to use it right out of the factory.

[0168] The solution in this embodiment is truly ready to use out of the box. After the intelligent computing all-in-one machine is delivered to the customer's site, the customer only needs to turn it on or perform simple configuration to complete the initialization of the cluster. Moreover, maintenance personnel do not need to travel with the customer, and do not need to be present when there are no problems, which greatly saves the company's manpower and travel costs.

[0169] Based on the same inventive concept, this embodiment also provides a device for automatically opening and using a smart computing all-in-one machine. This device is used to execute the method for automatically opening and using a smart computing all-in-one machine provided in any of the above embodiments, including:

[0170] The proxy component module is pre-installed in each node of the intelligent computing appliance and is set to start on boot, while the cloud-native cluster component is set not to start on boot.

[0171] The connection establishment module is used so that after the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery.

[0172] The IP detection module is used to detect changes in IP addresses in the current network environment. When a change in IP address is detected, a configuration update operation is performed.

[0173] The cluster management module sequentially starts the cloud-native cluster components on each node and sets the cloud-native cluster components to start on boot.

[0174] The testing and verification module is used to monitor the status of the cloud-native cluster. Once all nodes are in an available state, it automatically runs integration tests to verify the platform's availability.

[0175] The device for automatic out-of-box use of the intelligent computing all-in-one machine provided in this embodiment can realize the steps and processes of the method for automatic out-of-box use of the intelligent computing all-in-one machine provided in any of the above embodiments, and achieve the same technical effect, which will not be described in detail here.

[0176] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the above embodiments.

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

Claims

1. A method for automatically opening and using an all-in-one intelligent computing machine, characterized in that, S1, In each node of the cluster composed of intelligent computing all-in-one machines, a proxy component is pre-installed. The proxy component is set to start on boot, and the cloud-native cluster component is set not to start on boot. S2, After the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery. S3, the proxy component of the main control node detects changes in the IP address of the current network environment, and performs a configuration update operation when a change in the IP address is detected; S4, each node starts the cloud-native cluster component in sequence and sets the cloud-native cluster component to start on boot; S5, monitor the cloud-native cluster status, and when all nodes reach a usable state, automatically run integration tests to verify platform availability. In S3, the configuration update operation includes: Back up the configuration files and certificate directory of the master control node, and regenerate the certificate and configuration files based on the new IP address; The master control node distributes the certificates and configuration files required by other nodes to each other node; each other node then performs local backup and replacement operations after receiving the configuration files.

2. The method according to claim 1, characterized in that, In S2, the IP discovery method includes two modes: broadcast discovery and unicast configuration. The broadcast discovery mode is as follows: the master control node listens for broadcast messages on a specified port, other nodes send information to the broadcast address, and after receiving the broadcast information, the master control node sends its own IP address as a response message to the requester. The unicast configuration mode is as follows: the IP address of the master control node is set through a preset configuration file or command line, and other nodes directly connect to the specified master control node.

3. The method according to claim 1, characterized in that, The proxy components communicate with each other via the WebSocket protocol and employ a built-in public / private key mechanism to ensure communication security.

4. The method according to claim 1, characterized in that, The startup process of the cloud-native cluster component includes: Start the container runtime and kubelet service; Automatically start existing container workloads through the controller mechanism; Update the IP address in the ConfigMap configuration resource under the kube-system namespace and restart the corresponding Pod.

5. The method according to claim 1, characterized in that, The integration test adopts an e2e testing framework, which realizes automated testing and verification by calling the open API interface of the intelligent computing platform.

6. The method according to claim 1, characterized in that, It also includes a results feedback process: in an online environment, test results are sent to designated departments via email, and in an offline environment, a command-line query interface is provided for users to obtain test results.

7. A device for an intelligent computing all-in-one machine that is automatically ready to use out of the box, characterized in that, The device is used to perform the method for automatic out-of-the-box use of the intelligent computing all-in-one machine as described in any one of claims 1 to 6, including: The proxy component module is pre-installed in each node of the intelligent computing appliance and is set to start on boot, while the cloud-native cluster component is set not to start on boot. The connection establishment module is used so that after the intelligent computing all-in-one machine is powered on, the proxy component of the main control node starts the server, and the proxy components of other nodes connect to the server as clients through IP discovery. The IP detection module is used to detect changes in IP addresses in the current network environment. When a change in IP address is detected, a configuration update operation is performed. The cluster management module sequentially starts the cloud-native cluster components on each node and sets the cloud-native cluster components to start on boot. The testing and verification module is used to monitor the status of the cloud-native cluster. Once all nodes are in an available state, it automatically runs integration tests to verify the platform's availability. The configuration update operation includes: Back up the configuration files and certificate directory of the master control node, and regenerate the certificate and configuration files based on the new IP address; The master control node distributes the certificates and configuration files required by other nodes to each other node; each other node then performs local backup and replacement operations after receiving the configuration files.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

Images