Application resource processing method and device, cloud platform, medium and product

Abstract

Embodiments of the present application disclose an application resource processing method and device, a cloud platform, a medium and a product. The method comprises: receiving a first request sent by a user for performing a cross-cloud management operation on a target application resource in a first cluster; in response to the first request, processing the target application resource to generate a first custom resource definition corresponding to the target application resource; based on the first custom resource definition and a preset analysis module, obtaining an application configuration file corresponding to the first custom resource definition; based on the application configuration file and a preset conversion rule, generating a Kubernetes resource and a deployment operation sequence for the Kubernetes resource; and based on the deployment operation sequence, deploying the Kubernetes resource in the first cluster or a second cluster to complete the cross-cloud management of the target application resource.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an application resource processing method, apparatus, cloud platform, medium, and product. Background Technology

[0002] Currently, managing or migrating applications to the cloud involves a series of steps, including application containerization, cluster planning, network planning, application metadata migration, data migration, and monitoring log switching. Therefore, successfully integrating and managing applications on a cloud platform is a complex task. Typically, due to the complex structure and strong interrelationships of application metadata, even the resource abstraction, policy unification, and state synchronization involved in the management phase are highly challenging to implement. Furthermore, there are few solutions specifically addressing application metadata management in related technologies. Existing methods for migrating application metadata primarily rely on backup and recovery strategies using open-source tools. Specifically, this involves storing Kubernetes objects in a distributed object storage service (DPS) via its application programming interface (API), and then using a recovery controller to restore the metadata on the new cluster. However, this method requires an object storage server for backup, increasing the complexity and cost for users managing application metadata. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide an application resource processing method, apparatus, cloud platform, medium, and product, which can solve the problems of high complexity and cost in user operation of application metadata in related technologies.

[0004] The technical solution of this application is implemented as follows:

[0005] An application resource processing method, applied to a cloud platform, the method comprising:

[0006] Receive a first request from a user to perform cross-cloud management operations on target application resources in the first cluster; wherein the cloud platform manages at least the first cluster and the second cluster;

[0007] In response to the first request, the target application resource is processed to generate a first custom resource definition corresponding to the target application resource;

[0008] Based on the first custom resource definition and the preset parsing module, the application configuration file corresponding to the first custom resource definition is obtained; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process;

[0009] Based on the application configuration file and preset conversion rules, Kubernetes resources and a sequence of deployment operations for the Kubernetes resources are generated; wherein, the preset conversion rules are rules used to convert the application configuration in the application configuration file into Kubernetes resources and deployment logic;

[0010] In the first cluster or the second cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources.

[0011] In the above scheme, when the first request includes a management request, the step of responding to the first request, processing the target application resource, and generating a first custom resource definition corresponding to the target application resource includes:

[0012] The target application resources are subjected to legality and availability verification to obtain the verification results;

[0013] If the verification result indicates that both the legality verification and the availability verification have passed, the application configuration parameters, the identifier of the first cluster, the first namespace and environment identifier of the target application resource are obtained from the management request.

[0014] Based on the preset template, the application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier, the first custom resource definition is generated.

[0015] In the above scheme, generating the first custom resource definition based on the preset template, the application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier includes:

[0016] Based on the identifier of the first cluster and the first namespace, create a first deployment target;

[0017] Associating the first deployment target with the first environment identified by the environment identifier, a first deployment target associated with the first environment is obtained;

[0018] Based on the preset template, the application configuration parameters, and the first deployment target associated with the first environment, the first custom resource definition is generated.

[0019] In the above scheme, when the first request includes a migration request, the step of processing the target application resource to generate a first custom resource definition corresponding to the target application resource includes:

[0020] Create a second namespace, a second deployment target, and a second environment within the second cluster;

[0021] Based on the second namespace, the second deployment target, the second environment, the preset migration rules, and the second custom resource definition corresponding to the target application resource, the first custom resource definition is generated; wherein, the preset migration rules are rules used to guide the resource mapping and conversion between the first cluster and the second cluster; the second custom resource definition is generated before the target application resource is migrated and when it is managed by the cloud platform, and is stored in the cloud platform.

[0022] In the above scheme, the step of generating Kubernetes resources and a deployment operation sequence for the Kubernetes resources based on the application configuration file and preset conversion rules includes:

[0023] Based on the component type in the application configuration file, the target component is obtained from the preset conversion rules, and the target component is populated based on the component attributes in the application configuration file to generate the Kubernetes resource;

[0024] Based on the policy type in the application configuration file, the target policy is obtained from the preset conversion rules, and the target policy is populated based on the policy attributes of the application configuration file to generate a policy object;

[0025] Based on the workflow relationships in the preset transformation rules, the Kubernetes resources and the policy objects are combined to generate the deployment operation sequence; wherein, the workflow relationships are used to define the dependency relationships between the policy objects and the Kubernetes resources.

[0026] In the above scheme, within the first cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources, including:

[0027] Send the operation sequence to the first server of the first cluster;

[0028] In the first cluster, the operation sequence is executed by the first server to determine the metadata of the Kubernetes resource corresponding to the target application resource, so as to complete the management of the target application resource; wherein, the metadata represents the management relationship between the target application resource and the cloud platform.

[0029] In the above scheme, in the second cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources, including:

[0030] Send the operation sequence to the second server of the second cluster;

[0031] In the second cluster, the operation sequence is executed through the second server to create the Kubernetes resources in the second cluster and complete the migration of the target application resources.

[0032] In the above scheme, after deploying the Kubernetes resources in the first cluster or the second cluster based on the deployment operation sequence to complete cross-cloud management of the target application resources, it further includes:

[0033] Receive a second request from the user to disconnect the target application resource from the cloud platform;

[0034] In response to the second request, an unbinding operation is performed on the target application resource.

[0035] In the above scheme, the unbinding operation on the target application resource includes:

[0036] Determine the resource reclamation policy for the first custom resource definition; wherein the resource reclamation policy indicates that the Kubernetes resources corresponding to the target application resources should be retained;

[0037] Based on the resource recycling strategy, delete the first custom resource definition;

[0038] After deleting the first custom resource definition, delete the metadata related to the Kubernetes resource and the cloud platform.

[0039] An application resource processing apparatus, the apparatus comprising:

[0040] The receiving unit is used to receive a first request sent by a user for cross-cloud management operations on target application resources in the first cluster; wherein the cloud platform manages at least the first cluster and the second cluster.

[0041] The first processing unit is configured to respond to the first request, process the target application resource, and generate a first custom resource definition corresponding to the target application resource;

[0042] The second processing unit is used to obtain the application configuration file corresponding to the first custom resource definition based on the first custom resource definition and the preset parsing module; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process;

[0043] The third processing unit is used to generate Kubernetes resources and a sequence of deployment operations for the Kubernetes resources based on the application configuration file and preset conversion rules; wherein, the preset conversion rules are rules used to convert the application configuration in the application configuration file into Kubernetes resources and deployment logic;

