Scheduling method and device of device management service, electronic device and storage medium

Abstract

The present disclosure provides a device management service scheduling method and device, electronic equipment and storage medium, relates to the technical field of computers, and specifically relates to the technical fields of Internet of Things technology, cloud technology and container technology. The specific implementation scheme is as follows: obtaining scheduling data of a device management service; generating resource container group information corresponding to the scheduling data according to the scheduling data; deploying a resource container group according to the resource container group information; and running the device management service by using the deployed resource container group.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of Internet of Things technology, cloud technology, and container technology, and in particular to a scheduling method, apparatus, electronic device, and storage medium for device management services. Background Technology

[0002] The device management service, also known as the device management instance, is a sub-application of the device management platform. The device management platform can manage devices by scheduling the device management service.

[0003] Currently, the commonly used method for scheduling equipment management services is to use multiple modules such as instruction module, synchronization module and scheduling module to schedule and manage equipment management services. Summary of the Invention

[0004] This disclosure provides a scheduling method, apparatus, electronic device, and storage medium for device management services.

[0005] According to one aspect of this disclosure, a scheduling method for device management services is provided, comprising:

[0006] Obtain scheduling data from the device management service;

[0007] Based on the scheduling data, generate resource container group information corresponding to the scheduling data;

[0008] Deploy the resource container group based on the resource container group information;

[0009] The device management service is run using the deployed resource container group.

[0010] According to another aspect of this disclosure, a scheduling apparatus for device management services is provided, comprising:

[0011] The acquisition unit is used to acquire scheduling data from the device management service.

[0012] The generation unit is used to generate resource container group information corresponding to the scheduling data based on the scheduling data.

[0013] The deployment unit is used to deploy the resource container group according to the resource container group information;

[0014] The running unit is used to run the device management service using the deployed resource container group.

[0015] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0019] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described above and any possible implementation thereof.

[0020] According to another aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aspects and any possible implementations described above.

[0021] As can be seen from the above technical solution, this embodiment of the present disclosure obtains the scheduling data of the device management service, and then generates resource container group information corresponding to the scheduling data based on the scheduling data. Based on the resource container group information, the resource container group is deployed, so that the device management service can be run using the deployed resource container group. Since the resource container group deployed based on the resource container group information corresponding to the scheduling data is used to run the device management service during resource scheduling, the scheduling management process of the device management service is simplified, and the scheduling management of the device management service is made simpler and more efficient, thereby ensuring the reliability of the device management service scheduling.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0023] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0024] Figure 1 This is a schematic diagram based on the first embodiment of the present disclosure;

[0025] Figure 2 This is a schematic diagram according to the second embodiment of the present disclosure;

[0026] Figure 3 This is a schematic diagram of the scheduling service architecture of the scheduling method according to the second embodiment of this disclosure;

[0027] Figure 4 This is a schematic diagram according to the third embodiment of the present disclosure;

[0028] Figure 5 This is a block diagram of an electronic device used to implement the scheduling method for device management services according to embodiments of the present disclosure. Detailed Implementation

[0029] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0030] Obviously, the described embodiments are only some, not all, of the embodiments disclosed herein. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0031] It should be noted that the terminal devices involved in the embodiments of this disclosure may include, but are not limited to, smart devices such as mobile phones, personal digital assistants (PDAs), wireless handheld devices, and tablet computers; the display devices may include, but are not limited to, personal computers, televisions, and other devices with display functions.

[0032] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0033] Equipment management focuses on the scientific management of equipment throughout its entire lifecycle, aiming to improve overall equipment efficiency. It utilizes IoT technologies to manage equipment across its entire lifecycle. Management includes, but is not limited to, the network scale / environment in which the equipment operates, its physical accessibility, available resources, and physical status. Therefore, equipment management platforms have emerged. Equipment management services, or equipment management instances, are sub-applications of the equipment management platform. The platform manages equipment by scheduling these services. When scheduling these services, the platform often needs to manage their lifecycles and status.

[0034] Currently, the more mainstream scheduling methods for device management services include shared scheduling and command-based scheduling.

[0035] The shared scheduling method involves launching the application and device management platform on a single server. Device management services are started and managed within this application via an Application Programming Interface (API). Each device management service periodically reports its life status information, such as heartbeats. Because it's a shared application, the device management platform can quickly ascertain the current status of device management services and the allocation of resources, enabling scheduling of these services. When scaling is needed, the application is launched on another server, and the above operations are repeated. For request distribution, a separate API module handles the actual request distribution, forwarding requests to the specific device management service based on the mapping relationship between device management services and addresses recorded by the device management platform. This method uses the application to directly manage device management services, employing a shared application approach. The device management platform is launched directly within the application, and the life status of device management services is confirmed through periodic heartbeat reporting and anomaly handling. This simplifies the management of device management services and provides a fast scheduling response.

[0036] However, because the device management platform needs to dynamically manage the runtime resources of the device management service, but shared applications have difficulty dynamically allocating and limiting these resources, it becomes difficult to guarantee the performance of the device management platform as the number of devices increases. Therefore, this method is more suitable for scenarios with a smaller number of devices. Furthermore, directly allocating excessively large static server resources to the device management service would significantly increase the overall cost.

