Cloud resource management method and device, electronic equipment and readable storage medium

Abstract

The present disclosure provides a cloud resource management method and device, electronic equipment and readable storage medium. The method comprises: obtaining a resource change request from a micro message queue; wherein the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used for uniquely identifying the resource change request; the resource change request is sent by a first server to the micro message queue; the first message topic is pre-subscribed by a second server; according to the resource parameter, processing is performed on the resource corresponding to the resource name in the resource change request to obtain a processing execution result; a resource change response is generated according to the processing execution result; the resource change response is published to a second message topic in the micro message queue; the resource change response at least includes the request identifier and the processing execution result; the second message topic is subscribed by the first server.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of communication, and more particularly, to a cloud resource management method and device, an electronic device, and a readable storage medium. BACKGROUND

[0002] Edge cloud computing is a cloud computing platform based on the capabilities of cloud computing and edge computing, built on edge infrastructure, and can form an end-to-end technical architecture of "cloud-edge-terminal coordination" with the center cloud device and the Internet of Things terminal.

[0003] In the existing cloud-edge integrated architecture, the lightweight of the edge component is usually realized by setting the control plane of kubernetes on the center cloud side and reconstructing the kubelet component of kubernetes on the edge side, so as to realize the management of the computing nodes of the edge cloud side by the kubernetes cluster of the center cloud side. However, in the original kubernetes cluster, the communication mechanism between the computing node kubelet component and the control plane uses the list-watch mechanism of kubernetes, and after reconstruction, the communication mechanism between the kubelet component and the control plane is modified to the websocket mechanism. This mechanism makes the transmission of data less reliable in the case of weak network on the edge cloud side.

[0004] Therefore, it is necessary to provide a new cloud resource management method. SUMMARY

[0005] The embodiments of the present disclosure provide a cloud resource management method, which can ensure reliable transmission of data in the case of weak network of a first server.

[0006] According to a first aspect of the embodiments of the present disclosure, a cloud resource management method is provided, applied to a second server, comprising:

[0007] obtaining a resource change request from a first message topic of a micro message queue; wherein the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by the second server;

[0008] performing processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, to obtain a processing execution result;

[0009] generating a resource change response according to the processing execution result;

[0010] publishing the resource change response into the micro message queue; the resource change response at least includes the request identifier and the processing execution result; the second message topic is pre-subscribed by the first server.

[0011] Optionally, the method further comprises:

[0012] obtaining container group scheduling information; the container group in the container group scheduling information carries a preset label;

[0013] publishing the container group scheduling information into the micro message queue.

[0014] Optionally, the resource name at least includes any one of the following: node, event, container group and lease.

[0015] According to a second aspect of the embodiments of the present disclosure, a cloud resource management method applied to a first server is further provided, comprising:

[0016] sending a resource change request to a first message topic of a micro message queue; wherein the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used for uniquely identifying the resource change request; the first message topic is pre-subscribed by a second server;

[0017] obtaining a resource change response from a second message topic of the micro message queue according to the request identifier; the resource change response at least includes the request identifier and a processing execution result;

[0018] wherein the second message topic is pre-subscribed by the first server; the resource change response is sent by the second server to the second message topic of the micro message queue after obtaining the resource change request from the micro message queue and performing processing on the resource corresponding to the resource name in the resource change request according to the resource parameter.

[0019] Optionally, the method further comprises:

[0020] obtaining container group scheduling information from a third message topic of the micro message queue and caching; the container group scheduling information is published by the second server after obtaining;

[0021] generating container group update data according to the container group scheduling information.

[0022] Optionally, the resource name at least includes any one of the following: node, event, container group and lease.

[0023] According to a third aspect of the embodiments of the present disclosure, a cloud resource management device is further provided, comprising:

[0024] The acquisition module is configured to acquire a resource change request from a first message topic of a micro message queue; wherein the resource change request comprises at least a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by a second server.

[0025] The processing module is configured to perform processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, and obtain a processing execution result.

[0026] The generation module is configured to generate a resource change response according to the processing execution result.

[0027] The publishing module is configured to publish the resource change response to a second message topic of the micro message queue; wherein the resource change response comprises at least the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server.

[0028] According to a fourth aspect of the embodiments of the present disclosure, a cloud resource management apparatus is further provided, comprising:

