Cluster component updating method and apparatus, electronic device, and program product

Abstract

This invention discloses a cluster component update method, apparatus, electronic device, and program product, relating to the field of cloud computing technology or other related technical fields. The method includes: executing an update task; issuing an update instruction to a node agent module deployed on a specified component node; the update task includes at least: a specified component node and a target version; downloading the binary file of the target version through the node agent module; and, if the file integrity verification passes, calling the component hot-loading adapter corresponding to the specified component node; starting a new process through the component hot-loading adapter; using the new process to update the original version to the target version, and notifying the old process to exit; and confirming the update task is complete after verifying that the component functions of the specified component node are normal. This invention solves the technical problem in related technologies where large-scale cluster component updates rely on complete node reconstruction, which is time-consuming and reduces the response capability to sudden security threats.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology or other related fields, and more specifically, to a cluster component update method and apparatus, electronic device and program product. Background Technology

[0002] With the widespread adoption of cloud computing and microservice architectures, container orchestration platforms have been widely used to build and manage large-scale distributed applications. Container orchestration platforms significantly improve application resilience and operational efficiency by automating container deployment, scaling, and management. However, in ultra-large-scale container orchestration platform clusters (such as 1000+ clusters with millions of nodes), updating core components still faces severe challenges: current mainstream update strategies often rely on complete node rebuilding. This process typically involves marking the target node as unschedulable, then evicting all running minimum scheduling units, followed by image rebuilding of the node's operating system, and finally rejoining the node to the cluster. While this strategy ensures thoroughness, updating a single node in an ultra-large-scale environment can take 30 to 60 minutes. Assuming a cluster with millions of nodes needs updating, following the update methods in related technologies, completing the entire update could take weeks or even months, severely slowing down system iteration and reducing the ability to respond to sudden security threats.

[0003] Meanwhile, during node reconstruction, the smallest scheduling unit of all nodes will be forcibly migrated, causing temporary service unavailability. For stateful services (such as databases and message queues), such interruptions may mean data unavailability and prolonged application downtime, directly impacting the service quality and user experience of enterprises, and even violating service level agreements. In scenarios with extremely high real-time requirements, such as finance and e-commerce, even a brief service interruption can cause huge economic losses.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, apparatus, electronic device, and program product for updating cluster components, at least to solve the technical problem in related technologies that large-scale cluster component updates rely on complete node reconstruction, which is time-consuming and reduces the ability to respond to sudden security threats.

[0006] To achieve the above objectives, according to one aspect of this application, a cluster component update method is provided, applied to a target platform cluster pre-deployed with containerized applications. The target platform cluster includes at least: node agent modules deployed on each component node and component hot-loading adapters. The method includes: executing an update task; issuing update instructions to the node agent modules deployed on specified component nodes; wherein the update task includes at least: a specified component node and a target version; downloading the binary file of the target version through the node agent modules; and, if file integrity verification passes, invoking the component hot-loading adapter corresponding to the specified component node; starting a new process through the component hot-loading adapter; using the new process to update the original version to the target version and notifying the old process to exit; and confirming the update task is complete after verifying that the component functions of the specified component node are normal.

[0007] Optionally, before executing the update task and issuing the update instruction to the node agent module deployed on the specified component node, the method further includes: receiving the update task using the central controller of the target platform cluster; dividing all the update tasks into batches using the intelligent batching engine of the target platform cluster, and determining the minimum risk update batch based on the batch division result; and executing the update task in the minimum risk update batch.

[0008] Optionally, the step of using the intelligent batching engine of the target platform cluster to batch all the update tasks includes: obtaining node tags of specified component nodes in each update task via command line, wherein the node tags include at least one of the following: operating system, hardware type, and geographical location; determining the component region topology of the specified component node through the geographical location in the node tags; obtaining the processor utilization ratio, memory utilization, disk utilization, and network load of the specified component node to obtain load level parameters; obtaining the node type of the specified component node; obtaining the historical operation log of the specified component node and extracting historical fault data from the historical operation log; integrating the node tags, the component region topology, the load level parameters, the node type, and the historical fault data to obtain multi-dimensional node features; and batching the update tasks based on the multi-dimensional node features of the specified component nodes in the update tasks.

[0009] Optionally, after determining the minimum risk update batch based on the batch division results, the method further includes: real-time collection of load level parameters and geographical distribution data of each specified component node within the target platform cluster; and adjustment of the number of tasks in each batch based on the load level parameters and the geographical distribution data.

[0010] Optionally, after adjusting the number of tasks in each batch based on the load level parameters and the geographical distribution data, the method further includes: triggering an end-to-end health probe operation after adjusting the number of tasks in each batch; testing the network connectivity and plugin functionality of specified component nodes in each batch; and executing a circuit breaker and rollback mechanism to restore the original version of the component functionality if the test results are abnormal.

[0011] Optionally, the steps of starting a new process through the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: starting the new process using a predefined function via hot-calling the component; controlling the process state synchronization between the new process and the old process through a shared memory region; taking over multiple key node states of the old process using the new process, wherein the key node states include at least one of the following: container group cache state, network rule state, and container runtime context state; and, upon completion of the new process takeover, confirming that the new process has successfully registered as an active instance, notifying the old process to perform an exit operation, and stopping sending heartbeats to the application server.

[0012] Optionally, the steps of starting a new process through the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: if the component node is a designated proxy node, starting a new designated proxy node process through the component hot-loading adapter; the new designated proxy node process communicating with the old process through a preset Unix domain socket to request synchronization of the original version's state dataset, wherein the state dataset includes at least one of the following: a node list, storage volume mount status, and node lifecycle event cache; if synchronization is complete, registering the new designated proxy node process as an active instance with the application server and stopping the old process from sending heartbeats to the application server; and notifying the old process to exit and releasing process resources after a predetermined interval.

[0013] According to another aspect of the present invention, a cluster component update apparatus is also provided, applied to a target platform cluster pre-deployed with containerized applications. The target platform cluster includes at least: node agent modules deployed on each component node and component hot-loading adapters, comprising: an instruction issuing unit, configured to execute an update task and issue update instructions to the node agent modules deployed on specified component nodes, wherein the update task includes at least: a specified component node and a target version; a loading adapter invocation unit, configured to download the binary file of the target version through the node agent modules, and, if the file integrity verification passes, invoke the component hot-loading adapter corresponding to the specified component node; a version update unit, configured to start a new process through the component hot-loading adapter, use the new process to update the original version to the target version, and notify the old process to exit; and a task completion unit, configured to confirm the completion of the update task if the component functions of the specified component node are verified to be normal.

