Container group migration method and device, equipment, storage medium and computer program product

Abstract

The invention discloses a container group migration method and device, equipment, a storage medium and a computer program product, and relates to the technical field of data, the method comprises the following steps: when a migration request sent by a user to a container group is received, verifying the migration request, each container in the container group being in a working state and / or a non-working state; if the migration request passes the verification, determining a migration strategy of the container group based on the migration request, and executing a rescheduling process of the container group according to the migration strategy; if the rescheduling process is executed, it is judged that migration of the container group succeeds; and if the migration request does not pass the verification or the rescheduling process is not executed, determining that the container group migration fails. The rescheduling process of the container group is executed according to the migration strategy when the migration request passes the verification, and the migration process of the container group is monitored according to whether the rescheduling process is executed or not and whether the migration request passes the verification or not, so that more intelligent container group resource deployment is realized, and the migration effect of the container group is ensured.

Description

Technical Field

[0001] The present application relates to the field of data migration technology, and in particular to a container group migration method, apparatus, device, storage medium, and computer program product. Background Art

[0002] Pod migration is a critical operation in container orchestration systems like Kubernetes. It involves moving a running pod from one node to another. Existing pod migration methods simply delete a specific pod to achieve the desired migration goal. This approach fails to consider whether the entire migration process is suitable for the pod, making it difficult to guarantee successful migration. Summary of the Invention

[0003] The main purpose of this application is to provide a container group migration method, device, equipment, storage medium and computer program product, aiming to solve the technical problem that the migration effect of existing container group migration methods is difficult to guarantee.

[0004] To achieve the above objectives, the present application provides a container group migration method, which includes the following steps:

[0005] When receiving a migration request from a user for a container group, verifying that each container in the container group is in a working state and / or a non-working state;

[0006] If the migration request passes the verification, determining a migration strategy for the container group based on the migration request, and executing a rescheduling process for the container group according to the migration strategy;

[0007] If the rescheduling process is completed, it is determined that the migration of the container group is successful;

[0008] If the migration request fails to pass verification or the rescheduling process is not completed, it is determined that the container group migration has failed.

[0009] In one embodiment, when receiving a migration request for a container group from a user, verifying the migration request includes:

[0010] When receiving a migration request for a container group from a user, performing a first verification on the migration request according to the migration type of the container group;

[0011] If the migration request passes the first verification, a second verification is performed on the migration request according to the migration parameters included in the migration request.

[0012] In one embodiment, when receiving a migration request for a container group from a user, performing a first verification on the migration request according to the migration type of the container group includes:

[0013] If the migration type of the container group is cross-resource block migration, performing a first verification on the migration request based on whether the migration request contains the container group name, namespace, and resource pool type of the target node;

[0014] If the migration type of the container group is same resource block migration, the migration request is first verified according to whether the migration request contains the container group name, namespace, and resource pool type or node name of the target node.

[0015] In one embodiment, the migration parameter is a first parameter or a second parameter, and the step of performing a second verification on the migration request according to the migration parameter included in the migration request includes:

[0016] If the migration type of the container group is cross-resource block migration, performing a second verification on the migration request according to a first parameter included in the migration request, where the first parameter includes a stateful application set state, a cluster version, PVC information, resource block information, and DNS validity;

[0017] If the migration type of the container group is same resource block migration, the migration request is verified for the second time according to the second parameter included in the migration request, where the second parameter includes the cluster version, PVC information, and resource block information.

[0018] In one embodiment, the container group includes a first container group and a second container group. The step of determining a migration policy for the container group based on the migration request and executing a rescheduling process for the container group according to the migration policy includes:

[0019] Determining a migration policy for the container group based on the migration request, where the migration policy includes modification policies corresponding to associated resources in the container group;

[0020] The first container group is deleted, and the second container group is updated according to the migration policy to execute a rescheduling process of the container group.

[0021] In one embodiment, the container group migration method further includes:

[0022] When it is detected that the migration request passes the verification, backing up the current information in the container group to obtain backup information, and writing the backup information into a database;

