Container deployment processing method and device, equipment, storage medium and program product

Abstract

The invention relates to the technical field of cloud computing, provides a container deployment processing method and device, equipment, a storage medium and a program product, and can avoid the problem of unavailability caused by a fault of a single container scheduling engine cluster. Receiving a deployment record creation request sent by a user for the micro-application in the service system; when a container scheduling engine cluster meeting the resource requested by the user exists in a resource pool specified by the creation request, determining the container scheduling engine cluster meeting a workload distribution strategy in the resource pool according to the workload distribution strategy in the deployment record to obtain a target container scheduling engine cluster; according to the workload template in the deployment record, performing workload deployment on the target container scheduling engine cluster; and when sensing that the state of the workload is abnormal, determining other container scheduling engine clusters meeting the workload distribution strategy in the resource pool, and deploying the workload on the other container scheduling engine clusters according to the workload template.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and in particular to a container deployment processing method and device, computer equipment, a storage medium and a computer program product. BACKGROUND

[0002] In the technical field of cloud computing, a container scheduling engine cluster (such as kubernets) can be used for deployment and management of containers. The container scheduling engine cluster can include management type hosts and computing type hosts. A user can perform a container deployment action on a certain container scheduling engine cluster. However, the deployment action is responsible for the deployment task or the deployment result. After a container is successfully deployed on a certain container scheduling engine cluster, if the container has a problem, the container can only be restarted and retried to attempt to restore the container to normal. SUMMARY

[0003] Therefore, it is necessary to provide a container deployment processing method and device, computer equipment, a storage medium and a computer program product to solve the above technical problems.

[0004] The present application provides a container deployment processing method, which comprises the following steps:

[0005] receiving a creation request of a deployment record issued by a user for a micro application in a business system;

[0006] When a container scheduling engine cluster that meets the resource requested by the user exists in a resource pool specified by the creation request, determining a target container scheduling engine cluster that meets a workload distribution strategy in the resource pool according to the workload distribution strategy in the deployment record;

[0007] deploying a workload on the target container scheduling engine cluster according to a workload template in the deployment record;

[0008] When it is perceived that the state of the workload is abnormal, determining other container scheduling engine clusters that meet the workload distribution strategy in the resource pool, and deploying the workload on the other container scheduling engine clusters according to the workload template.

[0009] The present application provides a container deployment processing device, which comprises the following modules:

[0010] a creation request receiving module configured to receive a creation request of a deployment record issued by a user for a micro application in a business system;

[0011] The cluster determination module is configured to, when there is a container scheduling engine cluster satisfying the resource requested by the user in the resource pool specified by the creation request, determine, according to a workload distribution strategy in the deployment record, a container scheduling engine cluster satisfying the workload distribution strategy in the resource pool, to obtain a target container scheduling engine cluster.

[0012] The deployment processing module is configured to perform deployment of the workload on the target container scheduling engine cluster according to a workload template in the deployment record.

[0013] The exception processing module is configured to, when a state exception of the workload is perceived, determine another container scheduling engine cluster satisfying the workload distribution strategy in the resource pool, and perform deployment of the workload on the another container scheduling engine cluster according to the workload template.

[0014] The application provides a computer device, comprising a memory and a processor, the memory stores a computer program, and the processor executes the above method.

[0015] The application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to execute the above method.

[0016] The application provides a computer program product, which stores a computer program, and the computer program is executed by a processor to execute the above method.