[0014] Optionally, the cluster component update device further includes: a task receiving unit, used to receive update tasks using the central controller of the target platform cluster before executing update tasks and issuing update instructions to node agent modules deployed on designated component nodes; a task batching unit, used to batch all the update tasks using the intelligent batching engine of the target platform cluster, and determine the minimum risk update batch based on the batching results; and a task execution unit, used to execute the update tasks in the minimum risk update batch.

[0015] Optionally, the task batching unit includes: a node tag acquisition module, used to acquire node tags of specified component nodes in each update task via command line, wherein the node tags include at least one of the following: operating system, hardware type, and geographical location; a region topology determination module, used to determine the component region topology of the specified component node through the geographical location in the node tags; a load level acquisition module, used to acquire the processor utilization ratio, memory utilization, disk utilization, and network load of the specified component node to obtain load level parameters; and acquire the node type of the specified component node; a fault data acquisition module, used to acquire the historical operation logs of the specified component node and extract historical fault data from the historical operation logs; a node feature integration module, used to integrate the node tags, the component region topology, the load level parameters, the node type, and the historical fault data to obtain multi-dimensional node features; and a task batching module, used to batch the update tasks based on the multi-dimensional node features of the specified component nodes in the update tasks.

[0016] Optionally, the cluster component update device further includes: a load level acquisition module, used to collect load level parameters and geographical distribution data of each specified component node in the target platform cluster in real time after determining the minimum risk update batch based on the batch division results; and a batch task adjustment module, used to adjust the number of tasks in each batch based on the load level parameters and the geographical distribution data.

[0017] Optionally, the cluster component update device further includes: a probe operation triggering unit, used to trigger an end-to-end health probe operation after adjusting the number of tasks in each batch based on the load level parameters and the geographical distribution data, and after the adjustment of the number of tasks in each batch is completed; a component node network testing unit, used to test the network connectivity and plug-in functionality of specified component nodes in each batch; and a circuit breaker recovery unit, used to execute a circuit breaker and rollback mechanism to restore the original version of component functionality if the test results are abnormal.

[0018] Optionally, the version update unit includes: a function call module, used to hot-call a predetermined function through the component and start a new process using the predetermined function; a process synchronization module, used to control the process state synchronization between the new process and the old process through a shared memory area; a critical state takeover module, used to take over multiple node critical states of the old process using the new process, wherein the node critical states include at least one of the following: container group cache state, network rule state, and container runtime context state; and a first old process exit module, used to confirm that the new process has successfully registered as an active instance after the new process takeover is completed, notify the old process to perform an exit operation, and stop sending heartbeats to the application server.

[0019] Optionally, the version update unit includes: when the component node is a designated agent node, starting a new designated agent node process through the component hot-loading adapter; a state data synchronization module, used by the new designated agent node process to communicate with the old process through a preset Unix domain socket to request synchronization of the state dataset of the original version, wherein the state dataset includes at least one of the following: node list, storage volume mount status, node lifecycle event cache; a new process registration module, used by registering the new designated agent node process as an active instance with the application server through the new designated agent node process after synchronization is completed, and stopping the old process from sending heartbeats to the application server; and a second old process exit module, used to notify the old process to exit and release process resources after a predetermined interval.

[0020] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the cluster component update method of any one of the above.

[0021] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the cluster component update method of any one of the above.

[0022] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the cluster component update method described in any one of the above embodiments.

[0023] In this invention, an update task is executed by issuing an update command to a node proxy module deployed on a specified component node. The update task includes at least: a specified component node and a target version; downloading the binary file of the target version through the node proxy module; if the file integrity verification passes, invoking the component hot-reload adapter corresponding to the specified component node; starting a new process through the component hot-reload adapter; using the new process to update the original version to the target version and notifying the old process to exit; and confirming the completion of the update task after verifying that the component functions of the specified component node are normal.

[0024] Based on the aforementioned publicly available information, the new version is downloaded through the node agent module, and a new process is started through the component hot-loading adapter to complete the version update. This allows for the startup of the new version component process and the updating of core components without terminating the old process, interrupting business operations, or rebuilding nodes, thus achieving a "zero-awareness" upgrade. The update time for a single node is greatly shortened. For large-scale node clusters, a full update can be completed within hours, significantly improving the operational efficiency of large-scale clusters and enhancing the response capability to sudden security threats. This solves the technical problem in related technologies where large-scale cluster component updates rely on complete node reconstruction, which is time-consuming and reduces the response capability to sudden security threats. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0026] Figure 1A hardware structure block diagram of a computer terminal (or mobile device) for implementing a cluster component update method is shown.

[0027] Figure 2 This is a flowchart of an optional cluster component update method according to an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of an optional cluster component hot update system according to an embodiment of the present invention;

[0029] Figure 4 This is a timing diagram of an optional hot update method for cluster components according to an embodiment of the present invention;

[0030] Figure 5 This is a schematic diagram of an optional cluster component update device according to an embodiment of the present invention;

[0031] Figure 6 This is a structural block diagram of an electronic device that performs a cluster component update method according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0035] In-place hot update allows for direct updates to system components or applications without interrupting existing services. It enables seamless system upgrades while the system is running, avoiding the risks of service interruptions and data loss, and improving system availability and maintenance efficiency.

[0036] The central hot update controller coordinates the entire hot update process, including setting update strategies, intelligent allocation and control of update batches, monitoring the system health status during the update process, and making timely rollback decisions.

[0037] The Node Agent Module (NAM) runs on each worker node and is responsible for performing local hot update operations. It listens for instructions from the central hot update controller, downloads the new version of the binary file, verifies its integrity, performs the hot-swap operation, and ensures a smooth transition between the old and new processes.

[0038] The Component Hot Loader Adapter (CHLA) is a pluggable module that provides hot-reload capabilities for different components. Component-specific hot-reload adapters encapsulate the logic for hot loading and state transitions, allowing hot loading to be customized for different types of components.

[0039] The Intelligent Rolling Engine (IRE) intelligently divides update batches by analyzing characteristics such as node labels, regional topology, load level, minimum scheduling unit type, and historical failure rate, prioritizing updates to low-risk or low-load nodes to minimize the impact on the overall stability of the cluster.

[0040] Load level refers to the resource usage of a node, including the utilization of CPU, memory, disk, and network.

[0041] It should be noted that the cluster component update method and apparatus of the present invention can be used in the field of cloud computing technology to realize in-situ hot updates of large-scale multi-cluster components based on cloud computing, and can also be used in any field other than cloud computing technology to realize in-situ hot updates of large-scale multi-cluster components based on cloud computing. The application field of the cluster component update method and apparatus of the present invention is not limited.