[0023] When it is detected that the migration of the container group is successful or failed, it is determined that the migration of the container group is completed, and the execution result and execution log corresponding to the migration success or migration failure are written into the database.

[0024] In addition, to achieve the above-mentioned purpose, the present application also proposes a container group migration device, which includes:

[0025] a request verification module, configured to, upon receiving a migration request from a user for a container group, verify that each container in the container group is in a working state and / or a non-working state;

[0026] a process execution module, configured to determine a migration strategy for the container group based on the migration request if the migration request passes verification, and execute a rescheduling process for the container group according to the migration strategy;

[0027] A first determination module, configured to determine that the migration of the container group is successful if the rescheduling process is completed;

[0028] The second determination module is configured to determine that the migration of the container group has failed if the migration request fails to pass verification or the rescheduling process is not completed.

[0029] In addition, to achieve the above-mentioned objectives, the present application also proposes a container group migration device, which includes: a memory, a processor, and a container group migration program stored in the memory and executable on the processor, wherein the container group migration program is configured to implement the steps of the container group migration method described above.

[0030] In addition, to achieve the above-mentioned objectives, the present application also proposes a storage medium, which is a computer-readable storage medium and stores a container group migration program. When the container group migration program is executed by a processor, the steps of the container group migration method described above are implemented.

[0031] In addition, to achieve the above-mentioned object, the present invention further provides a computer program product, which includes a container group migration program. When the container group migration program is executed by a processor, the steps of the container group migration method described above are implemented.

[0032] When receiving a migration request from a user to a container group, the present application verifies the migration request, and each container in the container group is in a working state and / or a non-working state; if the migration request passes the verification, the migration strategy of the container group is determined based on the migration request, and the rescheduling process of the container group is executed according to the migration strategy; if the rescheduling process is completed, the migration of the container group is determined to be successful; if the migration request does not pass the verification or the rescheduling process is not completed, the migration of the container group is determined to be failed. The above method of the present application executes the rescheduling process of the container group according to the migration strategy when the migration request from the user to the container group passes the verification, and monitors the migration process of the container group according to whether the rescheduling process is completed and whether the migration request passes the verification, thereby achieving more intelligent container group resource deployment and ensuring the migration effect of the container group. At the same time, the present application supports the migration of container groups in a working state and / or a non-working state, which means that the migration operation does not force the container to stop service, so that it can adapt to the needs of different business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0035] Figure 1 This is a flow chart of the first embodiment of the container group migration method of the present application;

[0036] Figure 2 This is a schematic diagram of the container group creation process in the container group migration method of this application;

[0037] Figure 3 This is a flow chart of a second embodiment of the container group migration method of the present application;

[0038] Figure 4 This is a schematic diagram of the overall architecture of the container group migration method of this application;

[0039] Figure 5 This is a flowchart of the third embodiment of the container group migration method of the present application;

[0040] Figure 6 This is a schematic diagram of the architecture for implementing the container group migration method of this application;

[0041] Figure 7This is a structural block diagram of the first embodiment of the container group migration device of the present application;

[0042] Figure 8 This is a structural diagram of a container group migration device in a hardware operating environment involved in an embodiment of the present application.

[0043] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not intended to limit the present application.

[0045] It should be noted that the execution entity of the embodiments of the present application can be a computing service device with data processing, network communication, and program execution capabilities, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of performing the aforementioned functions, such as the container group migration device described above. The following embodiments are described using the container group migration device as an example.

[0046] This application embodiment provides a container group migration method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the container group migration method of the present application.

[0047] In this embodiment, the container group migration method includes the following steps:

[0048] Step S1: When a migration request for a container group is received from a user, the migration request is verified to determine whether each container in the container group is in a working state and / or a non-working state.

