Method and device for updating nodes in container application platform, processor and storage medium

Abstract

The invention discloses a method and a device for updating nodes in a container application platform, a processor and a storage medium. The method comprises the following steps: determining an update state of at least one node in a container application platform; determining a to-be-updated node in the at least one node based on the updating state; calling a resource portrait interface, and determining a to-be-run node corresponding to the to-be-updated node in the container application platform; migrating a to-be-migrated container in the to-be-updated node to a corresponding to-be-operated node for operation; and in response to successful migration of the to-be-migrated container to the to-be-operated node, updating the to-be-updated node. The technical problem of low node updating efficiency is solved.

Description

Technical Field

[0001] The present application relates to the field of cluster management, and in particular to a method, device, processor and storage medium for updating nodes in a container application platform. Background Art

[0002] Currently, container application platform clusters usually consist of many nodes, which sometimes need to be shut down for maintenance.

[0003] In the related art, the common maintenance method is to use related commands (for example, the "kubectl drain" command) to complete the update of the above nodes. This method needs to first confirm the node to be evicted, and use the above command to evict the pod running on the node. However, the above method can only perform node eviction for a single node and a single task, and cannot perform eviction for multiple tasks and multiple nodes, which has the technical problem of low node update efficiency.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present application provide a method, device, processor, and storage medium for updating nodes in a container application platform, so as to at least solve the technical problem of low node update efficiency.

[0006] According to one aspect of an embodiment of the present application, a method for updating nodes in a container application platform is provided, and the method may include: determining an update status of at least one node in the container application platform; determining a node to be updated in at least one node based on the update status; calling a resource portrait interface to determine a node to be run in the container application platform corresponding to the node to be updated; migrating a container to be migrated in the node to be updated to the corresponding node to be run for execution; and updating the node to be updated in response to the successful migration of the container to be migrated to the node to be run.

[0007] Optionally, calling a resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated includes: calling a resource portrait interface to determine the node running data of at least one node; determining the resource usage data of at least one node based on the node running data; and determining the node to be run based on the resource usage data.

[0008] Optionally, migrating the containers to be migrated in the node to be updated to the corresponding node to be run for running includes: classifying at least one container to be migrated to obtain at least one container group, wherein the controllers of the containers to be migrated in the same container group are of the same type; serially migrating the containers to be migrated in the same container group to the node to be run, and migrating the containers to be migrated in different container groups to the node to be run in parallel.

[0009] Optionally, the method may further include: determining state information of a controller of the container to be migrated; and determining a migration state of at least one container to be migrated under the controller based on the state information.

[0010] Optionally, the method may further include: in response to a node in the container application platform being a node to be updated, marking the node to be updated.

[0011] According to another aspect of an embodiment of the present application, a device for updating nodes in a container application platform is also provided, and the device may include: an acquisition unit, used to determine the update status of at least one node in the container application platform; a first determination unit, used to determine the node to be updated in at least one of the shown nodes based on the update status; a second determination unit, used to call a resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; a migration unit, used to migrate the container to be migrated in the node to be updated to the corresponding node to be run for operation; and an update unit, used to update the node to be updated in response to the successful migration of the container to be migrated to the node to be run.

[0012] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, which includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the node update method in the container application platform of the embodiment of the present application.

[0013] According to another aspect of an embodiment of the present application, a processor is further provided, the processor being used to run a program, wherein when the program is run by the processor, the method for updating a node in a container application platform of an embodiment of the present application is executed.

[0014] According to another aspect of an embodiment of the present application, a computer program product is further provided. The computer program product includes computer instructions, wherein when the computer instructions are executed by a processor, the method for updating a node in a container application platform of an embodiment of the present application is implemented.

[0015] In an embodiment of the present application, the update status of at least one node in the container application platform is determined; based on the update status, the node to be updated in at least one node is determined; the resource portrait interface is called to determine the node to be run in the container application platform corresponding to the node to be updated; the container to be migrated in the node to be updated is migrated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, the node to be updated is updated. That is to say, in an embodiment of the present application, the update status of at least one node is determined, and based on the update status, the node to be updated is determined from at least one node, and the resource portrait interface is called to determine the node to be run in the container update platform corresponding to the node to be updated. The node to be run can be used to process the container to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving node update efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 is a flowchart of a method for updating a node in a container application platform according to an embodiment of the present application;

[0018] Figure 2 It is a flowchart of a large model-driven Kubernetes security node expulsion method according to an embodiment of the present application;

[0019] Figure 3 is a schematic diagram of a node updating device in a container application platform according to an embodiment of the present application;

[0020] Figure 4 is a structural block diagram of a computer terminal according to an embodiment of the present application;

[0021] Figure 5 It is a block diagram of an electronic device of a method for updating a node in a container application platform according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0024] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following explanations:

[0025] The open source container orchestration platform (Kubernetes, K8S for short) can be used as a platform for automating the deployment, expansion and management of applications. It can be used to manage containerized applications and supports functions such as load balancing, service discovery, automatic expansion and self-healing. It can be used to enable development and operation teams to manage applications in multiple environments more easily.

[0026] Pod is the most basic deployment unit in the open source container orchestration platform. It can be used to represent a collection of one or more closely related containers. The collection can share the network, storage, and namespace, and can usually be used to run a single application instance.

[0027] Custom Resource Definition (CRD) can be used to extend the Kubernetes communication interface (API). Through CRD, users can define their own resource types so that they can work in parallel with Kubernetes native resources (such as Pod, Service, etc.);

[0028] Controllers, CRDs are usually used in conjunction with controllers to monitor the status of custom resources and perform corresponding operations to ensure that they meet the expected status.

[0029] According to an embodiment of the present application, an embodiment of a method for updating a node in a container application platform is provided. The steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0030] In this embodiment, a method for updating nodes in a container application platform is proposed. The method can determine the update status of at least one node, and based on the update status, determine the node to be updated from at least one node, call the resource portrait interface, and determine the node to be run in the container update platform corresponding to the node to be updated. The node to be run can be used to process the containers to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving the node update efficiency.