[0044] An execution unit is configured to deploy the Kubernetes resources in the first cluster or the second cluster based on the deployment operation sequence to complete cross-cloud management of the target application resources.

[0045] A cloud platform, the cloud platform comprising: a processor, a memory, and a communication bus;

[0046] The communication bus is used to realize the communication connection between the processor and the memory;

[0047] The processor is used to execute the application resource processing program stored in the memory to implement the steps of the above application resource processing method.

[0048] A computer-readable storage medium storing one or more programs that can be executed by one or more processors to perform the steps of the application resource processing method described above.

[0049] A computer program product includes a computer program that, when executed by a processor, implements the steps of the application resource processing method described above.

[0050] The application resource processing method, apparatus, cloud platform, medium, and product provided in this application embodiment first receive a first request from a user to perform cross-cloud management operations on target application resources in a first cluster, wherein the cloud platform manages at least the first cluster and the second cluster. Then, in response to the first request, the target application resources are processed to generate a first custom resource definition corresponding to the target application resources. Next, based on the first custom resource definition and a preset parsing module, an application configuration file corresponding to the first custom resource definition is obtained. The application configuration file is structured data used to drive resource conversion and deployment processes. Finally, based on the application configuration file and preset conversion rules, Kubernetes resources and deployment rules for the Kubernetes resources are generated. The system deploys an operation sequence and sets default conversion rules to convert application configurations in application configuration files into Kubernetes resources and deployment logic. Then, in the first or second cluster, Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources. In this way, the cloud platform can regenerate new Kubernetes resources in the first or second cluster. Its cross-cloud management of the target application resources is a point-to-point communication between the platform and the target cluster, which does not require any intermediate storage devices for transfer. It can achieve management without an intermediate medium, instead of requiring external object storage as an intermediate medium as in related technologies, thereby reducing the complexity and cost of cloud migration for users. Attached Figure Description

[0051] Figure 1 A flowchart illustrating an application resource processing method provided in an embodiment of this application;

[0052] Figure 2 A flowchart illustrating another application resource processing method provided in an embodiment of this application;

[0053] Figure 3 This is a schematic diagram illustrating the management of target application resources in an application resource processing method provided in an embodiment of this application.

[0054] Figure 4 This is a schematic diagram of the process for migrating target application resources in an application resource processing method provided in an embodiment of this application;

[0055] Figure 5 A schematic diagram of a multi-cloud platform infrastructure in an application resource processing method provided in an embodiment of this application;

[0056] Figure 6 A schematic diagram of a migration engine in an application resource processing method provided in an embodiment of this application;

[0057] Figure 7This is a schematic diagram of application rendering in an application resource processing method provided in an embodiment of this application;

[0058] Figure 8 A schematic diagram illustrating yet another application resource processing method provided in an embodiment of this application;

[0059] Figure 9 This is a schematic diagram of the structure of an application resource processing device provided in an embodiment of this application;

[0060] Figure 10 This is a schematic diagram of the structure of a cloud platform provided in an embodiment of this application. Detailed Implementation

[0061] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0062] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0063] It's important to note that migrating applications to the cloud involves a series of steps, including application containerization, cluster planning, network planning, application metadata migration, data migration, and monitoring log switching. Managing or migrating applications to the cloud is a complex and multifaceted process. Large enterprise applications often have complex architectures with various dependencies between services, necessitating a specific migration order. If components migrated earlier lack dependencies, timely business validation cannot be performed; conversely, a disordered migration order can lead to components being unable to roll back in an orderly manner. To address these dependencies, a method has been proposed that uses a Directed Acyclic Graph (DAG) to analyze application sub-component dependencies and generate a component migration order. This method then performs cross-cluster migration of cloud-native applications based on this migration order. Analyzing application sub-component dependencies using this DAG analysis automatically generates a component migration order, improving both migration and business validation efficiency. The related technologies also provide a method for disaster recovery, migration, and restoration of Kubernetes cloud-native applications. Specifically, this involves initializing the system into the main cluster, creating a series of custom resource definitions (CRDs) and related controllers. There are four main types of controllers: backup controller, recovery controller, operation controller, and object storage controller. Next, the object storage controller stores Kubernetes objects in Minio via the API of an open-source distributed object storage service (such as Minio), and backs up persistent volume (PV) data to Minio using an open-source cross-platform data backup tool (such as Restic). Third, the recovery operation is executed. The operation controller saves the recovery operation information to a distributed key-value store (such as etcd) via the Kubernetes application programming interface server (kube-apiserver), creating a corresponding recovery record (RestoreLog), which is then saved to the distributed key-value store via the Kubernetes application programming interface server. Fourth, the recovery controller checks the recovery record in the distributed key-value store and executes the relevant application recovery logic.

[0064] However, according to the above description, the migration of application metadata mainly relies on backup and recovery using open-source tools. For example, Kubernetes objects are stored in Minio via the Minio API, and then the metadata is restored on the new cluster using the system's recovery controller. This method requires users to prepare an object storage server for backup, which increases the complexity and cost of cloud migration. At the same time, command-line backup and recovery capabilities have a certain learning curve for users, requiring enterprises to have corresponding technical knowledge and management skills, which also increases the difficulty and cost of cloud migration. Furthermore, there is currently no relevant literature to support the management of application metadata.

[0065] Based on this, this application helps users easily achieve zero-modification, low-cost access to the cloud platform through product visualization. Furthermore, after accessing the cloud platform, it supports seamless migration of application metadata to other clusters or other cloud servers, meeting users' needs for multi-cloud and hybrid deployments. In addition, to address the risk of users' deep dependence on the cloud platform, it also provides the ability to unbind metadata from the cloud platform with one click, helping users seamlessly disconnect from the cloud platform without affecting application operations. Specifically:

[0066] This application provides an application resource processing method, which can be applied to a cloud platform, as described above. Figure 1 As shown, the method includes the following steps:

[0067] Step 101: Receive the first request sent by the user to perform cross-cloud management operations on the target application resources in the first cluster.

[0068] The cloud platform manages at least the first cluster and the second cluster.

[0069] In this embodiment, the cloud platform is a platform that supports unified management of multiple Kubernetes (K8s) clusters (such as public cloud, private cloud, and edge cloud); the first cluster and the second cluster are Kubernetes clusters that the user has already connected to the cloud platform, and the first cluster is usually the source cluster and the second cluster is the target cluster; the target application resource is the Kubernetes resource that the user wants to manage or migrate; the first request is an operation request initiated by the user, including management requests and migration requests.

[0070] In this embodiment of the application, a user initiates an operation request through the cloud platform's user interface (Web UI) or API, such as "to manage an application in the first cluster A to the platform" or "to migrate an application from the first cluster A to the second cluster B". The first request is received by the user layer in the multi-cloud platform infrastructure of the cloud platform, passed to the control layer, and finally processed by the cloud platform's migration engine.