[0017] The container deployment processing method, device, computer device, storage medium and computer program product provided in the application receive a creation request of a deployment record issued by a user for a micro application in a business system; when a container scheduling engine cluster satisfying the resources requested by the user exists in a resource pool specified by the creation request, a container scheduling engine cluster satisfying a workload distribution strategy in the resource pool is determined according to the workload distribution strategy in the deployment record, and a target container scheduling engine cluster is obtained; the deployment of the workload is performed on the target container scheduling engine cluster according to the workload template in the deployment record; when the state of the workload is sensed to be abnormal, other container scheduling engine clusters satisfying the workload distribution strategy in the resource pool are determined, and the deployment of the workload is performed on the other container scheduling engine clusters according to the workload template. In the scheme provided in the application, when the user needs to deploy a container, the user can control in the level of a business system (which can be referred to as a product)-micro application, so that the user can be shielded from perceiving the container scheduling engine cluster; after the deployment of the workload is performed on the target container scheduling engine cluster satisfying the workload distribution strategy in the resource pool according to the workload distribution strategy and the workload template in the deployment record, the state of the workload can be continuously monitored, and when the state is abnormal, the deployment of the workload can be performed on the other container scheduling engine clusters satisfying the workload distribution strategy in the resource pool according to the workload template. In this way, when the state of the workload on the target container scheduling engine cluster is abnormal, the workload can be timely replaced to the other container scheduling engine cluster, the unavailability problem caused by the failure of a single container scheduling engine cluster can be avoided, and the full life cycle management of the workload can be implemented, instead of being limited to a one-time deployment task. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the application or the related art, the following will briefly introduce the drawings needed to be used in the embodiments or the related art description. Obviously, the drawings in the following description only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0019] Figure 1 A flowchart of a container deployment processing method in an embodiment;

[0020] Figure 2 An upgrade processing flowchart in an embodiment;

[0021] Figure 3 A multi-active deployment architecture diagram in an embodiment;

[0022] Figure 4 A structural block diagram of a container deployment processing device in an embodiment;

[0023] Figure 5 Figure 1 is a schematic diagram of the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0024] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and not intended to limit the present application.

[0025] It should be noted that the terms "first", "second", etc. used in the present application can be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The terms "include" and "have" used in the present application and any variations thereof are intended to cover non-exclusive inclusion. The term "multiple" used in the present application refers to two or more. The term "and / or" used in the present application refers to one of the options or any combination of multiple options.

[0026] The container deployment processing method provided by the present application can be applied to a multi-live deployment platform, which can include Figure 1 The steps shown.

[0027] In step S101, a creation request of a deployment record issued by a user for a micro application in a business system is received.

[0028] The business system can be referred to as a product, and the business system can include several micro applications. For a user, the user will experience the following processes when creating a deployment record: 1, select a business system; 2, select a micro application; 3, create a deployment record.

[0029] Among them, the user can select the corresponding business system and the micro application under the business system, and issue a creation request of a deployment record for the micro application. The management and control service of the multi-live deployment platform can receive the creation request. Among them, the deployment record can include two configuration files, which are a workload template (which can be referred to as a workload configuration file) and a workload distribution strategy (which can be referred to as a scheduling configuration file). The creation request can also carry a resource pool specified by the user, such as the user can specify a resource pool A in multiple resource pools. The resource pool includes multiple container scheduling engine clusters (such as kubernets). Each resource pool can have its own multi-live scheduling component.

[0030] In step S102, when there is a container scheduling engine cluster in the resource pool specified by the creation request that meets the resources requested by the user, the container scheduling engine cluster in the resource pool that meets the workload distribution strategy in the deployment record is determined according to the workload distribution strategy in the deployment record, and a target container scheduling engine cluster is obtained.

[0031] After receiving a creation request, the management service of the multi-active deployment platform can record the information submitted by the user and perform resource-level verification, such as the user requesting a workload for a container with 1 CPU. The management service can determine the resource pool specified in the creation request and check whether the container scheduling engine cluster in that resource pool has a container scheduling engine cluster that can meet the user's requested resources. If so, the management service can send the workload template and workload distribution policy from the deployment record to the multi-active scheduling component in the multi-active deployment platform corresponding to the specified resource pool. For example, if resource pool A is specified, the management service can send the workload template and workload distribution policy to the multi-active scheduling component corresponding to resource pool A.

[0032] Taking a specified resource pool A as an example, the multi-active scheduling component can determine the container scheduling engine cluster in resource pool A that meets the workload distribution strategy based on the workload distribution strategy. This container scheduling engine cluster can be referred to as the target container scheduling engine cluster.