[0031] Figure 1 FIG. 1 is a flow chart of a method for updating a node in a container application platform according to an embodiment of the present application. Figure 1 As shown, the method may include the following steps:

[0032] Step S101, determining the update status of at least one node in the container application platform;

[0033] Step S102, determining a node to be updated in at least one node based on the update status;

[0034] Step S103, calling the resource portrait interface to determine the node to be run corresponding to the node to be updated in the container application platform;

[0035] Step S104, migrating the container to be migrated in the node to be updated to the corresponding node to be run for execution;

[0036] Step S105: in response to the container to be migrated being successfully migrated to the node to be run, updating the node to be updated.

[0037] In this embodiment, the container application platform can be a K8S cluster, which can include at least one worker node. The node can be a worker node, which can be used to run a container (pod). The update status can be used to determine whether the node needs to be updated, whether the node has been updated, the update status of the node, the progress of the expulsion of the container in the node, etc. It can be status information. It should be noted that this is only an example, and there is no specific restriction on the content of the update status. The node to be updated can be a working node that needs to be upgraded or has a fault and needs maintenance. It should be noted that this is only an example, and there is no specific restriction on the update reason of the node to be updated. The resource portrait interface can be used to determine the usage of resources in the container application platform to determine the node to be run that can run the container in the node to be updated. It can be a set resource portrait service, which can be used to provide an application program interface (for example, a REST API interface), which can be used to predict node resources, obtain scheduling suggestions, and can be used to evaluate the impact of the expulsion operation on the distribution of cluster resources.

[0038] Optionally, based on the resource profiling results, feasibility analysis can be provided for the eviction decision. For example, based on the resource profiling results, the remaining resources of the target node can be calculated, resource usage trends can be predicted, and the impact of resource fragmentation can be considered. Constraints can also be verified: node affinity rules can be checked, virtual path / virtual channel (PV / PVC) availability can be verified, and network policy compatibility can be evaluated.

[0039] Optionally, the container to be migrated may be a container running in the node to be updated.

[0040] Optionally, in a Kubernetes environment, a container group (Pod) runs on the node to be updated. A Pod can be the smallest deployable unit in Kubernetes and can contain one or more containers. When an application is deployed in a Kubernetes cluster, the application's containers are packaged into Pods. These Pods are then scheduled to run on the worker nodes in the cluster. The Kubernetes scheduler decides which worker node to schedule the Pod to based on a series of policies and constraints (such as resource requests, node affinity and anti-affinity, label selectors, etc.). The scheduler tries to evenly distribute the Pods to different worker nodes while meeting all constraints to achieve efficient resource utilization and load balancing.

[0041] Optionally, each worker node has certain computing resources (e.g., CPU, memory, storage, and network resources). After being scheduled to a worker node, a Pod occupies a portion of the node's resources. When a Pod runs, it uses the resources on the node to execute the application in its container. Therefore, when a worker node needs to be maintained or a node fails, Kubernetes needs to safely evict the Pods on the node so that they can be rescheduled on other nodes. For example, the `kubectl drain` command can be used to evict Pods on a node, but it is necessary to ensure that these Pods can be successfully rescheduled to other nodes to avoid service interruption.

[0042] Optionally, according to the update status, it can be determined which nodes are nodes to be updated, that is, those nodes that need software or hardware upgrades. After determining the nodes to be updated, it is necessary to migrate the containers in the nodes to be updated. The resource portrait interface can be called to determine the nodes to be run corresponding to the nodes to be updated in the container application platform. The nodes to be run can be nodes that can be used to run the containers running on the nodes to be updated. Among them, the above-mentioned resource portrait interface can be used to evaluate which nodes in the cluster can bear the load of the Pod on the nodes to be updated. The resource portrait interface can be used to provide the resource usage of the cluster, which can include memory, CPU, network bandwidth and disk space, etc., as well as scheduling constraints, such as node affinity and storage volume binding relationship. After determining the nodes to be run, at least one container to be migrated running in the nodes to be updated can be migrated to the nodes to be run. After at least one container to be migrated is successfully migrated to the nodes to be run, the nodes to be updated can be updated. For example, when the system confirms that the container (Pod) to be migrated has been successfully started and run on the node to be run, the planned update operation, such as kernel upgrade or hardware maintenance, can be safely performed on the original node to be updated.

[0043] For example, due to the need for software upgrades, security patches, or hardware maintenance, the current status of each node can be checked, including the kernel version it is running, the operating system patch level, the installed software package version, and other information, and it can be determined whether this information matches the planned update. In this way, the update status of at least one node can be determined. For example, suppose that the Kubernetes cluster contains nodes such as Node1, Node2, and Node3, and there is now a kernel upgrade plan, the goal is to upgrade to version v5.10.0. The system will check the kernel version of each node. The kernel versions of Node1 and Node2 are v5.4.0, while the kernel version of Node3 is v5.10.0. Therefore, the update status of Node1 and Node2 is determined to be pending update, and Node3 does not need to be updated. Further, the resource profile interface can be called to evaluate the resource status and scheduling capabilities of Node4 and Node5 (nodes that are not in the pending update state). Assume that Node4 has sufficient resources and Node5 has tight resources. Therefore, Node4 can be determined as a node to be run and can receive Pods migrated from Node1 and Node2. The Pod that needs to be migrated (i.e., the container running on the node to be updated) can be shut down and rescheduled to run on the determined node to be running. The migration process can be implemented through the Kubernetes data transmission interface (for example, Evict ion API), thereby ensuring that the Pod is safely migrated from one node to another. After confirming that Pod1, Pod2, Pod3, and Pod4 are running stably on Node4, the system starts to upgrade the kernel of Node1 and Node2. It should be noted that the above version information is only for example and is not specifically limited here.