[0042] It should be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected by this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. This process does not violate public order and good morals, and corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0043] It should be noted that in this invention, customer information is collected and analyzed, and users are provided with corresponding operation entry points to choose whether to agree to or reject the automated decision-making results; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0044] The following embodiments of the present invention can be applied to various systems / applications / devices that update cluster components. The present invention is applicable to the operation and maintenance management scenarios of large-scale cloud computing and containerized infrastructure, such as financial service scenarios using container orchestration platform clusters as container orchestration platforms, especially in scenarios with extremely high requirements for system stability, security, and continuity, such as high-frequency transactions and core banking systems. The present invention can ensure that services remain available when critical components are fixed with bugs, enhanced with features, or patched with security measures, avoiding transaction interruptions or data loss due to updates.

[0045] This invention enables the updating of core components without interrupting business operations or rebuilding nodes, achieving a "zero-awareness" upgrade and ensuring service continuity and user satisfaction. The update time for a single node is reduced to 1-3 minutes; for clusters with millions of nodes, a full update can be completed within hours, significantly improving the operational efficiency of large-scale clusters.

[0046] By introducing an intelligent batching engine, this invention can dynamically plan update batches based on the multi-dimensional characteristics of nodes (such as load, historical failure rate, etc.), effectively avoiding regional failures and minimizing the impact of updates on the overall stability of the cluster.

[0047] By employing dual-process hot switching and dynamic configuration injection, this invention supports fine-grained hot reloading capabilities, enabling component updates to be completed without restarting the service, thus reducing the impact of updates on service availability.

[0048] The present invention will now be described in detail with reference to various embodiments.

[0049] Example 1

[0050] According to an embodiment of the present invention, an embodiment of a cluster component update method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0051] The cluster component update method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a cluster component update method is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA)) is shown as 102a, 102b, ..., 102n. It also includes a memory 104 for storing data and a transmission device 106 for communication functions. In addition, it may include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0052] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0053] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the cluster component update method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned cluster component update method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 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.

[0054] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0055] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0056] To achieve the above objectives, according to one aspect of this application, a cluster component update method is provided, applied to a target platform cluster pre-deployed with containerized applications, the target platform cluster including at least: node agent modules deployed on each component node and component hot-reloading adapters.

[0057] To achieve the objective mentioned in this embodiment—namely, to enable efficient and low-risk in-situ hot updates of components in a large-scale cluster environment—the target platform cluster integrates at least two key components: a Node Agent Module (NAM) deployed on each component node and a Component Hot LoaderAdapter (CHLA). Each component node runs a Node Agent Module, which acts as the executor of hot update commands and the local resource manager. It receives update commands from the central hot update controller, downloads the new version's binary file, verifies the integrity of the update package, and triggers the hot update process for the corresponding component. It also collaborates with the Component Hot LoaderAdapter to ensure state synchronization and smooth transition between old and new processes. Through the presence of NAM, this embodiment achieves efficient issuance and localized execution of update commands, avoiding the latency and security risks that may arise from remote operations. The Component Hot LoaderAdapter is a customized hot update logic encapsulation layer for specific components (such as kubelet, kube-proxy, containerd, etc.), enabling fine-grained hot loading and state migration. When a new version of a component is detected to be available, the component hot-loading adapter is responsible for starting a new process and synchronizing critical states with the original process through kernel-level signals or Unix domain socket communication mechanisms. This provides component-level hot-update capabilities, greatly reducing the impact of updates on business operations.

[0058] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for updating cluster components is shown. Figure 2 This is a flowchart of an optional cluster component update method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps S201 to S204. The present invention will be described in detail below with reference to each implementation step.

[0059] Step S201: Execute the update task and issue the update command to the node agent module deployed on the specified component node. The update task includes at least the specified component node and the target version.

[0060] In this embodiment, upon receiving an update task request, the central controller issues an update command to the node agent module on the specific component node. The update task contains at least two important pieces of information: the component node to be updated and the target version. The node agent module facilitates the execution of update operations on the local node, including downloading the new version of the component binary file, verifying file integrity, and performing dual-process hot-switching, ensuring that the update process is both efficient and secure while maintaining business continuity.

[0061] Optionally, before executing the update task and issuing update instructions to the node agent module deployed on the specified component node, the method further includes: receiving the update task using the central controller of the target platform cluster; dividing all update tasks into batches using the intelligent batching engine of the target platform cluster, and determining the minimum risk update batch based on the batch division results; and executing the update task in the minimum risk update batch.

[0062] This embodiment first utilizes the central hot update controller of the target platform cluster to receive update tasks. The central controller not only serves as the entry point for these tasks but also parses and transmits task information to subsequent processing flows. Next, the intelligent batching engine is activated to batch all received update tasks. This batching process is based on multi-dimensional characteristics (such as node load levels, historical failure rates, and geographical distribution) to generate the lowest-risk update batches. The intelligent batching engine dynamically analyzes the cluster status, ensuring the flexibility and effectiveness of the update strategy. Through intelligent batching, this embodiment prioritizes updating low-risk or low-load nodes, thereby minimizing the impact of updates on the overall cluster stability and business continuity. After batching, the central controller executes the update tasks in the lowest-risk update batch, helping to maximize update efficiency while reducing potential negative impacts.

[0063] Optionally, the step of using the intelligent batching engine of the target platform cluster to batch all update tasks includes: obtaining the node labels of specified component nodes in each update task via command line, wherein the node labels include at least one of the following: operating system, hardware type, and geographical location; determining the component region topology of the specified component node through the geographical location in the node labels; obtaining the processor utilization ratio, memory utilization, disk utilization, and network load of the specified component node to obtain the load level parameter; obtaining the node type of the specified component node; obtaining the historical operation logs of the specified component node and extracting historical fault data from the historical operation logs; integrating the node labels, component region topology, load level parameter, node type, and historical fault data to obtain multi-dimensional node features; and batching the update tasks based on the multi-dimensional node features of the specified component nodes in the update tasks.

[0064] In this embodiment, the intelligent batching engine's operation process includes a series of detailed operations to ensure that update tasks can be reasonably and effectively decomposed into multiple batches, minimizing the update risk of each batch. First, node tags of specified component nodes in each update task can be obtained via command line. For example, tag information for each target component node can be obtained from a container orchestration platform cluster. Node tags provide key attributes about the node, including but not limited to the type of operating system used, hardware characteristics (e.g., processor model, memory size, disk type), and the geographical location information of the component node. This helps to further understand the environmental and configuration differences of the component nodes, providing a basis for subsequent decision-making. Then, based on the node's geographical location tags, the intelligent batching engine can construct a regional distribution map of the component nodes. This helps to identify the physical location relationships and network connectivity characteristics of the nodes. Especially in large distributed clusters, geographical location information is crucial for optimizing network traffic and reducing cross-regional communication latency. By integrating the component regional topology, this embodiment can more accurately assess the impact of update operations at the network layer.