[0049] It should be noted that the above container group (pod) is the smallest unit for scheduling, deployment, and management in the cluster. A container group usually contains one or more closely related containers. Containers in the same container group share the same IP address and port space. Container groups can mount shared storage volumes for containers to read and write data, achieving data persistence or data sharing between containers. Although containers are isolated, containers in a container group share the same process namespace (which can be adjusted through configuration). For more details, please refer to Figure 2 , Figure 2 This is a diagram of the container group creation process in the container group migration method of this application. Figure 2In the example, 1 indicates that the user initiates a request by naming kubectl (a command-line tool); 2 indicates that Kube-apiserver (a server) authenticates through the corresponding kubeconfig (configuration file), and after authentication, stores the pod information in YAML (a markup language) in ETCD (an open source distributed key-value storage system); 3 indicates that Controller-Manager (a controller manager) discovers the update of pod information through the watch interface of Kube-apiserver, performs the topology structure integration on which the resource depends, and after integration, passes the corresponding information to Kube-apiserver, which writes it to ETCD; 4 indicates that Scheduler (a scheduler) also updates the pod to be scheduled through the watch interface of Kube-apiserver, assigns nodes to pods through algorithms, and passes the information binding pods and corresponding nodes to Kube-apiserver, which writes it to ETCD; 5 indicates that Kubelet (a node agent) obtains the pod information to be created from Kube-apiserver, calls the relevant CNI (Container Network Interface, Container Network Interface), CSI (Container Storage Interface, Container Storage Interface), CRI (Container The Runtime Interface (Container Runtime Interface) and other interfaces complete the creation of related resources, and then complete the pod creation. After the business process is started, the pod runs successfully.

[0050] It should be understood that the above-mentioned migration request refers to the operational requirement to move a container group from one node to another. A container group migration request is essentially an operational requirement initiated by a user or system to migrate a running container group from one node to another. This migration can be triggered by a variety of reasons, such as node failure, insufficient resources, or to achieve load balancing. The migration request can include migration-related information such as the pod name, namespace, and resource pool type, which is not limited in this embodiment.

[0051] In a specific implementation, the various parameters contained in the migration request can be verified, thereby effectively filtering out invalid or unreasonable migration requests (such as insufficient resources, policy conflicts, etc.), preventing erroneous operations from causing system instability or service interruptions, thereby significantly improving the success rate of migration operations and the robustness of the overall system. In addition, this embodiment clearly states that each container in the container group is in a working state and / or a non-working state, which means that the migration operation does not force the container to stop service. It allows the choice between maintaining service continuity (such as rolling updates) or completely stopping service before performing migration, thus being able to adapt to different business scenario requirements.

[0052] Step S2: If the migration request passes verification, a migration strategy for the container group is determined based on the migration request, and a rescheduling process for the container group is executed according to the migration strategy.

[0053] It should be understood that if the migration request passes verification, it indicates that the migration request is valid and reasonable. Therefore, the target migration node and target migration parameters for the container group can be determined based on the migration request, and then the target migration node and target migration parameters can be used as the migration policy for the container group. Container group rescheduling refers to the process of migrating container groups already running on a node to other nodes to meet requirements such as cluster resource optimization, fault recovery, or policy constraints. This process corresponds to the above-mentioned rescheduling process.

[0054] Step S3: If the rescheduling process is completed, it is determined that the container group migration is successful.

[0055] Step S4: If the migration request fails to pass verification or the rescheduling process is not completed, it is determined that the container group migration has failed.

[0056] It is understandable that in the rescheduling process of the container group, if all instructions related to the container group migration (such as delete instructions, modify instructions, update instructions, etc.) are executed successfully, it can be determined that the rescheduling process is completed, and therefore the container group migration can be determined to be successful; if there is an instruction related to the container group migration that is not executed successfully, it can be determined that the rescheduling process is not completed, and therefore the container group migration can be determined to have failed. In addition, if the migration request passes the verification, it can be indicated that the migration request is invalid or unreasonable, and therefore the container group migration can be determined to have failed. When it is determined that the container group migration has failed, a migration failure message can be sent to the user, and the specific reason for the migration failure can be informed (for example, a certain instruction related to the container group migration has not been executed successfully).

[0057] When receiving a migration request from a user for a container group, this embodiment verifies the migration request and determines whether each container in the container group is in a working state and / or a non-working state. If the migration request passes the verification, the migration strategy of the container group is determined based on the migration request, and the rescheduling process of the container group is executed according to the migration strategy. If the rescheduling process is completed, the migration of the container group is determined to be successful. If the migration request fails the verification or the rescheduling process is not completed, the migration of the container group is determined to be unsuccessful. The above method of this embodiment executes the rescheduling process of the container group according to the migration strategy when the migration request from the user for the container group passes the verification, and monitors the migration process of the container group based on whether the rescheduling process is completed and whether the migration request passes the verification, thereby achieving more intelligent container group resource deployment and ensuring the migration effect of the container group. At the same time, this embodiment supports the migration of container groups in a working state and / or a non-working state, which means that the migration operation does not force the container to stop service, thereby being able to adapt to the needs of different business scenarios.

[0058] refer to Figure 3 , Figure 3 This is a flow chart of the second embodiment of the container group migration method of the present application.

[0059] In a feasible implementation, step S1 may include:

[0060] Step S11: When a migration request for a container group is received from a user, a first verification is performed on the migration request according to the migration type of the container group.

[0061] It should be noted that the above migration types can include cross-resource block migration and same-resource block migration. Among them, cross-resource block migration means migrating a container group from one resource block (such as a node, availability zone, region, etc.) to another different resource block, for example, migrating a container group from one availability zone to another, or migrating from one data center to another; same-resource block migration means migrating a container group within the same resource block, that is, the target node and the original node belong to the same resource block. For example, migrating a container group from one node to another node in the same availability zone.

[0062] In the specific implementation, since the service interfaces corresponding to cross-resource block migration and intra-resource block migration are different, it is necessary to perform a first check on the migration request based on the migration type of the container group to determine whether the migration request can meet the relevant parameters corresponding to the migration type.

[0063] Step S12: If the migration request passes the first verification, a second verification is performed on the migration request according to the migration parameters included in the migration request.

[0064] It should be understood that if a migration request passes the first verification, it indicates that the migration request contains the required migration parameters for the migration type, meaning that the migration request is considered compatible with the migration type. However, at this point, it's still unclear whether these migration parameters meet the migration requirements. Therefore, a second verification is required based on the migration parameters contained in the migration request.

[0065] In a feasible implementation, step S11 may include:

[0066] Step S111: If the migration type of the container group is cross-resource block migration, the migration request is first verified according to whether the migration request contains the container group name, namespace, and resource pool type of the target node.

[0067] Step S112: If the migration type of the container group is same resource block migration, the migration request is first verified based on whether the migration request contains the container group name, namespace, and resource pool type or node name of the target node.

[0068] In a specific implementation, when the migration type of a container group is cross-resource block migration, if the migration request includes the container group name, namespace, and resource pool type of the target node, it indicates that the migration request has passed the first verification; if the migration request does not include the container group name, namespace, or resource pool type of the target node, it indicates that the migration request has failed the first verification. When the migration type of a container group is same-resource block migration, if the migration request includes the container group name, namespace, and resource pool type or node name of the target node, it indicates that the migration request has passed the first verification; if the migration request does not include the container group name, namespace, or resource pool type / node name of the target node, it indicates that the migration request has failed the first verification.

[0069] In a feasible implementation manner, the migration parameter is the first parameter or the second parameter, and step S12 may include:

[0070] Step S121: If the migration type of the container group is cross-resource block migration, the migration request is verified for the second time according to the first parameter contained in the migration request, where the first parameter includes the stateful application set status, cluster version, PVC information, resource block information and DNS validity.

[0071] Step S122: If the migration type of the container group is same resource block migration, the migration request is verified for the second time according to the second parameter included in the migration request, where the second parameter includes the cluster version, PVC information, and resource block information.

[0072] In the specific implementation, when the migration type of the container group is cross-resource block migration, if the state of the stateful application set contained in the migration request is in the preparation state, and the cluster version is the target version, and the PVC (Persistent Volume Claim) information is qualified, and the container group is a slave node, and the resource block information is qualified (such as the resource block and resource pool are available), and the DNS (Domain Name System, domain name resolution service) is valid, then it can be determined that the migration request has passed the second verification; when the migration type of the container group is same-resource block migration, if the cluster version is the target version, and the PVC information is qualified, and the container group is a slave node, and the resource block information is qualified (such as the resource block and resource pool are available), then it can be determined that the migration request has passed the second verification.

[0073] In addition, please refer to Figure 4 , Figure 4 This is a schematic diagram of the overall architecture of the container group migration method for this application. Figure 4In the system, cdd-operation-system is an operation and maintenance service system that exposes services in the form of HTTP (Hypertext Transfer Protocol). It mainly implements the response and feedback of operation and maintenance requests. For example, in the pod migration request in this system, after the user initiates the request, the cdd-operation-system system receives the request and performs the pod migration operation. The Request parameter represents the parameters contained in the migration request (i.e., migration parameters). For migration within the same block (resource block), the Request parameter can include the podName (container group name), namespace Namespace, target node resource pool type ResCategory, or target NodeName (node ​​name) to be migrated; for cross-block migration types, the Request parameter can include podName, namespace Namespace, target node resource pool type ResCategory. After the Request specifies the multi-dimensional migration parameters of the pod, the cdd-operation-system completes the pod migration process according to the parameters. Specifying migration information and modifying scheduling policy information (such as affinity rules and tolerance) are completed by cdd-operation-system. The purpose of this process is to add "podMoving (migration information)" containing information such as the specified target migration pod and block to the Annotations of StatefulSet according to the migration requirements of the pod to be migrated, which serves as the basis for the scheduler to schedule the pod; in addition, cdd-operation-system modifies the affinity rules and tolerance of StatefulSet so that the pod can eventually be scheduled to a node with a block and resource pool type that meets the rules. Among them, Kube-controller is the controller of resource objects in the cluster, responsible for managing and controlling the entire cluster, mainly managing resource objects. When a pod object running in a Node node or the Node itself fails, Kuber-controller will discover and handle it in time to ensure that the entire cluster is in an ideal working state. Kube-apiserver is the only entry point for the cluster to access ETCD, and provides HTTP Rest interfaces such as add, delete, modify, and watch for various resource objects in the Kubernetes cluster. It is the data bus of the entire system. StatefulSet is a workload API object for managing stateful applications. pod (such as Figure 4 pod-0, pod-1, pod-2) is the smallest unit in Kubernetes. Multiple containers can run in a single pod.

[0074] In this embodiment, if the migration type of the container group is cross-resource block migration, the migration request is first verified based on whether the migration request contains the container group name, namespace, and resource pool type of the target node; if the migration type of the container group is same-resource block migration, the migration request is first verified based on whether the migration request contains the container group name, namespace, and resource pool type or node name of the target node; if the migration type of the container group is cross-resource block migration, the migration request is second verified based on the first parameter contained in the migration request, the first parameter including the stateful application set state, cluster version, PVC information, resource block information, and DNS validity; if the migration type of the container group is same-resource block migration, the migration request is second verified based on the second parameter contained in the migration request, the second parameter including the cluster version, PVC information, and resource block information. The above method of this embodiment sets different verification rules corresponding to the first and second verifications for different container group migration types, thereby accurately identifying whether the migration request corresponding to the container group is valid and reasonable, thereby realizing multi-dimensional migration of the container group in terms of designated nodes, same block, cross-block, and cross-resource pools.

[0075] refer to Figure 5 , Figure 5 This is a flowchart of the third embodiment of the container group migration method of the present application.

[0076] In a feasible implementation, the container group includes a first container group and a second container group, and step S2 may include:

[0077] Step S21: determining a migration policy of the container group based on the migration request, where the migration policy includes modification policies corresponding to associated resources in the container group.

[0078] Step S22: deleting the first container group, and updating the second container group according to the migration policy to execute a rescheduling process of the container group.

[0079] It should be noted that the first container group refers to the container group to be migrated, and the second container group refers to the target migration container group of the container group to be migrated.

[0080] In the specific implementation, you can refer to Figure 6 , Figure 6 This is a schematic diagram of the architecture for implementing the container group migration method in this application. Figure 6In the , operation and maintenance service is deployed using Deployment, and the service runs in the pod. When the user's Request requests access to the service interface, the service will perform the migration task according to the core process of the present invention. CRD is the definition interface of the configuration parameters. The operator monitors the new update messages of CRD and creates or updates sts and some other resources. Use sts to create and manage business pods. When the migration is initiated, cdd-operation-system modifies the CRD information (such as scheduling strategy, rolling update strategy), and then deletes the pod. Statefulset will rebuild the pod according to the updated version, and the new pod will be scheduled to the target machine. Other dependent components are components that only the business database depends on. These components record some data of the business database. Migration causes these data to change, and cdd-operation-system will modify these data.

[0081] In a feasible implementation, the container group migration method may further include:

[0082] Step S4: when it is detected that the migration request passes the verification, the current information in the container group is backed up to obtain backup information, and the backup information is written into the database.

[0083] Step S5: When it is detected that the migration of the container group is successful or failed, it is determined that the migration of the container group is completed, and the execution result and execution log corresponding to the migration success or migration failure are written into the database.

[0084] In its implementation, the cdd-operation-system performs a series of checks on the user's request before migrating the pod. To ensure the normal operation of the migrated pod, the system also synchronizes and modifies the pod's associated resources, such as PVCs, CRDs, and DNS resources. This system records all error messages and execution logs from the migration process (including successful and failed migrations) in the database, making it easier for users to review and troubleshoot errors.

[0085] In addition, the present invention is built on the Kubernetes ecosystem, which is a container orchestration and scheduling management framework. As a leading container orchestration engine, Kubernetes provides an abstraction layer that enables the deployment of container applications in physical or virtual environments, providing a container-centric infrastructure. In Kubernetes, all containers run in pods. A pod can host one or more related containers. In the latter case, containers in the same pod will be deployed on the same physical machine and can share resources. A pod can also contain 0 or more disk volume groups (volumes), which will be provided to a container in the form of directories or shared by all containers in the pod. For each pod created by the user, the system will automatically select a healthy machine with sufficient capacity and then create a container similar to the container. When container creation fails, the container will be automatically restarted by Kubelet, but if the pod fails or the machine fails, it will not be automatically transferred and started unless the user defines a replication controller.

[0086] This embodiment determines the migration strategy of the container group based on the migration request, and the migration strategy includes the modification strategy corresponding to the associated resources in the container group; deletes the first container group, and updates the second container group according to the migration strategy to execute the rescheduling process of the container group; when it is detected that the migration request passes the verification, the current information in the container group is backed up to obtain the backup information, and the backup information is written into the database; when it is detected that the migration of the container group is successful or failed, it is determined that the migration of the container group is completed, and the execution result and execution log corresponding to the migration success or migration failure are written into the database. The above method of this embodiment dynamically determines the migration strategy (including the modification strategy of the associated resources) based on the migration request, and automatically deletes the first container group and updates the second container group to execute the rescheduling process, which significantly reduces manual intervention, accelerates the container group migration process, and improves system resource utilization; at the same time, it automatically determines the end of the migration when the migration succeeds or fails, and writes the execution result and log into the database, which is convenient for post-monitoring, fault diagnosis and performance analysis, and improves system stability and operation and maintenance efficiency.

[0087] Reference Figure 7 , Figure 7 This is a structural block diagram of the first embodiment of the container group migration device of the present application.

[0088] like Figure 7 As shown, the container group migration device proposed in the embodiment of the present application includes:

[0089] A request verification module 701 is configured to verify, upon receiving a migration request from a user for a container group, whether each container in the container group is in a working state and / or a non-working state;

[0090] a process execution module 702 configured to determine a migration strategy for the container group based on the migration request if the migration request passes verification, and execute a rescheduling process for the container group according to the migration strategy;

[0091] A first determination module 703 is configured to determine that the container group migration is successful if the rescheduling process is completed;

[0092] The second determination module 704 is configured to determine that the container group migration has failed if the migration request fails to pass verification or the rescheduling process is not completed.

[0093] When receiving a migration request from a user for a container group, this embodiment verifies the migration request and determines whether each container in the container group is in a working state and / or a non-working state. If the migration request passes the verification, the migration strategy of the container group is determined based on the migration request, and the rescheduling process of the container group is executed according to the migration strategy. If the rescheduling process is completed, the migration of the container group is determined to be successful. If the migration request fails the verification or the rescheduling process is not completed, the migration of the container group is determined to be unsuccessful. The above method of this embodiment executes the rescheduling process of the container group according to the migration strategy when the migration request from the user for the container group passes the verification, and monitors the migration process of the container group based on whether the rescheduling process is completed and whether the migration request passes the verification, thereby achieving more intelligent container group resource deployment and ensuring the migration effect of the container group. At the same time, this embodiment supports the migration of container groups in a working state and / or a non-working state, which means that the migration operation does not force the container to stop service, thereby being able to adapt to the needs of different business scenarios.

[0094] Based on the first embodiment of the container group migration device of the present application, a second embodiment of the container group migration device of the present application is proposed.

[0095] In this embodiment, the request verification module 701 is further configured to, upon receiving a migration request from a user for a container group, perform a first verification on the migration request based on the migration type of the container group; and if the migration request passes the first verification, perform a second verification on the migration request based on migration parameters included in the migration request.

[0096] Furthermore, the request verification module 701 is further configured to, if the migration type of the container group is cross-resource block migration, perform a first verification on the migration request based on whether the migration request contains the container group name, namespace, and resource pool type of the target node; and if the migration type of the container group is same-resource block migration, perform a first verification on the migration request based on whether the migration request contains the container group name, namespace, and resource pool type or node name of the target node.

[0097] Furthermore, the migration parameter is a first parameter or a second parameter, and the request verification module 701 is also used to perform a second verification on the migration request according to the first parameter contained in the migration request if the migration type of the container group is cross-resource block migration, and the first parameter includes the stateful application set status, cluster version, PVC information, resource block information and DNS validity; if the migration type of the container group is same-resource block migration, the migration request is performed a second verification according to the second parameter contained in the migration request, and the second parameter includes the cluster version, PVC information and resource block information.

[0098] Furthermore, the container group includes a first container group and a second container group. The process execution module 702 is further configured to determine a migration policy for the container group based on the migration request, where the migration policy includes a modification policy corresponding to associated resources in the container group; delete the first container group, and update the second container group according to the migration policy to execute the rescheduling process for the container group.

[0099] Furthermore, the process execution module 702 is further configured to determine a migration policy for the container group based on the migration request, where the migration policy includes a modification policy corresponding to associated resources in the container group; delete the first container group, and update the second container group according to the migration policy to execute the rescheduling process for the container group.

[0100] Other embodiments or specific implementations of the container group migration device of the present application can refer to the above-mentioned method embodiments and will not be repeated here.

[0101] The present application provides a container group migration device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the container group migration method described in the first embodiment.

[0102] Reference below Figure 8, which shows a schematic diagram of the structure of a container group migration device suitable for implementing embodiments of the present application. The container group migration device in the embodiments of the present application can include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The container group migration device shown is only an example and should not limit the functions and scope of use of the embodiments of the present application.

[0103] like Figure 8 As shown, the container group migration device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the container group migration device. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems may be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and a communication device 1009. Communication device 1009 can allow the container group migration device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a container group migration device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0104] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0105] The container group migration device provided in this application utilizes the container group migration method described in the aforementioned embodiment, resolving the technical issue of existing container group migration methods, which struggle to guarantee migration results. Compared to existing technologies, the container group migration device provided in this application achieves the same beneficial effects as the container group migration method described in the aforementioned embodiment. Other technical features of the container group migration device are the same as those disclosed in the aforementioned embodiment and are not further elaborated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0107] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0108] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, wherein the computer-readable program instructions are used to execute the container group migration method in the above embodiment.