[0044] Optionally, through the above steps, resource profiling technology is used to evaluate the resource status of the cluster, Pod migration decisions are made based on the evaluation results, and finally the nodes are safely updated, avoiding the problems of application unavailability and resource waste caused by node updates.

[0045] Currently, a Kubernetes cluster consists of many Worker nodes, which sometimes need to be shut down for maintenance, such as when a vulnerability in the operating system kernel (Linux Kernel) is exposed, when the Linux Kernel is upgraded, when a broken disk is replaced, or when a node is downsized and offline.

[0046] In the related art, the common maintenance method is to use commands in K8S (for example, the "kubect l drain" command). This method first confirms the node that needs to be evicted, and expels the pod running on the node through "kubect l drain". However, there are many problems with the above method. For example, the command directly expels the container, and there is no guarantee that the evicted pod will be restarted on other nodes. In extreme cases, all available instances of the application may be deleted, resulting in the unavailability of the application, which will seriously have a fatal impact on business applications. Secondly, this method can only perform node expulsion on a single node and a single task, and cannot perform expulsion on multiple tasks and multiple nodes.

[0047] Optionally, before the pod on the node is expelled, the above method cannot evaluate whether the current node can be successfully scheduled when it is scheduled to other nodes in the cluster, and cannot consider many reasons such as whether the cluster resources are sufficient, node affinity and anti-affinity, whether there is necessary storage for the current node, and pod label selection. Without considering the resource usage of the k8s cluster, the expelled pod may fail to start, which in turn affects the business availability. In addition, the above method cannot guarantee whether the pod is running normally on other nodes. Manual confirmation is relatively time-consuming and complicated. At the same time, the above method does not consider the batch expulsion of k8s nodes. If the cluster resource utilization is low or the kernel needs to be upgraded in batches, k8s cluster nodes need to be expelled in batches. If a single command is executed or executed using the above patent, a business pod may be scheduled to the same batch of nodes that need to be offline. This may lead to the possibility of the same pod being expelled repeatedly. It wastes cluster scheduling resources and affects business stability.

[0048] In order to solve the above problems, this embodiment can perform single-task batch node expulsion and multi-task batch node expulsion by customizing CRD+ self-developed controller. For large-scale clusters, kernel upgrades, fault isolation, and node rescheduling scenarios can significantly improve the expulsion efficiency. The k8s cluster can be trained and fine-tuned through large model technology to establish a cluster resource profile and provide an interface. The current cluster resource situation can be quickly obtained through the interface. By calling the interface, the cluster resource usage can be quickly obtained to determine whether the resource requirements required for local pod expulsion are met. Avoid invalid expulsion. Through a recursive algorithm, the pod upper-level controller is found to be compatible with the k8s cluster's built-in resource controller and the custom resource controller, and the evicted pod is automatically obtained to complete the restart on other nodes. After confirming that the pod is expelled, the restart status is restarted, and the update of the node to be updated is completed. The above method solves the technical problem of low node update efficiency and achieves the technical effect of improving the node update efficiency.

[0049] For example, it corresponds to the process of checking the kernel version, software package, etc. of the nodes in the cluster. For example, when a kernel vulnerability is exposed, it can be confirmed which nodes are running the vulnerable kernel version. After determining which nodes need to be updated, the system will select those nodes that need to be updated most based on the current status of the nodes and the business load. This may involve priority sorting, such as giving priority to updating nodes with less resource consumption and the least business impact. After selecting the node to be updated, the resource profiling interface can be called to evaluate the resource situation and scheduling capabilities of other nodes in the cluster. It can include checking the availability of CPU, memory, and storage resources, as well as scheduling constraints such as node affinity and node labels to ensure that the migrated container can find a suitable node to run in the cluster. Once it is determined which containers can be safely migrated, the system can use Kubernetes's Evict ion API or similar tools to evict the container from the node to be updated and migrate it to the node to be run. It should be noted here that Pods under the same controller need to be migrated serially, while Pods under different controllers can be migrated in parallel to ensure service continuity and improve migration efficiency. After confirming that the container is successfully started and running stably on the node to be run, and the service health check passes, you can start updating the original node to be updated. The update operation can include performing kernel upgrades, system patches or software package updates, etc., which can be used to ensure that the node update operation will not cause service unavailability due to resource problems or scheduling failures.

[0050] Through the above steps S101 and S105 of the present application, the update status of at least one node in the container application platform is determined; based on the update status, the node to be updated in at least one node is determined; the resource portrait interface is called to determine the node to be run in the container application platform corresponding to the node to be updated; the container to be migrated in the node to be updated is migrated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, the node to be updated is updated. That is to say, in an embodiment of the present application, the update status of at least one node is determined, and based on the update status, the node to be updated is determined from at least one node, and the resource portrait interface is called to determine the node to be run in the container update platform corresponding to the node to be updated. The node to be run can be used to process the container to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving node update efficiency.

[0051] The above method of this embodiment is further introduced below.

[0052] As an optional implementation, step S103, calling the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated, includes: calling the resource portrait interface to determine the node running data of at least one node; based on the node running data, determining the resource usage data of at least one node; based on the resource usage data, determining the node to be run.

[0053] In this embodiment, a resource portrait interface can be called, and the node operation data corresponding to at least one node can be determined based on the resource portrait interface. Based on the node operation data, the resource usage data of at least one node can be determined, and based on the resource usage data, the node to be run can be determined. Among them, the above-mentioned node operation data can be an indicator that can reflect the current operating status and performance of the node, and can include but is not limited to data such as CPU usage, memory consumption, disk input / output (I / O), network bandwidth usage, node health status, and Pod operating status. It should be noted that this is only an example, and there is no specific restriction on the content of the node operation data. The above-mentioned resource usage data can be used to determine the usage of resources in the node, and can be data obtained after analyzing and processing the node operation data. It can be used to clearly indicate the resource allocation and consumption of the node, for example, it can be used to characterize the total number of available CPU cores, the total available memory size, the allocated storage space, etc.