[0029] The sending module is configured to send a resource change request to a first message topic of a micro message queue; wherein the resource change request comprises at least a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; and the first message topic is pre-subscribed by a second server.

[0030] The acquisition module is configured to acquire a resource change request from a first message topic of a micro message queue; wherein the resource change request comprises at least a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by a second server.

[0031] According to a fifth aspect of the embodiments of the present disclosure, an electronic device is further provided, comprising:

[0032] A processor and a memory, wherein the memory is configured to store instructions, and the instructions are used to control the processor to execute the method according to any one of the first aspect of the present disclosure; or the instructions are used to control the processor to execute the method according to any one of the second aspect of the present disclosure.

[0033] According to a sixth aspect of the embodiments of the present disclosure, a readable storage medium is provided, and the readable storage medium stores executable instructions. When the executable instructions are executed by a processor, the method in any one of the first aspect of the present disclosure is executed. Alternatively, when the executable instructions are executed by the processor, the method in any one of the second aspect of the present disclosure is executed.

[0034] In one embodiment, a resource change request is obtained from a first message topic of a micro message queue; wherein the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent by a first server to the micro message queue; the first message topic is pre-subscribed by a second server; according to the resource parameter, a resource corresponding to the resource name in the resource change request is processed to obtain a processing execution result; a resource change response is generated according to the processing execution result; the resource change response is published to a second message topic of the micro message queue; the resource change response at least includes the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server. In this way, the mechanism of publishing and subscribing different message topics in the micro message queue is used to realize the acquisition of resource change information, support million connections, replace the traditional k8s list-watch mechanism, guarantee the reliable transmission of data in the case that the first server is in a weak network, and solve the problem of large-scale access of massive devices.

[0035] Other features and advantages of the present application will become apparent from the following detailed description of illustrative embodiments thereof, which description should be taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings incorporated in and forming a part of the specification, illustrate embodiments of the present application and, together with the description, serve to explain the principles of the application.

[0037] Figure 1 is a cloud edge integration architecture schematic diagram of the embodiments of the present disclosure;

[0038] Figure 2 is a flow schematic diagram of a cloud resource management method according to the first embodiment of the present disclosure;

[0039] Figure 3 is a flow schematic diagram of node creation according to the first embodiment of the present disclosure;

[0040] Figure 4 is a flow schematic diagram of pod scheduling information publishing according to the first embodiment of the present disclosure;

[0041] Figure 5is a flowchart of a cloud resource management method according to Embodiment Two of the present disclosure;

[0042] Figure 6 is a schematic diagram of a system applying the cloud resource management method of the present disclosure;

[0043] Figure 7 is a principle block diagram of a cloud resource management device usable in the present disclosure;

[0044] Figure 8 is a principle block diagram of a cloud resource management device usable in the present disclosure;

[0045] Figure 9 is a principle block diagram of an electronic device usable in the present disclosure;

[0046] Figure 10 is a principle block diagram of an electronic device usable in the present disclosure;

[0047] Figure 11 is a principle block diagram of an electronic device usable in the present disclosure. DETAILED DESCRIPTION

[0048] Various exemplary embodiments of the present application will now be described in detail with reference to the accompanying drawings. It should be noted that the relative arrangement of the components and steps, numerical expressions, and numerical values set forth in these embodiments are not limiting to the scope of the present application unless specifically stated otherwise.

[0049] The following description of at least one exemplary embodiment is merely exemplary in nature and is in no way intended to limit the scope of the application, its application, or uses.

[0050] Techniques, methods, and devices known to those of ordinary skill in the relevant art can not be discussed in detail herein, but should be considered as part of the specification, where appropriate.

[0051] In all of the examples shown and discussed herein, any specific values should be interpreted as merely exemplary, and not as a limitation. Thus, other examples of exemplary embodiments can have different values.

[0052] It should be noted that like references and characters herein relate to like items throughout the figures, and once an item is defined in one figure, it need not be discussed further in subsequent figures.