[0071] Step 102: Respond to the first request, process the target application resources, and generate the first custom resource definition corresponding to the target application resources.

[0072] The first custom resource definition is generated based on the first request and is an abstract representation of the target application resource in the cloud platform.

[0073] In this embodiment, the first custom resource definition (AppCRD) is an abstract representation of the target application resource in the platform, encapsulating information such as components, strategies, and workflows. The platform processes the target application resource according to the type of the first request, i.e., whether the request is a management request or a migration request, and generates an internal abstract representation (i.e., AppCRD). It should be noted that the processing of the target application resource is different for different requests, i.e., the process of generating the first custom resource definition is different.

[0074] Step 103: Based on the first custom resource definition and the preset parsing module, obtain the application configuration file corresponding to the first custom resource definition.

[0075] Application configuration files are structured data used to drive resource transformation and deployment processes.

[0076] In this embodiment, the application configuration file (appFile) is a structured configuration file obtained by parsing the AppCRD through the parsing module (ApplicationRender). The application configuration file specifically contains rendering information such as components, strategies, and workflows. The AppCRD is parsed by the AppParser in the ApplicationRender module to generate a structured appFile for use by subsequent component drivers, strategy engines, etc.

[0077] Step 104: Based on the application configuration file and preset conversion rules, generate Kubernetes resources and a sequence of deployment operations for the Kubernetes resources.

[0078] The preset conversion rules are used to convert application configurations in application configuration files into Kubernetes resources and deployment logic.

[0079] In this embodiment, the preset conversion rule is a platform-defined conversion rule used to convert application configuration into Kubernetes resources; Kubernetes resources are specific Kubernetes native resource objects; the deployment operation sequence may specifically include resource creation, policy application, workflow execution, etc.; specific Kubernetes resource objects and deployment order can be generated based on the component, policy, and workflow information in the appFile, combined with the platform-defined conversion rules.

[0080] Step 105: In the first or second cluster, deploy Kubernetes resources based on the deployment operation sequence to complete cross-cloud management of the target application resources.

[0081] In this embodiment, after generating Kubernetes resources and deployment operation sequences, the generated deployment operation sequences can be sent to the API server of the first cluster or the second cluster, and the deployment operations can be executed in sequence to complete management or migration. Specifically, for management requests, the generated deployment operation sequences can be sent to the first cluster to execute deployment operations and complete management; for migration requests, the generated deployment operation sequences can be sent to the second cluster to execute deployment operations and complete migration.

[0082] The application resource processing method provided in this application embodiment allows the cloud platform to regenerate new Kubernetes resources in the first or second cluster. Its cross-cloud management of target application resources is a point-to-point communication between the platform and the target cluster, which does not require any intermediate storage device for transfer. It can achieve management without an intermediate medium, instead of requiring external object storage as an intermediate medium as in related technologies, thereby reducing the complexity and cost of cloud migration for users.

[0083] Based on the foregoing embodiments, this application provides yet another application resource processing method, referring to... Figure 2 , Figure 3 and Figure 4 As shown, the method includes the following steps:

[0084] Step 201: The cloud platform receives the first request sent by the user to perform cross-cloud management operations on the target application resources in the first cluster.

[0085] The cloud platform manages at least the first cluster and the second cluster.

[0086] In this embodiment of the application, before performing cross-cloud management operations on the target application resources, it is necessary to first complete the management of the cluster, that is, the cloud platform must manage at least the first cluster and the second cluster. Specifically, as follows: Figure 3 and Figure 4 As shown in the cluster management diagram, the user first initiates a cluster management request, and then the cloud platform processes the request through methods such as... Figure 5 The User Layer of the Multiple Cloud Platform Infrastructure (MLIP) receives the cluster management request. Then, the User Layer calls the Control Layer to create a Cluster Custom Resource Definition (Cluster CRD). The Control Layer then stores user configurations, cluster metadata, and other information in the Data Layer (including a central database and time storage). After that, the Control Layer notifies the Execution Layer to install a Cluster Agent in the Member Cluster. This Agent is responsible for communicating with the Control Layer, reporting the status of the Member Cluster, and receiving commands from the Control Layer, thereby managing the cluster.

[0087] It should be noted that steps 202 to 203 can be executed after step 201 (e.g., ...). Figure 3 As shown), steps 204 to 205 can also be executed after step 201 (as shown). Figure 4 (as shown)

[0088] Step 202: When the first request includes a management request, the cloud platform responds to the management request, performs legality verification and availability verification on the target application resources, and obtains the verification results.

[0089] In this application embodiment, the legality verification checks whether the user has the permission to operate the target application resource to ensure the compliance of the operation; the availability verification checks whether the target application resource is in a manageable state, for example, whether the target application resource has been occupied by another application on the platform, or whether the target application resource actually exists in the cluster and namespace (first cluster and first namespace) claimed by the user.

[0090] In this embodiment, after responding to a user's management request, the cloud platform does not immediately begin processing. Instead, it performs a series of checks on the resources the user wants to manage (i.e., the target application resources). Specifically, the cloud platform performs checks through methods such as... Figure 6The Resource Validator in the migration engine shown performs legality and availability verification on the target application resources and obtains a verification result (verification passed or verification failed).

[0091] Step 203: If the verification results indicate that both the legality verification and the availability verification are passed, the cloud platform obtains the application configuration parameters, the identifier of the first cluster, the first namespace of the target application resource, and the environment identifier from the management request.

[0092] Step 204: The cloud platform generates the first custom resource definition based on the preset template, application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier.

[0093] In this embodiment, application configuration parameters refer to key-value pairs of data entered by the user in the management request to define the characteristics of the application components themselves. These parameters are used to populate a preset template to generate the final application resource definition. The identifier of the first cluster refers to the unique identifier of the source cluster where the target application resource is located in the cloud platform. The first namespace is the Kubernetes namespace where the target application resource is located in the first cluster. The environment identifier refers to the unique identifier of the environment defined in the cloud platform, and an environment is a logically isolated unit, usually used to distinguish different stages such as development, testing, and production. The target template is a template pre-built by the cloud platform for building the application abstract definition. It defines the framework of the application's component structure, strategies, and workflow. In a feasible implementation, the application configuration parameters may specifically include container image version (e.g., image: nginx: 1.20), number of application replicas (e.g., replicas: 3), resource requests and limits (e.g., cpu: 2, memory: 4Gi), environment variables (e.g., ENV: production), and service port number (e.g., port: 80), etc. The identifier of the first cluster may be the name of the first cluster. The target template may specifically be a CUE template.

[0094] In this embodiment of the application, the cloud platform will only begin to build the abstract model (i.e., AppCRD) of the target application resource after both legality and availability have been verified.

[0095] It should be noted that step 204 can be achieved in the following way:

[0096] Step 204A1: The cloud platform creates the first deployment target based on the identifier of the first cluster and the first namespace.