[0033] Workload distribution policies can include resource pool information. Based on the resource pool information in the workload distribution policy, the container scheduling engine clusters within the resource pool that meet the workload distribution policy can be identified. Under different deployment modes, workload distribution policies can also include corresponding information. For example, if the deployment mode is a specified cluster deployment mode, the workload distribution policy can include the name of the specified container scheduling engine cluster, and subsequently, the container scheduling engine cluster corresponding to that name can be used as the target container scheduling engine cluster. Another example is if the deployment mode is a multi-availability domain deployment mode, the workload distribution policy can include the name of the specified availability domain, and subsequently, the target container scheduling engine cluster can be determined from the container scheduling engine clusters located in the corresponding availability domain. The availability domain name can be a network region name.

[0034] Step S103: Deploy the workload on the target container scheduling engine cluster according to the workload template in the deployment record.

[0035] After identifying the target container scheduling engine cluster, the multi-active scheduling component can deploy workloads on the target container scheduling engine cluster based on the workload templates in the deployment record.

[0036] Workload templates can be used to describe the containers to be run, the number of replicas, network, storage, configuration, etc. Deploying a workload involves pulling an image from the target container scheduling engine cluster, creating pods (container groups), and running the pods to deploy the containers.

[0037] A workload template can include application startup-related content, but it may not include distribution strategies. A workload template can be considered consistent with native Kubernetes workload configuration information, belonging to Kubernetes-recognizable configuration information. A workload template can also be called a workload configuration file. It can be understood that after receiving a workload template, Kubernetes' internal control logic (controller) can start containers based on the workload configuration information in the template.

[0038] The multi-active deployment platform can monitor workloads periodically. Specifically, the multi-active scheduling component can intermittently collect status information of workloads deployed on the target container scheduling engine cluster.

[0039] Step S104: When an abnormal workload status is detected, other container scheduling engine clusters that meet the workload distribution strategy within the resource pool are identified, and the workload is deployed on other container scheduling engine clusters according to the workload template.

[0040] Taking a designated resource pool A as an example, when the multi-active scheduling component determines that the workload is in an abnormal state based on the status information, it can identify other container scheduling engine clusters within resource pool A that meet the workload distribution strategy. Based on the workload template, the workload can be deployed on other container scheduling engine clusters, thereby enabling timely startup of the workload on other container scheduling engine clusters that meet the workload distribution strategy. This is not limited to completing a single deployment task and can achieve full lifecycle management of the workload.

[0041] In the above container deployment processing method, a request to create a deployment record from a user for a micro-application in the business system is received. When a container scheduling engine cluster that meets the user's requested resources exists in the resource pool specified by the creation request, the container scheduling engine cluster that meets the workload distribution policy in the deployment record is determined, and the target container scheduling engine cluster is obtained. The workload is deployed on the target container scheduling engine cluster according to the workload template in the deployment record. When an abnormal workload status is detected, other container scheduling engine clusters that meet the workload distribution policy in the resource pool are determined, and the workload is deployed on other container scheduling engine clusters according to the workload template. In the solution provided in this application, when a user needs to deploy containers, the user can control the deployment at the level of business system (which can be called product) - micro-application, thereby shielding the user from awareness of the container scheduling engine cluster. After the workload is deployed on the target container scheduling engine cluster that meets the workload distribution policy in the deployment record according to the workload distribution policy and workload template, the status of the workload can continue to be monitored. When the status is abnormal, the workload can be deployed on other container scheduling engine clusters in the resource pool that meet the workload distribution policy, and the workload can be deployed on other container scheduling engine clusters according to the workload template. In this way, when the status of the workload on the target container scheduling engine cluster is abnormal, it can be switched to other container scheduling engine clusters in a timely manner, which can avoid the unavailability problem caused by the failure of a single container scheduling engine cluster. It can realize the full life cycle management of the workload, rather than being limited to completing a deployment task.

[0042] In one embodiment, the method provided in this application further includes Figure 2 The steps shown are as follows:

[0043] Step S201: Receive the user's upgrade request for the deployment record; Step S202: Determine whether to perform an upgrade operation based on the upgrade request, depending on whether the resource requirements corresponding to the upgrade request have changed before and after the upgrade.

[0044] When a user upgrades a deployment record, they can submit an upgrade request. The management service receives this request, records the information submitted by the user, and performs resource-level verification, such as a user requesting to upgrade the workload of a container with 1 CPU. The management service then proceeds to conditional checks. It determines whether resource requirements have changed before and after the upgrade, obtains the result, and decides whether to perform the upgrade based on the request.