[0053] In the present disclosure, the first server refers to a cloud computing server based on cloud computing and edge computing capabilities, built on edge infrastructure, the second server refers to a central cloud server, and the first server, the second server and the Internet of Things terminal form an end-to-end technical architecture of "cloud-edge-end three-body cooperation". As shown inFigure 1 As shown, in the present disclosure, a cloud product MQTT (Message Queuing Telemetry Transport) module and a lightweight controller are added in the second server; in the first server, a lightweight k8s computing node is added, and the lightweight k8s computing node is provided with a lightweight kubelet and a container (containerd). As can be seen, the architecture of the embodiment of the present disclosure does not have intrusive modification and configuration to the original k8s cluster, belongs to bypass adaptation, and can be completely seamlessly integrated into the original k8s system.

[0054] Figure 2 is a flowchart of a cloud resource management method according to the first embodiment of the present disclosure. The method can be implemented by a second server as shown in Figure 1

[0055] As shown in Figure 2 The cloud resource management method of the present embodiment can include the following steps 2100-2400.

[0056] Step 2100, obtaining a resource change request from a first message topic of a micro message queue; wherein the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by a second server.

[0057] The resource name at least includes any one of a node, an event, a pod and a lease. The resource change request may, for example, be a node creation request, a node update request, an event creation request, an event update request, a pod creation request, a pod update request, a pod deletion request, a lease update request, and a lease creation request, which are not listed one by one.

[0058] Step 2200, performing processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, to obtain a processing execution result.

[0059] Step 2300, generating a resource change response according to the processing execution result.

[0060] Step 2400, publishing the resource change response to a second message topic of the micro message queue; the resource change response at least includes the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server.

[0061] ​In this embodiment, the cloud resource management method is illustrated by taking the creation of a node as an example. Specifically, as shown in Figure 3 The cloud controller in the second server (cloud) obtains a node creation request (lite / edge / nodes / (nodename1) / create) by subscription, and the node creation request includes parameter information required for the creation of the node and a request identifier.

[0062] The cloud controller calls the interface of the real API server by calling the interface of the client-go, and publishes the returned execution result and the corresponding request identifier to the message topic (topic) in the MQTT: lite / ack / {nodename} after executing the client-go command, so that the kubelet that subscribes to the ack topic of the node can find the resource change response corresponding to the request identifier of itself to determine whether the execution is successful or whether it is timed out.

[0063] Similarly, the operations of the event, pod and lease resources are similar to the above process, and will not be described here.

[0064] Optionally, in an embodiment, the method of the present embodiment can further include: obtaining container group (pod) scheduling information; the container group in the container group scheduling information carries a preset label; publishing the container group scheduling information to a third message topic in the micro message queue; and the third message topic is pre-subscribed by the first server.

[0065] As shown in Figure 4 The second server (cloud) needs to publish the pod scheduling information to the micro message queue through the cloud controller in the case of pod change, so that the information of the changed pod can be sent to the first server, and it can also be controlled which pods are run and downgraded to the edge cloud computing node. Optionally, the pods that can be downgraded to the edge cloud computing node need to carry a preset label, which can be openyurt.io / type=lite-node, for example.

[0066] The cloud resource management method of the embodiment of the present disclosure is described above in combination with the drawings. In the embodiment, a resource change request is acquired from a first message topic of a micro message queue. The resource change request at least includes a resource name, a resource parameter, and a request identifier. The request identifier is used to uniquely identify the resource change request. The resource change request is sent by a first server to the micro message queue. The first message topic is pre-subscribed by a second server. According to the resource parameter, a resource corresponding to the resource name in the resource change request is processed to obtain a processing execution result. A resource change response is generated according to the processing execution result. The resource change response is published to a second message topic of the micro message queue. The resource change response at least includes the request identifier and the processing execution result. The second message topic is pre-subscribed by the first server. In this way, the mechanism of publishing and subscribing different message topics in the micro message queue is used to acquire resource change information, which can support millions of connections, replace the traditional k8s list-watch mechanism, ensure reliable data transmission of the first server in a weak network, and solve the problem of large-scale access of massive devices.

[0067] Figure 5 is a flowchart of a cloud resource management method according to the second embodiment of the present disclosure. The method can be implemented by a second server as shown in Figure 1 .

[0068] As shown in Figure 5 , the cloud resource management method of the present embodiment can include the following steps 5100-5200.

[0069] Step 5100, a resource change request is sent to a first message topic of a micro message queue. The resource change request at least includes a resource name, a resource parameter, and a request identifier. The request identifier is used to uniquely identify the resource change request.