[0037] The command-based scheduling method selects server resources for device management services using multiple modules, including a general instruction module, a synchronization module, and a scheduling module. It utilizes a scheduling API to schedule the device management services and control their lifecycle. For resource allocation, the scheduling module manages available server resources for dynamic allocation. The device management services inform the scheduling module of their actions via callbacks, enabling lifecycle and state management. Since the scheduling module manages all aspects of the device management services, the device management platform only needs to focus on calculating resource requirements and configuring the pre-set environment for service startup. Once preparation is complete, the scheduling module handles the starting, stopping, and scaling of the device management services. The device management platform also uses a separate API module for forwarding actual requests. This method reduces the performance requirements of the device management platform, decouples some functions, and lowers the actual load.

[0038] However, since this method uses multiple modules such as instruction module, synchronization module and scheduling module to schedule device management services, each device management service needs to report heartbeat and synchronize life information regularly. It is difficult to maintain the consistency of information between modules. Moreover, this will make the upgrade operation more risky, and there may be situations where the upgrade fails and the device management service becomes unavailable.

[0039] Therefore, there is an urgent need to provide a scheduling method for equipment management services that can achieve secure and efficient scheduling of equipment management services to ensure the reliability of equipment management service scheduling.

[0040] Figure 1 This is a schematic diagram based on the first embodiment of the present disclosure, as shown below. Figure 1 As shown.

[0041] 101. Obtain scheduling data from the device management service.

[0042] 102. Based on the scheduling data, generate resource container group information corresponding to the scheduling data.

[0043] 103. Deploy the resource container group based on the resource container group information.

[0044] 104. Utilize the deployed resource container group to run the device management service.

[0045] It should be noted that the scheduling method of this device management service can be applied to a device management platform. This scheduling method can be implemented based on cloud-native technologies. Cloud-native is a cloud technology product system built upon distributed cloud deployment and unified operation and management, using technologies such as containers, microservices, processes, methods, and systems (DevOps). The device management service can be abstracted as a microservice, and can be containerized using an application container engine to create image spares and store them in an image repository.

[0046] It should be noted that the scheduling data can specifically be data related to the operation of the device management service, such as tag data, memory data, CPU data, network access permission data, etc. Correspondingly, the resource container group information can include tag information, memory information, CPU information, etc., corresponding to the device management service. A resource container group can include at least one resource container, and it can also include the resources required to run the device management service.

[0047] It should be noted that the scheduling data can be pre-configured data in response to user actions in the configuration interface. The scheduling data can also be pre-stored in a database.

[0048] It should be noted that some or all of the execution entities 101 to 104 can be applications located on the local terminal, or they can be functional units such as plug-ins or software development kits (SDKs) set in applications located on the local terminal, or they can be processing engines located on the network-side server, or they can be distributed systems located on the network side, such as processing engines or distributed systems in network-side device management platforms, etc. This embodiment does not impose any special limitations on this.

[0049] It is understood that the application may be a native program installed on the local terminal, or it may be a web application of a browser on the local terminal. This embodiment does not limit this.

[0050] In this way, by acquiring the scheduling data of the device management service, resource container group information corresponding to the scheduling data can be generated. Based on the resource container group information, the resource container group is deployed, enabling the device management service to run using the deployed resource container group. Since the resource container group deployed based on the resource container group information corresponding to the scheduling data is used to run the device management service during resource scheduling, the scheduling and management process of the device management service is simplified, achieving simpler and more efficient scheduling and management of the device management service, thereby ensuring the reliability of the device management service scheduling.

[0051] Optionally, in one possible implementation of this embodiment, in step 102, resource container group information corresponding to the scheduling data can be generated based on the running status of the device management service and the scheduling data.

[0052] In this implementation, the scheduling data may include at least one of runtime data and upgrade data. It is understood that the upgrade data may be runtime data after the configuration has been updated, for example, runtime data for an upgraded version.

[0053] In one specific implementation of this approach, in response to the device management service being in an undeployed state, resource container group information corresponding to the scheduling data can be generated based on the scheduling data.

[0054] In this specific implementation process, if the device management service is in an undeployed state, the scheduling data can be the running data of the undeployed device management service, and then the resource container group information corresponding to the running data can be generated based on the running data.

[0055] In this specific implementation process, the accuracy of the obtained device management service scheduling data can be further checked based on the tag data of the scheduling data. If correct, the resource container group information corresponding to the running data can be generated based on the running data.

[0056] In this way, by judging the running status of the device management service, it can be determined that the scheduling data is the running data of the undeployed device management service. Then, based on the running data, the resource container group information corresponding to the running data can be generated. This can effectively handle the startup of the device management service and ensure the reliability of the startup scheduling process of the device management service.

[0057] In another specific implementation of this approach, in response to the device management service being in a deployed state and the scheduling data being inconsistent with the running data corresponding to the deployed state, resource container group information corresponding to the scheduling data can be generated based on the scheduling data.

[0058] In this specific implementation process, if the device management service is in the deployed state, the scheduling data and the corresponding running data in the deployed state are compared to see if there is a difference. If the scheduling data is inconsistent with the running data in the deployed state, that is, the scheduling data can be the upgrade data of the deployed device management service, the upgrade data and the running data in the deployed state can be saved, and then the resource container group information corresponding to the upgrade data can be generated based on the upgrade data.