[0109] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, 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 thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0110] The computer-readable storage medium may be included in the container group migration device, or may exist independently without being assembled into the container group migration device.

[0111] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the container group migration device, the container group migration device can write computer program code for performing the operations of the present application in one or more programming languages ​​or a combination thereof. The programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++; and also include conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user computer, partially on the user computer, as a separate software package, partially on the user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user computer via any type of network, such as a local area network (LAN) or a wide area network (WAN), or connected to an external computer (for example, via the Internet using an Internet service provider).

[0112] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0113] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0114] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned container group migration method. This computer-readable storage medium can address the technical issue of existing container group migration methods, which struggle to ensure migration effectiveness. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the container group migration method provided in the aforementioned embodiments, and are not further elaborated here.

[0115] The present application also provides a computer program product, including a computer program, which implements the steps of the container group migration method as described above when executed by a processor.

[0116] The computer program product provided in this application can solve the technical problem of container group migration. Compared with the existing technology, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the container group migration method provided in the above embodiment, and will not be repeated here.

[0117] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A container group migration method, characterized in that: The method comprises the following steps: When receiving a migration request from a user for a container group, verifying that each container in the container group is in a working state and / or a non-working state; If the migration request passes the verification, determining a migration strategy for the container group based on the migration request, and executing a rescheduling process for the container group according to the migration strategy; If the rescheduling process is completed, it is determined that the migration of the container group is successful; If the migration request fails to pass verification or the rescheduling process is not completed, it is determined that the container group migration has failed.