[0065] Subsequently, the processor utilization, memory usage, disk usage, and network load of specified component nodes can be obtained to obtain load level parameters. By focusing on the actual operating status of component nodes, real-time usage of processors (CPU), memory (RAM), disks, and networks is collected. By monitoring the utilization levels of these key resources, this embodiment can assess the current load capacity of nodes. Furthermore, the node type indicates the main function of the node, such as whether it is a compute node, storage node, or network node. The node type affects the choice of update strategy because the impact and risk factors of hot updates on services may differ for different types of nodes. Then, by analyzing the historical operating logs of the nodes, the intelligent batching engine can identify past failure modes and frequencies. Historical failure data helps predict the sensitivity of nodes to updates, thereby avoiding selecting nodes with high failure risks as the first batch of update targets.

[0066] Furthermore, this embodiment integrates node tags, component region topology, load level parameters, node types, and historical fault data to form a comprehensive multi-dimensional feature set reflecting node characteristics. This set can cover both static attributes (such as hardware specifications and geographical location) and dynamic states (such as resource usage and operational history), providing a deep data analysis foundation for the intelligent batching engine. Finally, the intelligent batching engine uses these multi-dimensional node features to divide the data into batches, creating a series of update batches. Nodes in each batch are determined to have similar risk levels based on their features, helping to ensure that updates are performed first on lower-risk nodes and gradually rolled out to the entire cluster, thereby minimizing the potential impact of update operations on cluster stability.

[0067] Optionally, after determining the minimum risk update batch based on the batch division results, the process also includes: real-time collection of load level parameters and geographical distribution data of each specified component node within the target platform cluster; and adjustment of the number of tasks in each batch based on the load level parameters and geographical distribution data.

[0068] In this embodiment, the intelligent batching engine not only considers node characteristics during the initial batch division but also continuously collects load level parameters (such as CPU utilization, memory usage, disk space status, and network bandwidth usage) and geographical distribution data of specified component nodes within the target platform cluster in real time. This real-time monitoring helps maintain an up-to-date understanding of the cluster status, ensuring that update strategies can respond promptly to changes in node load and geographical distribution in a dynamic environment. Through continuously updated load data and geographical information, this embodiment can more intelligently adjust update strategies for subsequent batches, thereby reducing the impact of updates on business performance and network latency, and improving the efficiency and security of the overall update process.

[0069] After collecting relevant data in real time, the intelligent batching engine dynamically adjusts the number of update tasks in each batch based on load levels and geographical distribution information. The entire process fully considers the current resource usage and physical location of nodes, aiming to create more balanced and risk-controlled update batches. For example, if it is detected that the node load in a certain area is generally high, or that nodes under a specific hardware type frequently experience resource bottlenecks, this embodiment can reduce the proportion of these nodes in the current batch, or postpone their update time until the load situation improves. This adaptive adjustment strategy helps avoid update failures caused by node resource shortages or geographical location factors, ensuring a smooth update process.

[0070] Optionally, after adjusting the number of tasks in each batch based on load level parameters and geographical distribution data, the method further includes: triggering an end-to-end health probe operation after adjusting the number of tasks in each batch; testing the network connectivity and plugin functionality of specified component nodes in each batch; and executing a circuit breaker and rollback mechanism to restore the original version of component functionality if the test results are abnormal.

[0071] If any anomalies are detected during end-to-end health checks, such as decreased network connectivity, missing plugin functionality, or an abnormal increase in service response time, this embodiment immediately initiates a circuit breaker and rollback mechanism. First, it blocks the execution of subsequent update batches to prevent further spread of the anomaly. Then, this embodiment automatically restores the abnormal node to the original version of the component functionality. This process may involve restoring the node state from backups, redeploying the old version of the component, or performing other repair operations to ensure the node returns to its stable state before the update. Through the circuit breaker and rollback mechanism, this embodiment can quickly respond to update anomalies, reduce the potential impact on business continuity and user experience, and maintain the high availability and stability of the cluster.

[0072] This embodiment dynamically adjusts the number of tasks in each update batch by collecting real-time load level and geographical distribution data. Combined with end-to-end health detection and a circuit breaker rollback mechanism in case of anomalies, it forms a complete, closed-loop update process. This helps improve the intelligence level of hot updates, reduces the update risks caused by changes in node status, and ensures that the updates of core components are both efficient and secure in large-scale cluster environments.

[0073] Step S202: Download the binary file of the target version through the node proxy module. If the file integrity verification passes, call the component hot-reload adapter corresponding to the specified component node.

[0074] In the update process of this embodiment, the node agent module undertakes the critical download and verification tasks. Upon receiving an update command from the central hot update controller, the node agent module first downloads the corresponding binary file from a predetermined mirror repository or update center according to the target version specified in the command. The download process utilizes an efficient data transmission protocol, helping to reduce waiting time caused by network latency and accelerating the update process. Subsequently, the node agent module performs file integrity verification, for example, by comparing a pre-calculated hash value (such as SHA-256) with the hash value of the downloaded file to ensure that the downloaded binary file has not been tampered with or corrupted. After the file integrity verification passes, the node agent module calls the component hot-loading adapter corresponding to the specified component node to prepare for the hot update operation. The component hot-loading adapter then handles subsequent complex operations such as dual-process hot switching and state synchronization, ensuring that the update process is both smooth and efficient.

[0075] Step S203: Start a new process through the component hot-loading adapter, use the new process to update the original version to the target version, and notify the old process to exit.

[0076] After the component hot-reload adapter is invoked, the key hot-update operation in this embodiment is triggered. The component hot-reload adapter starts a new process based on the downloaded and verified target version binary file. The startup of the new process does not affect the current service operation, utilizing container technology or operating system-level process isolation features to ensure that the old and new processes can coexist on the same node for a period of time, performing necessary state transitions and functional verifications.

[0077] After a new process starts, the component hot-reload adapter executes a series of fine-grained hot-update mechanisms to smoothly migrate the component state from the original version to the new version. This process may involve technologies such as shared memory utilization, Unix domain socket communication, and state file synchronization. Once the state migration is complete, the new process begins handling all business requests, while the component hot-reload adapter notifies the old process to enter a graceful exit process, avoiding service interruptions and ensuring business continuity. Upon receiving the exit notification, the old process performs a series of cleanup operations, such as releasing system resources, clearing temporary files, and unregistering with the API Server, ensuring clean node resources and consistent cluster state. The entire exit process is graceful, meaning the old process waits until all processed requests are completed before exiting, avoiding data inconsistencies or service unavailability caused by sudden process termination.