[0059] In one specific implementation, before generating the resource container group information corresponding to the upgrade data based on the upgrade data, the current number of concurrent upgrade processes can be further updated to determine whether the current number of concurrent upgrade processes exceeds a preset threshold. If the current number of concurrent upgrade processes does not exceed the preset threshold, the resource container group information corresponding to the upgrade data can be generated based on the upgrade data. If the current number of concurrent upgrade processes exceeds the preset threshold, the process can wait until the current number of concurrent upgrade processes does not exceed the preset threshold before generating the resource container group information corresponding to the upgrade data based on the upgrade data.

[0060] In another scenario during this specific implementation, if the upgrade of the device management service fails, the container orchestration engine can be used to roll back the device management service. Then, based on the previously saved upgrade data and the running data corresponding to the deployed state, the process of generating the resource container group information corresponding to the upgrade data and subsequent steps can be re-executed.

[0061] In this way, by judging the running status of the device management service and judging whether the scheduling data is consistent with the running data corresponding to the deployed status, it can be determined that the scheduling data is the upgrade data of the deployed device management service. Then, based on the upgrade data, the resource container group information corresponding to the upgrade data can be generated. This can effectively handle the update of the device management service and ensure the reliability of the update scheduling process of the device management service.

[0062] In another specific implementation of this approach, the accuracy of the obtained device management service scheduling data can be further checked based on the tag data of the scheduling data. If correct, resource container group information corresponding to the scheduling data can be generated based on the running status of the device management service and the scheduling data.

[0063] In another specific implementation of this approach, resource container group information corresponding to the scheduling data can be dynamically generated based on the operating status and scheduling data of the device management service.

[0064] Specifically, resource container group information can be information corresponding to the container orchestration engine; that is, the resource container group information is information that the container orchestration engine can use for resource deployment. For example, resource container group information may include tag information, memory information, CPU information, etc., corresponding to the device management service.

[0065] In this way, the implementation method can confirm the running status of the device management service, and then dynamically generate the resource container group information corresponding to the scheduling data based on the scheduling data of the device management service under different running statuses. It can perform scheduling processing based on different running status conditions of the device management service, such as startup or upgrade, thereby improving the pertinence and reliability of the scheduling processing of the device management service.

[0066] Optionally, in one possible implementation of this embodiment, in step 103, the resource container group information can be sent to the container orchestration engine using the container orchestration engine interface, and the container orchestration engine can deploy the resource container group according to the resource container group information using the deployment controller.

[0067] Now that the deployed resource container group has been determined, we can proceed to step 104, which means using the deployed resource container group to run the device management service.

[0068] In this implementation, the container orchestration engine can use the deployment controller to find suitable machine nodes and allocate resources for the device management service based on the resource container group information in order to deploy the resource container group.

[0069] In this way, the container orchestration engine can deploy resource container groups based on resource container group information, thereby enabling dynamic expansion and scheduling of resources for the device management service. It can also effectively limit and isolate the resources used by the device management service, effectively manage the actual resource usage of the device management service, and thus use machine resources more rationally and improve the resource utilization efficiency of machine resources.

[0070] Optionally, in one possible implementation of this embodiment, in or after step 104, the state of the resource container group running the device management service can be further obtained, and then the changes in the state of the resource container group can be determined based on the state of the resource container group, so that the scheduling state of the device management service can be determined based on the changes in the state of the resource container group.

[0071] At this point, the scheduling status can be communicated to the resource management service so that the device management platform can know the scheduling status of the device management service, i.e., its operational status, such as whether the device management service has been successfully started or upgraded.

[0072] In this implementation, the state of the resource container group can include pending, running, and terminating states. Changes in the state of the resource container group can include changes from pending to running, from running to terminating, and from running to any other state except terminating. The scheduling state can include: started, paused, and deleted.

[0073] In a specific implementation of this approach, if the state of the resource container group changes from a pending state to a running state, the scheduling state of the device management service can be determined to be started. If the state of the resource container group changes from a running state to any state other than the terminated state, the scheduling state of the device management service can be determined to be paused. If the state of the resource container group changes from a running state to a terminated state, the scheduling state of the device management service can be determined to be deleted.

[0074] For example, for any device management service, a change in the state of the resource container group corresponding to that service from a pending state to a running state indicates that the device management service has been started. A change in the state of the resource container group corresponding to that service from a running state to any state other than a terminated state indicates that the device management service has been paused. A change in the state of the resource container group corresponding to that service from a running state to a terminated state indicates that the device management service has been deleted.

[0075] In another specific implementation of this method, if it is impossible to determine whether the state of the resource container group has changed from a pending state to a running state within a predetermined time, an error message can be sent to the device management service to facilitate manual troubleshooting.

[0076] In this way, the scheduling status of the device management service can be determined based on the changes in the status of the resource container group. Since only the changes in the status of the resource container group need to be monitored, it is possible to quickly know whether the scheduling of the device management service is successful, and whether the startup or upgrade of the device management service is successful. This allows for a rapid understanding of the scheduling status of the device management service, improves the efficiency of scheduling management, further simplifies the scheduling process of the device management service, and effectively ensures the consistency of the lifecycle of the device management service during the scheduling process, thereby further improving the efficiency and reliability of device management service scheduling.