2. The container group migration method according to claim 1, wherein: The step of verifying the migration request when receiving the migration request from the user for the container group includes: When receiving a migration request for a container group from a user, performing a first verification on the migration request according to the migration type of the container group; If the migration request passes the first verification, a second verification is performed on the migration request according to the migration parameters included in the migration request.

3. The container group migration method according to claim 2, wherein: The step of performing a first verification on the migration request for a container group according to the migration type of the container group upon receiving the migration request from the user includes: If the migration type of the container group is cross-resource block migration, performing a first verification on the migration request based on whether the migration request contains the container group name, namespace, and resource pool type of the target node; If the migration type of the container group is same resource block migration, the migration request is first verified according to whether the migration request contains the container group name, namespace, and resource pool type or node name of the target node.

4. The container group migration method according to claim 2, wherein: The migration parameter is a first parameter or a second parameter, and the step of performing a second verification on the migration request according to the migration parameter included in the migration request includes: If the migration type of the container group is cross-resource block migration, performing a second verification on the migration request according to a first parameter included in the migration request, where the first parameter includes a stateful application set state, a cluster version, PVC information, resource block information, and DNS validity; If the migration type of the container group is same resource block migration, the migration request is verified for the second time according to the second parameter included in the migration request, where the second parameter includes the cluster version, PVC information, and resource block information.