[0078] Optionally, the steps of starting a new process via the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: starting the new process using a predefined function via component hot-calling; controlling the process state synchronization between the new process and the old process via a shared memory region; taking over multiple key node states of the old process using the new process, wherein the key node states include at least one of the following: container group cache state, network rule state, and container runtime context state; and, upon completion of the new process takeover, confirming that the new process has successfully registered as an active instance, notifying the old process to perform an exit operation, and stopping sending heartbeats to the application server.

[0079] In this embodiment, after the node agent module completes the download and verification of the target version binary file, it will take the next step: starting a new process by calling a pre-defined component hot-loading adapter. The call process can use predefined functions or interfaces. The component hot-loading adapter starts a new process that runs in parallel with the original version based on the latest binary file. This parallel startup mechanism helps ensure a seamless transition between old and new versions during the switchover, guaranteeing uninterrupted service continuity.

[0080] It should be noted that, to ensure a smooth transition between the old and new processes, this embodiment employs a shared memory region technique. After the new process starts, the component hot-loading adapter can establish a shared memory region to control and manage the state synchronization process between the old and new processes. The shared memory region acts as a bridge for bidirectional communication, enabling the new process to read the critical state of the old process, while also allowing the old process to monitor the initialization progress of the new process.

[0081] The new process not only synchronizes its state with the old process upon startup but also gradually takes over the critical states of the old process. These critical states cover multiple aspects, including container group cache state, network rule state, and container runtime context state. The container group cache state encompasses various cached information maintained during component operation, such as the minimum scheduling unit cache. By reading cached information in the shared memory area, the new process can quickly restore itself to the same running state as the old process, avoiding service delays or data loss due to state resets. Network rule state: For network components, the new process needs to take over the network rule settings of the old process, including various firewall rules, routing table entries, load balancing configurations, etc., helping to ensure that the new process can immediately take over the network responsibilities of the old process without causing any network service interruption. Container runtime context state: For the container runtime environment, the new process must inherit the container runtime context of the old process, including the list of running containers, the container lifecycle management state, and any necessary information for interacting with containers. In this way, the new process can seamlessly take over the operation and management of containers, maintaining the continuity of container services.

[0082] Once the new process has taken over the aforementioned critical states and completed the necessary initialization and verification processes, this embodiment will confirm that the new process has successfully registered as an active instance, indicating to the application server (such as the API Server) in the cluster that it has the ability to handle business requests. At this point, the new process officially assumes the main responsibility for running the component, while the old process begins to perform an exit operation. The exit operation includes cleaning up process resources, releasing system handles, and deregistering the active instance status. Finally, the old process will stop sending heartbeat messages to the application server, indicating that it is no longer running. This graceful exit process helps ensure the effective reclamation of system resources and avoids potential service interference caused by the remnants of the old process.

[0083] This embodiment's hot update process starts a new process through a component hot-loading adapter and utilizes the new process to take over the critical state of the old process, facilitating seamless component version upgrades. The entire process includes not only efficient binary file download and verification, but also fine-grained state synchronization and takeover between the new and old processes, as well as the graceful exit of the old process. This helps maintain service continuity, improves update efficiency, and reduces the risks to business operations during the update process.

[0084] Optionally, the steps of starting a new process through the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: if the component node is a designated proxy node, starting a new designated proxy node process through the component hot-loading adapter; the new designated proxy node process communicating with the old process through a preset Unix domain socket to request synchronization of the original version's state dataset, wherein the state dataset includes at least one of the following: node list, storage volume mount status, node lifecycle event cache; if synchronization is complete, registering the new designated proxy node process as an active instance with the application server and stopping the old process from sending heartbeats to the application server; and after a predetermined interval, notifying the old process to exit and releasing process resources.

[0085] This embodiment provides a hot update operation for a specified proxy node. Upon receiving an update command, the node proxy module calls a hot-loading adapter that matches the specified proxy node component to start the new version of the specified proxy node process. This process starts based on the target version of the binary file. The new specified proxy node process runs in parallel with the old process in the initialization state, but has not yet undertaken any actual workload or responded to external services.

[0086] It's important to note that the newly started designated agent node process establishes a communication channel with the old process through a pre-defined Unix domain socket, ensuring the security and efficiency of inter-process communication. The new process can send requests to the old process through this communication channel to synchronize the critical state dataset maintained by the old version of kubelet. This state dataset can contain various key information about the node's runtime, such as the node inventory (i.e., metadata and status of all the smallest scheduling units on the node), the mount status of storage volumes (recording how containers access persistent storage resources), and a cache of node lifecycle events (saving records of all important events occurring on the node). This helps the new process quickly reach a working state consistent with the old process, avoiding service interruptions and data inconsistencies.

[0087] Once the state dataset synchronization is complete, the newly designated agent node process will initiate a registration request to the application server, declaring itself an active node agent instance and ready to take over the responsibilities of node management. Simultaneously, the old process will stop sending heartbeat messages to the application server; essentially, the old process is announcing its retirement to the system, signifying the imminent completion of the role transition between the old and new processes. Stopping heartbeat message sending helps the application server update cluster state information promptly, avoiding resource allocation conflicts or state update delays caused by the presence of the old process. Finally, this embodiment sets a predetermined period to observe the stability and reliability of the newly designated agent node process. After this monitoring period, if the new process performs normally without any abnormalities, the node agent module will notify the old designated agent node process to perform an exit operation. Upon receiving the exit instruction, the old process will perform a cleanup and resource release process, including releasing system resources (such as file handles and network ports) and cleaning up temporary files, ensuring that system resources are effectively reclaimed and no zombie processes or residual files occupy space.

[0088] Step S204: After verifying that the component functions of the specified component node are normal, confirm that the update task is completed.

[0089] In this embodiment, after the switchover and state synchronization of the old and new processes are completed, the verification phase begins. The purpose is to ensure that all functions of the specified component nodes operate normally after being updated to the target version, meeting the expected service quality and performance indicators. The verification process includes not only testing the basic functions of the components, such as checking whether they can start normally, respond to and execute common management commands, but also end-to-end service health checks to ensure that the components can be seamlessly integrated into the entire target platform cluster under the new version, with no service interruption and no significant performance degradation. Once the component functionality verification process is successfully completed, and all test results indicate that the new version of the components can run stably and efficiently, this embodiment will confirm the completion of the update task. Specifically, based on the global monitoring and management of the central hot update controller, not only is the update of a single node verified as successful, but the update status of the entire update batch and even the entire cluster is also assessed as safe and stable. The central controller marks the update status as complete and records relevant data, such as update time, version information, and test results, providing a basis for subsequent operation and maintenance analysis and troubleshooting.