[0054] Optionally, this embodiment can call the resource portrait interface to obtain node operation data to provide a data basis for subsequent analysis of resource usage. Based on the node operation data, the system can calculate the resource usage ratio, remaining resource amount, etc. to obtain resource usage data, which can provide specific values ​​for resource evaluation and node selection.

[0055] For example, if Node1 needs to be updated, the system will call the resource profiling interface to obtain the operation data of non-updated nodes such as Node2 and Node3. For example, the node operation data can be used to characterize that the CPU usage of Node2 is 30%, the memory usage is 40%; the CPU usage of Node3 is 50%, and the memory usage is 60%. Based on the node operation data of Node2 and Node3, it is determined that the total available CPU cores of Node2 are 8, 2.4 cores are used, and 5.6 cores are left; the total available memory is 16GB, 6.4 gigabytes (GB) are used, and 9.6GB are left. The total available CPU cores of Node3 are 10, 5 cores are used, and 5 cores are left; the total available memory is 18GB, 10.8GB is used, and 7.2GB is left.

[0056] Optionally, after obtaining the resource usage data of the node, you can evaluate which nodes can accommodate the containers to be migrated based on the resource usage data to determine the data to be run. When selecting the node to be run, you can consider factors such as the remaining amount of resources, the affinity and anti-affinity rules of the Pod, the compatibility of the network policy, and the availability of the storage volume (PV / PVC).

[0057] For example, if you need to migrate containers from Node1 to other nodes, you can determine based on the resource usage data of Node2 and Node3 that Node2 has sufficient remaining CPU and memory resources and does not violate the Pod affinity rules. Therefore, Node2 is determined as the node to be run and can accept the container from Node1.

[0058] In this embodiment, the resource profile interface can intelligently evaluate the resource usage of the node, ensure that the container is migrated to a node with sufficient resources, avoid waste of cluster resources, and improve resource utilization. By analyzing the node operation data and resource usage data, the scheduling rules of Kubernetes can be followed, such as node affinity and storage volume binding relationship, to ensure the stability of the container after migration. When determining the node to be run, the continuity of the business can be considered to avoid migrating the container to a node that may cause a resource bottleneck, thereby ensuring the normal operation of the business and reducing the risk of service interruption due to improper resource allocation.

[0059] Optionally, call the resource profile interface to obtain the current cluster resource situation to reserve resources for the nodes that need to be scheduled. Exclude the list of nodes to be evicted and perform resource evaluation on the remaining nodes in the cluster. Ensure that resources are sufficient before performing node eviction actions. If resources are insufficient, update the CR event (for example, DrainNodeConfig CR) status and record the reason for failure to evict. If resources are sufficient, the nodes to be run can be determined based on resource usage.

[0060] As an optional implementation, step S104, migrating the containers to be migrated in the node to be updated to the corresponding node to be run for running, includes: classifying at least one container to be migrated to obtain at least one container group, wherein the controllers of the containers to be migrated in the same container group are of the same type; serially migrating the containers to be migrated in the same container group to the node to be run, and migrating the containers to be migrated in different container groups to the node to be run in parallel.

[0061] In this embodiment, by traversing all pod lists on the node, the pods can be grouped according to the controller they belong to, so as to obtain at least one container group. Since the containers are classified according to the controllers, the controller types corresponding to the containers to be migrated in the same container group are the same. Furthermore, the containers to be migrated in the same container group can be serially migrated to the node to be run, and the containers to be migrated in different container groups can be migrated to the node to be run.

[0062] Optionally, determine the pods corresponding to the same controller, the pods corresponding to different controllers, and the pods not controlled by the controller, and classify at least one container in the pod or directly classify the pods through the above content to obtain at least one container group. Further, the Evict ion API can be called to evict (i.e., migrate) the pods, and the eviction content may include: serial eviction of pods under the same controller to ensure service availability; parallel eviction of pods belonging to different controllers to improve efficiency; direct eviction of non-business pods not controlled by the controller.

[0063] Optionally, in a Kubernetes cluster, containers are usually organized in Pods, and the lifecycle of Pods is managed by various controllers (e.g., Deployments, StatefulSets, DaemonSets, custom controllers, etc.). Before updating a node, the system needs to classify the containers to be migrated according to the controller type to which they belong, forming different container groups.

[0064] Optionally, in the process of migrating containers from the node to be updated to the node to be run, the system adopts a serial and parallel migration strategy, and determines the migration order based on the container group to which the container belongs. Within the container group, the migration of containers is performed serially to ensure that the migration of Pods managed by the same controller will not cause service interruption; between different container groups, the migration of containers is performed in parallel to improve migration efficiency and shorten the overall update time.

[0065] Optionally, the controller can be used to manage the life cycle of the Pod and ensure that the Pod runs in a predefined state. The controller can automatically create, delete, or replace the Pod to achieve or restore the desired state. Different types of controllers are suitable for different scenarios and requirements.

[0066] In this embodiment, the security of node batch update is achieved through customized CRD and self-developed controller. The controller dependency of Pod is analyzed through recursive algorithm to ensure that Pod migration under the same controller is carried out in series and Pod migration under different controllers is carried out in parallel. This strategy not only improves migration efficiency, but also ensures business continuity and rational use of cluster resources.

[0067] As an optional implementation, the method may further include: determining state information of a controller of the container to be migrated; and determining a migration state of at least one container to be migrated under the controller based on the state information.

