WO2023015988A1 - 云平台管理架构及管理方法、管理设备、存储介质 - Google Patents

云平台管理架构及管理方法、管理设备、存储介质 Download PDF

Info

Publication number
WO2023015988A1
WO2023015988A1 PCT/CN2022/091530 CN2022091530W WO2023015988A1 WO 2023015988 A1 WO2023015988 A1 WO 2023015988A1 CN 2022091530 W CN2022091530 W CN 2022091530W WO 2023015988 A1 WO2023015988 A1 WO 2023015988A1
Authority
WO
WIPO (PCT)
Prior art keywords
capability
application
cloud platform
management device
management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/091530
Other languages
English (en)
French (fr)
Inventor
全锐
陈皓
刘学生
徐代刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Priority to EP22854983.8A priority Critical patent/EP4369183A4/en
Priority to JP2024505368A priority patent/JP7667371B2/ja
Priority to US18/293,627 priority patent/US12603814B2/en
Publication of WO2023015988A1 publication Critical patent/WO2023015988A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play

Definitions

  • the embodiments of the present application relate to but are not limited to the application field of cloud-native scenarios, and in particular relate to a cloud platform management architecture and management method, management equipment, and computer-readable storage media.
  • the application orchestration on the cloud platform is basically coupled to the cloud platform.
  • the native resources provided by the cloud platform are used to orchestrate cloud-native applications.
  • the Platform as a Service (PaaS) system restricts the supported application types and supported functions, which is reflected in the fact that it cannot be extended, creates its own plug-in system, and is maintained by its own community. This plug-in mechanism can only be used for The closed small ecological capabilities exclusive to the PaaS system cannot be reliably utilized on a large scale.
  • the application design is aimed at the multi-cloud management system.
  • the central computer room centrally hosts different cloud platforms, and there are certain differences between different cloud platforms.
  • it cannot be designed for different plug-in capabilities of a specific cloud platform, so that the orchestration ability is completely dependent on the encapsulation of simple resources.
  • What kind of fields are exposed depends entirely on the developer's understanding of the application. If the fields need to be updated later, It can only be solved by modifying the code, re-creating the version, etc., which is very inflexible.
  • a large number of operation and maintenance related plug-ins in the cloud native ecosystem cannot be used, resulting in the inability to arrange for complex application features, making the overall arrangement effect worse.
  • Embodiments of the present application provide a cloud platform management architecture, a management method, a management device, and a computer-readable storage medium.
  • the embodiment of the present application provides a cloud platform management architecture, including: a first management device configured to define at least one application capability based on an open application model, each of which is used to represent a cloud platform support The load or the operation and maintenance characteristics acting on the load; the second management device, connected to the first management device, is configured to determine the application capability corresponding to the application capability according to the application capability from the first management device The capability boundary, the capability boundary is used to characterize each candidate cloud platform supporting the application capability; the application arrangement and instantiation device, connected to the first management device, is set to determine according to the capability boundary for each cloud platform The application orchestration and instantiation strategy of the alternative cloud platform.
  • the embodiment of the present application also provides a cloud platform management method, which is applied to the cloud platform management architecture, and the cloud platform management architecture includes a first management device and a second management device, and the first management device is connected to The second management device; the cloud platform management method, including: controlling the first management device to define at least one application capability based on an open application model, each of which is used to represent a load or role supported by a cloud platform Based on the operation and maintenance characteristics of the load; control the second management device to determine a capability boundary corresponding to the application capability according to the application capability from the first management device, and the capability boundary is used to characterize the support for the Each candidate cloud platform for application capabilities; determining an application orchestration and instantiation strategy for each of the candidate cloud platforms according to the capability boundary.
  • the embodiment of the present application also provides a cloud platform management device, including: a memory, a processor, and a computer program stored on the memory and operable on the processor, when the processor executes the computer program Realize the cloud platform management method of the second aspect as described above.
  • the embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, and the computer-executable instructions are used to execute the cloud platform management method in the second aspect as described above.
  • Fig. 1 is a schematic diagram of a cloud platform management architecture provided by an embodiment of the present application
  • Fig. 2 is a schematic diagram of a cloud platform management architecture provided by a specific example of the present application
  • Fig. 3 is a schematic diagram of a capability boundary provided by an embodiment of the present application.
  • Fig. 4 is a schematic interface diagram of a blueprint designer provided by an embodiment of the present application.
  • Fig. 5 is a flowchart of a cloud platform management method provided by an embodiment of the present application.
  • Fig. 6 is a flow chart of determining the target cloud platform in the cloud platform management method provided by one embodiment of the present application.
  • FIG. 7 is a flow chart of a cloud platform management method provided by another embodiment of the present application.
  • Fig. 8 is a flowchart of a cloud platform management method provided by another embodiment of the present application.
  • FIG. 9 is a flow chart of determining a capability boundary in a cloud platform management method provided by an embodiment of the present application.
  • FIG. 10 is a specific flow chart of the cloud platform management framework accessing the cloud platform according to the embodiment of the present application.
  • FIG. 11 is a specific flow chart of the cloud platform management framework of the embodiment of the present application delivering capability definitions to the lower-level cloud platform;
  • FIG. 12 is a specific flow chart of the cloud platform management framework executing application instantiation according to the embodiment of the present application.
  • This application provides a cloud platform management architecture and management method, management equipment, and computer-readable storage media.
  • multiple application capabilities are defined through the first management device, so it can provide cloud-native applications.
  • Capability abstraction so as to characterize the differentiated scenarios of each cloud platform in a matching manner, enhance the portability of cloud-native applications among various cloud platforms, and determine the alternatives for characterizing and supporting the defined application capabilities through the second management device
  • the capability boundary of the cloud platform enables the auxiliary application arrangement and instantiation device to determine the application arrangement and instantiation strategy for each candidate cloud platform through the capability boundary, so as to realize the management of differentiated scenarios of multiple cloud platforms and optimize application arrangement and instantiated effects.
  • FIG. 1 is a schematic diagram of a cloud platform management architecture 100 provided by an embodiment of the present application.
  • the cloud platform management architecture 100 may include but not limited to a first management device 200, the first management device 200 is configured to define at least one application capability based on an open application model, and each application capability is used to represent a cloud The loads supported by the platform or the O&M features acting on the loads.
  • the cloud platform applied by the cloud platform management framework 100 of the embodiment of the present application can take cloud infrastructure as the core, and can run on standardized hardware facilities and enhanced and customized hardware devices.
  • the cloud platform can provide virtual machines, bare metal and Containers and other basic virtualized single or mixed resource services can integrate and provide technical components, network and business services, etc., and can also be expanded on demand to provide cloud-native technology stacks for multiple products.
  • the above-mentioned standardized hardware facilities and enhanced and customized devices include but are not limited to general-purpose servers, storage devices, network devices, customized all-in-one machines, smart network cards, and acceleration hardware.
  • the cloud platform can be a container cloud platform based on the K8S platform, or a dual-core cloud platform based on K8S and an open stack (Openstack).
  • Openstack an open stack
  • the embodiment of the present application does not specify the type of the cloud platform. limit.
  • an open application model (Open Application Model, OAM) is a standard specification for building and delivering cloud-native applications.
  • OAM Open Application Model
  • the modern cloud-native application management platform based on OAM and K8S is essentially an "application-oriented Center" K8S ensures that this application platform can seamlessly access the entire cloud-native ecosystem.
  • OAM can further shield the complexity and differences of container infrastructure, and bring a low-burden, standardized, and consistent application management and delivery experience to cloud platform users.
  • the application capability may, but is not limited to, refer to the atomic functions that can form a complete application. It can be regarded as the capability abstraction provided by the cloud platform for the application definer, mainly expressed as supported loads or acting on these loads. With the support of these capabilities, application definers can define cloud-native applications that meet business requirements.
  • loads include but are not limited to functions, containers, cloud resources, virtual machines, and many other forms of workloads. Loads are used to describe how applications are run; operation and maintenance features include but are not limited to traffic management, release strategies, Various O&M capabilities such as elastic policies and observability policies.
  • the cloud platform itself can provide end users with differentiated scenarios through combinations of different loads and O&M features, helping users define cloud-native applications.
  • a standard template is used to define the application capability.
  • the application capability is divided into load capability and feature capability, wherein the load capability can be defined in the standard template of the open application model specification, for example, using core.oam.dev/v1alpha2.WorkloadDefinition of oam-kubernetes-runtime
  • the feature capability can be defined through the core.oam.dev/v1alpha2.TraitDefinition of oam-kubernetes-runtime. It is understandable that both the workload definition (WorkloadDefinition) and the feature definition (Trait Definition) are K8S custom resources (Custom Resource Definitions, CRD), so the capability definition can be obtained from the cloud platform through the CRD type.
  • workload types can be divided into core workload types (Core Workload Type), standard workload types (Standard Workload Type) and extended workload types (Extended Workload Type), and the range of feature capabilities can be It is divided into core trait (Core Trait) range, standard trait (Standard Trait) range and extended trait (Extended Trait) range.
  • the capabilities of the core feature range are predefined capabilities of the open application model;
  • the capabilities of the standard feature range are the application capabilities that can be realized by the device of the embodiment of the application, and can support running on most cloud platforms in practical applications;
  • the ability to expand the range of features is based on the application capabilities obtained by the secondary development of the cloud platform users targeted by the device in the embodiment of the present application. It can be connected to the cloud platform ecology and use various plug-ins widely existing in the open source community to develop the required Various application capabilities. Under normal circumstances, the application capabilities of the core feature range and standard feature range will not be modified, and the application capabilities of the extended feature range can be updated at any time and take effect dynamically.
  • the load capacity on the K8S cloud platform can be defined by referring to K8S predefined resources or CRDs, that is, it can be defined through a yaml file. If a new CRD needs to be introduced, the corresponding capacity needs to be added Executors, or bottom-level dependent plug-ins. If the feature capabilities require the support of bottom-level plug-ins, corresponding capability executors and bottom-level plug-ins can also be added as needed. Among them, the capability definition supports the definition of leading actions to load these capability executors and plug-ins .
  • the application capability definition itself can be expressed through JavaScript Object Notation (JSON).
  • JSON JavaScript Object Notation
  • the application capability definition can also be developed using a template language.
  • the template language that can be used includes but is not limited to CUELang or Helm .
  • the first management device 200 is also configured to determine the target application capabilities supported by the target cloud platform according to the target cloud platform and the application capabilities, and is configured to send target capability definition data corresponding to the target application capabilities to the target cloud platform Bag.
  • the first management device 200 when a cloud platform is included in the management scope of the first management device 200, the first management device 200 can actively discover the capability set supported by the cloud platform, because the application capability is defined by the specification of the open application model Yes, so you can query all load definition and feature definition instances through the K8S native interface, and get detailed information such as the corresponding application capability description and scope of action.
  • the application capabilities discovered by the first management device 200 will be persisted in the database of the first management device 200, thereby forming a corresponding table storage cloud platform and a corresponding relationship between capabilities, and finally forming the first management device 200 management
  • the respective capability sets of multiple cloud platforms will be persisted in the database of the first management device 200, thereby forming a corresponding table storage cloud platform and a corresponding relationship between capabilities, and finally forming the first management device 200 management The respective capability sets of multiple cloud platforms.
  • the first management device 200 can support the capability types defined by the open application model specification, and support a predefined capability set.
  • This preset capability can be supported by default by most cloud platforms, such as predefined by K8S Capabilities corresponding to resource types.
  • the first management device 200 provides a capability definition specification, uses a capability database to maintain various capabilities, provides a variety of preset capabilities, and provides users with the ability to load secondary development and import cloud-native community definitions capabilities, all capability definitions are persisted to the capability database.
  • capability discovery and capability distribution are performed for each cloud platform, and the device will simultaneously establish the corresponding relationship between each capability and the managed cloud platform instance in the capability database to determine the capabilities supported by each cloud platform set.
  • the embodiment of this application also supports remote capability warehouses. Various capabilities contributed by the open source community can be placed in the capability warehouses. By configuring the remote capability warehouses, the cloud-native ecosystem can be seamlessly connected.
  • the cloud platform When a cloud platform is included in the management of the first management device 200, it is first necessary to ensure that the cloud platform has a capability executor, wherein the capability executor is set to process the defined application capabilities, and its specification and content can be selected according to the situation , if it does not exist, the capability executor is delivered in a cloud-native way.
  • the first management device 200 When accessing the cloud platform, the first management device 200 will deliver various preset capabilities to the target cloud platform, so that the cloud platform has corresponding capabilities. Because the capability definitions are K8S CRDs, these capability definitions can be delivered in the native way of K8S.
  • the platform developer can subsequently define more capabilities through the specification of the open application model, incorporate them into the management of the first management device 200, and assign them to the corresponding cloud platform.
  • Various open source capabilities under the K8S ecosystem in the cloud-native community can also be used and imported into the first management device 200, so that the management capabilities of the first management device 200 can be continuously expanded.
  • the capability definition can be re-delivered and updated on the corresponding cloud platform.
  • the capability definition package can be selected to be delivered to the corresponding cloud platform system for loading when the application is instantiated.
  • the cloud platform management architecture 100 of the embodiment of the present application also includes a second management device 300, which is connected to the first management device 200 and is configured to determine and The capability boundary corresponding to the application capability.
  • the capability boundary is used to characterize each candidate cloud platform that supports the application capability.
  • the capability boundary refers to the range of cloud platform instances that support a specific capability definition, which is closely related to the capability type and determined by a certain cloud platform support capability set.
  • a specific capability definition which is closely related to the capability type and determined by a certain cloud platform support capability set.
  • its scope of action is all K8S cloud platforms.
  • a capability defined by secondary development or a capability defined by the imported cloud-native community its scope of action is the cloud platform instance that explicitly delivers this capability, or the cloud platform instance that has already installed this capability on the cloud platform.
  • the second management device 300 is set to verify the running status of the application capabilities from the first management device 200, and is set to adjust the application capabilities according to the running status of the application capabilities, and is set to The application capability determines the capability boundary corresponding to the adjusted application capability.
  • the capability definition itself involves various operations on cloud platform resources, plug-ins, etc., which has certain complexity. Processes such as development, testing, and launch need to be considered.
  • K8S Through the Webhook mechanism of K8S, it is possible to verify the capability definition, verify the validity of the capability definition yaml, check the validity of the capability definition template language, and check the capability definition dependent resources and the satisfaction of the underlying plug-ins.
  • the second management device 300 also provides a capability testing sandbox, which conducts a simulation test on the newly launched capability, assists in analyzing the test output, and ensures that capability development meets user needs.
  • the capability sandbox is a capability simulation operating environment, which is isolated from the production environment. It adopts a simulation method for the execution of many capability-related logics, and does not perform real resource operation actions. It can simulate the actual running effect of the capability to a certain extent, and The developer judges the correctness of the logic based on the output assistance ability. After the sandbox pre-test is passed, the capability can be loaded into the official cloud environment to provide services. In addition, in the capability definition upgrade scenario, the test capability can also be provided through webhook. At the beginning, some capability creation requests are diverted to the capability definition implementation of the new version, and the old version is gradually replaced with the new version according to the execution effect.
  • the cloud platform management framework 100 of the embodiment of the present application further includes an application orchestration device 400, which is connected to the first management device 200 and is configured to determine the application orchestration strategy for each candidate cloud platform according to the capability boundary .
  • the traditional application orchestration system basically adopts the hard-coded mode, which realizes the hard-coded orchestration interface according to the specific cloud platform resource type, and because it is not scalable, the defined application is not portable. Therefore, it cannot cope with the differential management of multi-cloud platform capabilities.
  • the application orchestration device 400 of the embodiment of the present application can flexibly apply capability elements, dynamically generate application orchestration elements according to the capability template definitions in the capability definition database, and allow the application definer to correspond to the capabilities according to the capability boundaries. Use orchestration elements.
  • the new capability definitions that are constantly introduced, continue to improve the orchestration capabilities of the device to support application definitions, and make more effective use of the cloud-native ecosystem.
  • the application orchestration apparatus 400 in the embodiment of the present application is configured to determine a target cloud platform for executing application instantiation from various candidate cloud platforms according to the capability boundary.
  • the capability boundary can be used to use various extended capability definitions, or the capability boundary can be ignored first, and all capability definitions managed by the application orchestration device 400 can be used to act on the capability when the application is instantiated. boundary.
  • the application definition generated by the embodiment of this application can be packaged into a CHART package through Helm for instantiation and execution.
  • the application When the application is instantiated, it needs to execute the actions defined by the capability.
  • the capabilities defined in this application are provided through the K8S CRD, and the corresponding capability CRD needs to be executed through the capability executor, which needs to provide a corresponding controller (Controller) to implement related logic.
  • the capability executor converts the capability defined by the CRD to the cloud platform native resources or custom resources according to the capability reference definition.
  • the feature capability it executes the corresponding logic according to the capability template definition, and may even rely on other Operators or controls on the cloud platform. Controller (Controller) and the assistance of the underlying plug-ins.
  • the embodiment of this application arranges the blueprint to instantiate an application, it can select a cloud platform instance that supports this application according to the capability boundary; It can create application running conditions, and the ultimate goal is to ensure that the defined application can be instantiated normally on the cloud platform and ensure the portability of the application between different cloud platforms.
  • the cloud platform management architecture 100 of the embodiment of the present application also includes a capability database configured to store at least one capability template corresponding to at least one application capability, and the capability database is connected to the application orchestration device 400 through the first management device 200 ;
  • the application composition apparatus 400 is also configured to generate a writeable application capability composition element according to the capability template from the capability database, and the application capability composition element corresponds to the capability template.
  • the cloud platform capability template managed by the first management device 200 will eventually be persisted in the capability database, so as to provide continuous management of the capability, and subsequently generate an orchestration interface according to the capability data.
  • the capability database provides interfaces such as capability definition template registration, query, update and deletion, for example:
  • GET ⁇ apiRoot ⁇ /app_lcm/v2/capabilities defines the interface for querying all capability template definitions on the cloud platform, and for example, GET ⁇ apiRoot ⁇ /app_lcm/v2/capabilities/:id defines the capability template for querying the specified ID on the cloud platform
  • the information interface for example, 3.
  • POST ⁇ apiRoot ⁇ /app_lcm/v2/capability defines the interface for submitting user-defined capability templates to the cloud platform.
  • the application orchestration apparatus 400 can present all preset capabilities during the orchestration, because its capability boundary is the full set of the cloud platform. At the same time, if it is possible to specify one or more cloud platform instances in which the defined application will run, then the intersection of the capabilities of these cloud platform instances can be used by the application definer, so that the defined application can be used normally in the target cloud platform instance. change.
  • the candidate target cloud platform instance can be filtered according to the capability boundary. Only the cloud platform instances corresponding to the capability boundaries corresponding to all the capabilities required by the application are filtered out for the user to choose. In this way, it can also effectively ensure that the application is instantiated normally on the target cloud platform.
  • the first management device 200 may also expand the capability set of the cloud platform instance, and expand the capability boundaries of certain capabilities. If the corresponding capability definition package and the plug-in package on which the capability definition package depends exist in the first management device 200, you can choose to deliver the capability definition package to the corresponding cloud platform for installation, thereby enabling the cloud platform to enable it to Supports deployment of applications that would otherwise not be supported.
  • the embodiment of the present application defines multiple application capabilities through the first management device 200, so it can provide the capability abstraction of cloud-native applications, thereby matching the differentiated scenarios of each cloud platform, Enhance the portability of cloud-native applications between various cloud platforms, and determine the capability boundary used to characterize the candidate cloud platform supporting the defined application capability through the second management device 300, so that the auxiliary application orchestration device 400 passes the capability boundary Determine the application orchestration strategy for each candidate cloud platform, so as to manage the differentiated scenarios of multiple cloud platforms and achieve the effect of optimizing application orchestration.
  • FIG. 2 is a schematic diagram of a cloud platform management architecture provided in a specific example of the present application.
  • the first cloud platform includes a capability manager and a capability executor
  • the capability manager is a capability management control plane, and is configured as a capability management
  • the capability executor is a capability management data plane, and is configured as a capability loading , execute and instantiate application packages, such as application instances in the second cloud platform and the third cloud platform.
  • the first cloud platform also has data plane functions.
  • the capability management control plane provides capability definition by referring to the capability definition method agreed in the open application model specification, and adopts a standard template to provide capability definition; through capability abstraction, elements supporting application definition are abstracted, and through differentiated management of capabilities on multiple lower-level cloud platforms, Clarify the capability range of each cloud platform, and persist the capabilities on each cloud platform in the capability definition database, and finally provide complete capability management; when connecting to the lower-level cloud platform, the preset capabilities and user-defined extensions
  • the capability set is delivered to the target cloud platform to provide capability delivery; all load definitions and feature definition details are queried through K8S, and detailed information such as corresponding capability description and scope of action are obtained, thereby providing multi-cloud platform capability discovery.
  • the capability management control plane When the capability management control plane is connected to each lower-level cloud platform, it issues and loads a capability executor for the data plane, so that the lower-level cloud platform is capable of checking the validity and validity of the capability definition template language when receiving the capability template definition issued by the control plane.
  • the capability executor provides a capability testing sandbox module, which conducts simulation tests on newly launched capabilities, and assists in analyzing test output to ensure that capability development meets user needs, and finally load capabilities smoothly.
  • the capability executor provides testing capabilities for the capability definition upgrade scenario, diverts some capability creation requests to the implementation of the capability definition of the new version, and gradually replaces the old version with the new version according to the execution effect.
  • the blueprint orchestrator obtains the capability template definition in the capability definition database from the capability management control plane, dynamically generates application orchestration elements, and allows the application definer to flexibly select the orchestration elements according to the capability boundary. Users use the orchestrator to publish application package files to the control plane. During instantiation, the control plane determines the cloud platforms that can be deployed according to the capability boundary, and delivers the application package to the lower-level cloud platform. The various capabilities of the cloud platform are converted into cloud platform CRD and K8S native resources, thereby instantiating application packages.
  • FIG. 3 is a schematic diagram of a capability boundary in an embodiment of the present application.
  • CC Core Capability
  • SC Standard Capability
  • EC Extended Capability
  • CC is a predefined capability of the open application model
  • SC is the default implementation capability of the cloud platform management architecture of the embodiment of this application, and can support running on most cloud platforms
  • EC is based on the cloud platform management architecture of the embodiment of this application.
  • the secondary development capabilities of cloud platform users can be connected to the cloud platform ecology, and various plug-ins widely available in the open source community can be used to develop various capabilities required for application definition.
  • CC and SC capabilities cannot be modified, but EC can be updated and take effect dynamically.
  • the CC and SC of each platform are the same, that is, in Figure 3, the fourth cloud platform, the fifth cloud platform and the sixth cloud platform all have the same first core capability, second core competencies and third core competencies.
  • the full set of CC and SC is called a preset capability set, and its capability boundary is all cloud platforms, in FIG. 3 , it is the fourth cloud platform, the fifth cloud platform, and the sixth cloud platform.
  • FIG. 4 is a schematic diagram of the interface of the blueprint designer provided by the embodiment of the present application.
  • the blueprint designer consists of the layout element bar, ability filter and ability full set radio buttons, attribute input box, canvas and necessary buttons.
  • the arrangement element column on the left mainly presents various capabilities supported by the cloud platform management architecture of the embodiment of the present application, including preset capabilities and extension capabilities, that is, elements required for application definition.
  • Capability screening supports specifying the cloud platform on which the package can be deployed based on the capability boundary when writing an application package.
  • its capability screening column lists all the lower-level cloud platforms connected to the cloud platform management framework of the embodiment of the present application for selection, and according to the selection situation, the extended capability part of the arrangement element column displays all selected cloud platforms The intersection of extended capability sets.
  • the application of this scene orchestration can be instantiated directly on these selected cloud platforms, because the required capabilities are already supported.
  • the blueprint designer also supports not specifying the cloud platform according to the capability boundary when writing the package, that is, the full set of capabilities selection box.
  • the cloud platform management architecture of the embodiment of the application displays the union of all cloud platform extension capability sets in the extended capability part of the capability selection column, and the application definition can maximize the use of the cloud platform management of the embodiment of the application Ability to manage structures. Its capability boundaries are used when deploying applications using this package.
  • the designer dynamically displays writable capability definition parameters in the property bar according to the capability definition in the capability definition database.
  • vCDN virtual Content Delivery Network
  • Application, App Application, App
  • its general characteristics include running in a container, Expose web services to the outside world and support scaling, etc.; business features include setting up appropriate edge routing.
  • Pre-actions include accessing each edge cloud to support the operation of the vCDN App.
  • the capabilities of these edge clouds are found in the cloud platform management architecture of the embodiment of this application, such as specific capabilities that support offloading of edge applications.
  • the orchestration process includes:
  • Orchestration elements include general capabilities, such as container load, scaling features, and edge cloud-specific capabilities and expansion capabilities, such as distribution capabilities; according to the needs of vCDN App, drag and drop the container load of the orchestrator, scaling features, ingress (Ingress) capabilities and Distribute capabilities to define applications on the canvas. For specific capabilities, you can set the corresponding properties on the far right side of the arranger according to the capability definition.
  • the user needs to upload the business container image, and configure the image name in the image (Image) attribute of the container load; after defining the vCDN App, click Save to publish the App blueprint, that is, the user-defined application.
  • the App can modify the traffic rules and divert the content service requests on the edge side.
  • this app provides a management interface for operation and maintenance users through Ingress.
  • Capability elements can be applied flexibly, application orchestration elements can be dynamically generated according to capability template definitions in the capability definition database, and application definers can flexibly select orchestration elements according to capability boundaries.
  • the cloud platform management framework of the embodiment of the present application can continuously improve the orchestration capability of the application definition, and make more effective use of the cloud native ecology.
  • the embodiment of the present application also proposes the concept of capability boundary, which is used to manage the capability differences between cloud platforms, and dynamically generates the application orchestration interface based on the application capability and capability boundary, It can assist application developers in orchestrating and deploying application blueprints on multi-cloud platforms, further optimizing the effect of application orchestration.
  • FIG 5 is a flowchart of a cloud platform management method provided by an embodiment of the present application, which can be applied to the cloud platform management architecture in the embodiment shown in Figure 1, the cloud platform management method includes but is not limited to Steps S100 to S300.
  • Step S100 controlling the first management device to define at least one application capability based on the open application model, and each application capability is used to represent a load supported by a cloud platform or an operation and maintenance characteristic acting on a load;
  • Step S200 controlling the second management device to determine a capability boundary corresponding to the application capability according to the application capability from the first management device, and the capability boundary is used to represent each candidate cloud platform supporting the application capability;
  • Step S300 determine the application orchestration strategy for each candidate cloud platform according to the capability boundary.
  • multiple application capabilities are defined through the first management device, so the capability abstraction of cloud-native applications can be provided, thereby matching the differentiated scenarios of each cloud platform, and enhancing the integration of cloud-native applications in each cloud.
  • the second management device determines the capability boundaries used to characterize the candidate cloud platforms that support the defined application capabilities, so that the auxiliary application orchestration device determines the application for each candidate cloud platform through the capability boundaries Orchestration strategy, so as to realize the management of differentiated scenarios of multiple cloud platforms, and achieve the effect of optimizing application orchestration.
  • the first management device provides a capability definition specification, uses a capability database to maintain various capabilities, provides a variety of preset capabilities, and provides users with the ability to load secondary development and import cloud-native community-defined ability. All capability definitions are persisted to the capability database. At the same time, with the access of cloud platform instances, capability discovery and capability distribution are performed for each cloud platform, and the device will simultaneously establish the corresponding relationship between each capability and the managed cloud platform instance in the capability database to determine the capabilities supported by each cloud platform set.
  • the embodiment of this application also supports remote capability warehouses. Various capabilities contributed by the open source community can be placed in the capability warehouses. By configuring the remote capability warehouses, the cloud-native ecosystem can be seamlessly connected.
  • the capability definition itself involves various operations on cloud platform resources and plug-ins, and has certain complexity. Processes such as development, testing, and launch need to be considered.
  • K8S Through the Webhook mechanism of K8S, it is possible to verify the capability definition, verify the validity of the capability definition yaml, check the validity of the capability definition template language, and check the capability definition dependent resources and the satisfaction of the underlying plug-ins.
  • a preset capability definition element when programming an application, a preset capability definition element may be selected.
  • various extended capability definitions can be used by utilizing the capability boundary according to the selected cloud platform instance. It is even possible to ignore the capability boundary first, use all capability definitions managed by the application orchestration device, and then act on the capability boundary when instantiating the application.
  • the application definition generated by the embodiment of this application is packaged into a CHART package through Helm for instantiation and execution.
  • the application When the application is instantiated, it needs to execute the actions defined by the capability.
  • the capabilities defined in the embodiments of this application are provided through the K8S CRD, and the corresponding capability CRD needs to be executed through the capability executor, which needs to provide a corresponding controller (Controller) to implement related logic.
  • the capability executor converts the capability defined by the CRD to the cloud platform native resources or custom resources according to the capability reference definition.
  • the feature capability it executes the corresponding logic according to the capability template definition, and may even rely on other Operators or controls on the cloud platform. Controller (Controller) and the assistance of the underlying plug-ins.
  • a cloud platform instance that supports the application can be selected according to the capability boundary; if the conditions are met, it can also choose to actively deliver the capabilities required by the application to the target cloud platform, for
  • the cloud platform empowers and creates application operating conditions. The ultimate goal is to ensure that the defined application can be instantiated normally on the cloud platform and ensure the portability of the application between different cloud platforms.
  • the cloud platform management architecture of the embodiment of the present application also includes a capability database configured to store at least one capability template corresponding to at least one application capability, and the capability database is connected to the application arrangement device through the first management device; the application arrangement The device is also configured to generate a scriptable application capability orchestration element according to the open application model, and the application capability orchestration element corresponds to the capability template.
  • FIG. 6 is a specific flowchart of step S300 of the cloud platform management method in FIG. 5 .
  • step S300 includes but is not limited to step S310.
  • step S310 a target cloud platform for executing application instantiation is determined from various candidate cloud platforms according to the capability boundary.
  • the application orchestration device can present all preset capabilities during the orchestration, because its capability boundary is the full set of the cloud platform. At the same time, if it is possible to specify one or more cloud platform instances in which the defined application will run, then the intersection of the capabilities of these cloud platform instances can be used by the application definer, so that the defined application can be used normally in the target cloud platform instance. change.
  • the candidate target cloud platform instance can be filtered according to the capability boundary. Only the cloud platform instances corresponding to the capability boundaries corresponding to all the capabilities required by the application are filtered out for the user to choose. In this way, it can also effectively ensure that the application is instantiated normally on the target cloud platform.
  • the first management device may also expand the capability set of the cloud platform instance, and expand the capability boundary of certain capabilities. If the corresponding capability definition package and the plug-in package that the capability definition package depends on exist in the first management device, you can choose to deliver the capability definition package to the corresponding cloud platform for installation, thereby enabling the cloud platform to support Deployment of applications that are not natively supported.
  • FIG. 7 is a flowchart of a cloud platform management method provided by another embodiment of the present application.
  • the cloud platform management method in the embodiment of the present application further includes but not limited to step S400.
  • Step S400 controlling the first management device to determine the target application capability supported by the target cloud platform according to the target cloud platform and the application capability.
  • the cloud platform management method of the embodiment of the present application further includes but not limited to step S410.
  • Step S410 controlling the first management device to send a target capability definition data packet corresponding to the target application capability to the target cloud platform.
  • the first management device when a cloud platform is included in the management scope of the first management device, the first management device will actively discover the capability set supported by the cloud platform. Because capabilities are defined through the specifications of the open application model, all load definitions and feature definition instances can be queried through K8S native interfaces, and detailed information such as corresponding capability descriptions and scopes can be obtained.
  • the capabilities discovered by the first management device will be persisted in the database of the first management device, so there will be a corresponding table to store the corresponding relationship between the cloud platform and the capabilities. Finally, the respective capability sets of the multiple cloud platforms managed by the first management device are formed.
  • the first management device supports the capability types defined by the open application model specification, and supports a predefined capability set.
  • This preset capability is supported by most cloud platforms by default, such as predefined by K8S The capability corresponding to the resource type.
  • the first management device When a cloud platform is included in the management of the first management device, it must first be ensured that there is a capability executor on the cloud platform, and if not, the capability executor is issued in a cloud-native manner. When accessing the cloud platform, the first management device will deliver various preset capabilities to the target cloud platform, so that the cloud platform has corresponding capabilities. Because the capability definitions are K8S CRDs, these capability definitions can be delivered in the native way of K8S.
  • platform developers can define more capabilities through the specification of the open application model, incorporate them into the management of the first management device, and assign them to the corresponding cloud platform. It is also possible to use various open source capabilities of the K8S ecosystem in the cloud native community and import them into the first management device, so that the management capabilities of the first management device will continue to expand. In addition, if the existing capability definition is changed, the capability definition can be re-delivered and correspondingly updated on the target cloud platform.
  • the capability definition package can be selected to be delivered to the target cloud platform system for loading when the application is instantiated.
  • FIG. 9 is a specific flowchart of step S200 of the cloud platform management method in FIG. 5 .
  • step S200 includes but not limited to step S210.
  • Step S210 controlling the second management device to check the operation status of the application capability from the first management device, and controlling the second management device to adjust the application capability according to the operation status of the application capability, and controlling the second management device to adjust the application capability according to the adjusted application capability Determine capability boundaries that correspond to adjusted application capabilities.
  • a capability test sandbox is used to perform a simulation test on the capability just launched, and assist in analyzing the test output, so as to ensure that capability development meets user requirements.
  • the capability sandbox is a capability simulation operating environment, which is isolated from the production environment. It adopts a simulation method for the execution of many capability-related logics, and does not perform real resource operation actions. It can simulate the actual running effect of the capability to a certain extent, and The developer judges the correctness of the logic based on the output assistance ability.
  • the capability can be loaded into the official cloud environment to provide services.
  • the test capability can also be provided through webhook. At the beginning, some capability creation requests are diverted to the capability definition implementation of the new version, and the old version is gradually replaced with the new version according to the execution effect.
  • the specific implementation of the cloud platform management method in this embodiment can refer to the above-mentioned embodiments
  • the specific embodiments of the cloud platform management architecture in the above-mentioned embodiment have all the improvements of the cloud platform management architecture in the above-mentioned embodiments, and will not be repeated here.
  • the cloud platform management method in the embodiment of the present application further includes but not limited to step S420.
  • Step S420 generating a rescriptable application capability orchestration element according to the open application model, where the application capability orchestration element corresponds to a capability template.
  • the application capability orchestration elements are generated through the open application model, and the application capability orchestration elements can be flexibly used by users correspondingly, so as to further optimize the effect of application orchestration.
  • the specific implementation of the cloud platform management method in this embodiment can refer to the above-mentioned embodiments
  • the specific embodiments of the cloud platform management architecture in the above-mentioned embodiment have all the improvements of the cloud platform management architecture in the above-mentioned embodiments, and will not be repeated here.
  • FIG. 10 is a specific flow chart of the cloud platform management framework accessing the cloud platform according to the embodiment of the present application.
  • the specific process of accessing the cloud platform by the cloud platform management framework of the embodiment of the present application includes:
  • Step S500 initiate the operation of accessing the cloud platform instance
  • Step S510 delivering the capability executor through the Helm client, and loading the capability executor on the target cloud platform;
  • Step S520 judging whether the capability executor is successfully loaded; if yes, continue to execute step S530, otherwise, execute step S521;
  • Step S521, prompting that access to the cloud platform fails
  • Step S530 download and load the prefabricated capability template Chart through the Helm client, and load various plug-ins required by the prefabricated template at the same time;
  • Step S540 judging whether the prefabrication capacity is successfully loaded; if yes, continue to execute step S550, otherwise, execute step S541;
  • Step S541 uninstalling the capability executor, prompting that the access to the cloud platform fails
  • Step S550 discovering the capabilities supported by the new access cloud platform through capability discovery
  • Step S560 establishing capability set data supported by the cloud platform in the capability definition database
  • Step S570 updating the capability management boundary.
  • FIG. 11 is a specific flow chart of the cloud platform management architecture in the embodiment of the present application delivering capability definitions to lower-level cloud platforms.
  • the specific process for the cloud platform management framework of the embodiment of the present application to deliver capability definitions to the lower-level cloud platform includes:
  • Step S600 the capability manager initiates a capability definition delivery operation
  • Step S601 judge whether the current capability definition exists on the target cloud platform; if yes, skip to step S610; otherwise, continue to execute downward;
  • Step S602 judge whether the current capability definition package exists in the device; if yes, deliver the capability definition package to the target platform, and execute downward; otherwise, skip to step S609;
  • Step S603 the target cloud platform capability executor verifies the capability definition template, and judges whether the verification is passed; if yes, continue to execute downward; otherwise, skip to step S609;
  • Step S604 the target cloud platform capability executor parses the capability definition template, and judges whether there is a leading action initAction definition; if yes, continue to execute; otherwise, skip to step S609;
  • Step S605 the target cloud platform capability executor loads the plug-ins that the capability depends on for the cloud platform according to the initAction description in the capability definition;
  • Step S606 the target cloud platform loads the capability definition in the sandbox, and executes the capability sandbox test at the same time;
  • Step S607 judging whether the capability definition has passed the sandbox test; if yes, continue to execute downward; otherwise, skip to step S609;
  • Step S608 the target platform loads the definition of the capability, and at the same time feedbacks that the capability is delivered successfully;
  • Step S609 prompting that the loading of the capability definition fails and feeding back the reason
  • Step S610 prompting that the capability delivery is successful.
  • FIG. 12 is a specific flowchart of application instantiation performed by the cloud platform management architecture of the embodiment of the present application.
  • the specific process of instantiating the application by the cloud platform management architecture of the embodiment of the present application includes:
  • Step S700 execute instantiated application operation
  • Step S701 judging whether a cloud platform instance is selected when arranging the application package; if yes, jump to step S710; otherwise, continue to execute downward;
  • Step S702 analyzing all capability definition elements used in the application definition in the application package, and obtaining a cloud platform instance supporting the application according to the capability boundary;
  • Step S703 determine whether there is a cloud platform that can deploy the application; if yes, jump to step S710; otherwise, continue to execute downward;
  • Step S704 judging whether to select advanced functions to further deploy the application package; if yes, continue to execute downwards, otherwise, jump to step S711;
  • Step S705 displaying all connected cloud platform instances
  • Step S706 designate a cloud platform instance to deploy the application package
  • Step S707 calculate the capability set of the target cloud platform that is not good enough to deploy this application, and judge whether the poor capability set has a corresponding capability installation package; if yes, continue to execute downward; otherwise, jump to step S707 S711;
  • Step S708 deliver the corresponding capability installation package to the target cloud platform to perform capability installation, and judge whether the installation is successful; if yes, continue to execute downwards, otherwise, jump to step S711;
  • Step S709 execute the application instantiation action on the target cloud platform, and judge whether the instantiation is successful; if the instantiation fails, the prompt jumps to step S711;
  • Step S710 presenting a list of cloud platforms supported by the application for the user to choose;
  • Step S711 prompting that the application instantiation fails.
  • the specific implementation of the cloud platform management method in this embodiment can refer to the above-mentioned embodiments
  • the specific embodiments of the cloud platform management architecture in the above-mentioned embodiment have all the improvements of the cloud platform management architecture in the above-mentioned embodiments, and will not be repeated here.
  • an embodiment of the present application also provides a cloud platform management device, which includes: the cloud platform management architecture in the embodiment shown in FIG. 1 or the cloud platform management architecture in the embodiment shown in FIG. 2 .
  • the non-transitory software programs and instructions required to realize the cloud platform management method of the above-mentioned embodiment are stored in the memory, and when executed by the processor, the cloud platform management method of the above-mentioned embodiment is executed, for example, the above-described diagram is executed.
  • cloud platform management device in this embodiment can be applied to the cloud platform management architecture in the embodiment shown in Figure 1 or the cloud platform management architecture shown in the embodiment in Figure 2, and these embodiments all belong to Because of the same inventive concept, these embodiments have the same implementation principles and technical effects, and will not be described in detail here.
  • an embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by a processor or a controller, for example, by the above-mentioned device
  • the execution of the processor in the embodiment can cause the processor to execute the cloud platform management method in the above embodiment, for example, execute the method steps S100 to S300 in FIG. 5 described above, the method step S310 in FIG. 6 , and the method in FIG. Method step S400 in 7, method step S410 in Fig. 8, method step S210 in Fig. 9, method step S500 to step S570 in Fig. 10, method step S600 to S610 in Fig. 11, method step in Fig. 12 S700 to S711 or method step S420.
  • the embodiment of the present application includes: a cloud platform management framework, including a first management device, configured to define at least one application capability based on an open application model, and each application capability is used to represent a load supported by a cloud platform or an operation and maintenance action on a load Characteristics; the second management device, connected to the first management device, is configured to determine a capability boundary corresponding to the application capability according to the application capability from the first management device, and the capability boundary is used to characterize each candidate cloud platform supporting the application capability; The application arrangement and instantiation device is connected to the first management device and configured to determine the application arrangement and instantiation strategy for each candidate cloud platform according to the capability boundary.
  • a cloud platform management framework including a first management device, configured to define at least one application capability based on an open application model, and each application capability is used to represent a load supported by a cloud platform or an operation and maintenance action on a load Characteristics
  • the second management device connected to the first management device, is configured to determine a capability boundary corresponding to the application capability according to the application
  • multiple application capabilities are defined through the first management device, so the capability abstraction of cloud-native applications can be provided, and the differentiation of each cloud platform can be represented in a matching manner Scenario, enhance the portability of cloud-native applications between various cloud platforms, and determine the capability boundary of the candidate cloud platform that supports the defined application capabilities through the second management device, so that the auxiliary application arrangement and instantiation device Determine the application orchestration and instantiation strategy for each candidate cloud platform through the capability boundary, so as to manage the differentiated scenarios of multiple cloud platforms and achieve the effect of optimizing application orchestration and instantiation.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridges, tape, magnetic disk storage or other magnetic storage devices, or can Any other medium used to store desired information and which can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)