[0070] The resource name at least includes any one of a node, an event, a container group, and a lease. The resource change request may, for example, be a node creation request, a node update request, an event creation request, an event update request, a container group creation request, a container group update request, a container group deletion request, a lease update request, and a lease creation request, which are not listed one by one.

[0071] Step 5200, a resource change response is acquired from a second message topic of the micro message queue according to the request identifier. The resource change response at least includes the request identifier and a processing execution result.

[0072] The second message topic is pre-subscribed by the first server; and the resource change response is published to the second message topic in the micro message queue by the second server after the second server obtains the resource change request from the micro message queue and performs processing on a resource corresponding to a resource name in the resource change request according to the resource parameter.

[0073] It should be noted that in the code logic of the kubelet in the present embodiment, a new structure body openyurt.ClientSet{} is created to implement the clientset.Interface interface, and the communication between the kubelet and the apiserver mainly involves node, event, pod and lease resources and operations. Therefore, only the operations of the event, lease, node and pod need to be implemented by using the newly created structure body, and other methods are implemented by using the fake.Clientset in the client-go. After the clientset.Interface part is re-implemented by using the MQTT client, we do not need to modify the parameters of the kubelet key code, and the kubelet key logic is not modified in an invasive manner. The three clients in the kubelet, namely HeartbeatClient, KubeClient and EventClient, are initialized by using the NewSimpleClientset() method: the core logic is to assemble the MQTT information, and the parameters required for creating a node are sent to the MQTT broker (MQTT publisher) on the cloud through the MQTT, and finally the cloud controller on the cloud consumes the parameters to actually call the interface of the client-go to create a node.

[0074] As shown in Figure 6 For example, the kubelet publishes the parameter information required for creating a node to the micro message queue.

[0075] Optionally, in an embodiment, the method further includes: obtaining container group scheduling information from a third message topic of the micro message queue and caching; the container group scheduling information is published by the second server after obtaining; and generating container group update data according to the container group scheduling information.

[0076] Generally, there are three ways to obtain the container group (pod) scheduling information, as shown in Figure 7As shown, the first is to obtain the static pod declaration file on the local file system; the second is to obtain the pod declaration file on the network (web); and the third is to obtain the pod declaration file through the apiserver. The first two are the static container group (static pod) method commonly used to create containers, the first of which is commonly used to install some system components required before creating a k8s cluster, and is managed by kubelet and is not controlled by k8s. The third is the mainstream way for kubelet to obtain pod declaration files. These pods are controlled by k8s scheduling and controllers. The pod files obtained through the above three ways are all collected into the corresponding channel of the PodConfig module. After the merge operation of the PodConfig module, it is determined whether the changed pod is created, updated or deleted, and finally enters the syncLoop logic module in kubelet to perform the creation, update and deletion operations of the pod.

[0077] In this embodiment, considering that the mechanism of MQTT itself can guarantee the reliability of data transmission in a weak network environment, on the basis of the existing kubelet pod scheduling information acquisition method, the NewSourceMQTTFile pod acquisition method is added, as shown in Figure 8 As shown, the changed pod is obtained through the MQTT protocol and cached to the local file. The subsequent pod processing method is similar to the NewSourceFile principle. The change of the local file is monitored (watched) and the corresponding channel is notified to enter the merge operation, and finally the channel data of PodUpdate is generated. The subsequent processing logic remains unchanged. The advantage is that if the cloud-edge network is normal, the pod change information can be continuously obtained through the MQTT protocol and cached to the local file. The NewSourceMQTTFile logic can send the pod change information to the channel of PodUpdate through the watch of the local file change, and enter the next merge operation. Once the network is disconnected, kubelet can process the MQTT cached local file in the same way as the static pod of the local file system. In this way, the host can be restarted, the edge cloud network can be disconnected, but the pod can still be started normally. If the network is restored, the edge cloud network normal processing logic is entered.