[0068] In this embodiment, during the process of migrating the container to be migrated, the state information of the controller corresponding to the container to be migrated can be determined, and the state information can be used to determine the migration state of different containers to be migrated under the controller, for example, it can be used to determine whether the migration of the container to be migrated is successful, and can include a success state, a failure state, an abnormal state, etc. It should be noted that this is only an example, and no specific limitation is made to the state information. Further, based on the state information, the migration state of at least one container to be migrated under the controller can be determined, and the migration state can be used to determine whether the container in the container group under the controller is successfully migrated.

[0069] Optionally, use a recursive algorithm to obtain the name of the controller to which it belongs through the owner reference (pod.OwnerReference) of the container, and query the controller status to obtain the status information corresponding to the controller, which can be used to characterize all pod information under the controller. Wait until the controller status of the evicted pod shows that all pod quantities are running normally. Confirm that the pod is safely evicted and safely started on other nodes. Based on the status information of the controller, the migration status of the containers to be migrated under the controller can be determined. In response to the successful migration of the containers to be migrated under the controller to the nodes to be run, the nodes to be updated can be updated.

[0070] Optionally, based on the status information, it can be determined whether the safe eviction of all nodes is completed. If yes, the DrainNodeConfig CR status can be updated, and the nodes to be updated can be updated. If no, the node safe eviction logic can be continued. After all pod evictions are completed, the DrainNodeConfig CR status is updated, and the node safe eviction tuning logic is ended.

[0071] As an optional implementation, the method may further include: in response to a node in the container application platform being a node to be updated, marking the node to be updated.

[0072] In this embodiment, if the node is a node to be updated, the node may be marked to prevent the node from being called again.

[0073] Optionally, obtain the node list that needs to be executed for this node eviction, which can include the node list that has not been evicted and the node list that has completed the eviction. You can add a non-schedulable taint to all node lists to prevent pods from being scheduled to other nodes that have not been evicted. You can traverse the node list that has not been evicted and perform the eviction logic.

[0074] In an embodiment of the present application, the update status of at least one node is determined, and based on the update status, a node to be updated is determined from at least one node, and a resource portrait interface is called to determine a node to be run in the container update platform that corresponds to the node to be updated. The node to be run can be used to process containers to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving node update efficiency.

[0075] The above method is further described below with reference to another optional embodiment.

[0076] Figure 2 is a flowchart of a large model-driven Kubernetes security node expulsion method according to an embodiment of the present application, such as Figure 2 As shown, the method may include the following steps:

[0077] Step S201, creating a CR.

[0078] In this embodiment, the user can create a custom resource `DrainNodeConfig`, which can be used to specify `nodeList` as `[Node3,Node7]`, and set `enableSafe` to `true`, indicating that safe eviction is required.

[0079] Optionally, this embodiment can deploy a large model, which can be used to fill the resource profile of the k8s cluster and provide an interface, which can be a resource profile interface. A DrainNodeconfig resource can be created to specify the list of nodes to be safely evicted this time.

[0080] Step S202: monitor CR events.

[0081] In this embodiment, the DrainNodeConfig CR event can be monitored: the custom `DrainController` monitors the creation event of the `DrainNodeConfig` resource.

[0082] Optionally, Drain Controller listens to the creation of DrainNodeconfig resources and performs resource tuning process.

[0083] Optionally, the DrainNodeConfig CR event may be monitored to determine whether there is a create event, an update event, or a delete event, which may be used to determine related operations performed on the node.

[0084] Step S203, determining the CR state.

[0085] In this embodiment, it is determined whether DrainNodeconfig is in a new or updated state. If it is in an updated state, step S204 can be executed. If it is in a created state, step S205 can be executed.

[0086] Step S204, obtaining status information and node expulsion progress.

[0087] In this embodiment, if DrainNodeconfig is updated, the DrainNodeconfig status information and node expulsion progress can be obtained to determine whether the expulsion action of all nodes is completed this time. If so, the process ends. If not, step S205 can be executed to continue the node security expulsion logic.

[0088] Step S205, obtaining a list of nodes that need to be executed for this node expulsion.

[0089] In this embodiment, a node list that needs to be executed for this node eviction may be obtained, and the node list may include a list of nodes that have not been evicted and a list of nodes that have been evicted.

[0090] Step S206, marking the nodes in the node list.

[0091] In this embodiment, all node lists may be marked with unschedulable taints to prevent pods from being scheduled to other nodes that have not been evicted.

[0092] Optionally, you can traverse the list of nodes that have not been evicted and perform the eviction logic.

[0093] Step S207: reserve resources for nodes that need to be scheduled.

[0094] In this embodiment, the resource profile interface can be called to obtain the current cluster resource status and reserve resources for the nodes that need to be scheduled.

[0095] Optionally, exclude the list of nodes to be evicted and perform resource evaluation on the remaining nodes in the cluster. Ensure that resources are sufficient before performing node eviction. If resources are insufficient, update the DrainNodeConfig CR status, record the reason for failure to evict, and re-execute step S202. If resources are sufficient, proceed to step S208.

[0096] Step S208, traverse all pod lists on the node.

[0097] In this embodiment, all pod lists on the node are traversed, and the pods can be grouped according to the controller they belong to. The grouping content may include: pods belonging to the same controller, pods belonging to different controllers, and pods not controlled by the controller.

[0098] Step S209: evict the pod.

[0099] In this embodiment, the Evict ion API may be called to evict the pod.

[0100] Optionally, pods under the same controller are evicted serially to ensure service availability; pods belonging to different controllers are evicted in parallel to improve efficiency; non-business pods not controlled by a controller are evicted directly.

[0101] Step S210, determining the eviction status of the pod.

[0102] In this embodiment, a recursive algorithm may be used to obtain the name of the owning controller through pod.OwnerReference.

[0103] Optionally, query the controller status to obtain all pod information under the controller. Wait until the controller status of the evicted pod shows that all pods are running normally. Confirm that the pod is safely evicted and safely started on other nodes. Further, the above steps can be repeated until the evicted status of all pods is confirmed. The above evicted status can be the migration status of the container to be migrated.