5. The container group migration method according to claim 1, wherein: The container group includes a first container group and a second container group. The step of determining a migration strategy for the container group based on the migration request and executing a rescheduling process for the container group according to the migration strategy includes: Determining a migration policy for the container group based on the migration request, where the migration policy includes modification policies corresponding to associated resources in the container group; The first container group is deleted, and the second container group is updated according to the migration policy to execute a rescheduling process of the container group.

6. The container group migration method according to claim 1, wherein: The method further comprises: When it is detected that the migration request passes the verification, backing up the current information in the container group to obtain backup information, and writing the backup information into a database; When it is detected that the migration of the container group is successful or failed, it is determined that the migration of the container group is completed, and the execution result and execution log corresponding to the migration success or migration failure are written into the database.

7. A container group migration device, characterized in that: The container group migration device includes: a request verification module, configured to, upon receiving a migration request from a user for a container group, verify that each container in the container group is in a working state and / or a non-working state; a process execution module, configured to determine a migration strategy for the container group based on the migration request if the migration request passes verification, and execute a rescheduling process for the container group according to the migration strategy; A first determination module, configured to determine that the migration of the container group is successful if the rescheduling process is completed; The second determination module is configured to determine that the migration of the container group has failed if the migration request fails to pass verification or the rescheduling process is not completed.

8. A container group migration device, characterized in that: The device includes: a memory, a processor, and a container group migration program stored in the memory and executable on the processor, wherein the container group migration program is configured to implement the steps of the container group migration method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium. A container group migration program is stored on the storage medium. When the container group migration program is executed by a processor, the steps of the container group migration method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product includes a container group migration program, which, when executed by a processor, implements the steps of the container group migration method according to any one of claims 1 to 6.

Images