[0097] In the embodiments of this application, reference is made to Figure 6As shown, the cloud platform can use a preprocessor to create a first deployment target using the identifier of the first cluster (e.g., cluster-01) and the first namespace (e.g., namespace-a), and the unique identifier of the first deployment target can be cluster-01 / namespace-a.

[0098] Step 204A2: The cloud platform associates the first deployment target with the first environment identified by the environment identifier, thus obtaining the first deployment target that has been associated with the first environment.

[0099] In this embodiment, the cloud platform finds the corresponding environment object based on the environment identifier (such as env-prod) provided in the management request, and then adds the newly created first deployment target to the jurisdiction of the environment specified by the environment identifier. In this way, subsequent operations deployed to this environment will take effect on the deployment target.

[0100] Step 204A3: The cloud platform generates a first custom resource definition based on the preset template, application configuration parameters, and the first deployment target associated with the first environment.

[0101] In the embodiments of this application, reference is made to Figure 6 As shown, the cloud platform can collaboratively generate the first custom resource definition through the application builder (AppBuilder) and template engine in the migration engine. Specifically, the template reader reads a preset template (such as a CUE template), and then the template engine fills the application configuration parameters into the specific configuration of the application in the preset template (such as image version, number of replicas, etc.). The first deployment target associated with the first environment is filled into the application's deployment strategy in the preset template (specifying which environment this application should be deployed to). Then, the application adapter (AppAdaptor) performs some adaptation operations on the generated AppCRD prototype, such as adding a management tag and setting a resource recycling strategy. Finally, a complete first AppCRD is created.

[0102] Step 205: When the first request includes a migration request, the cloud platform responds to the migration request and creates a second namespace, a second deployment target, and a second environment in the second cluster.

[0103] In this embodiment, a migration request is an operation instruction initiated by a user to migrate an application from a first cluster (source cluster) to a second cluster (target cluster); the second cluster is the target Kubernetes cluster to which the user-specified application is to be migrated; the second namespace refers to the Kubernetes namespace created in the second cluster to accommodate the migrated application resources, which is usually the same name as the namespace in the first cluster (i.e., the first namespace), but can also be mapped according to rules; the second deployment target is a new deployment location defined in the cloud platform, which is associated with the second cluster and the second namespace in the second cluster, and indicates that the migrated application will be deployed to this new location; the second environment is a logical environment used to group and manage the deployment targets of the second cluster, which can be the same as the first environment or a different environment.

[0104] In this embodiment, this step is a preparatory step for the migration operation. That is, after confirming that the user has initiated a migration request, the cloud platform does not immediately begin moving resources. Instead, it first deploys the necessary basic elements within the second cluster and the cloud platform. This ensures that the second cluster has a compliant, isolated space (second namespace) for application deployment, and the cloud platform is aware of this new deployment location (second deployment target) and its logical affiliation (second environment). Specifically, refer to... Figure 6 As shown, the migration can be primarily executed through the Migration Builder in the migration engine. The cloud platform calls the Kubernetes API of the second cluster to create a namespace in the second cluster (if it does not already exist). The namespace name is usually specified by the user or generated according to rules. A new deployment target (i.e., the second deployment target) is created. The unique identifier of this second deployment target consists of the identifier of the second cluster (e.g., cluster-02) and the second namespace (namespace-b) (e.g., cluster-02 / namespace-b). Afterward, the multi-cloud management platform will also create a new environment (i.e., the second environment), which specifies the logical group to which the migrated application belongs.

[0105] Step 206: The cloud platform generates a first custom resource definition based on the second namespace, the second deployment target, the second environment, the preset migration rules, and the second custom resource definition corresponding to the target application resources.

[0106] Among them, the preset migration rules are rules used to guide the resource mapping and conversion between the first cluster and the second cluster; the second custom resource definition is generated by the target application resource before migration and when it is managed by the cloud platform, and is stored in the cloud platform.

[0107] In this application embodiment, the preset migration rules are a set of rules predefined by the cloud platform to guide the migration process. Specifically, they include resource mapping rules between the old and new clusters (i.e., the first cluster and the second cluster) (such as image repository address replacement, storage class mapping), default deployment scheme templates, etc. The core of these rules is to solve the problem of cross-cluster differences. The second custom resource definition is a custom resource (AppCRD) that already exists in the cloud platform before the migration operation and represents the application being migrated. It was generated when the application was previously managed and is an abstract representation of the application in the first cluster. It is also the basic template or data source for generating the new AppCRD (i.e., the first custom resource definition).

[0108] In this embodiment, the migration builder can obtain the second AppCRD of the application to be migrated from the model storage of the cloud platform. Then, the cloud platform reads the preset migration rules, and the migration builder transforms the obtained second AppCRD according to the preset migration rules to generate an intermediate application definition adapted to the second environment of the second cluster. Then, the migration builder updates the deployment strategy in the obtained intermediate application definition, changing it from pointing to the original first deployment target and first environment to pointing to the newly created second deployment target and second environment. Then, the cloud platform uses the migration builder to fill the application definition content after rule transformation and deployment information update into the deployment scheme template (i.e., the preset template), and finally generates the first AppCRD. The first AppCRD defines a brand new application instance to be deployed in the second cluster. It should be noted that the first AppCRD is saved to the cloud platform and submitted to the Kubernetes API server.

[0109] It should be noted that step 207 can be executed after steps 204 and 206;

[0110] Step 207: The cloud platform obtains the application configuration file corresponding to the first custom resource definition based on the first custom resource definition and parsing module.

[0111] Step 208: The cloud platform obtains the target component from the preset conversion rules based on the component type in the application configuration file, and populates the target component based on the component attributes in the application configuration file to generate Kubernetes resources.

[0112] In this application embodiment, the component type defines the type of Kubernetes resource to be created, and each type corresponds to a component definition; the target component refers to the specific component definition template found from the preset conversion rules according to the component type; the component attribute refers to the specific parameter value configured for a specific component.

[0113] In this embodiment, this step is the core of resource rendering. The cloud platform needs to convert the abstract component concept into concrete, raw API objects that can be created in the Kubernetes cluster. Specifically, refer to... Figure 7 As shown, the cloud platform can execute through the component driver in application rendering. That is, the component driver reads the application configuration file (appFile) to obtain a list of all declared components (including the target component). Then, for each component in the component list, the target component is found from the preset transformation rules according to its component type. Then, the component driver obtains the component attributes of the target component and populates these component attributes into the variables of the target component. Finally, the template engine executes the target component populated with component attributes and outputs one or more standard Kubernetes resources.

[0114] Step 209: The cloud platform obtains the target policy from the preset conversion rules based on the policy type in the application configuration file, and populates the target policy based on the policy attributes in the application configuration file to generate a policy object.