[0104] Step S211, determining whether the safe expulsion of all nodes is completed.

[0105] In this embodiment, it can be determined whether the safe eviction of all nodes is completed. If yes, the DrainNodeConfig CR state can be updated and the process returns to step S202. If no, the process returns to step S208 and continues the node safe eviction logic.

[0106] Optionally, after all pods are evicted, the DrainNodeConfig CR status is updated, and the node safety eviction tuning logic is finally terminated.

[0107] Optionally, the above eviction tuning logic may include:

[0108] API version: "xx.xxx.com / v1"

[0109] Type: DrainNodeConfig

[0110] Metadata:

[0111] Name: my-drain-node-object

[0112] specification:

[0113] Node list:

[0114] node1

[0115] node2

[0116] node3

[0117] Enable Safe Mode: True

[0118] Enable Preview Mode: False

[0119] state:

[0120] condition:

[0121] Last conversion time: "2024-xx-xxTxx:xx:xxZ"

[0122] Message: '54 / 74podxxx'

[0123] Reason: Pod eviction

[0124] Status: "true"

[0125] Phase: Operation

[0126] Evicted nodes:

[0127] node1

[0128] Nodes not evicted:

[0129] node2

[0130] node3

[0131] Optionally, the configuration of safe node expulsion can be specified through the above execution logic, and its properties include node list, whether to enable safety mode, whether to enable rehearsal mode, and state information such as conditions, stages, and lists of evicted and non-evicted nodes.

[0132] Optionally, the above method can be applied to scenarios such as kernel upgrade, problem troubleshooting, node scaling down, and business pod rescheduling.

[0133] In this embodiment, a method for securely expelling nodes from Kubernetes based on big model technology is proposed. The method may include the following three core algorithms: a resource evaluation algorithm based on cluster resource portraits of big models, a CRD definition and Pod controller dependency recursive algorithm, and a node security expulsion decision algorithm.

[0134] Optionally, the resource assessment algorithm based on the cluster resource portrait of the big model establishes an accurate resource portrait of the Kubernetes cluster through the big model technology, providing a decision-making basis for the safe eviction of nodes.

[0135] Optionally, the resource evaluation algorithm based on the large model cluster resource portrait may include the following: (1) Resource data collection and feature engineering: continuously collect CPU, memory, storage, network and other resource usage data of cluster nodes and Pods; collect scheduling constraints such as node affinity rules, taint settings, storage volume binding relationships, etc.; calculate resource usage trends through sliding windows, and perform anomaly detection and feature extraction. (2) Large model training and optimization: use the Transformer architecture to build a prediction model and learn resource usage patterns; optimize scheduling decisions through reinforcement learning to balance resource utilization and service quality; continuously fine-tune the model to improve prediction accuracy. (3) Resource portrait service, providing a REST API interface to support querying node resource predictions and obtaining scheduling recommendations. In addition, evaluate the impact of eviction operations on cluster resource distribution. Finally, based on the resource portrait results, provide a feasibility analysis for eviction decisions.

[0136] Optionally, resource portrait-based assessment may include: calculating remaining resources of target nodes, predicting resource usage trends, and considering the impact of resource fragmentation.

[0137] Optionally, the constraint verification may include: checking node affinity rules, verifying PV / PVC availability, and evaluating network policy compatibility.

[0138] In this embodiment, the above-mentioned custom resources (CRD) and controller are used to achieve precise control of node eviction, and cooperate with the resource profiling system to ensure the security of node eviction.

[0139] Optionally, the above-mentioned custom resource definition may include: defining a CRD resource DrainNodeconfig based on the k8s cluster, and developing the CRD Drain controller to monitor the creation, deletion, and update operations of CR, thereby controlling the entire security node expulsion logic.

[0140] Optionally, the above-mentioned Pod dependency recursive algorithm may include: the Drain Controller monitors the creation, deletion, and update operations of the DrainNodeConfig resource, formulates an eviction strategy based on the evaluation results of the resource portrait system, and reflects the eviction progress and status in real time through the status field.

[0141] Optionally, you can also build a Pod controller dependency graph, which can be built through the following steps: build a DAG by recursively traversing OwnerReference; identify controllers that require ordered deployment, such as StatefulSet; and analyze Service associations to determine business dependencies.

[0142] In this embodiment, the recursive algorithm analyzes the controller dependency of the Pod, evicts the Pods of the same controller serially, and evicts the Pods of different controllers in parallel. At the same time, the running status of the evicted Pods on the new node is continuously monitored. The algorithm supports the creation of multiple eviction tasks, ensures that multiple eviction tasks do not interfere with each other, and provides the ability to pause, resume, and roll back tasks.

[0143] Optionally, the parallel eviction implementation may include the following steps: Workqueue-based concurrency control: implement a work queue with priority; use a token bucket to limit the number of concurrency; support dynamic adjustment of concurrency.

[0144] Optionally, this embodiment may also include an error handling and retry mechanism, which can be used to implement exponential backoff retry, record detailed error logs, support manual intervention and rollback, and serial eviction guarantee.

[0145] Optionally, the distributed lock implementation may include: using etcd to implement controller-level distributed locks; setting a lock timeout automatic release mechanism; and supporting lock status query and forced release.

[0146] Optionally, Pod status monitoring can include: listening to Pod lifecycle events, verifying the readiness of new Pods, and checking service health probes.

[0147] In this embodiment, through the custom CRD + self-developed controller method, single-task batch node eviction and multi-task batch node eviction can be performed. For large-scale clusters, kernel upgrades, fault isolation, and node rescheduling, the eviction efficiency can be significantly improved.

[0148] Optionally, the k8s cluster can be trained and fine-tuned through large model technology to establish a cluster resource profile and provide an interface. The current cluster resource status can be quickly obtained through the interface. By calling the interface, the cluster resource usage can be quickly obtained to determine whether the resource requirements for local pod expulsion are met. Avoid invalid expulsion.