[0078] The cloud resource management method of the embodiment of the present disclosure is described above in combination with the drawings. In the embodiment, a resource change request is sent to a first message topic of a micro message queue; the resource change request at least includes a resource name, a resource parameter, and a request identifier; the request identifier is used to uniquely identify the resource change request; the first message topic is pre-subscribed by a second server; a resource change response is obtained from the micro message queue according to the request identifier; the resource change response at least includes the request identifier and a processing execution result. In this way, the mechanism of publishing and subscribing different message topics in the micro message queue is used to obtain the resource change information, which can support a million connections, replace the traditional k8s list-watch mechanism, guarantee the reliable transmission of data of the first server in a weak network, and solve the problem of large-scale access of a large number of devices.

[0079] <Device Embodiment>

[0080] In the embodiment, a cloud resource management device is also provided. As shown in Figure 9 The cloud resource management device 4000 can include an obtaining module 4100, a processing module 4200, a generating module 4300, and a publishing module 4400.

[0081] The obtaining module 4100 is configured to obtain a resource change request from a first message topic of a micro message queue; the resource change request at least includes a resource name, a resource parameter, and a request identifier; the request identifier is used to uniquely identify the resource change request; the resource change request is sent to the micro message queue by a first server; and the first message topic is pre-subscribed by a second server.

[0082] The processing module 4200 is configured to perform processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, to obtain a processing execution result.

[0083] The generating module 4300 is configured to generate a resource change response according to the processing execution result.

[0084] The publishing module 4400 is configured to publish the resource change response to a second message topic of the micro message queue; the resource change response at least includes the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server.

[0085] The resource name at least includes any one of a node, an event, a container group, and a lease.

[0086] In an embodiment, the obtaining module 4100 is further configured to obtain container group scheduling information; the container group in the container group scheduling information carries a preset label; the publishing module 4400 is further configured to publish the container group scheduling information into a third message topic of the micro message queue; and the third message topic is pre-subscribed by the first server.

[0087] The cloud resource management apparatus of this embodiment can be used to execute the technical solution of the above method embodiment one, and has similar implementation principles and technical effects, which will not be described here again.

[0088] In this embodiment, a cloud resource management apparatus is also provided, as shown in Figure 10 The cloud resource management apparatus 5000 can include a sending module 5100 and an obtaining module 5200.

[0089] The sending module 5100 is configured to send a resource change request to a first message topic of a micro message queue; the resource change request includes at least a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; and the first message topic is pre-subscribed by a second server.

[0090] The obtaining module 5200 is configured to obtain a resource change response from a second message topic of the micro message queue according to the request identifier; the resource change response includes at least the request identifier and a processing execution result; the second message topic is pre-subscribed by the first server; and the resource change response is sent to the second message topic of the micro message queue by the second server after the second server obtains the resource change request from the micro message queue and performs processing on a resource corresponding to the resource name in the resource change request according to the resource parameter.

[0091] The resource name includes at least any one of a node, an event, a container group and a lease.

[0092] In an embodiment, the obtaining module 5200 is further configured to obtain container group scheduling information from a third message topic of the micro message queue and cache the container group scheduling information; the container group scheduling information is published by the second server after being obtained; and the apparatus further includes an updating module configured to generate container group updating data according to the container group scheduling information.

[0093] The cloud resource management apparatus of this embodiment can be used to execute the technical solution of the above method embodiment one, and has similar implementation principles and technical effects, which will not be described here again.

[0094] <Device Embodiment>

[0095] In this embodiment, an electronic device is also provided, which is Figure 11The electronic device 6000 shown includes:

[0096] The memory 6100 is configured to store executable commands.

[0097] The processor 6200 is configured to execute the method described in any method embodiment of the present disclosure under the control of the executable commands stored in the memory 6100.

[0098] The electronic device according to the implementation subject of the executed method embodiment can be a server or an electronic device.

[0099] <Readable storage medium embodiment>

[0100] The present embodiment provides a readable storage medium, the storage medium stores executable commands, the executable commands are executed by the processor, and the method described in any method embodiment of the present disclosure is executed.

[0101] The present application can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0102] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0103] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0104] Computer readable program instructions for carrying out operations of the present application can be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0105] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0106] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include a non-transitory computer readable storage medium that can be a computer- readable storage medium having no data, programs, program modules, e.g., instructions for operation, or digital content stored thereon or therein for a short time or not at all. The computer readable storage medium can also have instructions stored thereon or therein which may

[0107] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0108] The flow diagrams and block diagrams in the attached Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams and block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions (i.e., acts). In some alternative implementations, the functions noted in the block can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and