[0115] In this application embodiment, the policy type defines the type of operation and maintenance or deployment policy to be applied; the target policy refers to the specific policy template found from the preset conversion rules according to the policy type; the policy attribute refers to the specific parameter value configured for a specific policy in the application configuration file; and the policy object is an executable policy that has been populated with specific attribute values.

[0116] In this embodiment, the cloud platform executes the policy engine in application rendering. Specifically, the policy engine reads all policy lists declared in the application configuration file. For each policy in the policy list, based on its policy type, it searches for the target policy corresponding to the policy type from the preset conversion rules, and then refers to... Figure 7 As shown, the policy attributes of the target policy are obtained through the policy engine and populated into the variables of the target policy. Then, the target policy with the populated policy attributes is executed through the template engine to generate an executable policy object. This policy object contains complete configuration information and is waiting to be associated with a specific Kubernetes resource.

[0117] Step 210: Based on the workflow relationships in the preset conversion rules, the cloud platform combines Kubernetes resources and policy objects to generate a deployment operation sequence.

[0118] Workflow relationships are used to define the dependencies between policy objects and Kubernetes resources.

[0119] In the embodiments of this application, the workflow relationship defines the application logic and execution order between the policy object and the Kubernetes resource, which clearly indicates which policy should take effect on which component (resource) and at which stage (such as pre-deployment or post-deployment); the operation sequence specifies the precise order of creating or updating resources, dependencies, and the logic of applying policies.

[0120] In the embodiments of this application, reference is made to Figure 7 As shown, the cloud platform can execute through the Workflow Executor in application rendering. Specifically, the Workflow Executor reads the Workflow Definition in the application configuration file and refers to the Workflow Definition in the preset transformation rules to understand the overall workflow relationship, which defines the correspondence between strategies and components and the dependency relationship of execution steps. Then, the Workflow Executor combines the Kubernetes resources generated in step 208 and the policy entities generated in step 209 according to the workflow relationship. After that, based on the combined dependency relationship and logic, the Workflow Executor finally generates a detailed, linear operation sequence, which is a series of explicit instructions.

[0121] It should be noted that after generating Kubernetes resources and operation sequences as described above, Kubernetes resources can be deployed in the first or second cluster based on the Kubernetes resources and operation sequences to complete cross-cloud management of the target application resources. Specifically, when the first request includes a management request, steps 211 to 212 can be executed, and when the first request includes a migration request, steps 213 to 214 can be executed.

[0122] Step 211: The cloud platform sends the deployment operation sequence to the first server of the first cluster.

[0123] In this embodiment of the application, the first server refers to the server of the first cluster, specifically the Kubernetes API server of the first cluster; the cloud platform can mark the management relationship by writing specific information into the metadata of the target application resource, and the metadata can specifically include tags and annotations.

[0124] Step 212: In the first cluster, the cloud platform executes a deployment operation sequence through the first server to determine the metadata of the Kubernetes resources corresponding to the target application resources, so as to complete the management of the target application resources.

[0125] Metadata represents the management relationship between the target application resources and the cloud platform.

[0126] In this embodiment of the application, the management relationship refers to the control and subordinate relationship between the cloud platform and the target application resource. That is, the cloud platform adds its own identifier (such as a specific tag) to the metadata of the target application resource to indicate that the target application resource has been managed by the cloud platform. Subsequent cloud platform policy distribution, monitoring, operation and maintenance operations will be targeted at these marked resources.

[0127] In this embodiment, the first server receives the operation sequence, transforms it into Kubernetes API calls (usually HTTP requests) according to their order and logic, and ultimately executes these requests. This involves adding or modifying specific tags and annotations in the metadata of the target application resources. The cloud platform then periodically scans the cluster to find resources with these specific tags, thereby identifying which resources it manages. Once the metadata of all target application resources has been successfully tagged, the management operation for the target application resources is considered complete. Afterward, the application can be seen on the cloud platform's interface and access advanced management functions provided by the cloud platform, such as monitoring, operation and maintenance, and migration.

[0128] Step 213: The cloud platform sends the deployment operation sequence to the second server of the second cluster.

[0129] In this embodiment, the second server refers to the server of the second cluster, specifically the Kubernetes API server of the second cluster; the cloud platform sends the deployment operation sequence as an HTTP request to the Kubernetes API server of the second cluster through the API server.

[0130] Step 214: In the second cluster, the cloud platform executes the deployment operation sequence through the second server, creates Kubernetes resources in the second cluster, and completes the migration of the target application resources.

[0131] In this embodiment, after receiving the operation sequence, the Kubernetes API server executes the operation sequence, performs Kubernetes resource execution according to the operation sequence, and once all Kubernetes resources reach a normal operating state in the second cluster, the migration of the target application resources is officially completed. At this point, the application has been completely switched from the first cluster to the second cluster.

[0132] It should be noted that, based on the above embodiments, the following steps may also be included:

[0133] Step 215: The cloud platform receives a second request from the user to disconnect the target application resource from the cloud platform.

[0134] In this embodiment of the application, the second request is an operation instruction initiated by the user to remove the management relationship between the platform and the target application resources, i.e., an unbinding or removal from control request; the cloud platform receives the second request through the user layer of the multi-cloud platform infrastructure, and then the user layer forwards the second request to the control layer, and then the second request is routed to the migration engine responsible for application lifecycle management for processing.

[0135] Step 216: The cloud platform responds to the second request and performs an unbinding operation on the target application resources.

[0136] In this embodiment, the unbinding operation refers to the cloud platform releasing its management relationship with the target application resource, so that the resource is no longer subject to platform scheduling, policies, monitoring, or other controls, but the target application resource itself and its business load continue to operate normally in the cluster. The core principle of performing the unbinding operation on the target application resource is to only remove management without affecting business operations.

[0137] It should be noted that step 216 can be achieved in the following way:

[0138] Step 216B1: The cloud platform determines the resource reclamation strategy for the first custom resource definition.

[0139] The resource reclamation strategy specifies the retention of Kubernetes resources corresponding to the target application resources.

[0140] In this embodiment of the application, the cloud platform first queries the resource reclamation policy defined in the first AppCRD through the migration engine and sets its value to retain. This policy is equivalent to telling the cloud platform: "Even if you no longer manage this application, please do not delete any real resources that it is running in the underlying cluster."

[0141] Step 216B2: The cloud platform deletes the first custom resource definition based on the resource recycling strategy.

[0142] In this embodiment of the application, after ensuring that the resource reclamation policy is set to retain, the Kubernetes API is called through the migration engine to delete the first AppCRD representing the application. Since the resource reclamation policy is set to retain, the underlying real resources associated with the first AppCRD will not be deleted.

[0143] Step 216B3: After deleting the first custom resource definition, the cloud platform deletes the metadata related to the Kubernetes resource and the cloud platform.