[0045] This embodiment can make relatively intelligent upgrade decisions based on changes in resource requirements before and after the upgrade, enabling precise control of the upgrade operation and resource optimization.

[0046] In one embodiment, determining whether to perform an upgrade operation based on the upgrade request, according to whether the resource requirements corresponding to the upgrade request have changed before and after the upgrade, includes:

[0047] If the resource requirements corresponding to the upgrade request remain unchanged before and after the upgrade, the upgrade request will be allowed to proceed, and the upgrade operation will be performed on the workload of the corresponding container scheduling engine cluster according to the upgrade request. If the resource requirements corresponding to the upgrade request change before and after the upgrade, it will be determined whether the resource quota corresponding to the business system supports the upgrade, so as to determine whether to perform the upgrade operation based on the upgrade request.

[0048] Upon receiving an upgrade request, the management service can determine whether resource requirements have changed before and after the upgrade. Specifically, it can check if the current resource usage of the container corresponding to the upgrade request matches the target value after the upgrade. If they match, it can be determined that resource requirements have not changed before and after the upgrade, and the management service can allow the upgrade request and send it to the multi-active scheduling component. The multi-active scheduling component can then perform the upgrade operation on the workload of the corresponding container scheduling engine cluster based on the upgrade request. If resource requirements have changed before and after the upgrade, the management service can further determine whether the resource quota corresponding to the business system supports the upgrade, thereby determining whether to perform the upgrade operation based on the upgrade request.

[0049] In this embodiment, if the resource requirements remain unchanged before and after the upgrade, the upgrade request can be approved, which can solve the problem of wasted resource quotas caused by the upgrade and ensure the continuity of services corresponding to the container. If the resource requirements change before and after the upgrade, an intelligent upgrade decision can be made based on whether the resource quota corresponding to the business system supports the upgrade, which can effectively prevent resource overload caused by the upgrade.

[0050] In one embodiment, determining whether the resource quota corresponding to the business system supports the upgrade, in order to determine whether to perform an upgrade operation based on the upgrade request, includes:

[0051] If the resource quota corresponding to the business system does not support the upgrade, the upgrade request is rejected; if the resource quota corresponding to the business system supports the upgrade, the upgrade operation is performed on the workload of the corresponding container scheduling engine cluster according to the upgrade request.

[0052] For example, a certain business system has an available resource quota of 10 CPUs. If the currently used resource quota is 9 CPUs, then the remaining resource quota is 1 CPU. If this upgrade requires adding 1 CPU, the management service can determine that the resource quota corresponding to the business system supports this upgrade. The management service can then send the upgrade request to the multi-active scheduling component. The multi-active scheduling component can then perform the upgrade operation on the workload of the corresponding container scheduling engine cluster according to the upgrade request.

[0053] If this upgrade requires the addition of 2 CPUs, the management service can determine that the resource quota corresponding to the business system does not support this upgrade, and can reject the upgrade request to avoid resource overload caused by the upgrade.

[0054] In one embodiment, the method provided in this application further includes:

[0055] Based on the access control file of the container scheduling engine cluster's interface, the connectivity of the container scheduling engine cluster is verified; if the verification passes, the container scheduling engine cluster is added to the resource pool.

[0056] Taking Kubernetes as an example, each Kubernetes cluster has an access control file for its corresponding interface, which can be referred to as kubeconfig. When a multi-active deployment platform performs the action of adding a cluster to a resource pool, it can verify the connectivity of the corresponding cluster through kubeconfig. If the verification is successful, the corresponding Kubernetes cluster can be added to the resource pool.

[0057] The multi-active deployment platform can call the interfaces of Kubernetes added to the resource pool through kubeconfig. These calls allow access to resource information, host machine information, and workload information. The platform's metadata database maintains a corresponding cluster type table for each Kubernetes instance. This table contains basic cluster information, such as IP address, availability zone, and tag information.

[0058] In one embodiment, the resource pool comprises a cluster of container scheduling engines in different network regions.