[0077] It should be noted that the various specific implementation processes of the device management service provided in the aforementioned implementation methods can be combined with the various specific implementation processes of determining the scheduling state of the device management service provided in this implementation method to implement the scheduling method of the device management service. Detailed descriptions can be found in the relevant content of the aforementioned implementation methods, and will not be repeated here.

[0078] In this embodiment, by acquiring the scheduling data of the device management service, resource container group information corresponding to the scheduling data can be generated. Based on the resource container group information, the resource container group is deployed, enabling the device management service to run using the deployed resource container group. Since the resource container group deployed by the resource container group information corresponding to the scheduling data is used to run the device management service during resource scheduling, the scheduling management process of the device management service is simplified, achieving simpler and more efficient scheduling management of the device management service, thereby ensuring the reliability of the device management service scheduling.

[0079] In addition, by adopting the technical solution provided in this embodiment, the operating status of the device management service can be confirmed, and then the resource container group information corresponding to the scheduling data can be dynamically generated based on the scheduling data of the device management service under different operating status conditions, such as startup or upgrade, thereby improving the pertinence and reliability of the scheduling processing of the device management service.

[0080] In addition, by using the technical solution provided in this embodiment, the scheduling data is determined to be the running data of the undeployed device management service by judging the running status of the device management service. Then, the resource container group information corresponding to the running data can be generated based on the running data, thereby effectively handling the startup of the device management service and ensuring the reliability of the startup scheduling process of the device management service.

[0081] Furthermore, by adopting the technical solution provided in this embodiment, by judging the running status of the device management service and judging whether the scheduling data is consistent with the running data corresponding to the deployed status, it is determined that the scheduling data is the upgrade data of the deployed device management service. Then, based on the upgrade data, the resource container group information corresponding to the upgrade data can be generated. This can effectively handle the update of the device management service and ensure the reliability of the update scheduling process of the device management service.

[0082] Furthermore, by adopting the technical solution provided in this embodiment, the scheduling status of the device management service can be determined based on the changes in the status of the resource container group. Since only the changes in the status of the resource container group need to be monitored, it is possible to quickly know whether the scheduling of the device management service is successful, and whether the startup or upgrade of the device management service is successful. This allows for a rapid understanding of the scheduling status of the device management service, improves the efficiency of scheduling management, further simplifies the scheduling process of the device management service, and effectively ensures the consistency of the lifecycle of the device management service during the scheduling process, thereby further improving the efficiency and reliability of the device management service scheduling.

[0083] Furthermore, by adopting the technical solution provided in this embodiment, the resource container group can be deployed according to the resource container group information through the container orchestration engine, which can realize the dynamic expansion and scheduling of the resources of the device management service. It can also effectively limit and isolate the resources used by the device management service, effectively manage the actual usage of resources by the device management service, thereby making more rational use of machine resources and improving the resource utilization efficiency of machine resources.

[0084] Figure 2 This is a schematic diagram based on the second embodiment of the present disclosure, as shown below. Figure 2 As shown.

[0085] In this embodiment, Figure 3 This is a schematic diagram of the scheduling service architecture of the scheduling method according to the second embodiment of this disclosure, now combined with Figure 3 The scheduling method of the device management service in this embodiment will be described in detail, such as... Figure 3 As shown.

[0086] The scheduling service may include: a scheduling service API, scheduling service worker threads, a container engine, a container orchestration engine, and cloud servers. This scheduling service can be implemented using cloud-native technologies.

[0087] Specifically, the scheduling service API may include: an instance scheduling module, a service discovery module, and a debugging module. The scheduling service worker threads may include: an asynchronous task module, a synchronous module, and a checking module.

[0088] The instance scheduling module can implement functions such as instance control and canary rollout.

[0089] The service discovery module can perform functions such as instance discovery and instance address mapping.

[0090] The Debug module can implement functions such as printing resource lists and internal status.

[0091] The asynchronous task module can implement functions such as full upgrade and exception rollback.

[0092] The synchronization module can realize functions such as instance resource synchronization.

[0093] The inspection module, also known as the listening module, can perform functions such as deployment resource inspection and container group resource inspection. Among them, deployment resource inspection can be used to check the deployment resource status of the deployment controller (Deployment).

[0094] It is understandable that the example here is a device management service. The container engine can be Docker, and the container orchestration engine can be Kubernetes.

[0095] 201. Obtain scheduling data from the device management service.

[0096] Here, the scheduling data for the device management service can be data pre-configured by the resource management service of the device management platform in response to user operations on the configuration interface. The scheduling data can be pre-stored in a database. The scheduling data may include at least one of operational data and upgrade data.

[0097] 202. Based on the operating status and scheduling data of the equipment management service, generate resource container group information corresponding to the scheduling data.

[0098] Specifically, the instance scheduling module can be used to generate resource container group information corresponding to the scheduling data based on the running status of the device management service and the scheduling data. Then, the instance scheduling module sends the resource container group information to Kubernetes via the Kubernetes-API.

[0099] This instance scheduling module can be used for the lifecycle management of device management services, as well as the management of resource container group information and scheduling data for device management services. It can also be used for canary upgrades. Canary upgrades can be performed on a specific device management service, allowing for the observation of the reliability of the new version of the device management service.

[0100] The communication between the instance scheduling module and Kubernetes is implemented based on the service discovery module of the scheduling service. The service discovery module can be used to discover the virtual Layer 2 network address of the device management service, thereby enabling end-to-end communication between business services.