[0144] In this embodiment, the deletion of the first AppCRD can be detected through application rendering. After the deletion of the first AppCRD is detected, the API server is called through application rendering. The API server performs update operations on all Kubernetes resources corresponding to the target application resources, accurately removing those platform-related tags and annotations added during management. Thus, these Kubernetes resources are completely decoupled from the cloud platform, both in terms of actual data and metadata identification. This supports one-click unbinding from the cloud platform, enabling one-click unbinding of the application without affecting its normal operation. This allows the application to easily break free from the control of the cloud platform, reducing the risk of users' deep dependence on the platform.

[0145] In other embodiments of this application, reference is made to Figure 8 As shown, the implementation scheme for cross-cloud takeover and application migration is mainly divided into three parts, and the functions of each module are described as follows: 1. Migration Engine: This includes a resource validator, preprocessor, application builder, and migration builder. The migration engine is mainly responsible for converting the underlying Kubernetes resources that users need to manage or migrate into platform applications according to preset transformation rules; at the same time, it configures resource distribution for applications during migration and deploys resources according to the new deployment scheme. 2. Application Rendering: This specifically includes an application resolver, component driver, policy engine, workflow executor, and API server. The application rendering is mainly responsible for rendering platform application resources, parsing the workload definitions in the application resources and converting them into native Kubernetes resource definitions; at the same time, it deploys resources to the underlying sub-cluster according to the policies defined in the application resources and tunes the applications. 3. Multi-cloud platform infrastructure: This specifically includes a control layer, through which container services for cloud A, cloud B, cloud C, and Kubernetes can be implemented. The multi-cloud platform infrastructure uses automated and standardized management methods to uniformly manage and virtualize edge nodes, ordinary Kubernetes clusters, or computing resources from different cloud platforms. This enables unified management of heterogeneous clusters such as public clouds, private clouds, and edge clouds, providing applications with a standard runtime computing and storage environment and supporting upper-layer cross-cloud scheduling capabilities. Thus, this application not only achieves management and migration capabilities without intermediaries and one-click unbinding from cloud platforms, but also visualizes these capabilities through a graphical interface. This frees users from the constraints and barriers of command lines, allowing for easy application migration to the cloud through direct interface operation, lowering the learning curve for cloud migration. Furthermore, based on a multi-cloud platform, it supports access to cloud servers from different cloud vendors and provides cross-cluster scheduling and application distribution capabilities, making cross-cloud deployment of applications a reality and meeting users' needs for multi-cloud and hybrid deployments.

[0146] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0147] The application resource processing method provided in this application embodiment allows the cloud platform to regenerate new Kubernetes resources in the first or second cluster. Its cross-cloud management of target application resources is a point-to-point communication between the platform and the target cluster, which does not require any intermediate storage device for transfer. It can achieve management without an intermediate medium, instead of requiring external object storage as an intermediate medium as in related technologies, thereby reducing the complexity and cost of cloud migration for users.

[0148] Based on the foregoing embodiments, this application provides an application resource processing device that can be applied to... Figure 1 and Figure 2 In the corresponding embodiment of the application resource processing method, refer to Figure 9 As shown, the application resource processing device 3 may include: a receiving unit 31, a first processing unit 32, a second processing unit 33, a third processing unit 34, and an execution unit 35, wherein:

[0149] The receiving unit 31 is used to receive a first request sent by a user for cross-cloud management operations on target application resources in the first cluster; wherein the cloud platform manages at least the first cluster and the second cluster.

[0150] The first processing unit 32 is used to respond to the first request, process the target application resources, and generate a first custom resource definition corresponding to the target application resources;

[0151] The second processing unit 33 is used to obtain the application configuration file corresponding to the first custom resource definition based on the first custom resource definition and the preset parsing module; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process;

[0152] The third processing unit 34 is used to generate Kubernetes resources and deployment operation sequences for Kubernetes resources based on application configuration files and preset conversion rules; wherein, the preset conversion rules are a set of rules used to convert application configuration in application configuration files into Kubernetes resources and deployment logic;

[0153] Execution unit 35 is used to deploy Kubernetes resources in the first or second cluster based on the deployment operation sequence to complete cross-cloud management of target application resources.

[0154] In other embodiments of this application, the first processing unit 32 is further configured to perform the following steps:

[0155] Perform legality and availability verification on the target application resources and obtain the verification results;

[0156] If the verification results indicate that both the legality verification and the availability verification are successful, obtain the application configuration parameters, the identifier of the first cluster, the first namespace of the target application resource, and the environment identifier from the management request.

[0157] Based on the preset template, application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier, a first custom resource definition is generated.

[0158] In other embodiments of this application, the first processing unit 32 is further configured to perform the following steps:

[0159] Create the first deployment target based on the identifier and namespace of the first cluster;

[0160] Associate the first deployment target with the first environment identified by the environment identifier to obtain the first deployment target that has been associated with the first environment;

[0161] Based on the preset template, application configuration parameters, and the first deployment target associated with the first environment, a first custom resource definition is generated.

[0162] In other embodiments of this application, the first processing unit 32 is further configured to perform the following steps:

[0163] Create a second namespace, a second deployment target, and a second environment in the second cluster;

[0164] Based on the second namespace, second deployment target, second environment, preset migration rules, and the second custom resource definition corresponding to the target application resources, a first custom resource definition is generated; wherein, the preset migration rules are rules used to guide the resource mapping and conversion between the first cluster and the second cluster; the second custom resource definition is generated before the target application resources are migrated and when they are managed by the cloud platform, and is stored in the cloud platform.

[0165] In other embodiments of this application, the third processing unit 34 is further configured to perform the following steps:

[0166] Based on the component type in the application configuration file, the target component is obtained from the preset transformation rules, and the target component is populated based on the component attributes in the application configuration file to generate Kubernetes resources;

[0167] Based on the policy type in the application configuration file, the target policy is obtained from the preset conversion rules, and the target policy is populated based on the policy attributes in the application configuration file to generate a policy object;

[0168] Based on the workflow relationships in the preset transformation rules, Kubernetes resources and policy objects are combined to generate a deployment operation sequence; among them, the workflow relationships are used to define the dependencies between policy objects and Kubernetes resources.

[0169] In other embodiments of this application, the execution unit 35 is further configured to perform the following steps:

[0170] Send the deployment operation sequence to the first server of the first cluster;

[0171] In the first cluster, the deployment operation sequence is executed through the first server to determine the metadata of the Kubernetes resources corresponding to the target application resources, so as to complete the management of the target application resources; among them, the metadata represents the management relationship between the target application resources and the cloud platform.

[0172] In other embodiments of this application, the execution unit 35 is further configured to perform the following steps:

[0173] Send the deployment operation sequence to the second server in the second cluster;

[0174] In the second cluster, the deployment operation sequence is executed through the second server to create Kubernetes resources in the second cluster and complete the migration of the target application resources.

[0175] In other embodiments of this application, the execution unit 35 is further configured to perform the following steps:

[0176] Receive a second request from the user to disconnect the target application resources from the cloud platform;

[0177] In response to the second request, perform an unbinding operation on the target application resource.