[0059] Taking Kubernetes as an example of a container scheduling engine cluster, a single resource pool can manage Kubernetes in multiple network regions, thus enabling a single deployment record to be deployed to multiple Kubernetes instances in different availability zones.

[0060] To better understand the above method, the following details an application example of the container deployment processing method described in this application. The container scheduling engine cluster can use Kubernetes. The deployment record includes a pair of workload templates and a workload distribution strategy; where workload is a concept belonging to the container scheduling engine cluster (such as Kubernetes), and is a management concept above a group of containers. The hierarchy can be understood as workload-pods-containers, a 1:N:N relationship.

[0061] Kubernetes includes management hosts and compute hosts. During deployment, users can deploy containers on a specific Kubernetes cluster. Deployed containers can appear on both management and compute hosts within the same Kubernetes cluster. For deployments across multiple Kubernetes clusters, deployments can be initiated sequentially on the target Kubernetes clusters.

[0062] In related technologies, the computing resources within a single Kubernetes cluster have an upper limit. Since resource management needs to be handled by a management program on a management-type host, this results in a limit on the amount of computing resources that a single Kubernetes cluster can manage. In other words, a single Kubernetes cluster cannot provide an unlimited amount of resources.

[0063] To ensure management stability, a single Kubernetes cluster typically places management and compute hosts on the same network or in a network with low latency. This means that when deploying across networks or regions using a single Kubernetes cluster, the management programs on the management hosts are susceptible to network latency issues, leading to misjudgments (such as incorrectly identifying a container as not alive or incorrectly identifying a compute host as disconnected).

[0064] In related technologies, when the native Kubernetes scheduler limits resources, if the container startup rule is to start a new container first and then delete the old container, it will result in the need to set the resource quota to be twice the actual resource usage. For example, if a 1-CPU container is started, due to the aforementioned update rule, a 2-CPU quota needs to be set to support the startup of the new container, and then the old container is deleted, resulting in a waste of resources.

[0065] Related technologies can initiate sequential deployments across multiple Kubernetes clusters, which can solve the multi-Kubernetes deployment problem to some extent. However, this only provides responsibility for the deployment task or the deployment result, not for the entire lifecycle of the container. For example, after a container is successfully deployed, no subsequent management is provided. When a container encounters a problem, it can only rely on Kubernetes' own scheduling to restart and retry within a single Kubernetes cluster. There is a lack of external programs to schedule containers across Kubernetes clusters. This means that when a Kubernetes cluster fails as a whole, such as due to a local network failure, even if containers within a single Kubernetes cluster are restarted, the service cannot be restored to normal.

[0066] The related Kubernetes technology only manages deployments and containers, lacking higher-level management concepts. In this application instance, the concepts of business systems and micro-applications are introduced. Deployments can be regarded as instances of micro-applications. The relationship between business systems, micro-applications, and deployments can be 1:N:N. The related Kubernetes technology struggles to manage this concept and finds it difficult to limit the resource quotas used by business systems across clusters.

[0067] This application example provides a serverless architecture-based active-active deployment solution for applications. It combines multiple Kubernetes instances into a resource pool, allowing scheduling to be performed within this pool. This overcomes the limitations of managing computing resources with a single Kubernetes instance, enabling the simultaneous management of approximately 10 Kubernetes instances. Individual Kubernetes instances can be placed on the same network, reducing network latency. Kubernetes instances within a resource pool can originate from different network regions, enabling cross-network region deployment of a single service.

[0068] This application instance takes over some of the scheduling work of the native Kubernetes to a certain extent. Therefore, resource management can be performed on the multi-active deployment platform implemented in this application instance. During upgrades, it can check whether the current container resource usage is consistent with the target value after the upgrade. If they are consistent, the upgrade policy (i.e., the upgrade request) is allowed. This can avoid the aforementioned waste in resource management.

[0069] The solution provided in this application example allows you to define deployment strategies that apply to the native Kubernetes objects `deployments`, which in turn deploy containers. This allows you to determine the type of cluster a user wants to deploy on. For example, if a user's deployment strategy selects three clusters—Kubernetes A, B, and C—then when a container on Kubernetes A fails, it can be migrated to Kubernetes B, thus resolving unavailability issues caused by a single Kubernetes failure.