Abstract

一种云平台管理架构及管理方法、管理设备、计算机可读存储介质，其中，云平台管理架构（100），包括第一管理装置（200），被设置为基于开放应用模型定义至少一个应用能力，每个应用能力用于表征一个云平台支持的负载或者作用于负载的运维特性；第二管理装置（300），连接于第一管理装置（200），被设置为根据来自第一管理装置（200）的应用能力确定与应用能力对应的能力边界，能力边界用于表征支持应用能力的各个备选云平台；应用编排和实例化装置，连接于第一管理装置（200），被设置为根据能力边界确定针对各个备选云平台的应用编排和实例化策略。

Description

云平台管理架构及管理方法、管理设备、存储介质
相关申请的交叉引用
本申请基于申请号为202110915014.6，申请日为2021年08月10日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请实施例涉及但不限于云原生场景应用领域，尤其涉及一种云平台管理架构及管理方法、管理设备、计算机可读存储介质。
背景技术
目前，云平台上的应用编排基本都是耦合在云平台上以进行的，使用云平台提供的原生资源编排云原生应用，由于其资源种类有限，因此当编排系统对云平台的各种资源类型进行硬编码时，无法充分利用云原生生态提供的各种资源，更不具备在各个云平台之间的可移植性，换言之，对应用开发者而言，云平台陷入了能力困境，大多数平台即服务(Platform as a Service，PaaS)系统对支持的应用类型和支持的功能进行约束，体现在不可扩展、创建自身的插件系统，并由自身的社区维护等，而这种插件机制只能为PaaS系统专属的封闭小生态能力，无法大范围地可靠利用。并且，在实践中，针对多云管理系统进行应用设计，其中，中心机房集中托管不同云平台，不同云平台之间存在一定差异，在编排时，可选的编排元素通常仅能对一些简单通用资源进行封装，不能针对特定的云平台不同的插件能力进行设计，使得编排能力完全依赖于简单资源的封装，暴露什么样的字段则完全取决于开发人员对应用的理解，后期如需要更新字段时，只能通过修改代码、重新做版本等手段进行解决，非常的不灵活，同时造成云原生生态中大量的运维相关的插件无法使用，导致无法针对复杂应用特征进行编排，使得整体上的编排效果变差。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本申请实施例提供了一种云平台管理架构及管理方法、管理设备、计算机可读存储介质。
第一方面，本申请实施例提供了一种云平台管理架构，包括：第一管理装置，被设置为基于开放应用模型定义至少一个应用能力，每个所述应用能力用于表征一个云平台支持的负载或者作用于所述负载的运维特性；第二管理装置，连接于所述第一管理装置，被设置为根据来自所述第一管理装置的所述应用能力确定与所述应用能力对应的能力边界，所述能力边界用于表征支持所述应用能力的各个备选云平台；应用编排和实例化装置，连接于所述第一管理装置，被设置为根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略。
第二方面，本申请实施例还提供了一种云平台管理方法，应用于云平台管理架构，所述云平台管理架构包括第一管理装置和第二管理装置，所述第一管理装置连接于所述第二管理装置；所述云平台管理方法，包括：控制所述第一管理装置基于开放应用模型定义至少一个应用能力，每个所述应用能力用于表征一个云平台支持的负载或者作用于所述负载的运维特性；控制所述第二管理装置根据来自所述第一管理装置的所述应用能力确定与所述应用能力对应的能力边界，所述能力边界用于表征支持所述应用能力的各个备选云平台；根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略。
第三方面，本申请实施例还提供了一种云平台管理设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上所述第二方面的云平台管理方法。
第四方面，本申请实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如上所述第二方面的云平台管理方法。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来 实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1是本申请一个实施例提供的云平台管理架构的示意图；
图2是本申请一个具体示例提供的云平台管理架构示意图；
图3是本申请一个实施例提供的能力边界的示意图；
图4是本申请一个实施例提供的蓝图设计器的界面示意图；
图5是本申请一个实施例提供的云平台管理方法的流程图；
图6是本申请一个实施例提供的云平台管理方法中确定目标云平台的流程图；
图7是本申请另一个实施例提供的云平台管理方法的流程图；
图8是本申请另一个实施例提供的云平台管理方法的流程图；
图9是本申请一个实施例提供的云平台管理方法中确定能力边界的流程图；
图10是本申请实施例的云平台管理架构接入云平台的具体流程图；
图11是本申请实施例的云平台管理架构向下级云平台下发能力定义的具体流程图；
图12是本申请实施例的云平台管理架构执行应用实例化的具体流程图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
需要注意的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本申请提供了一种云平台管理架构及管理方法、管理设备、计算机可读存储介质，在开放应用模型的具体场景下，通过第一管理装置定义多个应用能力，因此能够提供云原生应用的能力抽象，从而匹配性地表征各个云平台的差异化场景，增强云原生应用在各个云平台之间的可移植性，并且通过第二管理装置确定用于表征支持所定义的应用能力的备选云平台的能力边界，使得辅助应用编排和实例化装置通过能力边界确定针对各个备选云平台的应用编排和实例化策略，从而实现对多个云平台的差异化场景进行管理，达到优化应用编排和实例化的效果。
下面结合附图，对本申请实施例作进一步阐述。
如图1所示，图1是本申请一个实施例提供的云平台管理架构100的示意图。
在图1的示例中，云平台管理架构100可以包括但不限于第一管理装置200，第一管理装置200被设置为基于开放应用模型定义至少一个应用能力，每个应用能力用于表征一个云平台支持的负载或者作用于负载的运维特性。
具体地，本申请实施例的云平台管理架构100所应用的云平台可以以云基础设施为核心，可运行于标准化硬件设施和增强及定制化硬件设备，云平台能够对外提供虚机、裸机和容器等基础虚拟化的单一或混合资源服务，并能整合提供技术组件、网络及业务服务等，也可按需扩展，为多产品提供云原生技术栈。
在一实施例中，上述标准化硬件设施和增强及定制化设备包括但不限于通用服务器、存储器、网络设备、定制化一体机、智能网卡和加速硬件等。
具体地，在本申请实施例中，云平台可以是基于K8S平台的容器云平台，也可以是基于K8S和开放式堆栈(Openstack)的双核云平台，本申请实施例不对云平台的类型做具体限制。
在一实施例中，开放应用模型(Open Application Model，OAM)是一种用于构建和交付云原生应用的标准规范。相比于传统平台，例如PaaS封闭不能同以能力执行器(Operator)为基础的云原生生态相衔接的现状，基于OAM和K8S构建的现代云原生应用管理平台，本质上是一个“以应用为中心”的K8S，保证了这个应用平台在能够无缝接入整个云原生生态。同时，OAM可以进一步屏蔽掉容器基础设施的复杂性和差异性， 为云平台的使用者带来低负担的、标准化的、一致的应用管理与交付体验。
在本申请实施例中，应用能力可以但不限于指能够组成一个完整应用的原子化功能，可以看作云平台为应用定义者提供的能力抽象，主要表述为支持的负载或者作用于这些负载上的运维特性，通过这些能力支持，应用定义者能够定义出满足业务要求的云原生应用出来。
具体地，负载包括但不限于函数、容器、云资源、虚拟机等多种不同形态的工作负载，负载用于描述以什么方式运行应用；运维特性则包括但不限于流量管理、发布策略、弹性策略、可观测性策略等多种不同的运维能力。最终，云平台本身可以通过不同负载和运维特性组合来对最终用户提供差异化的场景，帮助用户进行云原生应用定义。
在一实施例中，参照开放应用模型规范中约定的应用能力定义方式，采用标准模板定义应用能力。
在一实施例中，应用能力分为负载能力和特性能力，其中负载能力可以通过开放应用模型规范的标准模板中进行定义，例如，采用oam-kubernetes-runtime的core.oam.dev/v1alpha2.WorkloadDefinition进行定义，特性能力可以通过oam-kubernetes-runtime的core.oam.dev/v1alpha2.TraitDefinition定义，可以理解地是，负载定义(WorkloadDefinition)和特性定义(Trait Definition)都是K8S的自定义资源(Custom Resource Definitions，CRD)，所以通过CRD类型可以从云平台获取能力定义。
具体地，参照开放应用模型，根据应用能力特征，负载类型能够被分为核心负载类型(Core Workload Type)、标准负载类型(Standard Workload Type)和扩展负载类型(Extended Workload Type)，特性能力范围能够被分为核心特性(Core Trait)范围、标准特性(Standard Trait)范围和扩展特性(Extended Trait)范围。
其中，核心特性范围的能力是开放应用模型预定义的能力；标准特性范围的能力是本申请实施例的装置所能够实现的应用能力，在实际应用中，可以支持在大多数的云平台运行；扩展特性范围的能力是基于本申请实施例的装置所针对的云平台用户二次开发得到的应用能力，其可以对接云平台生态，利用开源社区广泛存在的各种插件，开发应用定义所需的各种应用能力。在通常情况下，核心特性范围和标准特性范围的应用能力不作修改，扩展特性范围的应用能力可以随时更新并动态生效。
在一实施例中，在K8S云平台上的负载能力可以通过引用K8S预定义资源或者CRD定义，即，可以通过yaml文件即可定义，若需要引入一种新的CRD，则需要加入对应的能力执行器，或者底层依赖插件，若特性能力需要底层插件的支持，则也可以根据需要加入对应的能力执行器和底层插件，其中，能力定义中支持定义前导动作，以加载这些能力执行器和插件。
在一实施例中，应用能力定义本身可以通过JavaScript对象简谱(JavaScript Object Notation,JSON)来表达，此外，应用能力定义也可以使用模板语言来开发，能够使用的模板语言包括但不限于CUELang或者Helm。
需要说明的是，第一管理装置200还被设置为根据目标云平台和应用能力确定目标云平台支持的目标应用能力，并且被设置为向目标云平台发送与目标应用能力对应的目标能力定义数据包。
在一实施例中，当一个云平台纳入第一管理装置200的管理范围时，第一管理装置200可以主动去发现此云平台支持的能力集，由于应用能力是通过开放应用模型的规范进行定义的，所以可以通过K8S原生接口查询所有的负载定义和特性定义实例，并得到对应应用能力描述、作用范围等细节信息。
在一实施例中，第一管理装置200发现的应用能力会持久化到第一管理装置200的数据库中，从而形成对应的表存储云平台和能力的对应关系，最终形成第一管理装置200管理的多个云平台各自的能力集合。
需要说明的是，针对不同的云平台实例，其能力集合可以相同，也可以不同。
在一实施例中，第一管理装置200可以支持开放应用模型规范定义的能力类型，并支持预定义能力集，这种预置的能力可以为大多数云平台默认支持的，比如通过K8S预定义的资源类型所对应的能力。
在一实施例中，第一管理装置200提供了能力定义规范，使用能力数据库维护各种能力，并提供了预置的多种能力，以及提供用户加载二次开发的能力，导入云原生社区定义的能力，所有能力定义都持久化到能力数据库中。同时，随着云平台实例的接入，对于各云平台进行能力发现和能力下发，本装置会同时在能力数据库中建立各能力和所管云平台实例的对应关系，确定各云平台支持的能力集。本申请实施例同时支持远程能力仓库，开源社区贡献的各种能力可以放置到能力仓库中，通过配置远程能力仓库，能够无缝对接云原生生态。
当一个云平台纳入第一管理装置200管理时，首先需要确保此云平台存在能力执行器，其中，能力执行器被设置为对所定义的应用能力进行处理，可以根据情况选择设置其规格和内容，如果不存在，则通过云原生方式下发能力执行器。接入云平台时，第一管理装置200会将预置的各种能力下发给目标云平台，从而让此云平台具备相应能力。因为能力定义是K8S CRD，所以可以通过K8S原生的方式下发这些能力定义。
同时，平台开发者后续可以通过开放应用模型的规范定义出更多的能力出来，纳入第一管理装置200管理，并指定下发给对应的云平台。也可以利用云原生社区中K8S生态下开源的各种能力，导入到第一管理装置200中，使得第一管理装置200管理的能力不断扩展。此外，如果已有能力定义发生了改变，可以重新下发此能力定义，并在对应云平台上对应更新。
需要说明的是，如果应用定义需要的能力定义包及其依赖的插件包在本装置中已经存在，则应用实例化的时候可以根据需要选择下发能力定义包到对应的云平台系统进行装载。
参照图1，本申请实施例的云平台管理架构100还包括第二管理装置300，第二管理装置300连接于第一管理装置200，被设置为根据来自第一管理装置200的应用能力确定与应用能力对应的能力边界，能力边界用于表征支持应用能力的各个备选云平台。
具体地，能力边界是指支持一个特定能力定义的云平台实例范围，其和能力类型关系密切，同时决定于某个云平台支持能力集。例如，对于预置的K8S平台能力，其作用范围是所有K8S类型的云平台。对于某个二次开发定义的能力或者导入的云原生社区定义的能力，其作用范围是显式下发此能力的云平台实例，或者是已经云平台上安装过此能力的云平台实例。
需要说明的是，第二管理装置300，被设置为校验来自第一管理装置200的应用能力的运行情况，并且被设置为根据应用能力的运行情况调节应用能力，并且被设置为根据调节后的应用能力确定与调节后的应用能力对应的能力边界。
此外，能力定义本身涉及对云平台资源、插件等各种操作，具有一定复杂性。需要考虑开发、测试以及上线等流程。通过K8S的网络钩(Webhook)机制，可以对能力定义进行校验，校验能力定义yaml合法性，检查能力定义模板语言的合法性，检验能力定义依赖资源和底层插件满足度。
第二管理装置300还提供一个能力测试沙箱，对刚上线的能力进行模拟测试，辅助分析测试输出，以确保能力开发满足用户需求。能力沙箱是一个能力模拟运行环境，其和生产环境隔离，对很多能力相关逻辑执行采用模拟方式，并不执行真实的资源操作动作，可以在一定程度上模拟出能力实际运行时的效果，并根据输出辅助能力开发者判定逻辑正确性。沙箱预测试通过后，能力就可以加载到正式云环境中提供服务了。并且在能力定义升级场景还可以通过webhook提供测试的能力，最开始导流部分能力创建请求到新版本能力定义实现上，根据执行效果逐渐用新版本替换老版本。
参照图1，本申请实施例的云平台管理架构100还包括应用编排装置400，应用编排装置400连接于第一管理装置200，被设置为根据能力边界确定针对各个备选云平台的应用编排策略。
需要说明的是，传统的应用编排系统基本采用硬编码的模式，其根据具体云平台资源类型实现硬编码编排界面，而由于其本身不具有可扩展性，造成定义的应用不具有可移植性，因此无法应对多云平台能力的差异管理。相对于传统硬编码的应用编排系统，本申请实施例的应用编排装置400可以灵活应用能力元素，根据能力定义数据库中的能力模板定义动态生成应用编排元素，并可以根据能力边界让应用定义者对应使用编排元素。同时根据不断引入的新能力定义，持续提升本装置支持应用定义的编排能力，更有效利用云原生生态。
需要说明的是，本申请实施例的应用编排装置400，被设置为根据能力边界从各个备选云平台中确定用于执行应用实例化的目标云平台。
用户编排应用的时候，可以选择预置的能力定义元素。同时，可以根据选择的云平台实例，利用能力边界使用各种扩展的能力定义，或者，可以先忽略能力边界，使用应用编排装置400管理的所有能力定义，至实例化应用的时候再作用于能力边界。
本申请实施例生成的应用定义可以通过Helm打包成CHART包，供实例化执行。
应用实例化的时候需要执行能力定义的动作。本申请定义的能力是通过K8S CRD的方式提供，对应能力CRD需要通过能力执行器来执行，能力执行器需要提供对应的控制器(Controller)实现相关逻辑。能力执行器对于负载能力是将CRD定义的能力按照能力引用定义转换到云平台原生资源或者自定义资源上，对于特 性能力是根据能力模板定义执行相应逻辑，甚至可能依赖云平台上其他Operator或者控制器(Controller)以及底层插件的协助。
本申请实施例编排蓝图实例化应用的时候，可以根据能力边界选择支持此应用的云平台实例；在相应条件下，还可以选择主动下发此应用需要的能力到目标云平台，为云平台赋能，创造应用运行条件，最终目标达到确保定义的应用能在云平台正常实例化，保障应用在不同云平台间的可移植性。
可以理解的是，本申请实施例的云平台管理架构100还包括被设置为存储与至少一个应用能力对应的至少一个能力模板的能力数据库，能力数据库通过第一管理装置200连接于应用编排装置400；应用编排装置400还被设置为根据来自能力数据库的能力模板生成可编写的应用能力编排元素，应用能力编排元素与能力模板对应。
第一管理装置200所管理的云平台能力模板最终会持久化到能力数据库中，以便对能力提供持续性管理，以根据能力数据后续生成编排界面。同时，能力数据库提供能力定义模板注册、查询、更新和删除等接口，例如：
GET{apiRoot}/app_lcm/v2/capabilities定义了查询云平台上所有能力模板定义的接口，又如，GET{apiRoot}/app_lcm/v2/capabilities/:id定义了查询云平台上指定ID的能力模板信息的接口，再如，3.POST{apiRoot}/app_lcm/v2/capability定义了向云平台提交用户自定义的能力模板的接口。
在一实施例中，应用编排装置400在编排的时候，可以呈现所有预置能力，因为其能力边界是云平台全集。同时如果编排时能明确后续此定义应用运行的一个或多个云平台实例，则可以取这些云平台实例的能力的交集供应用定义者使用，从而使得定义的应用后续可以正常在目标云平台实例化。
并且，在应用编排时也可以先不关注各云平台能力集差异，因为某些云平台可能是后续才纳入本第一管理装置200管理的，此外，也可以在纳入第一管理装置200后主动在云平台实例上安装各种能力。所以可以让用户按照自己需要选择第一管理装置200管理的所有能力类型。在实例化的时候，备选目标云平台实例可以根据能力边界进行过滤。仅仅过滤出支持本应用所需的所有能力所对应的能力边界的云平台实例供用户选择。这样，也能有效确保应用在目标云平台正常实例化。
在一实施例中，第一管理装置200还可以扩大云平台实例的能力集，扩展某些能力的能力边界。如果对应的能力定义包及该能力定义包所依赖的插件包在第一管理装置200中存在，则可以选择下发能力定义包到对应云平台执行安装，从而为云平台赋能，让其能支持原本不支持的应用部署。
因此，本申请实施例在开放应用模型的具体场景下，通过第一管理装置200定义多个应用能力，因此能够提供云原生应用的能力抽象，从而匹配性地表征各个云平台的差异化场景，增强云原生应用在各个云平台之间的可移植性，并且通过第二管理装置300确定用于表征支持所定义的应用能力的备选云平台的能力边界，使得辅助应用编排装置400通过能力边界确定针对各个备选云平台的应用编排策略，从而实现对多个云平台的差异化场景进行管理，达到优化应用编排的效果。
为了更清楚地阐述以上各个实施例的工作原理，以下给出具体示例进行说明。
示例一：
参照图2，图2是本申请一个具体示例提供的云平台管理架构示意图。
在图2的示例中，第一云平台包括能力管理器和能力执行器，能力管理器是能力管理控制面，被设置为能力管理；能力执行器，是能力管理数据面，被设置为能力装载，执行和应用包实例化，例如第二云平台和第三云平台中的应用实例。同时，第一云平台也具备数据面功能。
其中，能力管理控制面通过参照开放应用模型规范中约定的能力定义方式，采用标准模板提供能力定义；通过能力抽象出支持应用定义的元素，通过对多个下级云平台上能力的差异化管理，明确各云平台的能力范围，并将各云平台上的能力持久化在能力定义数据库中，最终提供完整的能力管理；通过在接入下级云平台时，将预置能力和用户自定义的扩展能力集下发给目标云平台，提供能力下发；通过K8S查询所有的负载定义和特性定义详情，并得到对应能力描述，作用范围等细节信息，从而提供多云平台能力发现。
能力管理控制面在接入各下级云平台时，为数据面下发并装载能力执行器，使得下级云平台具备在接收控制面下发的能力模板定义时，检查能力定义模板语言的合法性和依赖云平台资源、底层插件的满足度的能力。同时，能力执行器提供能力测试沙箱模块，对刚上线的能力进行模拟测试，辅助分析测试输出，以确保能力开发满足用户需求，最后顺利装载能力。此外，能力执行器为能力定义升级场景提供测试的能力，导流 部分能力创建请求到新版本能力定义实现上，根据执行效果逐渐用新版本替换老版本。蓝图编排器从能力管理控制面获取能力定义数据库中的能力模板定义，动态生成应用编排元素，并可以根据能力边界让应用定义者灵活的选择编排元素。用户使用编排器向控制面发布应用包文件。实例化时，控制面根据能力边界确定可用部署的云平台，下发应用包到下级云平台，下级云平台在收到蓝图编排的应用包后，通过数据面的能力执行器将应用定义所使用的各能力转换为云平台CRD、K8S原生资源，从而实例化应用包。
示例二：
参照图3，图3是本申请实施例的能力边界的示意图。
在图3的示例中，根据运维和工作负载的能力特征，将能力分为三种，分别是核心能力(CoreCapability，CC)、标准能力(Standard Capability，SC)和扩展能力(Extended Capability，EC)。
其中，CC是开放应用模型预定义的能力；SC是本申请实施例的云平台管理架构默认实现的能力，能支持在大多数云平台运行；EC是基于本申请实施例的云平台管理架构，云平台用户二次开发出的能力，其可以对接云平台生态，利用开源社区广泛存在的各种插件，开发应用定义所需的各种能力。CC和SC能力不允许修改，EC可以更新，并动态生效。
因此，对于多云平台而言，其各平台具有的CC和SC是相同的，即图3中，第四云平台、第五云平台和第六云平台都具有相同的第一核心能力、第二核心能力和第三核心能力。本申请实施例将CC和SC的全集称为预置能力集，其能力边界为所有云平台，在图3中为第四云平台、第五云平台和第六云平台。
此外，由于EC一般是用户二次开发，根据用户下发情况和云平台基础设施的不同，不同云平台在实际运行中，可能具有不同或相同的EC。所以从能力边界而言，不同的EC可能具有相同或不同的能力边界。以图3为例：第一扩展能力和第四扩展能力的能力边界为第四云平台和第五云平台；第二扩展能力和第三扩展能力的能力边界为第四云平台；第五扩展能力的能力边界为第五云平台；第六扩展能力、第七扩展能力、第九扩展能力的能力边界为第六云平台。
示例三：
参照图4，图4是本申请实施例提供的蓝图设计器的界面示意图。蓝图设计器由编排元素栏、能力筛选和能力全集单选框、属性输入框，以及画布和必要的按键组成。
其中，左边的编排元素栏主要呈现本申请实施例的云平台管理架构支持的各种能力，包括预置能力和扩展能力，即应用定义所需元素。
能力筛选支持在编写应用包时，根据能力边界指定包可部署的云平台。当选中能力筛选框时，其能力筛选栏列出本申请实施例的云平台管理架构所接入的所有下级云平台供选择，根据选择情况，编排元素栏的扩展能力部分展示所选所有云平台扩展能力集的交集。这种场景编排的应用可以直接在这些所选云平台实例化，因为所需能力都已支持。
同时，蓝图设计器也支持在编写包时，不根据能力边界指定云平台，即能力全集选择框。当勾选能力全集框时，本申请实施例的云平台管理架构在能力选择栏的扩展能力部分展示所有云平台扩展能力集的并集，应用定义可以最大化使用本申请实施例的云平台管理架构管理的能力。其能力边界在使用该包部署应用时作用。
最后，在蓝图设计器画布中选中具体的能力定义时，设计器根据能力定义数据库中的能力定义动态在属性栏中显示可编写的能力定义参数。
下面是使用本申请实施例定义应用的过程，例如要定义一个5G边缘业务的虚拟内容分发网络(virtual Content Delivery Network，vCDN)内容服务应用(Application，App)，其通用特性包括以容器方式运行、对外暴露web服务和支持弹缩等；业务特性包括要设置合适的边缘路由。
前置动作包括接入各个边缘云，以支持vCDN App运行，这些边缘云的能力被发现到本申请实施例的云平台管理架构，比如支持边缘应用分流的特定能力。
编排过程包括：
打开本申请实施例的云平台管理架构的应用蓝布编排器开始定义应用；可以通过能力选择器选择vCDN App可能运行的边缘云平台；蓝布编排器根据能力数据库和能力边界呈现编排元素栏，编排元素包括通用的能力，比如容器负载，弹缩特性以及边缘云特定能力及扩展能力，比如分流能力；根据vCDN App需要，拖拽编排器的容器负载、弹缩特性、入口(Ingress)能力和分流能力到画布上定义应用，对于具体的能力，可以 根据能力定义在编排器最右边设置对应属性。同时用户要上载业务容器镜像，并对应在容器负载的镜像(Image)属性中配置镜像名称；定义好vCDN App后点击保存，即可以发布App蓝图了，即用户定义的应用。
在一实施例中，可以选择vCDN App蓝图，以及选择具体的云平台，执行应用实例化动作，最终在指定的边缘云上部署此App，App可以修改流量规则，导流边缘侧的内容服务请求到本APP，可以缓存各种内容信息，就近为用户服务。同时此App通过Ingress为运维用户提供管理界面。
综上，相对传统的应用编排系统多数是硬编码、本身不具有可扩展性、定义的应用不具有可移植性以及无法应对多云平台能力的差异等特点，基于本申请实施例的云平台管理架构可以灵活应用能力元素，根据能力定义数据库中的能力模板定义动态生成应用编排元素，并可以根据能力边界让应用定义者灵活的选择编排元素。同时根据不断引入新的能力元素，持续提升本申请实施例的云平台管理架构支持应用定义的编排能力，更有效利用云原生生态，换言之，本申请实施例针对现有云平台上应用定义能力的困境，利用开放应用模型和成熟的云原生生态对云平台能力进行定义，明确提出对能力进行相应管理、划分能力类型以及提供预置能力等操作。尤其是在多云场景下，通过主动发现各云平台支持的应用负载、运维特性等应用定义能力，同时支持基于云平台现有各种插件开发各种应用能力，集中下发给各云平台，并且为云平台赋能，需要强调的是，本申请实施例还提出了能力边界的概念，用于管理各云平台之间的能力差异，并且基于应用能力和能力边界而动态生成应用编排界面，能够辅助应用开发者在多云平台上进行应用蓝图编排和部署，进一步优化应用编排的效果。
基于上述云平台管理架构，提出本申请的云平台管理方法的各个实施例。
如图5所示，图5是本申请一个实施例提供的云平台管理方法的流程图，可以应用于如图1所示实施例中的云平台管理架构，该云平台管理方法包括但不限于步骤S100至S300。
步骤S100，控制第一管理装置基于开放应用模型定义至少一个应用能力，每个应用能力用于表征一个云平台支持的负载或者作用于负载的运维特性；
步骤S200，控制第二管理装置根据来自第一管理装置的应用能力确定与应用能力对应的能力边界，能力边界用于表征支持应用能力的各个备选云平台；
步骤S300，根据能力边界确定针对各个备选云平台的应用编排策略。
在开放应用模型的具体场景下，通过第一管理装置定义多个应用能力，因此能够提供云原生应用的能力抽象，从而匹配性地表征各个云平台的差异化场景，增强云原生应用在各个云平台之间的可移植性，并且通过第二管理装置确定用于表征支持所定义的应用能力的备选云平台的能力边界，使得辅助应用编排装置通过能力边界确定针对各个备选云平台的应用编排策略，从而实现对多个云平台的差异化场景进行管理，达到优化应用编排的效果。
在一实施例中，第一管理装置提供了能力定义规范，使用能力数据库维护各种能力，并提供了预置的多种能力，以及提供用户加载二次开发的能力，导入云原生社区定义的能力。所有能力定义都持久化到能力数据库中。同时，随着云平台实例的接入，对于各云平台进行能力发现和能力下发，本装置会同时在能力数据库中建立各能力和所管云平台实例的对应关系，确定各云平台支持的能力集。本申请实施例同时支持远程能力仓库，开源社区贡献的各种能力可以放置到能力仓库中，通过配置远程能力仓库，能够无缝对接云原生生态。
在一实施例中，能力定义本身涉及对云平台资源，插件的各种操作，具有一定复杂性。需要考虑开发，测试，上线等流程。通过K8S的网络钩(Webhook)机制，可以对能力定义进行校验，校验能力定义yaml合法性，检查能力定义模板语言的合法性，检验能力定义依赖资源和底层插件满足度。
在一实施例中，在编排应用时，可以选择预置的能力定义元素。同时，可以根据选择的云平台实例，利用能力边界使用各种扩展的能力定义。甚至可以先忽略能力边界，使用应用编排装置管理的所有能力定义，实例化应用的时候再作用于能力边界。
本申请实施例生成的应用定义通过Helm打包成CHART包，供实例化执行。
应用实例化的时候需要执行能力定义的动作。本申请实施例定义的能力是通过K8S CRD的方式提供，对应能力CRD需要通过能力执行器来执行，能力执行器需要提供对应的控制器(Controller)实现相关逻辑。能力执行器对于负载能力是将CRD定义的能力按照能力引用定义转换到云平台原生资源或者自定义资源上，对于特性能力是根据能力模板定义执行相应逻辑，甚至可能依赖云平台上其他Operator或者控制器 (Controller)以及底层插件的协助。
本申请实施例编排应用蓝图实例化应用的时候，可以根据能力边界选择支持此应用的云平台实例；在条件具备的情况下，还可以选择主动下发此应用需要的能力到目标云平台，为云平台赋能，创造应用运行条件。最终目标都是确保定义的应用能在云平台正常实例化，保障应用在不同云平台间的可移植性。
可以理解的是，本申请实施例的云平台管理架构还包括被设置为存储与至少一个应用能力对应的至少一个能力模板的能力数据库，能力数据库通过第一管理装置连接于应用编排装置；应用编排装置还被设置为根据开放应用模型生成可编写的应用能力编排元素，应用能力编排元素与能力模板对应。
如图6所示，图6是图5中云平台管理方法的步骤S300的具体流程图。
在图6的示例中，步骤S300包括但不限于步骤S310。
步骤S310，根据能力边界从各个备选云平台中确定用于执行应用实例化的目标云平台。
在一实施例中，应用编排装置在编排的时候，可以呈现所有预置能力，因为其能力边界是云平台全集。同时如果编排时能明确后续此定义应用运行的一个或多个云平台实例，则可以取这些云平台实例的能力的交集供应用定义者使用，从而使得定义的应用后续可以正常在目标云平台实例化。
并且，在应用编排时也可以先不关注各云平台能力集差异，因为某些云平台可能是后续才纳入本第一管理装置管理的，此外，也可以在纳入第一管理装置后主动在云平台实例上安装各种能力，所以可以让用户按照自己需要选择第一管理装置管理的所有能力类型。在实例化的时候，备选目标云平台实例可以根据能力边界进行过滤。仅仅过滤出支持本应用所需的所有能力所对应的能力边界的云平台实例供用户选择。这样，也能有效确保应用在目标云平台正常实例化。
在一实施例中，第一管理装置还可以扩大云平台实例的能力集，扩展某些能力的能力边界。如果对应的能力定义包及该能力定义包所依赖的插件包在第一管理装置中存在，则可以选择下发能力定义包到对应云平台执行安装，从而为云平台赋能，让其能支持原本不支持的应用部署。
如图7所示，图7是本申请另一实施例提供的云平台管理方法的流程图。
在图7的示例中，本申请实施例的云平台管理方法还包括但不限于步骤S400。
步骤S400，控制第一管理装置根据目标云平台和应用能力确定目标云平台支持的目标应用能力。
在图8的示例中，本申请实施例的云平台管理方法还包括但不限于步骤S410。
步骤S410，控制第一管理装置向目标云平台发送与目标应用能力对应的目标能力定义数据包。
在一实施例中，当一个云平台纳入第一管理装置的管理范围时，第一管理装置会主动去发现此云平台支持的能力集。因为能力是通过开放应用模型的规范进行定义的，所以可以通过K8S原生接口查询所有的负载定义和特性定义实例，并得到对应能力描述，作用范围等细节信息。
第一管理装置发现的能力会持久化到第一管理装置的数据库中，所以会有对应的表存储云平台和能力的对应关系。最终形成第一管理装置管理的多个云平台各自的能力集合。
需要说明的是，不同的云平台实例，其能力集合可以相同也可以不同。
在一实施例中，第一管理装置会支持开放应用模型规范定义的能力类型，并支持预定义能力集，这种预置的能力是大多数云平台默认就支持的，比如通过K8S预定义的资源类型所对应的能力。
当一个云平台纳入第一管理装置管理时，首先要确保此云平台存在能力执行器，如果不存在，则通过云原生方式下发能力执行器。接入云平台时，第一管理装置会将预置的各种能力下发给目标云平台，从而让此云平台具备相应能力。因为能力定义是K8S CRD，所以可以通过K8S原生的方式下发这些能力定义。
同时，平台开发者后续可以通过开放应用模型的规范定义出更多的能力出来，纳入第一管理装置管理，并指定下发给对应的云平台。也可以利用云原生社区中K8S生态下开源的各种能力，导入到第一管理装置中，使得第一管理装置管理的能力不断扩展。此外，如果已有能力定义发生了改变，可以重新下发此能力定义，并在目标云平台上对应更新。
需要说明的是，如果应用定义需要的能力定义包及其依赖的插件包在本装置中已经存在，则应用实例化的时候可以根据需要选择下发能力定义包到目标云平台系统装载。
如图9所示，图9是图5中云平台管理方法的步骤S200的具体流程图。
在图9的示例中，步骤S200包括但不限于步骤S210。
步骤S210，控制第二管理装置校验来自第一管理装置的应用能力的运行情况，并且控制第二管理装置根 据应用能力的运行情况调节应用能力，并且控制第二管理装置根据调节后的应用能力确定与调节后的应用能力对应的能力边界。
在一实施例中，通过能力测试沙箱对刚上线的能力进行模拟测试，辅助分析测试输出，以确保能力开发满足用户需求。能力沙箱是一个能力模拟运行环境，其和生产环境隔离，对很多能力相关逻辑执行采用模拟方式，并不执行真实的资源操作动作，可以在一定程度上模拟出能力实际运行时的效果，并根据输出辅助能力开发者判定逻辑正确性。沙箱预测试通过后，能力就可以加载到正式云环境中提供服务。并且在能力定义升级场景还可以通过webhook提供测试的能力，最开始导流部分能力创建请求到新版本能力定义实现上，根据执行效果逐渐用新版本替换老版本。
值得注意的是，由于本实施例中的云平台管理方法与上述实施例中的云平台管理架构属于同一发明构思，因此本实施例中的云平台管理方法的具体实施方式，可以参照上述实施例中的云平台管理架构的具体实施例，具有上述实施例中的云平台管理架构的全部改进，在此不作赘述。
本申请实施例的云平台管理方法，还包括但不限于步骤S420。
步骤S420，根据开放应用模型生成可编写的应用能力编排元素，应用能力编排元素与能力模板对应。
在一实施例中，通过开放应用模型生成应用能力编排元素，可供用户对应地灵活使用应用能力编排元素，从而进一步优化应用编排的效果。
值得注意的是，由于本实施例中的云平台管理方法与上述实施例中的云平台管理架构属于同一发明构思，因此本实施例中的云平台管理方法的具体实施方式，可以参照上述实施例中的云平台管理架构的具体实施例，具有上述实施例中的云平台管理架构的全部改进，在此不作赘述。
示例四：
参照图10，图10是本申请实施例的云平台管理架构接入云平台的具体流程图。
在图10的示例中，本申请实施例的云平台管理架构接入云平台的具体流程包括：
步骤S500，发起接入云平台实例操作；
步骤S510，通过Helm客户端下发能力执行器，在目标云平台装载能力执行器；
步骤S520，判断能力执行器是否装载成功；如果是，则继续向下执行步骤S530，否则，执行步骤S521；
步骤S521，提示接入云平台失败；
步骤S530，通过Helm客户端下发装载预制能力模板Chart，同时装载预制模板所需的各种插件；
步骤S540，判断预制能力是否装载成功；如果是，则继续向下执行步骤S550，否则，执行步骤S541；
步骤S541，卸载能力执行器，提示接入云平台失败；
步骤S550，通过能力发现，发现此新接入云平台支持的能力；
步骤S560，在能力定义数据库中建立此云平台支持的能力集数据；
步骤S570，更新能力管理边界。
示例五：
参照图11，图11是本申请实施例的云平台管理架构向下级云平台下发能力定义的具体流程图。
在图11的示例中，本申请实施例的云平台管理架构向下级云平台下发能力定义的具体流程包括：
步骤S600，能力管理器发起能力定义下发操作；
步骤S601，判断当前能力定义在目标云平台是否存在；如果是，则跳到步骤S610；否则，继续向下执行；
步骤S602，判断当前能力定义包在本装置是否存在；如果是，则下发能力定义包到目标平台，并向下执行；否则，跳到步骤S609；
步骤S603，目标云平台能力执行器校验能力定义模板，判断是否通过校验；如果是，则继续向下执行；否则，跳到步骤S609；
步骤S604，目标云平台能力执行器解析能力定义模板，判断是否存在前导动作initAction定义；如果是，则继续向下执行；否则，跳到步骤S609；
步骤S605，目标云平台能力执行器根据能力定义中的initAction描述，为云平台装载能力所依赖的插件；
步骤S606，目标云平台在沙箱中加载能力定义，同时执行能力沙箱测试；
步骤S607，判断能力定义是否通过沙箱测试；如果是，则继续向下执行；否则，跳到步骤S609；
步骤S608，目标平台装载能力定义，同时反馈能力下发成功；
步骤S609，提示能力定义加载失败并反馈原因；
步骤S610，提示下发能力成功。
示例六：
参照图12，图12是本申请实施例的云平台管理架构进行应用实例化的具体流程图。
在图12的示例中，本申请实施例的云平台管理架构进行应用实例化的具体流程包括：
步骤S700，执行实例化应用操作；
步骤S701，判断编排应用包时，是否选择了云平台实例；如果是，跳转到步骤S710；否则，继续向下执行；
步骤S702，分析该应用包中，应用定义所使用的所有能力定义元素，根据能力边界得出支持此应用的云平台实例；
步骤S703，根据云平台实例，判断是否有云平台可以部署此应用；如果是，跳转到步骤S710；否则，继续向下执行；
步骤S704，判断是否选择高级功能进一步部署此应用包；如果是，则继续向下执行，否则，跳转到步骤S711；
步骤S705，展示所有接入的云平台实例；
步骤S706，指定部署此应用包的云平台实例；
步骤S707，根据能力边界，计算目标云平台要部署此应用还差的能力集合，并判断所差的能力集是否有对应能力安装包；如果是，则继续向下执行；否则，跳转到步骤S711；
步骤S708，下发对应能力安装包到目标云平台执行能力安装，并判断安装是否成功；如果是，则继续向下执行，否则，跳转到步骤S711；
步骤S709，在目标云平台上执行应用实例化动作，并判断是否实例化成功；若实例化失败，提示跳转到步骤S711；
步骤S710，呈现应用支持的云平台列表供用户选择；
步骤S711，提示应用实例化失败。
值得注意的是，由于本实施例中的云平台管理方法与上述实施例中的云平台管理架构属于同一发明构思，因此本实施例中的云平台管理方法的具体实施方式，可以参照上述实施例中的云平台管理架构的具体实施例，具有上述实施例中的云平台管理架构的全部改进，在此不作赘述。
另外，本申请的一个实施例还提供了一种云平台管理设备，该管理设备包括：如图1所示实施例中的云平台管理架构或者如图2实施例所示的云平台管理架构。
其中，实现上述实施例的云平台管理方法所需的非暂态软件程序以及指令存储在存储器中，当被处理器执行时，执行上述实施例的云平台管理方法，例如，执行以上描述的图5中的方法步骤S100至步骤S300、图6中的方法步骤S310、图7中的方法步骤S400、图8中的方法步骤S410、图9中的方法步骤S210、图10中的方法步骤S500至步骤S570、图11中的方法步骤S600至S610、图12中的方法步骤S700至S711或方法步骤S420。
需要说明的是，本实施例中的云平台管理设备，可以应用于如图1所示实施例中的云平台管理架构或者如图2实施例所示的云平台管理架构，这些实施例均属于相同的发明构思，因此这些实施例具有相同的实现原理以及技术效果，此处不再详述。
以上所描述的装置实施例仅仅是举例，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
此外，本申请的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被处理器或控制器执行，例如，被上述设备实施例中的处理器执行，可使得上述处理器执行上述实施例中的云平台管理方法，例如，执行以上描述的图5中的方法步骤S100至步骤S300、图6中的方法步骤S310、图7中的方法步骤S400、图8中的方法步骤S410、图9中的方法步骤S210、图10中的方法步骤S500至步骤S570、图11中的方法步骤S600至S610、图12中的方法步骤S700至S711或方法 步骤S420。
本申请实施例包括：云平台管理架构，包括第一管理装置，被设置为基于开放应用模型定义至少一个应用能力，每个应用能力用于表征一个云平台支持的负载或者作用于负载的运维特性；第二管理装置，连接于第一管理装置，被设置为根据来自第一管理装置的应用能力确定与应用能力对应的能力边界，能力边界用于表征支持应用能力的各个备选云平台；应用编排和实例化装置，连接于第一管理装置，被设置为根据能力边界确定针对各个备选云平台的应用编排和实例化策略。根据本申请实施例提供的方案，在开放应用模型的具体场景下，通过第一管理装置定义多个应用能力，因此能够提供云原生应用的能力抽象，从而匹配性地表征各个云平台的差异化场景，增强云原生应用在各个云平台之间的可移植性，并且通过第二管理装置确定用于表征支持所定义的应用能力的备选云平台的能力边界，使得辅助应用编排和实例化装置通过能力边界确定针对各个备选云平台的应用编排和实例化策略，从而实现对多个云平台的差异化场景进行管理，达到优化应用编排和实例化的效果。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上是对本申请的若干实施方式进行的具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (15)

  1. 一种云平台管理架构，包括：
    第一管理装置，被设置为基于开放应用模型定义至少一个应用能力，每个所述应用能力用于表征一个云平台支持的负载或者作用于所述负载的运维特性；
    第二管理装置，连接于所述第一管理装置，被设置为根据来自所述第一管理装置的所述应用能力确定与所述应用能力对应的能力边界，所述能力边界用于表征支持所述应用能力的各个备选云平台；
    应用编排和实例化装置，连接于所述第一管理装置，被设置为根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略。
  2. 根据权利要求1所述的云平台管理架构，其中，所述应用编排和实例化装置，被设置为根据所述能力边界从各个所述备选云平台中确定用于执行应用编排和实例化的目标云平台。
  3. 根据权利要求2所述的云平台管理架构，其中所述第一管理装置，还被设置为根据所述目标云平台和所述应用能力确定所述目标云平台支持的目标应用能力。
  4. 根据权利要求3所述的云平台管理架构，其中所述第一管理装置，还被设置为向所述目标云平台发送与所述目标应用能力对应的目标能力定义数据包。
  5. 根据权利要求1至4任意一项所述的云平台管理架构，其中，所述第二管理装置，被设置为校验来自所述第一管理装置的所述应用能力的运行情况，并且被设置为根据所述应用能力的所述运行情况调节所述应用能力，并且被设置为根据调节后的所述应用能力确定与调节后的所述应用能力对应的所述能力边界。
  6. 根据权利要求1所述的云平台管理架构，还包括被设置为存储与至少一个所述应用能力对应的至少一个能力模板的能力数据库，其中，所述能力数据库通过所述第一管理装置连接于所述应用编排和实例化装置。
  7. 根据权利要求6所述的云平台管理架构，其中，所述应用编排和实例化装置，还被设置为根据所述开放应用模型生成可编写的应用能力编排元素，所述应用能力编排元素与所述能力模板对应。
  8. 一种云平台管理方法，应用于云平台管理架构，所述云平台管理架构包括第一管理装置和第二管理装置，所述第一管理装置连接于所述第一管理装置；
    所述云平台管理方法，包括：
    控制所述第一管理装置基于开放应用模型定义至少一个应用能力，每个所述应用能力用于表征一个云平台支持的负载或者作用于所述负载的运维特性；
    控制所述第二管理装置根据来自所述第一管理装置的所述应用能力确定与所述应用能力对应的能力边界，所述能力边界用于表征支持所述应用能力的各个备选云平台；
    根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略。
  9. 根据权利要求8所述的云平台管理方法，其中，所述根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略，包括：
    根据所述能力边界从各个所述备选云平台中确定用于执行应用编排和实例化的目标云平台。
  10. 根据权利要求9所述的云平台管理方法，其中，所述根据所述能力边界确定针对各个所述备选云平台的应用编排和实例化策略之后，还包括：
    控制所述第一管理装置根据所述目标云平台和所述应用能力确定所述目标云平台支持的目标应用能力。
  11. 根据权利要求10所述的云平台管理方法，其中，所述控制所述第一管理装置根据所述目标云平台和所述应用能力确定所述目标云平台支持的目标应用能力之后，还包括：
    控制所述第一管理装置向所述目标云平台发送与所述目标应用能力对应的目标能力定义数据包。
  12. 根据权利要求8至11任意一项所述的云平台管理方法，其中，所述控制所述第二管理装置根据来自所述第一管理装置的所述应用能力确定与所述应用能力对应的能力边界，包括：
    控制所述第二管理装置校验来自所述第一管理装置的所述应用能力的运行情况，并且控制所述第二管理装置根据所述应用能力的所述运行情况调节所述应用能力，并且控制所述第二管理装置根据调节后的所述应用能力确定与调节后的所述应用能力对应的所述能力边界。
  13. 根据权利要求8所述的云平台管理方法，其中，所述云平台管理架构还包括被设置为存储与至少一个所述应用能力对应的至少一个能力模板的能力数据库，所述能力数据库通过所述第一管理装置连接于所述应 用编排和实例化装置；
    所述云平台管理方法，还包括：
    根据所述开放应用模型生成可编写的应用能力编排元素，所述应用能力编排元素与所述能力模板对应。
  14. 一种云平台管理设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求8至13中任意一项所述的云平台管理方法。
  15. 一种计算机可读存储介质，存储有计算机可执行指令，其中，所述计算机可执行指令用于执行权利要求8至13中任意一项所述的云平台管理方法。