[0101] Optionally, the service discovery module can be packaged as an SDK for easy invocation by other services. The service discovery module's workflow may include querying resource container groups (Pods) via the Kubernetes API, based on label information. Each device management service on cloud-native Kubernetes can have a unique label, for example, the label information from the resource container group information corresponding to scheduling data. Then, using the Pod's IP, end-to-end communication is performed over Kubernetes' virtual Layer 2 network, thereby reducing network latency. Furthermore, this Pod IP can be stored in the SDK's cache. When other business services communicate using the Pod IP corresponding to the device management service, if any call returns a 404 error or the resource does not exist, the Pod IP cache in the SDK is removed.

[0102] Specifically, resource container group information can be information corresponding to Kubernetes, that is, information that Kubernetes can use for resource deployment, such as Deployment information.

[0103] 203. Deploy the resource container group based on the resource container group information.

[0104] Here, Kubernetes can utilize the Deployment controller to deploy resource container groups (Pods) based on resource container group information.

[0105] 204. Utilize the deployed resource container group to run device management services.

[0106] 205. Obtain the status of the resource container group running the device management service.

[0107] 206. Determine the changes in the state of the resource container group based on its state.

[0108] Specifically, the status of the resource container group running the device management service can be obtained based on the inspection module. This inspection module can be used to obtain changes in the Kubernetes resource container group. This module is a background worker thread group that starts when the scheduling service starts, and unlike inspections based on long connections, this inspection module utilizes the SharedInfomer mechanism to obtain changes in the resource container group from Kubernetes at regular intervals and perform corresponding processing.

[0109] 207. Determine the scheduling status of the device management service based on the changes in the status of the resource container group.

[0110] 208. Inform the equipment management platform of the scheduling status.

[0111] In this embodiment, the scheduling data may include at least one of the following: running data and upgrade data.

[0112] In one implementation of this embodiment, in response to the device management service being in an undeployed state, resource container group information corresponding to the scheduling data is generated based on the scheduling data.

[0113] In this specific implementation, if the device management service is in an undeployed state, the scheduling data can be the running data of the undeployed device management service. Then, based on the tag data of the running data, the correctness of the obtained running data of the device management service is checked. If correct, resource container group information corresponding to the running data can be generated. This resource container group information is then sent to Kubernetes via the Kubernetes API. Kubernetes can use Deployments to deploy Pods based on the resource container group information. The changes in Pods and Deployments in Kubernetes are then obtained based on the checking module. Finally, the scheduling status of the device management service can be determined based on the changes in the Pod status, so that the scheduling status can be informed to the device management platform.

[0114] Specifically, for any device management service, the inspection module can be used to monitor the following three types of Pod and Deployment changes, thereby determining the scheduling status of the device management service corresponding to each type of change:

[0115] The first type is the change of the Pod corresponding to the device management service from the pending state to the running state. That is, the change of a Pod with the device management service tag from the pending state to the running state. The scheduling state of the device management service corresponding to this change is "started", that is, the device management service has been started.

[0116] The second type is a Pod with the device management service tag that changes from a running state to any state other than a terminated state. The scheduling state of the device management service corresponding to this change is paused, that is, the device management service has been paused.

[0117] The third type is a change in the running state of a Pod with the device management service tag from the terminated state, or a change in the deployed state of a Deployment with the device management service tag from the deleted state. The scheduling state of the device management service corresponding to this change is deleted, that is, the device management service has been deleted.

[0118] Therefore, if the first type of change is detected during the scheduling of starting the device management service, it can be reported to the device management platform. For example, it can be reported to the device management platform through the resource management service API of the device management platform to inform that the device management service has started successfully.

[0119] Specifically, a Pod's pending state can mean that the Pod creation request has been accepted by Kubernetes, but the container group has not yet started successfully. It may be in any of the following four stages: writing data to a highly available key-value store (ETCD), scheduling and pulling images, or starting the container group. A Pod's running state means that the Pod has been bound to a node, and all containers in the container group have started successfully. A Pod's terminating state means that the Pod has been deleted and is in the exit stage. Other Pod states can include success, failure, and unknown states.

[0120] Furthermore, if the change in the Pod's status from pending to running cannot be determined within the predetermined time, an error message can be sent to the device management service scheduling system based on the Debug module to facilitate manual troubleshooting. Specifically, this Debug module can be used to check the status of Kubernetes and the current status of device management service resources, providing features such as snapshot technology for operations and maintenance personnel to troubleshoot.

[0121] Understandably, if it's impossible to determine whether a Pod's state has changed from pending to running, causing the scheduling process to drag on, it may indicate that Kubernetes is experiencing issues such as insufficient machine resources or corrupted instance images. In this case, manual troubleshooting using the Debug module can be performed to pinpoint the source of the problem. Generally, the issue is due to insufficient machine resources, and therefore, horizontal scaling to add more machines will resolve the problem.

[0122] In another implementation of this embodiment, specifically in response to the device management service being in a deployed state and the scheduling data being inconsistent with the running data corresponding to the deployed state, resource container group information corresponding to the scheduling data is generated based on the scheduling data.