[0070] This application example follows a product-microapplication-deployments hierarchy, allowing users to control the application directly at the product-microapplication level, thus shielding them from the awareness of Kubernetes.

[0071] The multi-active deployment platform implemented based on this application example has the following two management concepts:

[0072] For operators of multi-active deployment platforms, the hierarchy they see can be: resource pool - cluster - workload; for users, the hierarchy can be: product - micro-application - deployment record - workload; the two have different management structures.

[0073] The following describes how a single deployment is completed from the user's perspective.

[0074] For users, creating a deployment record involves the following steps: 1. Select a product; 2. Select a micro-application; 3. Create a deployment record; 4. The multi-active scheduling component of the multi-active deployment platform can transform the deployment record into a workload and distribute it to various clusters.

[0075] Deployment records can include two configuration files: a workload template (which can be called a workload configuration file) and a workload distribution policy (which can be called a scheduling configuration file or deployment policy). The multi-active scheduling component can select clusters that meet the workload distribution policy based on the workload distribution policy, and then deploy the workloads on the corresponding clusters using the workload template.

[0076] The following describes how to manage multiple Kubernetes instances using a multi-active deployment platform.

[0077] Each Kubernetes node can have its own access control file for its interface, which can be denoted as kubeconfig. When a multi-active deployment platform performs the action of adding a cluster to a resource pool, it can verify the connectivity of the corresponding cluster through kubeconfig. If the verification is successful, the corresponding Kubernetes node can be added to the resource pool.

[0078] The multi-active deployment platform can call the interfaces of Kubernetes added to the resource pool through kubeconfig. By calling the interfaces, it can obtain resource information, host information, and workload information.

[0079] The metadata database of a multi-active deployment platform can maintain a corresponding cluster type table for each Kubernetes cluster. The cluster type table contains basic cluster information, such as cluster IP information, cluster availability domain information, and cluster tag information.

[0080] When a user initiates a request to create a deployment record, the request can enter the management service of the multi-active deployment platform. The management service can record the information submitted by the user and perform resource-level verification, such as the user requesting a workload of a container with 1 CPU. The management service can check whether there are clusters in the resource pool that meet the conditions. If so, it can send the workload template and workload distribution policy to the multi-active scheduling component.

[0081] The multi-active scheduling component can select clusters that meet the workload distribution strategy and deploy workloads on the corresponding clusters using workload templates. The multi-active scheduling component can intermittently collect the status information of the workloads deployed on the corresponding clusters.

[0082] When a user initiates an upgrade request for a deployed system, the request enters the management service. The management service records the information submitted by the user and performs resource-level verification, such as when a user requests to upgrade a 1-CPU container workload. The management service can make the following judgments: 1. Whether the user's resource requirements have changed before and after the upgrade; if not, the upgrade request can be sent to the multi-active scheduling component to perform the corresponding cluster workload upgrade operation. 2. If there have been changes, it can verify whether the resource quota configured by the user for the business system can support this upgrade. If it cannot, the user's upgrade request can be rejected; if it can, the upgrade request can be sent to the multi-active scheduling component for upgrade.

[0083] The multi-active deployment architecture diagram for this application example can be referenced. Figure 3 Among them, the multi-active deployment platform can be called the multi-active management and control platform. Figure 3 The example shown can include two resource pools, denoted as resource pool A and B, each with a corresponding multi-active scheduling component. The resource pools can be a k8s-cluster, where k8s is an abbreviation for Kubernetes. A k8s-cluster can include multiple members, each corresponding to a Kubernetes instance. Each member can manage resources through namespaces, and workloads (such as deployments) can be deployed within these namespaces.

[0084] In this application example, a single resource pool can manage multiple Kubernetes instances, resolving the management limitations of a single Kubernetes instance. Furthermore, hosts within a single Kubernetes instance can originate from the same availability zone, reducing misjudgments caused by network latency and other issues. Additionally, a single resource pool can manage Kubernetes instances from various network regions, allowing a single deployment record to be deployed across multiple Kubernetes instances in different availability zones.