PCT/CN2022/091530 2021-08-10 2022-05-07 云平台管理架构及管理方法、管理设备、存储介质 Ceased WO2023015988A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP22854983.8A EP4369183A4 (en) 2021-08-10 2022-05-07 CLOUD PLATFORM MANAGEMENT ARCHITECTURE, METHOD AND DEVICE, AND RECORDING MEDIUM
JP2024505368A JP7667371B2 (ja) 2021-08-10 2022-05-07 クラウドプラットフォーム管理アーキテクチャ、管理方法、管理機器、及び記憶媒体
US18/293,627 US12603814B2 (en) 2021-08-10 2022-05-07 Architecture, method and device for managing cloud platform, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110915014.6A CN115705210A (zh) 2021-08-10 2021-08-10 云平台管理架构及管理方法、管理设备、存储介质
CN202110915014.6 2021-08-10

Publications (1)

Publication Number Publication Date
WO2023015988A1 true WO2023015988A1 (zh) 2023-02-16

Family

ID=85179551

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/091530 Ceased WO2023015988A1 (zh) 2021-08-10 2022-05-07 云平台管理架构及管理方法、管理设备、存储介质

Country Status (5)

Country Link
US (1) US12603814B2 (zh)
EP (1) EP4369183A4 (zh)
JP (1) JP7667371B2 (zh)
CN (1) CN115705210A (zh)
WO (1) WO2023015988A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117234882B (zh) * 2023-09-28 2024-04-16 哈尔滨工业大学（威海） 一种在线应用云资源供应软件定义模型构建方法及终端机
CN117234545B (zh) * 2023-11-16 2024-03-08 深圳万物安全科技有限公司 应用程序安装方法、装置、终端设备以及存储介质
CN117938405B (zh) * 2024-03-21 2024-05-31 北京火山引擎科技有限公司 多云环境下的cdn服务编排方法、装置、设备及存储介质
CN119743530B (zh) * 2024-12-16 2025-12-16 苏州元脑智能科技有限公司 服务访问方法、装置、通信设备及存储介质
CN119729415B (zh) * 2024-12-30 2025-12-12 中国电信股份有限公司技术创新中心 业务编排方法、系统、装置、计算机设备和可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347663A (zh) * 2018-09-28 2019-02-15 南京易捷思达软件科技有限公司 一种OpenStack云平台中资源可视化编排方法
US20190281112A1 (en) * 2018-03-08 2019-09-12 Nutanix, Inc. System and method for orchestrating cloud platform operations
CN110704164A (zh) * 2019-09-30 2020-01-17 珠海市新德汇信息技术有限公司 一种基于Kubernetes技术的云原生应用平台构建方法
US20200218580A1 (en) * 2017-05-02 2020-07-09 Namu Tech Co., Ltd. Cloud platform system
CN112799789A (zh) * 2021-03-22 2021-05-14 腾讯科技（深圳）有限公司 一种节点集群管理方法、装置、设备及存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8667138B2 (en) * 2010-10-29 2014-03-04 Cisco Technology, Inc. Distributed hierarchical rendering and provisioning of cloud services
US10521286B2 (en) * 2017-03-23 2019-12-31 Rathinasabapathy Arumugam System and method for interoperable cloud DSL to orchestrate multiple cloud platforms and services
US11146620B2 (en) 2017-09-14 2021-10-12 Cisco Technology, Inc. Systems and methods for instantiating services on top of services
JP2022095016A (ja) 2020-12-16 2022-06-28 株式会社日立製作所 演算装置、共通リソース生成方法
US11675627B1 (en) * 2021-12-29 2023-06-13 Bereej Technologies Private Limited Method and system for integrating multiple cloud platforms with diagraming tools
US12386675B2 (en) * 2022-07-29 2025-08-12 Salesforce, Inc. Orchestration of operations on a cloud platform based on multiple version maps of services
US12481513B2 (en) * 2023-01-31 2025-11-25 Salesforce, Inc. Orchestration of datacenter destruction on a cloud platform
US12498914B2 (en) * 2023-01-31 2025-12-16 Salesforce, Inc. Orchestration of software releases on a cloud platform
US20240345830A1 (en) * 2023-04-14 2024-10-17 Salesforce, Inc. Orchestration of software releases on a cloud platform across stagger groups

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200218580A1 (en) * 2017-05-02 2020-07-09 Namu Tech Co., Ltd. Cloud platform system
US20190281112A1 (en) * 2018-03-08 2019-09-12 Nutanix, Inc. System and method for orchestrating cloud platform operations
CN109347663A (zh) * 2018-09-28 2019-02-15 南京易捷思达软件科技有限公司 一种OpenStack云平台中资源可视化编排方法
CN110704164A (zh) * 2019-09-30 2020-01-17 珠海市新德汇信息技术有限公司 一种基于Kubernetes技术的云原生应用平台构建方法
CN112799789A (zh) * 2021-03-22 2021-05-14 腾讯科技（深圳）有限公司 一种节点集群管理方法、装置、设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4369183A4 *