[0149] Optionally, through a recursive algorithm, the pod upper-level controller is found to be compatible with the built-in resource controller and custom resource controller of the k8s cluster, and the evicted pod is automatically obtained to see whether it has been restarted on other nodes. By comparing the official implementation and the existing patent, the restart status of the pod after it is evicted is confirmed.

[0150] According to an embodiment of the present application, a device for updating nodes in a container application platform is also provided. It should be noted that the device for updating nodes in a container application platform of this embodiment can be used to execute the method for updating nodes in a container application platform of the above embodiment of the present application.

[0151] Figure 3 Schematic diagram of a node update device in a container application platform according to an embodiment of the present application. Figure 3 As shown, the updating device 30 for nodes in the container application platform may include: an acquiring unit 302 , a first determining unit 304 , a second determining unit 306 , a migrating unit 308 and an updating unit 310 .

[0152] The acquisition unit 302 is used to determine the update status of at least one node in the container application platform.

[0153] The first determining unit 304 is configured to determine a node to be updated among at least one of the nodes based on the update status.

[0154] The second determining unit 306 is used to call the resource portrait interface to determine the node to be run corresponding to the node to be updated in the container application platform.

[0155] The migration unit 308 is used to migrate the container to be migrated in the node to be updated to the corresponding node to be run for execution.

[0156] The updating unit 310 is configured to update the node to be updated in response to the successful migration of the container to be migrated to the node to be run.

[0157] The device for updating nodes in the container application platform of this embodiment determines the update status of at least one node in the container application platform through an acquisition unit; determines the node to be updated in at least one of the shown nodes based on the update status through a first determination unit; calls a resource portrait interface through a second determination unit to determine the node to be run in the container application platform corresponding to the node to be updated; migrates the container to be migrated in the node to be updated to the corresponding node to be run for operation through a migration unit; and updates the node to be updated in response to the successful migration of the container to be migrated to the node to be run through an update unit, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving node update efficiency.

[0158] The embodiment of the present application may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced by a terminal device such as a mobile terminal.

[0159] Optionally, in this embodiment, the computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

[0160] In this embodiment, the above-mentioned computer terminal can execute the program code of the following steps in the method for updating nodes in the container application platform: determining the update status of at least one node in the container application platform; based on the update status, determining the node to be updated in at least one node; calling the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; migrating the container to be migrated in the node to be updated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, updating the node to be updated.

[0161] Optionally, Figure 4 is a structural block diagram of a computer terminal according to an embodiment of the present application, such as Figure 4 As shown, the computer terminal 408 may include: one or more (only one is shown in the figure) processors 402 , a memory 404 and a transmission device 406 .

[0162] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the update method and device of the node in the container application platform in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, the update method of the node in the container application platform mentioned above is realized. The memory may include a high-speed random access memory, and may also include a 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 a memory remotely arranged relative to the processor, and these remote memories can be connected to the computer terminal 408 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0163] The processor can call the information and application programs stored in the memory through the transmission device to execute the following steps: determine the update status of at least one node in the container application platform; based on the update status, determine the node to be updated in at least one node; call the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; migrate the container to be migrated in the node to be updated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, update the node to be updated.

[0164] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the computer terminal 408 may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (MID for short), a PAD, or other terminal devices. Figure 4 The structure of the computer terminal 408 is not limited. For example, the computer terminal 408 may also include Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 4 Different configurations are shown.

[0165] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0166] According to an embodiment of the present application, a computer-readable storage medium is further provided, the computer-readable storage medium including a stored program, wherein the program executes the method for updating a node in a container application platform in the above embodiment.

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

[0168] Optionally, in this embodiment, the computer-readable storage medium is configured to store program codes for executing the following steps: determining the update status of at least one node in the container application platform; determining the node to be updated in at least one node based on the update status; calling the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; migrating the container to be migrated in the node to be updated to the corresponding node to be run for execution; and updating the node to be updated in response to the successful migration of the container to be migrated to the node to be run.

[0169] Optionally, the computer-readable storage medium may also execute program code of the following steps: calling a resource portrait interface to determine node operation data of at least one node; determining resource usage data of at least one node based on the node operation data; and determining a node to be operated based on the resource usage data.

[0170] Optionally, the computer-readable storage medium may further execute program codes of the following steps: classifying at least one container to be migrated to obtain at least one container group, wherein the controllers of the containers to be migrated in the same container group are of the same type; migrating the containers to be migrated in the same container group to the nodes to be run in series, and migrating the containers to be migrated in different container groups to the nodes to be run in parallel.

[0171] Optionally, the computer-readable storage medium may further execute program code for the following steps: determining state information of a controller of the container to be migrated; and determining a migration state of at least one container to be migrated under the controller based on the state information.

[0172] Optionally, the computer-readable storage medium may further execute program code of the following steps: in response to a node in the container application platform being a node to be updated, marking the node to be updated.

[0173] In this embodiment, the update status of at least one node is determined, and based on the update status, a node to be updated is determined from at least one node, and a resource portrait interface is called to determine a node to be run in the container update platform that corresponds to the node to be updated. The node to be run can be used to process the containers to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving the node update efficiency.

[0174] According to an embodiment of the present application, a processor is further provided, the processor being used to run a program, wherein when the program is run by the processor, the method for updating a node in a container application platform in the above embodiment is executed.

[0175] Optionally, in this embodiment, the computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

[0176] In this embodiment, the above-mentioned computer terminal can execute the program code of the following steps in the method for updating nodes in the container application platform: determining the update status of at least one node in the container application platform; based on the update status, determining the node to be updated in at least one node; calling the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; migrating the container to be migrated in the node to be updated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, updating the node to be updated.