[0178] In other embodiments of this application, the execution unit 35 is further configured to perform the following steps:

[0179] Determine the resource reclamation policy for the first custom resource definition; wherein, the resource reclamation policy indicates that the Kubernetes resources corresponding to the target application resources should be retained;

[0180] Based on the resource recycling strategy, delete the first custom resource definition;

[0181] After deleting the first custom resource definition, delete the metadata related to the Kubernetes resource and the cloud platform.

[0182] It should be noted that the specific implementation process of the steps performed by each module in the embodiments of this application can be referred to Figure 1 and Figure 2The implementation process of the application resource processing method provided in the corresponding embodiments will not be described in detail here.

[0183] The application resource processing device provided in this application embodiment allows the cloud platform to regenerate new Kubernetes resources in the first or second cluster. Its cross-cloud management of target application resources is a point-to-point communication between the platform and the target cluster, which does not require any intermediate storage device for transfer. It can achieve management without an intermediate medium, instead of requiring external object storage as an intermediate medium as in related technologies, thereby reducing the complexity and cost of cloud migration for users.

[0184] Based on the foregoing embodiments, embodiments of this application provide a cloud platform that can be applied to... Figure 1 and Figure 2 In the corresponding embodiment of the application resource processing method, refer to Figure 10 As shown, the cloud platform 4 may include: a processor 41, a memory 42, and a communication bus 43, wherein:

[0185] Communication bus 43 is used to realize the communication connection between processor 41 and memory 42;

[0186] Processor 41 is used to execute the application resource processing program in memory 42 to perform the following steps:

[0187] Receive a first request from a user to perform cross-cloud management operations on target application resources in the first cluster; wherein the cloud platform manages at least the first cluster and the second cluster;

[0188] In response to the first request, the target application resources are processed to generate the first custom resource definition corresponding to the target application resources;

[0189] Based on the first custom resource definition and the preset parsing module, the application configuration file corresponding to the first custom resource definition is obtained; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process;

[0190] Based on application configuration files and preset transformation rules, Kubernetes resources and deployment operation sequences for Kubernetes resources are generated; among them, preset transformation rules are a set of rules used to convert application configuration in application configuration files into Kubernetes resources and deployment logic;

[0191] In the first or second cluster, Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources.

[0192] In other embodiments of this application, the processor 41 is configured to execute the application resource processing program in the memory 42, when the first request includes a management request, respond to the first request, process the target application resource, and generate a first custom resource definition corresponding to the target application resource to implement the following steps:

[0193] Perform legality and availability verification on the target application resources and obtain the verification results;

[0194] If the verification results indicate that both the legality verification and the availability verification are successful, obtain the application configuration parameters, the identifier of the first cluster, the first namespace of the target application resource, and the environment identifier from the management request.

[0195] Based on the preset template, application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier, a first custom resource definition is generated.

[0196] In other embodiments of this application, the processor 41 is used to execute the application resource processing program in the memory 42 to generate a first custom resource definition based on a preset template, application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier, in order to implement the following steps:

[0197] Create the first deployment target based on the identifier and namespace of the first cluster;

[0198] Associate the first deployment target with the first environment identified by the environment identifier to obtain the first deployment target that has been associated with the first environment;

[0199] Based on the preset template, application configuration parameters, and the first deployment target associated with the first environment, a first custom resource definition is generated.

[0200] In other embodiments of this application, the processor 41 is configured to execute the application resource processing program in the memory 42 when the first request includes a migration request, process the target application resource, and generate a first custom resource definition corresponding to the target application resource to implement the following steps:

[0201] Create a second namespace, a second deployment target, and a second environment in the second cluster;

[0202] Based on the second namespace, second deployment target, second environment, preset migration rules, and the second custom resource definition corresponding to the target application resources, a first custom resource definition is generated; wherein, the preset migration rules are rules used to guide the resource mapping and conversion between the first cluster and the second cluster; the second custom resource definition is generated before migration and when it is managed by the cloud platform, and is stored in the cloud platform.

[0203] In other embodiments of this application, processor 41 is used to execute the application resource processing program in memory 42 based on application configuration files and preset transformation rules to generate Kubernetes resources and a sequence of deployment operations for the Kubernetes resources, in order to implement the following steps:

[0204] Based on the component type in the application configuration file, the target component is obtained from the preset transformation rules, and the target component is populated based on the component attributes in the application configuration file to generate Kubernetes resources;

[0205] Based on the policy type in the application configuration file, the target policy is obtained from the preset conversion rules, and the target policy is populated based on the policy attributes in the application configuration file to generate a policy object;

[0206] Based on the workflow relationships in the preset transformation rules, Kubernetes resources and policy objects are combined to generate a deployment operation sequence; among them, the workflow relationships are used to define the dependencies between policy objects and Kubernetes resources.

[0207] In other embodiments of this application, the processor 41 is used to execute the application resource processing program in the memory 42 in the first cluster, deploying Kubernetes resources based on a deployment operation sequence to complete cross-cloud management of the target application resources, thereby implementing the following steps:

[0208] Send the deployment operation sequence to the first server of the first cluster;

[0209] In the first cluster, the deployment operation sequence is executed through the first server to determine the metadata of the Kubernetes resources corresponding to the target application resources, so as to complete the management of the target application resources; among them, the metadata represents the management relationship between the target application resources and the cloud platform.

[0210] In other embodiments of this application, processor 41 is used to execute the application resource processing program in memory 42 in the second cluster, deploying Kubernetes resources based on deployment Kubernetes resources and operation sequences to complete cross-cloud management of target application resources, thereby implementing the following steps:

[0211] Send the deployment operation sequence to the second server in the second cluster;

[0212] In the second cluster, the deployment operation sequence is executed through the second server to create Kubernetes resources in the second cluster and complete the migration of the target application resources.

[0213] In other embodiments of this application, the processor 41 is used to execute the application resource processing method of the application resource processing program in the memory 42 to implement the following steps:

[0214] Receive a second request from the user to disconnect the target application resources from the cloud platform;

[0215] In response to the second request, perform an unbinding operation on the target application resource.

[0216] In other embodiments of this application, the processor 41 is used to execute the application resource processing program in the memory 42 to perform an unbinding operation on the target application resource, in order to achieve the following steps:

[0217] Determine the resource reclamation policy for the first custom resource definition; wherein, the resource reclamation policy indicates that the Kubernetes resources corresponding to the target application resources should be retained;

[0218] Based on the resource recycling strategy, delete the first custom resource definition;

[0219] After deleting the first custom resource definition, delete the metadata related to the Kubernetes resource and the cloud platform.

[0220] It should be noted that a detailed description of the steps performed by the processor can be found in [reference needed]. Figure 1 and Figure 2 The implementation process of the application resource processing method provided in the corresponding embodiments will not be described in detail here.