Also Published As

Publication number Publication date
US12603814B2 (en) 2026-04-14
EP4369183A1 (en) 2024-05-15
US20240348501A1 (en) 2024-10-17
JP7667371B2 (ja) 2025-04-22
JP2024527103A (ja) 2024-07-19
EP4369183A4 (en) 2024-05-15
CN115705210A (zh) 2023-02-17

Similar Documents

Publication Publication Date Title
WO2023015988A1 (zh) 云平台管理架构及管理方法、管理设备、存储介质
US20230342128A1 (en) Application blueprints based on service templates to deploy applications in different cloud environments
US9858068B2 (en) Methods and systems for planning application deployment
US11455184B2 (en) End-to-end validation of virtual machines
US10003514B2 (en) Method and system for determining a deployment of applications
CN111984269B (zh) 提供应用构建服务的方法及应用构建平台
US20160342443A1 (en) Optimizing virtual machine memory sizing for cloud-scale application deployments
CN105988878A (zh) 用于动态地管理虚拟化环境中的工作负荷放置的方法及系统
CN113885892B (zh) 一种基于多云平台的低代码配置接入方法
US12475015B2 (en) Managing resource constraints in a cloud environment
US20250245625A1 (en) Network architecture provisioning using build sheets
CN114500268B (zh) chart资源的部署方法、装置、服务器及存储介质
CN113204368A (zh) 应用程序处理方法、服务器及存储介质
US20210232438A1 (en) Serverless lifecycle management dispatcher
CN118057776A (zh) 部署虚拟化网络功能的方法和通信装置
Semenov et al. Dslab faas: Fast and accurate simulation of faas clouds
EP4589906A1 (en) Method and apparatus for deploying virtualized network function
US20240176631A1 (en) Wizard based gateway onboarding to cloud
CN116668294A (zh) 应用编排方法、云平台及第一边缘集群
CN120578432A (zh) 参数编排方法、设备和计算机可读介质
Padilla Pinedo Network Function Virtualization technologies applied to cellular systems
CN116932028A (zh) 一种组件处理方法、装置及设备、存储介质、产品
CN118567778A (zh) 虚拟机迁移方法、服务器、系统及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22854983

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2024505368

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18293627

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022854983

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022854983

Country of ref document: EP

Effective date: 20240208

NENP Non-entry into the national phase

Ref country code: DE

WWG Wipo information: grant in national office

Ref document number: 18293627

Country of ref document: US