[0085] This application example enhances scheduling rules when deployed on a real Kubernetes cluster. It records user resource quota information on the multi-active deployment platform, allowing the platform to centrally manage how many resources a single business system can use. This solves the problem of setting resource quotas for each Kubernetes cluster in related management models, while also avoiding the highly fragmented management issues associated with such models. This application example can also be enhanced for upgrade scenarios. If the resource quota requirements recorded before and after a user's upgrade remain unchanged, the upgrade request can be allowed, resolving the resource quota waste caused by past upgrades.

[0086] A multi-active deployment platform can monitor workloads periodically, enabling real-time awareness of the workload status created by deployment records. When a workload status becomes abnormal, it can promptly launch the workload on other Kubernetes instances that meet the deployment policy using the workload templates and distribution strategies in the deployment records. This goes beyond simply completing a single deployment task, enabling full lifecycle management of workloads.

[0087] This application example creates two management logics on a multi-active deployment platform: for platform operations personnel, the visible hierarchy is: resource pool - cluster - workload; for users, the visible hierarchy is: business system - micro-application - deployment record - workload. This solves the problem of Kubernetes lacking product-micro-application logic in its native implementation, while also freeing users from focusing on specific clusters.

[0088] Understandably, the existence of management and control functions allows relevant personnel to view data without strictly adhering to the aforementioned hierarchical structure. For example, operations and maintenance personnel can also view all pods under a specific deployment record within the resource pool. Users can also view all pods under a specific deployment record within the business system's micro-applications' deployment records. Regarding deployment records and workloads, it's understood that deployment records can include workload templates, which can be understood as workload metadata stored on the multi-active scheduling component. Workloads can be metadata information specific to a particular cluster. In terms of name, deployment records and member cluster workloads can be understood as equivalent. For users, the business logic doesn't require focusing on the workloads on member clusters, as most user tasks involve operating on pods, such as viewing logs, executing command lines, deleting pods, and viewing events. In some scenarios, the design can skip the member cluster workload layer and directly aggregate all pod data under the deployment record for display.

[0089] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0090] Based on the same inventive concept, this application also provides a container deployment processing apparatus for implementing the container deployment processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more container deployment processing apparatus embodiments provided below can be found in the limitations of the container deployment processing method described above, and will not be repeated here.

[0091] In one embodiment, such as Figure 4 As shown, a container deployment processing apparatus is provided, comprising:

[0092] Create request receiving module 401, which is used to receive the creation request for deployment record issued by the user for the micro-application in the business system;

[0093] The cluster determination module 402 is used to determine the container scheduling engine cluster in the resource pool that satisfies the workload distribution strategy in the deployment record when there is a container scheduling engine cluster in the resource pool that satisfies the resources requested by the user in the resource pool specified by the creation request, and obtain the target container scheduling engine cluster.

[0094] The deployment processing module 403 is used to deploy workloads on the target container scheduling engine cluster according to the workload template in the deployment record.

[0095] The exception handling module 404 is used to determine other container scheduling engine clusters in the resource pool that meet the workload distribution strategy when the state of the workload is detected to be abnormal, and to deploy the workload on the other container scheduling engine clusters according to the workload template.

[0096] In one embodiment, the apparatus includes an upgrade processing module for:

[0097] Receive an upgrade request from a user for the deployment record; determine whether to perform an upgrade operation based on the upgrade request, depending on whether the resource requirements corresponding to the upgrade request have changed before and after the upgrade.

[0098] In one embodiment, the upgrade processing module is used for:

[0099] If the resource requirements corresponding to the upgrade request remain unchanged before and after the upgrade, the upgrade request is allowed to proceed, and the upgrade operation is performed on the workload of the corresponding container scheduling engine cluster according to the upgrade request. If the resource requirements corresponding to the upgrade request change before and after the upgrade, it is determined whether the resource quota corresponding to the business system supports the upgrade, so as to determine whether to perform the upgrade operation based on the upgrade request.

[0100] In one embodiment, the upgrade processing module is used for:

[0101] If the resource quota corresponding to the business system does not support the upgrade, the upgrade request is rejected; if the resource quota corresponding to the business system supports the upgrade, the upgrade operation is performed on the workload of the corresponding container scheduling engine cluster according to the upgrade request.