[0109] Having described various embodiments of the application, it is to be understood that the above description is meant to be illustrative only and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art, without departing from the scope and spirit of the described embodiments. The selection of terms to be used in the description is intended to best explain the principles of the embodiments, the practical application, or technical improvement over the prior art, or to enable others skilled in the art to understand the embodiments disclosed herein. The scope of the application is defined by the claims appended hereto.

Claims

1. A cloud resource management method, applied to a second server, characterized in that, The method comprises the following steps: obtaining a resource change request from a first message topic of a micro message queue; wherein the resource change request at least comprises a resource name, a resource parameter and a request identifier; the request identifier is used for uniquely identifying the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by a second server; performing processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, to obtain a processing execution result; generating a resource change response according to the processing execution result; publishing the resource change response to a second message topic of the micro message queue; the resource change response at least comprises the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server.

2. The method of claim 1, wherein, The method further comprises the following steps: obtaining container group scheduling information; the container group in the container group scheduling information carries a preset label; publishing the container group scheduling information to a third message topic of the micro message queue; and the third message topic is pre-subscribed by the first server.

3. The method of claim 1, wherein, The resource name at least comprises any one of a node, an event, a container group and a lease. 4.A cloud resource management method, applied to a first server, and having the characteristics of, The method comprises the following steps: sending a resource change request to a first message topic of a micro message queue; wherein the resource change request at least comprises a resource name, a resource parameter and a request identifier; the request identifier is used for uniquely identifying the resource change request; and the first message topic is pre-subscribed by a second server; obtaining a resource change response from a second message topic of the micro message queue according to the request identifier; the resource change response at least comprises the request identifier and a processing execution result; wherein the second message topic is pre-subscribed by the first server; and the resource change response is published to the second message topic of the micro message queue by the second server after the resource change request is obtained from the first message topic of the micro message queue and processing is performed on a resource corresponding to the resource name in the resource change request according to the resource parameter.

5. The method of claim 4, wherein, The method further comprises the following steps: obtaining container group scheduling information from a third message topic of the micro message queue and caching; the container group scheduling information is published after being obtained by the second server; generating container group update data according to the container group scheduling information.

6. The method of claim 4, wherein, The resource name at least comprises any one of a node, an event, a container group and a lease.

7. A cloud resource management apparatus, characterized by comprising: The method comprises the following steps: an obtaining module, configured to obtain a resource change request from a first message topic of a micro message queue; wherein the resource change request at least comprises a resource name, a resource parameter and a request identifier; the request identifier is used for uniquely identifying the resource change request; the resource change request is sent by a first server to the micro message queue; and the first message topic is pre-subscribed by a second server; a processing module, configured to perform processing on a resource corresponding to the resource name in the resource change request according to the resource parameter, to obtain a processing execution result; a generating module, configured to generate a resource change response according to the processing execution result; A publishing module is configured to publish the resource change response to a second message topic of the micro message queue; the resource change response at least includes the request identifier and the processing execution result; and the second message topic is pre-subscribed by the first server.

8. A cloud resource management apparatus, characterized by comprising: The method comprises the following steps: A sending module is configured to send a resource change request to a first message topic of the micro message queue; the resource change request at least includes a resource name, a resource parameter and a request identifier; the request identifier is used to uniquely identify the resource change request; and the first message topic is pre-subscribed by a second server. A obtaining module is configured to obtain a resource change response from a second message topic of the micro message queue according to the request identifier; the resource change response at least includes the request identifier and a processing execution result. The second message topic is pre-subscribed by the first server; and the resource change response is sent to the second message topic of the micro message queue by the second server after the second server obtains the resource change request from the micro message queue and performs processing on a resource corresponding to the resource name in the resource change request according to the resource parameter.

9. An electronic device, comprising: The method comprises the following steps: A processor and a memory are provided; the memory is configured to store instructions; the instructions are used to control the processor to execute the method according to any one of claims 1-3; or the instructions are used to control the processor to execute the method according to any one of claims 4-6. 10.A readable storage medium, the storage medium stores executable instructions; when the executable instructions are executed by a processor, the method according to any one of claims 1-3 is executed; or when the executable instructions are executed by a processor, the method according to any one of claims 4-6 is executed.

Images