[0123] In this specific implementation, if the device management service is in a deployed state, the scheduling data of the device management service is compared with the running data corresponding to the deployed state to check for differences. If the scheduling data is inconsistent with the running data corresponding to the deployed state, that is, the scheduling data may be upgrade data of the deployed device management service, then an asynchronous upgrade task can be issued using the asynchronous task module, and the upgrade task can be started. Based on the upgrade data, the resource container group information corresponding to the upgrade data is generated. Simultaneously, the upgrade data and the running data corresponding to the deployed state can be saved.

[0124] In this specific implementation, before generating the resource container group information corresponding to the upgrade data based on the upgrade data from the device management service, the current number of concurrent upgrade processes can be further updated to determine whether the current number of concurrent upgrade processes exceeds a preset threshold. If the current number of concurrent upgrade processes does not exceed the preset threshold, the resource container group information corresponding to the upgrade data can be generated based on the upgrade data. If the current number of concurrent upgrade processes exceeds the preset threshold, the process can wait until the current number of concurrent upgrade processes does not exceed the preset threshold before generating the resource container group information corresponding to the upgrade data based on the upgrade data.

[0125] Furthermore, after generating the resource container group information corresponding to the upgrade data, this information can be sent to Kubernetes via the Kubernetes API. Kubernetes can then use Deployments to deploy Pods based on this information. The inspection module then retrieves changes to Pods and Deployments within Kubernetes. Finally, based on the changes in Pod status, the scheduling status of the device management service can be determined, and this status can be communicated to the device management platform.

[0126] Here, the inspection module can continuously monitor changes to Kubernetes Pods and Deployments. The changes to Pods and Deployments monitored by the inspection module are the same as those in the aforementioned implementation, namely the three types of changes mentioned earlier. Furthermore, since the scheduling service can continuously update the configuration of Kubernetes Deployments, it is sufficient to focus only on the first type of change.

[0127] Specifically, for any device management service, if the change in the Kubernetes Pod is the first type of change, it indicates that the upgrade data for that device management service has been initiated, meaning the upgrade for that device management service has been completed, and the count of concurrent upgrade processes is decremented by 1. This process of scheduling upgrade data for device management services is repeated until all device management services have completed their upgrade tasks.

[0128] In addition, if the device management service upgrade fails, the device management service can be rolled back using Kubernetes Deployment via Kubernetes-API. Then, based on the previously saved upgrade data and the running data corresponding to the deployed state, the process of generating the resource container group information corresponding to the upgrade data and subsequent steps can be re-executed.

[0129] Here, during the upgrade scheduling process of the device management service, the asynchronous task module of the scheduling service is utilized. This asynchronous task module can be used to handle full upgrades and rollbacks due to exceptions encountered during the full upgrade process.

[0130] Specifically, during the maintenance and updates of the scheduling service, the synchronization module of the scheduling service can be used to synchronize any device management service control requests that may have been missed. Typically, this is done when the scheduling service restarts, synchronizing the relevant data of the current device management service to the container orchestration engine; for example, synchronizing the relevant data of the currently configured device management service to Kubernetes, in order to ensure the consistency of the device management service.

[0131] Furthermore, in this embodiment, the scheduling service used to implement the scheduling method for device management services can be applied to a device management platform, such as an IoT device management platform. This scheduling service is implemented based on cloud-native technology, and the device management platform can also be a platform adapted to cloud-native scheduling services.

[0132] Here, the scheduling service of this cloud-native device management service is designed and implemented based on Docker and Kubernetes. Docker is a containerization technology that supports the creation and use of Linux containers. Kubernetes is a portable, scalable, open-source platform for managing containerized workloads and services, promoting declarative configuration and automation, and providing a framework for elastically running distributed systems that can meet scalability requirements, failover, deployment modes, and more.

[0133] Furthermore, all services of the device management platform have been transformed into microservices and containers. The device management platform can include services such as device management services (instances), resource management services, API forwarding services, and scheduling services.

[0134] The Device Management Service (Instance) is the core service of the Device Management Platform, used for the comprehensive management of products and devices included in a specific Device Management Service. Examples include device message access, device authentication, and querying the definition of an object model.

[0135] The resource management service is used to uniformly allocate available external resources for devices. Examples include Message Queuing Telemetry Transport (MQTT) and message queues. The device management service can only function correctly if available external resources are allocated. For instance, a device management service without allocated MQTT resources will not allow devices to report messages via MQTT. This resource management service can also respond to user configuration operations on the configuration interface, configuring the scheduling data for the device management service. Furthermore, it can receive the scheduling status of the device management service from the scheduling service, allowing the device platform to know the current scheduling status of the device management service, such as whether the device management service has started or whether upgrade data for the device management service has been initiated.

[0136] API forwarding services are used to distribute specific requests for a device management service. For example, if an external resource that a device can use is created on a device management service, and a rule is created to distribute the device's messages to the data destination through the rule engine.

[0137] The scheduling service is used for unified scheduling and management of instances. This service is internal and not visible to users. The scheduling service can schedule device management services through the scheduling service API and the resource management service. Simultaneously, the scheduling service also needs to maintain the lifecycle of device management services, service discovery and registration for device management services, resource expansion for device management services, and vertical updates of images.