[0090] During the verification process, this embodiment can employ various testing methods and monitoring metrics. For example, for a specific node proxy component, it may be necessary to check whether the creation and deletion operations of the smallest scheduling unit are smooth, whether the container lifecycle management meets expectations, and whether communication with the API Server is stable. Furthermore, this embodiment may include a feedback loop, i.e., after confirming the completion of the update task, continuing to monitor the component's operational status for a period of time to capture potential delays or indirect problems. This helps strengthen confidence in the stability of the updated component and also provides data support for future update strategy optimization.

[0091] Through the above steps, an update task can be executed, issuing update instructions to the node agent module deployed on the specified component node. The update task includes at least: the specified component node, the target version; downloading the binary file of the target version through the node agent module; and, if the file integrity verification passes, invoking the component hot-loading adapter corresponding to the specified component node; starting a new process through the component hot-loading adapter; updating the original version to the target version using the new process; and notifying the old process to exit; confirming the update task is complete after verifying that the component functions of the specified component node are normal. In this embodiment, downloading the new version through the node agent module and starting a new process through the component hot-loading adapter to complete the version update enables the startup of the new version component process and the updating of core components without terminating the old process, interrupting business operations, or rebuilding the node. This achieves a "zero-awareness" upgrade, significantly shortening the update time for a single node. For large-scale node clusters, a full update can be completed within hours, greatly improving the operational efficiency of large-scale clusters and enhancing the response capability to sudden security threats. This solves the technical problem in related technologies where large-scale cluster component updates rely on complete node reconstruction, which is time-consuming and reduces the response capability to sudden security threats.

[0092] The following describes in detail another optional implementation method.

[0093] This invention provides an in-situ hot update system and method for ultra-large-scale multi-container orchestration platform cluster components, solving problems such as low update efficiency, high service interruption, and significant impact from restarts in related technologies. It achieves "zero-awareness," "zero-downtime," and "high-concurrency" hot update capabilities for core components. Without terminating the old process, the new version of the component process is started, and a smooth handover of state and connections is completed through kernel-level signals or Unix domain sockets, followed by a graceful exit from the old process. The entire process requires no service restart, no eviction of the smallest scheduling unit, and no node reconstruction.

[0094] Figure 3 This is a schematic diagram of an optional cluster component hot update system according to an embodiment of the present invention, such as... Figure 3As shown, the system includes: a health verification and circuit breaker module, a central hot update controller (HotUpdate Controller, which can be referred to as the central controller), an intelligent rolling engine, a node agent module (NodeAgent, which is deployed on each component node), and a component hot loading adapter (HotLoader Adapter).

[0095] The central hot update controller is the core control unit of the entire hot update process. It coordinates global policy formulation, issues update commands, and monitors update status. Deployed on the management plane, it is responsible for global update policy formulation, batch scheduling, health checks, and rollback decisions. Implementation: Built on a container orchestration platform, it utilizes its provided application programming interface (API) to manage cluster resources. It listens for specific events (such as the release of a new image version) and triggers the update process. It integrates a health check mechanism to monitor service status in real time and decide whether to continue updating or rollback based on feedback.

[0096] The node agent module runs on each worker node, listening for update commands and performing operations such as local binary replacement, hot-swapping between two processes, and state synchronization. It can be developed as a lightweight daemon process, deployed on each node in the cluster, periodically communicating with the central controller to obtain the latest commands. It is responsible for the actual low-level operations such as file transfer, process start / stop, etc., and supports plug-in extensions to adapt to different types of components and services.

[0097] Among them, the component hot reload adapter is a hot reload plugin customized for various cluster components, which encapsulates their lifecycle management and state transition logic.

[0098] Implementation method: Design an interface specification that allows different components to access the hot update framework by implementing the interface, using languages ​​such as Python to create migration commands.

[0099] Taking hot reloading of a specified agent node kubelet as an example: After the Node Agent detects the new version of the specified agent node binary, it writes it to / opt / kube / bin / kubelet.v2; it calls the HotLoader Adapter to start the new specified agent node process, passing the --hot-swap-mode parameter; the new specified agent node communicates with the old process through / var / run / kubelet.sock to request synchronization of the minimum scheduling unit list, volume mount status, PLEG event cache, etc.; after synchronization is completed, the new specified agent node registers itself as an active instance with the application server API Server, and the old specified agent node stops sending heartbeats to the API Server; after 5 minutes, the old specified agent node automatically exits and releases resources.

[0100] The intelligent batching engine dynamically generates minimum-risk update batches based on multi-dimensional features such as node tags, regional topology, load level, minimum scheduling unit type (stateful / stateless), and historical failure rate. It analyzes factors such as the load and geographical distribution of each node in the cluster to determine the optimal update order and scale, dynamically adjusting the quantity of each batch to avoid affecting too many nodes simultaneously and causing a decline in service quality.

[0101] Among them, the health verification and circuit breaker module automatically triggers end-to-end health checks (such as minimum scheduling unit creation, network connectivity, and plug-in functionality) after each batch of updates. If an abnormality is found, the circuit breaker is immediately triggered and the system is rolled back.

[0102] Figure 4 This is a timing diagram of an optional hot update method for cluster components according to an embodiment of the present invention, such as... Figure 4 As shown, the hot update method may include the following steps:

[0103] Step 1. The central controller receives the update task (specifying the component, target version, and canary release strategy).

[0104] Step 2. The intelligent batching engine divides the update batches according to the real-time status of the cluster, prioritizing the update of low-risk nodes;

[0105] Step 3. Send the overheat update command for the target node to the Node Agent module;

[0106] Step 4. The Node Agent module downloads the new version binary, verifies its integrity, and calls the corresponding component's hotload adapter (HotLoader Adapter).

[0107] Step 5. The HotLoader Adapter starts a new process and takes over critical state (such as minimum scheduling unit cache, network rules, container runtime context) from the old process via shared memory or UnixSocket.

[0108] The old component process returns a list of minimum scheduling units, network rules, container runtime context, etc. to the new component process.

[0109] Step 6. Once the new process is ready, notify the old process to enter the graceful exit process. During this process, the new process handles all new requests. At the same time, the new component process registers itself as an active instance with the API Server and begins to process new requests. The old component process stops sending heartbeats and exits the relevant process.

[0110] Furthermore, the new component process will notify the node agent module that the switch has been completed, and then the node agent module will report a message of successful update to the central controller.

[0111] Step 7. After the central controller verifies that the node component is functioning normally, it marks the update as successful and proceeds to the next batch;

[0112] Step 8. If any node fails to update or has an abnormal health check, automatically trigger a rollback: restore the old version binary and restart the old process (or restore from a backup snapshot).