[0177] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the update method and device of the node in the container application platform in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, the update method of the node in the container application platform mentioned above is realized. The memory may include a high-speed random access memory, and may also include a 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 a memory remotely arranged relative to the processor, and these remote memories can be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0178] The processor can call the information and application programs stored in the memory through the transmission device to execute the following steps: determine the update status of at least one node in the container application platform; based on the update status, determine the node to be updated in at least one node; call the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated; migrate the container to be migrated in the node to be updated to the corresponding node to be run for operation; in response to the successful migration of the container to be migrated to the node to be run, update the node to be updated.

[0179] Optionally, the processor may also execute program code of the following steps: calling a resource portrait interface to determine node operation data of at least one node; determining resource usage data of at least one node based on the node operation data; and determining a node to be operated based on the resource usage data.

[0180] Optionally, the processor may further execute program codes of the following steps: classifying at least one container to be migrated to obtain at least one container group, wherein the controllers of the containers to be migrated in the same container group are of the same type; serially migrating the containers to be migrated in the same container group to the nodes to be run, and migrating the containers to be migrated in different container groups to the nodes to be run in parallel.

[0181] Optionally, the processor may further execute program codes of the following steps: determining state information of a controller of the container to be migrated; and determining a migration state of at least one container to be migrated under the controller based on the state information.

[0182] Optionally, the processor may further execute program code of the following steps: in response to a node in the container application platform being a node to be updated, marking the node to be updated.

[0183] By adopting the embodiment of the present application, the update status of at least one node is determined, and based on the update status, the node to be updated is determined from at least one node, and the resource portrait interface is called to determine the node to be run in the container update platform that corresponds to the node to be updated. The node to be run can be used to process the containers to be migrated in the node to be updated. When all the containers to be migrated are migrated to the node to be run, the node to be updated can be updated, thereby solving the technical problem of low node update efficiency and achieving the technical effect of improving the node update efficiency.

[0184] According to an embodiment of the present application, a computer program product is further provided. The computer program product includes computer instructions. When the computer instructions are executed by a processor, the method for updating a node in a container application platform in the above embodiment is implemented.

[0185] An embodiment of the present application may provide an electronic device, which may include a memory and a processor.

[0186] Figure 5 It is a block diagram of an electronic device according to a method for updating a node in a container application platform according to an embodiment of the present application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0187] like Figure 5 As shown, the device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 to a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the device 500 can also be stored. The computing unit 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0188] A number of components in the device 500 are connected to the I / O interface 505, including: an input unit 506, such as a keyboard, a mouse, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a disk, an optical disk, etc.; and a communication unit 509, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 509 allows the device 500 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0189] The computing unit 501 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as a verification method for data. For example, in some embodiments, the verification method for data may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 500 via the ROM 502 and / or the communication unit 509. When the computer program is loaded into the RAM 503 and executed by the computing unit 501, one or more steps of the verification method for data described above may be executed. Alternatively, in other embodiments, the computing unit 501 may be configured to execute the data verification method in any other appropriate manner (for example, by means of firmware).

[0190] According to an embodiment of the present application, a method for updating a node in a container application platform is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0191] Various embodiments of the systems and techniques described above herein may be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: being implemented in one or more computer programs that are executable and / or interpreted on a programmable system including at least one programmable processor that may be a dedicated or general purpose programmable processor that may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0192] The program code for implementing the method of the present application can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code can be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0193] In the context of the present application, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0194] To provide interaction with a user, the systems and techniques described herein may be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or an LCD (liquid crystal display, monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a path ball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0195] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a Local Area Network (LAN), a Wide Area Network (WAN), and the Internet.

[0196] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0197] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0198] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0199] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0200] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0201] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0202] If the integrated unit is implemented in the form of 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 application, 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, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0203] The above are only preferred implementations of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for updating a node in a container application platform, characterized in that: include: Determining an update status of at least one node in the container application platform; Based on the update status, determining a node to be updated among the at least one node; Calling a resource portrait interface to determine a node to be run in the container application platform corresponding to the node to be updated; Migrate the container to be migrated in the node to be updated to the corresponding node to be run for execution; In response to the container to be migrated being successfully migrated to the node to be run, the node to be updated is updated.

2. The method according to claim 1, characterized in that The calling of the resource portrait interface to determine the node to be run in the container application platform corresponding to the node to be updated includes: Calling the resource profile interface to determine node operation data of at least one of the nodes; Determining resource usage data of at least one of the nodes based on the node operation data; The node to be run is determined based on the resource usage data.

3. The method according to claim 1, characterized in that The step of migrating the container to be migrated in the node to be updated to the corresponding node to be run for running includes: Classifying at least one container to be migrated to obtain at least one container group, wherein the controllers of the containers to be migrated in the same container group are of the same type; The containers to be migrated in the same container group are serially migrated to the node to be run, and the containers to be migrated in different container groups are migrated to the node to be run in parallel.

4. The method according to claim 1, characterized in that: The method further comprises: Determine status information of the controller of the container to be migrated; Based on the status information, a migration status of at least one container to be migrated under the controller is determined.

5. The method according to claim 1, characterized in that The method further comprises: In response to a node in the container application platform being the node to be updated, marking the node to be updated.

6. A device for updating nodes in a container application platform, characterized in that: include: An acquisition unit, used to determine an update status of at least one node in the container application platform; A first determining unit, configured to determine a node to be updated among the at least one node based on the update status; A second determination unit is used to call a resource portrait interface to determine a node to be run in the container application platform corresponding to the node to be updated; A migration unit, used to migrate the container to be migrated in the node to be updated to the corresponding node to be run for execution; An updating unit is configured to update the node to be updated in response to the container to be migrated successfully migrating to the node to be run.

7. A processor, characterized in that: The processor is used to run a program, wherein the program executes the method described in any one of claims 1 to 5 when run by the processor.

8. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 5 when executed.

9. An electronic device, comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 5.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 5 when being executed by a processor.

Images