[0138] Therefore, in the implementation of this device management service scheduling method, the most important aspect of the scheduling service is ensuring its normal operation. The specific architecture of the scheduling service, such as... Figure 3 As shown in the diagram. Here, the device management service, i.e., the device management instance, can be abstracted as a microservice, which conforms to the definition of cloud-native. By containerizing the device management service, creating image spares, and storing them in an image repository, the scheduling service can dynamically create corresponding Kubernetes resource Pods based on relevant data of the device management service, such as scheduling data, to run the device management service, thereby completing the scheduling of the device management service.

[0139] In this embodiment, the Kubernetes application resource Deployment can be further used as a cloud-native resource definition for a device management service. The Deployment can maintain the number of Pod replicas and update rules, etc. The Deployment resource, i.e., Deployment information, can support setting unique tags. These tags can be used for querying, aggregation, etc. Deployment information can be configured through the scheduling service API.

[0140] Specifically, in this embodiment, after the scheduling service is made cloud-native, Kubernetes can take over the control of the device management service from the scheduling service. Therefore, the scheduling service can focus on the cloud-native resource management of Kubernetes.

[0141] It is understandable that as device-related services are updated and iterated, device management services require a full update. When a device management platform has a large number of device management services, any anomaly can lead to data loss and significant adverse effects. The method in this embodiment ensures that updates to individual device management services are guaranteed and uninterrupted. Therefore, during the upgrade of all device management services, by controlling the number of concurrent upgrades and continuously monitoring changes in Kubernetes resource container groups, the speed and security of the upgrade can be maintained.

[0142] By adopting the technical solution provided in this embodiment, the scheduling and management process of the device management service can be simplified through scheduling based on cloud-native device management services. It also effectively ensures the consistency of the lifecycle of the device management service during the scheduling process, realizing simpler and more efficient scheduling and management of the device management service, thereby ensuring the reliability of device management service scheduling.

[0143] Furthermore, by deploying resource container groups based on resource container group information through the container orchestration engine, dynamic expansion and scheduling of resources for the device management service can be achieved. It can also effectively limit and isolate the resources used by the device management service, effectively manage the actual resource usage of the device management service, and thus use machine resources more rationally and improve the resource utilization efficiency of machine resources.

[0144] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited to the described order of actions, because according to this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this disclosure.

[0145] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0146] Figure 4 This is a schematic diagram based on the third embodiment of the present disclosure, as shown below. Figure 4 As shown. The scheduling device 400 for the device management service in this embodiment may include an acquisition unit 401, a generation unit 402, a deployment unit 403, and a running unit 404. The acquisition unit 401 is used to acquire scheduling data for the device management service; the generation unit 402 is used to generate resource container group information corresponding to the scheduling data; the deployment unit 403 is used to deploy resource container groups according to the resource container group information; and the running unit 404 is used to run the device management service using the deployed resource container groups.

[0147] It should be noted that some or all of the scheduling device for the device management service in this embodiment may be an application located on a local terminal, or it may be a plugin or software development kit (SDK) or other functional unit set in the application located on the local terminal, or it may be a processing engine located on the network-side server, or it may be a distributed system located on the network side, such as a processing engine or distributed system in the device management platform on the network side. This embodiment does not impose any particular limitations on this.

[0148] It is understood that the application may be a native program installed on the local terminal, or it may be a web application of a browser on the local terminal. This embodiment does not limit this.

[0149] Optionally, in one possible implementation of this embodiment, the generation unit 402 may be used to generate resource container group information corresponding to the scheduling data based on the running status of the device management service and the scheduling data.

[0150] For example, the generation unit 402 can also be further configured to generate resource container group information corresponding to the scheduling data based on the scheduling data in response to the device management service being in an undeployed state.

[0151] Alternatively, for example, the generation unit 402 may further be used to generate resource container group information corresponding to the scheduling data in response to the device management service being in a deployed state and the scheduling data being inconsistent with the running data corresponding to the deployed state.

[0152] Optionally, in one possible implementation of this embodiment, the running unit 404 may be used to obtain the status of the resource container group running the device management service; determine the changes in the status of the resource container group based on the status of the resource container group; and determine the scheduling status of the device management service based on the changes in the status of the resource container group.

[0153] Optionally, in one possible implementation of this embodiment, the scheduling state may include: start, pause, or delete.

[0154] In this embodiment, the acquisition unit obtains the scheduling data of the device management service, and then the generation unit generates the resource container group information corresponding to the scheduling data based on the scheduling data. The deployment unit deploys the resource container group based on the resource container group information, so that the running unit can use the deployed resource container group to run the device management service. Since the resource container group deployed by the resource container group information corresponding to the scheduling data is used to run the device management service during resource scheduling, the scheduling management process of the device management service is simplified, and the scheduling management of the device management service is made simpler and more efficient, thereby ensuring the reliability of the device management service scheduling.

[0155] In addition, by adopting the technical solution provided in this embodiment, the operating status of the device management service can be confirmed, and the resource container group information corresponding to the scheduling data can be dynamically generated based on the scheduling data of the device management service under different operating status conditions, such as startup or upgrade, thereby improving the pertinence and reliability of the scheduling processing of the device management service.

[0156] In addition, by using the technical solution provided in this embodiment, the scheduling data is determined to be the running data of the undeployed device management service by judging the running status of the device management service. Then, the resource container group information corresponding to the running data can be generated based on the running data, thereby effectively handling the startup of the device management service and ensuring the reliability of the startup scheduling process of the device management service.