[0113] In this embodiment of the invention, the in-situ hot update mechanism eliminates the need to rebuild nodes or migrate the smallest scheduling unit, significantly reducing the update time of a single node from the original 30-60 minutes to 1-3 minutes. This enables full updates in ultra-large-scale clusters (such as those with millions of nodes) to be completed within hours, rather than weeks. This not only greatly improves update efficiency but also reduces system maintenance costs associated with updates, enhancing the iteration capabilities and response speed of large-scale clusters.

[0114] Since the hot update mechanism of this invention supports smooth upgrades of components during operation without restarting services or interrupting business, for stateful services, it means that during the update process, services such as databases and message queues can continue to provide services to the outside world, avoiding business interruption caused by updates, maintaining high availability and continuity of services, and improving user experience.

[0115] Through an AI-driven intelligent batching engine, this invention can dynamically adjust the nodes and number of updates in a batch. Based on multi-dimensional features such as real-time load levels, geographical distribution, and minimum scheduling unit type, it prioritizes updating low-risk nodes, effectively avoiding regional failures or service degradation caused by improper update strategies. Simultaneously, the dual-process hot-switching mechanism of this invention, combined with dynamic configuration injection and smooth state switching, ensures seamless integration between the old and new processes during the update process. The new process can quickly take over the critical states of the old process, such as node caches, network rules, and container runtime context, achieving service continuity and immediate availability of component functions, avoiding temporary service unavailability caused by component restarts.

[0116] After the update, this embodiment of the invention automatically triggers end-to-end health detection to test network connectivity, plugin functionality, etc. Once an anomaly is detected, it can immediately execute the circuit breaker and rollback mechanism to quickly restore the stable state before the update. This helps to identify and deal with the negative effects that the update may bring as soon as possible, ensure the stable operation of the cluster, and reduce the scope and time of fault propagation.

[0117] The following is a detailed description with reference to another embodiment.

[0118] Example 2

[0119] The cluster component update device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above. The specific implementation method and beneficial effects can be referred to the aforementioned method embodiment, and will not be repeated here.

[0120] According to another aspect of the present invention, a cluster component update apparatus is also provided, which is applied to a target platform cluster in which containerized applications are pre-deployed. The target platform cluster includes at least: node agent modules deployed on each component node and component hot-loading adapters.

[0121] Figure 5 This is a schematic diagram of an optional cluster component update device according to an embodiment of the present invention, such as... Figure 5 As shown, the cluster component update device may include: an instruction issuing unit 51, an adapter loading and calling unit 52, a version update unit 53, and a task completion unit 54.

[0122] The instruction issuing unit 51 is used to execute the update task and issue update instructions to the node agent module deployed on the specified component node. The update task includes at least the specified component node and the target version.

[0123] The load adapter call unit 52 is used to download the binary file of the target version through the node proxy module. If the file integrity verification passes, it calls the component hot-load adapter corresponding to the specified component node.

[0124] Version update unit 53 is used to start a new process through the component hot-loading adapter, use the new process to update the original version to the target version, and notify the old process to exit.

[0125] Task completion unit 54 is used to confirm the completion of the update task after verifying that the component functions of the specified component node are normal.

[0126] The aforementioned cluster component update device can execute update tasks through instruction issuing unit 51, issuing update instructions to the node agent module deployed on the specified component node. The update task includes at least: the specified component node, the target version, and downloading the binary file of the target version through the node agent module via the loading adapter calling unit 52. If the file integrity verification is passed, the component hot-loading adapter corresponding to the specified component node is called. A new process is started through the component hot-loading adapter via the version update unit 53, and the new process is used to update the original version to the target version. The old process is notified to exit. The task completion unit 54 confirms that the update task is completed after verifying that the component function of the specified component node is normal. In this embodiment, the new version is downloaded through the node agent module, and a new process is started through the component hot-loading adapter to complete the version update. This allows the new version component process to be started and the core components to be updated without terminating the old process, interrupting business, or rebuilding the node, thus achieving a "zero-aware" upgrade. The update time for a single node is greatly shortened. For a large-scale cluster of nodes, a full update can be completed within a few hours, which greatly improves the operation and maintenance efficiency of large-scale clusters and enhances the response capability to sudden security threats. This solves the technical problem in related technologies where large-scale cluster component updates rely on the complete rebuilding of nodes, which is time-consuming and reduces the response capability to sudden security threats.

[0127] Optionally, the cluster component update device further includes: a task receiving unit, used to receive update tasks using the central controller of the target platform cluster before executing update tasks and issuing update instructions to the node agent modules deployed on the specified component nodes; a task batching unit, used to divide all update tasks into batches using the intelligent batching engine of the target platform cluster, and determine the minimum risk update batch based on the batching results; and a task execution unit, used to execute update tasks in the minimum risk update batch.

[0128] Optionally, the task batching unit includes: a node label acquisition module, used to acquire node labels of specified component nodes in each update task via command line, wherein the node labels include at least one of the following: operating system, hardware type, and geographical location; a region topology determination module, used to determine the component region topology of the specified component node through the geographical location in the node labels; a load water level acquisition module, used to acquire the processor utilization ratio, memory utilization, disk utilization, and network load of the specified component node to obtain load water level parameters; acquire the node type of the specified component node; a fault data acquisition module, used to acquire the historical operation logs of the specified component node and extract historical fault data from the historical operation logs; a node feature integration module, used to integrate node labels, component region topology, load water level parameters, node types, and historical fault data to obtain multi-dimensional node features; and a task batching module, used to batch the update tasks based on the multi-dimensional node features of the specified component nodes in the update tasks.

[0129] Optionally, the cluster component update device further includes: a load level acquisition module, used to collect load level parameters and geographical distribution data of each specified component node in the target platform cluster in real time after determining the minimum risk update batch based on the batch division results; and a batch task adjustment module, used to adjust the number of tasks in each batch based on the load level parameters and geographical distribution data.

[0130] Optionally, the cluster component update device further includes: a probe operation triggering unit, used to trigger an end-to-end health probe operation after adjusting the number of tasks in each batch based on load level parameters and geographical distribution data, and after the adjustment of the number of tasks in each batch is completed; a component node network testing unit, used to test the network connectivity and plugin functionality of specified component nodes in each batch; and a circuit breaker recovery unit, used to execute a circuit breaker and rollback mechanism to restore the original version of component functionality if the test results are abnormal.

[0131] Optionally, the version update unit includes: a function call module for launching a new process by hot-calling a predefined function through a component; a process synchronization module for controlling the process state synchronization between the new process and the old process through a shared memory area; a critical state takeover module for taking over multiple critical states of the old process using the new process, wherein the critical states of the nodes include at least one of the following: container group cache state, network rule state, and container runtime context state; and a first old process exit module for confirming that the new process has successfully registered as an active instance, notifying the old process to perform an exit operation, and stopping sending heartbeats to the application server after the new process has taken over.