[0102] In one embodiment, the apparatus further includes a pool entry processing module for:

[0103] According to the access control file of the container scheduling engine cluster's interface, the connectivity of the container scheduling engine cluster is verified; if the verification passes, the container scheduling engine cluster is added to the resource pool.

[0104] In one embodiment, the resource pool includes a cluster of container scheduling engines in different network regions.

[0105] Each module in the aforementioned container deployment processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0106] In one exemplary embodiment, a computer device is provided, which may be a server and can be applied to a multi-active deployment platform; the internal structure diagram of the computer device may be as follows. Figure 5As shown, the computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores the data involved in the aforementioned methods. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a container deployment processing method.

[0107] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0108] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps in the various method embodiments described above.

[0109] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the various method embodiments described above.

[0110] In one embodiment, a computer program product is provided having a computer program stored thereon, the computer program being executed by a processor of the steps described in the various method embodiments above.

[0111] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0112] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0113] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0114] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A container deployment processing method characterized by comprising: The method comprises: receiving a user's creation request for a deployment record of a micro application in a business system; when there is a container scheduling engine cluster in a resource pool specified by the creation request that meets the user's requested resources, determining a container scheduling engine cluster in the resource pool that meets a workload distribution strategy in the deployment record according to the workload distribution strategy, to obtain a target container scheduling engine cluster; deploying a workload on the target container scheduling engine cluster according to a workload template in the deployment record; when a state anomaly of the workload is perceived, determining other container scheduling engine clusters in the resource pool that meet the workload distribution strategy, and deploying the workload on the other container scheduling engine clusters according to the workload template.

2. The method of claim 1, wherein, The method further comprises: receiving a user's upgrade request for the deployment record; determining whether to perform an upgrade operation based on the upgrade request according to whether there is a change in resource requirements corresponding to the upgrade request before and after the upgrade.

3. The method of claim 2, wherein, Determining whether to perform an upgrade operation based on the upgrade request according to whether there is a change in resource requirements corresponding to the upgrade request before and after the upgrade comprises: if there is no change in resource requirements corresponding to the upgrade request before and after the upgrade, then releasing the upgrade request for processing, to perform an upgrade operation on a workload of a corresponding container scheduling engine cluster according to the upgrade request; if there is a change in resource requirements corresponding to the upgrade request before and after the upgrade, then determining whether a resource quota corresponding to the business system supports the upgrade, to determine whether to perform an upgrade operation based on the upgrade request.

4. The method of claim 3, wherein, Determining whether a resource quota corresponding to the business system supports the upgrade, to determine whether to perform an upgrade operation based on the upgrade request, comprises: if the resource quota corresponding to the business system does not support the upgrade, then rejecting the upgrade request; if the resource quota corresponding to the business system supports the upgrade, then performing an upgrade operation on a workload of a corresponding container scheduling engine cluster according to the upgrade request.

5. The method of claim 1, wherein, The method further comprises: verifying connectivity of a container scheduling engine cluster according to an access control file of an interface of the container scheduling engine cluster; if the verification is passed, then adding the container scheduling engine cluster to a resource pool.

6. The method according to any one of claims 1 to 5, characterized in that, The resource pool comprises container scheduling engine clusters in different network regions.

7. A container deployment processing apparatus characterized by comprising: The apparatus comprises: a creation request receiving module configured to receive a user's creation request for a deployment record of a micro application in a business system; a cluster determining module configured to, when there is a container scheduling engine cluster in a resource pool specified by the creation request that meets the user's requested resources, determine a container scheduling engine cluster in the resource pool that meets a workload distribution strategy in the deployment record according to the workload distribution strategy, to obtain a target container scheduling engine cluster; a deployment processing module configured to deploy a workload on the target container scheduling engine cluster according to a workload template in the deployment record. An exception handling module is configured to determine other container scheduling engine clusters satisfying the workload distribution policy in the resource pool when the state of the workload is sensed to be abnormal, and to perform deployment of the workload on the other container scheduling engine clusters according to the workload template.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 6.

Images