[0157] Furthermore, by adopting the technical solution provided in this embodiment, by judging the running status of the device management service and judging whether the scheduling data is consistent with the running data corresponding to the deployed status, it is determined that the scheduling data is the upgrade data of the deployed device management service. Then, based on the upgrade data, the resource container group information corresponding to the upgrade data can be generated. This can effectively handle the update of the device management service and ensure the reliability of the update scheduling process of the device management service.

[0158] Furthermore, by adopting the technical solution provided in this embodiment, the scheduling status of the device management service can be determined based on the changes in the status of the resource container group. Since only the changes in the status of the resource container group need to be monitored, it is possible to quickly know whether the scheduling of the device management service is successful, and whether the startup or upgrade of the device management service is successful. This allows for a rapid understanding of the scheduling status of the device management service, improves the efficiency of scheduling management, further simplifies the scheduling process of the device management service, and effectively ensures the consistency of the lifecycle of the device management service during the scheduling process, thereby further improving the efficiency and reliability of the device management service scheduling.

[0159] Furthermore, by adopting the technical solution provided in this embodiment, the resource container group can be deployed according to the resource container group information through the container orchestration engine, which can realize the dynamic expansion and scheduling of the resources of the device management service. It can also effectively limit and isolate the resources used by the device management service, effectively manage the actual usage of resources by the device management service, thereby making more rational use of machine resources and improving the resource utilization efficiency of machine resources.

[0160] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with relevant laws and regulations and do not violate public order and good morals.

[0161] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0162] Figure 5A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0163] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0164] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0165] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the scheduling method for device management services. For example, in some embodiments, the scheduling method for device management services may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the scheduling method for device management services described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the scheduling method for device management services by any other suitable means (e.g., by means of firmware).

[0166] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0167] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0168] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0169] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0170] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0171] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0172] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0173] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A scheduling method for device management services, comprising: Obtain scheduling data for the device management service, the scheduling data including tag data, memory data, and CPU data related to the operation of the device management service; Based on the scheduling data, resource container group information corresponding to the scheduling data is generated. The resource container group information includes tag information, memory information, and CPU information corresponding to the device management service. Deploy the resource container group based on the resource container group information; The device management service is run using the deployed resource container group; The step of generating resource container group information corresponding to the scheduling data based on the scheduling data includes: In response to the device management service being in an undeployed state, and determining the scheduling data to be correct based on the tag data, resource container group information corresponding to the scheduling data is generated based on the scheduling data; or In response to the device management service being in a deployed state, the scheduling data being inconsistent with the running data corresponding to the deployed state, and the scheduling data being determined to be correct based on the tag data, an asynchronous upgrade task is issued using the asynchronous task module, and the upgrade task is started. Based on the upgrade data, resource container group information corresponding to the upgrade data is generated, and the upgrade data and the running data corresponding to the deployed state are saved. Deploying the resource container group based on the resource container group information includes: The resource container group information is sent to the container orchestration engine using the container orchestration engine interface, so that the container orchestration engine uses the deployment controller to find suitable machine nodes based on the resource container group information, allocate the resources used by the device management service, and deploy the resource container group. The method further includes: Obtain the status of the resource container group running the device management service; Based on the state of the resource container group, determine the changes in the state of the resource container group; The scheduling status of the device management service is determined based on the changes in the status of the resource container group.

2. The method according to claim 1, wherein, The scheduling status includes: start, pause, and delete.

3. A scheduling device for equipment management services, comprising: The acquisition unit is used to acquire scheduling data of the device management service, the scheduling data including tag data, memory data and CPU data related to the operation of the device management service; The generation unit is used to generate resource container group information corresponding to the scheduling data based on the scheduling data. The resource container group information includes tag information, memory information and CPU information corresponding to the device management service. The deployment unit is used to deploy the resource container group according to the resource container group information; The running unit is used to run the device management service using the deployed resource container group; Specifically, when the generation unit generates the resource container group information corresponding to the scheduling data based on the scheduling data, it performs the following: In response to the device management service being in an undeployed state, and determining the scheduling data to be correct based on the tag data, resource container group information corresponding to the scheduling data is generated based on the scheduling data; or In response to the device management service being in a deployed state, the scheduling data being inconsistent with the running data corresponding to the deployed state, and the scheduling data being determined to be correct based on the tag data, an asynchronous upgrade task is issued using the asynchronous task module, and the upgrade task is started. Based on the upgrade data, resource container group information corresponding to the upgrade data is generated, and the upgrade data and the running data corresponding to the deployed state are saved. When the deployment unit deploys the resource container group based on the resource container group information, it specifically performs the following: The resource container group information is sent to the container orchestration engine using the container orchestration engine interface, so that the container orchestration engine uses the deployment controller to find suitable machine nodes based on the resource container group information, allocate the resources used by the device management service, and deploy the resource container group. The operating unit is also used for Obtain the status of the resource container group running the device management service; Based on the state of the resource container group, determine the changes in the state of the resource container group; and The scheduling status of the device management service is determined based on the changes in the status of the resource container group.

4. The apparatus according to claim 3, wherein, The scheduling status includes: start, pause, and delete.

5. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-2.

6. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-2.

7. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-2.

Images