[0132] Optionally, the version update unit includes: when the component node is a designated agent node, starting a new designated agent node process through a component hot-loading adapter; a state data synchronization module, used by the new designated agent node process to communicate with the old process through a preset Unix domain socket to request synchronization of the original version's state dataset, wherein the state dataset includes at least one of the following: a node list, storage volume mount status, and node lifecycle event cache; a new process registration module, used by registering the new designated agent node process as an active instance with the application server through the new designated agent node process after synchronization is completed, and stopping the old process from sending heartbeats to the application server; and a second old process exit module, used to notify the old process to exit and release process resources after a predetermined interval.

[0133] The aforementioned cluster component update device may also include a processor and a memory. The instruction issuing unit 51, the loading adapter calling unit 52, the version update unit 53, the task completion unit 54, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0134] The processors described above contain a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and in-situ hot updates for large-scale application clusters can be achieved by adjusting kernel parameters.

[0135] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0136] Example 3

[0137] Embodiments of this application may provide an electronic device. Figure 6 This is a structural block diagram of an electronic device that performs a cluster component update method according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) Processor 602, memory 604, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0138] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the cluster component update method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned cluster component update method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal 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.

[0139] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Execute an update task by issuing an update command to the node agent module deployed on the specified component node. The update task includes at least the specified component node and the target version. Download the binary file of the target version through the node agent module. If the file integrity verification passes, call the component hot-load adapter corresponding to the specified component node. Start a new process through the component hot-load adapter, use the new process to update the original version to the target version, and notify the old process to exit. Confirm that the update task is complete after verifying that the component functions of the specified component node are normal.

[0140] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0141] Those skilled in the art will understand that all or part of the steps in the various cluster component update methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0142] Example 4

[0143] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the cluster component update method provided in Embodiment 1.

[0144] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute the cluster component update method of any one of the above embodiments.

[0145] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0146] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the cluster component update method described in various embodiments of this application.

[0147] This application also provides a computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the cluster component update method described in various embodiments of this application.

[0148] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0149] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0152] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0153] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0154] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for updating cluster components, characterized in that, A target platform cluster for pre-deploying containerized applications, the target platform cluster comprising at least: node proxy modules deployed on each component node and component hot-reloading adapters, including: Execute an update task and issue an update command to the node agent module deployed on the specified component node. The update task includes at least: the specified component node and the target version. The target version's binary file is downloaded through the node proxy module. If the file integrity verification passes, the component hot-reload adapter corresponding to the specified component node is invoked. A new process is started through the component hot-load adapter, the new process is used to update the original version to the target version, and the old process is notified to exit. If the component functions of the specified component node are verified to be normal, the update task is confirmed to be complete.

2. The cluster component update method according to claim 1, characterized in that, Before executing the update task and issuing update commands to the node agent modules deployed on the specified component nodes, the process also includes: The update task is received using the central controller of the target platform cluster; The intelligent batching engine of the target platform cluster is used to divide all the update tasks into batches, and the minimum risk update batch is determined based on the batch division results. Execute the update tasks in the minimum risk update batch.

3. The cluster component update method according to claim 2, characterized in that, The step of using the intelligent batching engine of the target platform cluster to divide all the update tasks into batches includes: Obtain the node tags of specified component nodes in each update task via command line, wherein the node tags include at least one of the following: operating system, hardware type, and geographical location; The component region topology of the specified component node is determined by the geographical location in the node label; Obtain the processor utilization ratio, memory utilization, disk utilization, and network load of the specified component node to obtain the load level parameters; Obtain the node type of the specified component node; Obtain the historical operation log of the specified component node, and extract historical fault data from the historical operation log; By integrating the node labels, component region topology, load level parameters, node types, and historical fault data, multidimensional node features are obtained. The update task is divided into batches based on the multi-dimensional node features of the specified component nodes in the update task.

4. The cluster component update method according to claim 2, characterized in that, After determining the minimum risk update batch based on the batch segmentation results, the following is also included: Real-time collection of load level parameters and geographical distribution data of each specified component node within the target platform cluster; The number of tasks in each batch is adjusted based on the load level parameters and the geographical distribution data.

5. The cluster component update method according to claim 4, characterized in that, After adjusting the number of tasks in each batch based on the load level parameters and the geographical distribution data, the process also includes: Trigger an end-to-end health detection operation when the number of tasks in each batch is adjusted. Test the network connectivity and plugin functionality of specified component nodes in each batch; If the test results are abnormal, the circuit breaker and rollback mechanism will be executed to restore the original version of the component functionality.

6. The cluster component update method according to claim 1, characterized in that, The steps of starting a new process via the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: The component hot-calls a predefined function, and the predefined function is used to start a new process. By using a shared memory region, the process state synchronization between the new process and the old process is controlled; The new process takes over multiple key node states of the old process, wherein the key node states include at least one of the following: container group cache state, network rule state, and container runtime context state. Once the new process has completed its takeover, it is confirmed that the new process has been successfully registered as an active instance. The old process is then notified to exit and stop sending heartbeats to the application server.

7. The cluster component update method according to claim 1, characterized in that, The steps of starting a new process via the component hot-loading adapter, updating the original version to the target version using the new process, and notifying the old process to exit include: When the component node is a designated proxy node, the process of the new designated proxy node is started through the component hot-reload adapter; The newly designated agent node process communicates with the old process through a preset Unix domain socket to request the synchronization of the original version's state dataset, wherein the state dataset includes at least one of the following: node list, storage volume mount status, and node lifecycle event cache; Once synchronization is complete, the newly designated proxy node process is registered as an active instance with the application server, and the old process stops sending heartbeats to the application server. After a predetermined interval, the old process is notified to exit and its resources are released.

8. A cluster component update device, characterized in that, A target platform cluster for pre-deploying containerized applications, the target platform cluster comprising at least: node proxy modules deployed on each component node and component hot-reloading adapters, including: The instruction issuing unit is used to execute update tasks and issue update instructions to the node agent modules deployed on the specified component nodes. The update task includes at least: the specified component node and the target version. The load adapter call unit is used to download the binary file of the target version through the node proxy module, and call the component hot-load adapter corresponding to the specified component node if the file integrity verification passes. The version update unit is used to start a new process through the component hot-loading adapter, use the new process to update the original version to the target version, and notify the old process to exit. The task completion unit is used to confirm the completion of the update task after verifying that the component functions of the specified component node are normal.

9. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the cluster component update method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the cluster component update method according to any one of claims 1 to 7.

Images