[0221] The cloud platform provided in this application embodiment can regenerate new Kubernetes resources in the first cluster or the second cluster. Its cross-cloud management of target application resources is a point-to-point communication between the platform and the target cluster. It does not need to go through any intermediate storage device for transfer, and can realize management without an intermediate medium, instead of requiring external object storage as an intermediate medium as in related technologies, thereby reducing the complexity and cost of cloud migration for users.

[0222] Based on the foregoing embodiments, this application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to achieve... Figure 1 and Figure 2 The steps in the application resource processing method provided in the corresponding embodiment.

[0223] Based on the foregoing embodiments, this application provides a computer program product, which, when executed by a processor, implements... Figure 1 and Figure 2 The steps in the application resource processing method provided in the corresponding embodiment.

[0224] It should be noted that the aforementioned computer-readable storage media can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various electronic devices including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0225] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0226] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0227] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0228] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0229] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0230] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0231] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for processing application resources, characterized in that, Applied to a cloud platform, the method includes: The system receives a first request from a user to perform cross-cloud management operations on target application resources in a first cluster; wherein the cloud platform manages at least the first cluster and the second cluster. In response to the first request, the target application resource is processed to generate a first custom resource definition corresponding to the target application resource; Based on the first custom resource definition and the preset parsing module, the application configuration file corresponding to the first custom resource definition is obtained; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process, and includes component type and strategy type; Based on the application configuration file and preset transformation rules, Kubernetes resources and a sequence of deployment operations for the Kubernetes resources are generated. The preset transformation rules are used to convert the application configuration in the application configuration file into Kubernetes resources and deployment logic. The preset transformation rules include workflow relationships. The deployment operation sequence is generated by sorting the Kubernetes resources generated based on the component type and the policy objects generated based on the policy type, based on the workflow relationships. The workflow relationships are used to define the dependencies between the policy objects and the Kubernetes resources. In the first cluster or the second cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources.

2. The method according to claim 1, characterized in that, When the first request includes a management request, the step of responding to the first request, processing the target application resource, and generating a first custom resource definition corresponding to the target application resource includes: The target application resources are subjected to legality and availability verification to obtain the verification results; If the verification result indicates that both the legality verification and the availability verification have passed, the application configuration parameters, the identifier of the first cluster, the first namespace and environment identifier of the target application resource are obtained from the management request. Based on the preset template, the application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier, the first custom resource definition is generated.

3. The method according to claim 2, characterized in that, The process of generating the first custom resource definition based on the preset template, the application configuration parameters, the identifier of the first cluster, the first namespace, and the environment identifier includes: Based on the identifier of the first cluster and the first namespace, create a first deployment target; Associating the first deployment target with the first environment identified by the environment identifier, a first deployment target associated with the first environment is obtained; Based on the preset template, the application configuration parameters, and the first deployment target associated with the first environment, the first custom resource definition is generated.

4. The method according to claim 1, characterized in that, When the first request includes a migration request, the step of processing the target application resource to generate a first custom resource definition corresponding to the target application resource includes: Create a second namespace, a second deployment target, and a second environment within the second cluster; Based on the second namespace, the second deployment target, the second environment, the preset migration rules, and the second custom resource definition corresponding to the target application resource, the first custom resource definition is generated; wherein, the preset migration rules are rules used to guide resource mapping and conversion between the first cluster and the second cluster; the second custom resource definition is generated before the target application resource is migrated and when it is managed by the cloud platform, and is stored in the cloud platform.

5. The method according to claim 1, characterized in that, The step of generating Kubernetes resources and a sequence of deployment operations for the Kubernetes resources based on the application configuration file and preset conversion rules includes: Based on the component type in the application configuration file, the target component is obtained from the preset conversion rules, and the target component is populated based on the component attributes in the application configuration file to generate the Kubernetes resource; Based on the policy type in the application configuration file, the target policy is obtained from the preset conversion rules, and the target policy is populated based on the policy attributes of the application configuration file to generate a policy object; Based on the workflow relationships in the preset conversion rules, the Kubernetes resources and the policy objects are combined to generate the deployment operation sequence.

6. The method according to claim 3, characterized in that, In the first cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources, including: Send the deployment operation sequence to the first server of the first cluster; In the first cluster, the deployment operation sequence is executed by the first server to determine the metadata of the Kubernetes resources corresponding to the target application resources, so as to complete the management of the target application resources; wherein, the metadata represents the management relationship between the target application resources and the cloud platform.

7. The method according to claim 4, characterized in that, In the second cluster, the Kubernetes resources are deployed based on the deployment operation sequence to complete cross-cloud management of the target application resources, including: Send the deployment operation sequence to the second server of the second cluster; In the second cluster, the deployment operation sequence is executed through the second server to create the Kubernetes resources in the second cluster and complete the migration of the target application resources.

8. The method according to claim 1, characterized in that, After deploying Kubernetes resources in the first cluster or the second cluster based on the deployment operation sequence to complete cross-cloud management of the target application resources, the method further includes: Receive a second request from the user to disconnect the target application resource from the cloud platform; In response to the second request, an unbinding operation is performed on the target application resource.

9. The method according to claim 8, characterized in that, Performing an unbinding operation on the target application resource includes: Determine the resource reclamation policy for the first custom resource definition; wherein the resource reclamation policy indicates that the Kubernetes resources corresponding to the target application resources should be retained; Based on the resource recycling strategy, delete the first custom resource definition; After deleting the first custom resource definition, delete the metadata related to the Kubernetes resource and the cloud platform.

10. An application resource processing device, characterized in that, The device includes: The receiving unit is used to receive a first request sent by a user for cross-cloud management operations on target application resources in the first cluster; wherein the cloud platform manages at least the first cluster and the second cluster. The first processing unit is configured to respond to the first request, process the target application resource, and generate a first custom resource definition corresponding to the target application resource; The second processing unit is used to obtain the application configuration file corresponding to the first custom resource definition based on the first custom resource definition and the preset parsing module; wherein, the application configuration file is structured data used to drive the resource conversion and deployment process, and includes component type and strategy type; The third processing unit is configured to generate Kubernetes resources and a deployment operation sequence for the Kubernetes resources based on the application configuration file and preset conversion rules. The preset conversion rules are used to convert the application configuration in the application configuration file into Kubernetes resources and deployment logic. The preset conversion rules include workflow relationships. The deployment operation sequence is generated by sorting the Kubernetes resources generated based on the component type and the policy objects generated based on the policy type based on the workflow relationships. The workflow relationships are used to define the dependency relationships between the policy objects and the Kubernetes resources. An execution unit is configured to deploy the Kubernetes resources in the first cluster or the second cluster based on the deployment operation sequence to complete cross-cloud management of the target application resources.

11. A cloud platform, characterized in that, The cloud platform includes: a processor, a memory, and a communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is used to execute an application resource processing program in memory to implement the steps of the application resource processing method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the application resource processing method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the application resource processing method according to any one of claims 1 to 9.

Images