Containerization-based resource scheduling method, apparatus and device, and storage medium

Abstract

The invention discloses a containerization-based resource scheduling method, which comprises the following steps of: receiving and analyzing a resource application request sent by a resource applicant to obtain an analyzed content; verifying the analysis content, and when the verification is passed, adding the analysis content into a pre-constructed scheduling queue by taking a container as a basic unit; sequentially acquiring container information of the containers from the scheduling queue according to a specified scheduling method, and allocating a target server to the resource applicant according to the container information; based on the container information, creating a container in the target server, and loading a resource mirror image corresponding to the resource application request in the container; after loading of the resource mirror image is completed, resources are allocated to the resource applicant to complete resource scheduling; the invention can improve the efficiency and reliability of resource scheduling, thereby improving the resource utilization rate and enhancing the overall performance of the system.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a containerized resource scheduling method, apparatus, device, and storage medium. Background Technology

[0002] With the rapid development of information technology, resource scheduling technology plays a vital role in various fields. Resource scheduling refers to the rational and effective adjustment, measurement, analysis and use of various resources. It is not only related to the effective utilization of resources, but also directly affects the performance, stability and scalability of the system.

[0003] In existing technologies, Hadoop, Flink, and Spark are used to build mainstream real-time storage and computing systems. Components manage and schedule resources through Yarn. However, this resource scheduling method still has some problems. In some cases, resource scheduling may not be able to respond to changes in resource demand in a timely manner, resulting in insufficient resource elasticity. Furthermore, due to uneven resource allocation, a large number of resources will be idle during off-peak business periods, resulting in low resource utilization and affecting the overall performance of the system. Summary of the Invention

[0004] This invention provides a containerized resource scheduling method that can improve the efficiency and reliability of resource scheduling, thereby increasing resource utilization and enhancing the overall performance of the system.

[0005] In a first aspect, embodiments of the present invention provide a containerized resource scheduling method, including:

[0006] Receive and parse the resource request sent by the resource requester to obtain the parsed content;

[0007] The parsed content is verified, and when the verification is successful, the parsed content is added to a pre-built scheduling queue with containers as the basic unit.

[0008] The container information of the container is obtained sequentially from the scheduling queue according to the specified scheduling method, and a target server is allocated to the resource requester based on the container information;

[0009] Based on the container information, a container is created in the target server, and the resource image corresponding to the resource request is loaded into the container;

[0010] After the resource image is loaded, resources are allocated to the resource requester to complete resource scheduling.

[0011] Furthermore, the resource request includes, but is not limited to, the type of framework to be requested, the type of resource to be requested, the size of the resource to be requested, and the deployment order of the framework.

[0012] Furthermore, after verifying the parsed content, the process also includes:

[0013] When verification fails, a parsing error message is generated and returned to the resource requester so that the resource requester can modify the resource request based on the parsing error message.

[0014] Furthermore, the step of allocating a target server to the resource requester based on the container information includes:

[0015] Obtain the resource usage status of all resources in each server node, and determine the available resources based on the resource usage status; wherein, the resource usage status includes resource utilization status and resource health status;

[0016] Based on the container information, the available resources are traversed, and a server node that meets the resource request requirements is selected as the target server for the resource requester.

[0017] Furthermore, the step of allocating a target server to the resource requester based on the container information also includes:

[0018] When the container information contains tagged resources, server nodes with the same tags are preferentially matched as the target server for the resource requester.

[0019] Furthermore, loading the resource image corresponding to the resource request into the container includes:

[0020] The type of framework to be requested is determined based on the resource request request;

[0021] Obtain the framework image corresponding to the framework type to be applied for from the image repository, and store the framework image in the local image library; wherein, the framework type to be applied for includes storage framework, computing framework and development framework;

[0022] The framework image is loaded and started in the container.

[0023] Furthermore, the method also includes:

[0024] Monitor the container's entire lifecycle status and obtain the container's runtime logs;

[0025] When an anomaly is detected in a container, a container anomaly alarm is generated based on the operation log, and the container anomaly alarm is returned to the resource requester so that the resource requester can handle the anomaly; wherein, the anomaly includes, but is not limited to, image loading anomaly, resource utilization anomaly, network anomaly, job execution anomaly, and database anomaly.

[0026] Secondly, embodiments of the present invention provide a containerized resource scheduling device, comprising:

[0027] The request receiving module is used to receive and parse the resource request sent by the resource requester to obtain the parsed content;

[0028] The parsing and verification module is used to verify the parsed content. When the verification is successful, the parsed content is added to a pre-built scheduling queue with containers as the basic unit.

[0029] The server allocation module is used to sequentially obtain the container information of the container from the scheduling queue according to the specified scheduling method, and allocate a target server to the resource requester based on the container information.

[0030] The image loading module is used to create a container in the target server based on the container information, and load the resource image corresponding to the resource request into the container;

[0031] The resource scheduling module is used to allocate resources to the resource requester after the resource image is loaded, so as to complete the resource scheduling.

[0032] Thirdly, embodiments of the present invention provide an electronic device, comprising:

[0033] Memory, used to store computer programs;

[0034] A processor for executing the computer program;

[0035] Wherein, when the processor executes the computer program, it implements the containerized resource scheduling method described in any of the first aspects above.

[0036] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed, implements the containerized resource scheduling method described in any of the first aspects above.

[0037] Compared with existing technologies, the containerized resource scheduling method provided in this invention has the following advantages: It receives and parses resource request requests sent by resource requesters to obtain parsed content; verifies the parsed content, and when verification is successful, adds the parsed content to a pre-built scheduling queue with containers as the basic unit; sequentially retrieves container information from the scheduling queue according to a specified scheduling method, and allocates a target server to the resource requester based on the container information; creates a container on the target server based on the container information, and loads the resource image corresponding to the resource request into the container; after the resource image is loaded, allocates resources to the resource requester to complete resource scheduling; this improves the efficiency and reliability of resource scheduling, thereby increasing resource utilization and enhancing the overall performance of the system. Attached Figure Description

[0038] To more clearly illustrate the technical features of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart illustrating an embodiment of a containerized resource scheduling method provided by the present invention.

[0040] Figure 2 This is a schematic diagram of an embodiment of a containerized resource scheduling device provided by the present invention;

[0041] Figure 3 This is a schematic diagram of the structure of one embodiment of an electronic device provided by the present invention. Detailed Implementation

[0042] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0043] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0045] Firstly, embodiments of the present invention provide a containerized resource scheduling method, see [link to previous document]. Figure 1 This is a flowchart illustrating an embodiment of a containerized resource scheduling method provided by the present invention.

[0046] like Figure 1 As shown, the method includes the following steps:

[0047] S1: Receive and parse the resource request sent by the resource requester to obtain the parsed content;

[0048] S2: Verify the parsed content. When the verification is successful, add the parsed content to a pre-built scheduling queue with containers as the basic unit.

[0049] S3: Obtain the container information of the container from the scheduling queue in sequence according to the specified scheduling method, and allocate a target server to the resource requester based on the container information;

[0050] S4: Based on the container information, create a container in the target server and load the resource image corresponding to the resource request into the container;

[0051] S5: After the resource image is loaded, resources are allocated to the resource requester to complete resource scheduling.

[0052] In practice, the resource requester sends a resource request to the system. This request is made by writing a YAML file. The YAML file contains key information such as the framework to be requested and its combination, the type and size of the resources to be requested, the images to be loaded, service configuration, deployment order, number and status of replicas, etc. After the user writes the YAML file, they submit it to the system. The system parses the file and verifies the parsed content. This may include checking the format of the YAML file, the rationality of the resource request, the existence and accessibility of the images, and the correctness of the service configuration. Once the verification is successful, the system adds the resource request to a pre-built scheduling queue based on the information described in the YAML file, using containers as the basic unit. The system then retrieves container information from the scheduling queue sequentially according to the specified scheduling method and allocates appropriate server resources to each container based on the information. The scheduling method can be a first-come, first-served approach, and no specific limitation is made here.

[0053] After a target server is matched, a container is created on the target server, and the resource image specified in the resource request is loaded from the image repository. After loading is complete, the required resources are allocated to the container, and the allocated resources are ensured to meet the needs of the application or service inside the container. At this point, the resource scheduling process has been successfully completed, and the resource requester can access and use the requested container and resources through the interface or tools provided by the system.

[0054] In summary, this invention receives and parses resource request requests sent by resource requesters to obtain parsed content; verifies the parsed content, and when verification is successful, adds the parsed content to a pre-built scheduling queue with containers as the basic unit; sequentially retrieves container information from the scheduling queue according to a specified scheduling method, and allocates a target server to the resource requester based on the container information; creates a container on the target server based on the container information, and loads the resource image corresponding to the resource request into the container; after the resource image is loaded, allocates resources to the resource requester to complete resource scheduling; effectively allocates and manages container resources for resource requesters, ensuring effective resource utilization and stable service operation, improving the efficiency and reliability of resource scheduling, thereby increasing resource utilization and enhancing the overall performance of the system. Containerization technology allows each container to run its own application or service independently without being affected by other containers, making resource scheduling more flexible and efficient.

[0055] In one optional implementation, the resource request includes, but is not limited to, the type of framework to be requested, the type of resource to be requested, the size of the resource to be requested, and the framework deployment order.

[0056] Specifically, resource request requests include, but are not limited to, the type of framework to be requested, the type of resource to be requested, the size of the resource to be requested, and the framework deployment order. Among them, the type of framework to be requested is used to specify the type of framework the user wants to request, including storage frameworks, computing frameworks, and development frameworks. Storage frameworks provide mechanisms for data storage, management, and access, and can be selected from distributed storage systems such as HDFS. Computing frameworks provide computing capabilities for data processing and analysis, and can be selected from data processing frameworks such as Flink. Development frameworks are the user's window to the system. Users can perform various operations and interact with the system's functions and data through the interface provided by the development framework.

[0057] Furthermore, the resource type and size to be requested are used to specify the types and capacity of resources required by the user. Resource types can include various resources such as CPU, memory, disk, image, service, replica, role, rule, and tag. All resources need to be uniformly named. Among them, CPU can specify the number of CPU cores required according to the needs; memory can specify the required memory size in GB; disk can specify the required disk capacity in GB and specify the disk type; image can specify the required framework image, such as Flink, Spark, HDFS, MinIO, etc., and can specify to use a specific version as the base image for easy version management; service can specify the external access port of the service to ensure that the service can be accessed externally; replica can define high availability and scalability, such as a three-replica configuration of one master and two slaves, or stateless replicas. When replicas are present, roles can be assigned to each replica to clarify its working attributes. Each replica can be defined with a role type, such as Master or Salve; rules can specify conditions such as alarms, restarts, or failures to automatically trigger corresponding response actions when the conditions are met; tags are used for scheduling and matching to ensure that resources are scheduled to servers that meet the requirements. The framework deployment order is used to specify the order in which resources are deployed. The order in which the framework is filled in represents the deployment order.

[0058] For example, a user can fill in an application for three types of resources: the storage framework HDFS, the computing framework Flink, and the development framework. Each resource runs in its own container. The computing framework Flink requests 16 CPU cores and 32GB of memory, while the storage framework HDFS requests 8 cores, 16GB of memory, and 100GB of disk space. The Master has one replica, and the Slave has three replicas. After parsing the resource application request, the system will create four containers for the HDFS framework. One container will serve as the Master, with resources of 8 cores, 16GB of memory, and 100GB of storage. The other three containers will serve as HDFS framework Slaves, each with resources of 8 cores, 16GB of memory, and 100GB of storage. The four containers will then be added to the scheduling queue.

[0059] In one optional implementation, after verifying the parsed content, the method further includes:

[0060] When verification fails, a parsing error message is generated and returned to the resource requester so that the resource requester can modify the resource request based on the parsing error message.

[0061] Specifically, when the parsing verification fails, it indicates that the user's resource request does not meet the system's requirements. The system will generate a parsing exception message, detailing the specific reasons for the failure, such as the requested CPU core count exceeding system limits or memory size not meeting regulations. This message is then returned to the resource requester, who can modify the request based on the reasons provided and resubmit it for parsing and verification until it passes. By introducing a verification process and a mechanism for handling verification failures, the system ensures that user-submitted resource requests are reasonable and feasible, effectively avoiding resource waste and system conflicts.

[0062] In one optional implementation, allocating a target server to the resource requester based on the container information includes:

[0063] Obtain the resource usage status of all resources in each server node, and determine the available resources based on the resource usage status; wherein, the resource usage status includes resource utilization status and resource health status;

[0064] Based on the container information, the available resources are traversed, and a server node that meets the resource request requirements is selected as the target server for the resource requester.

[0065] Specifically, the system obtains the resource usage information of all resources periodically reported by each server node, including resource utilization status and resource health status, such as the quantity of each resource, load status, and whether any anomalies have occurred. Based on the resource usage information, the system evaluates the resources of each server node to determine which resources are available. According to the resource specifications requested in the container information, the system selects server nodes that meet the resource request requirements from among the various server nodes as the target servers for the resource requester.

[0066] In an optional implementation, the step of allocating a target server to the resource requester based on the container information further includes:

[0067] When the container information contains tagged resources, server nodes with the same tags are preferentially matched as the target server for the resource requester.

[0068] Specifically, when a container uses tagged resources, server nodes are first filtered based on the tags marked on the container. Only server nodes with the corresponding tags are considered. Among the server nodes filtered by tag matching, the current resource usage of each node is further checked based on the container's resource request. Nodes that meet the resource request are scheduled, while nodes that do not meet the resource request are placed in a priority waiting queue for subsequent container scheduling. For example, if a container is tagged with server1, only server nodes of server1 will be matched. If there are no relevant nodes, the system will wait. When the wait exceeds the preset timeout, the system will send an error message to the resource requester, informing them that there are currently no available server nodes to run the container.

[0069] In one optional implementation, loading the resource image corresponding to the resource request in the container includes:

[0070] The type of framework to be requested is determined based on the resource request request;

[0071] Obtain the framework image corresponding to the framework type to be applied for from the image repository, and store the framework image in the local image library; wherein, the framework type to be applied for includes storage framework, computing framework and development framework;

[0072] The framework image is loaded and started in the container.

[0073] Specifically, based on the resource request, the system determines the type of framework the user wants to apply for, retrieves the corresponding framework image from the image repository, downloads the retrieved framework image to the local image library, loads it into the specified container, starts the framework image in the container, and provides a unified interface to the outside world after the image starts. The interface is bound to the container itself, enabling the outside world to access the services inside the container.

[0074] When a user specifies a computing framework to apply for, they need to configure storage service information. The computation results of the computing service will be stored in the storage service. There are several types of computing services, such as real-time streaming read, real-time streaming write, and real-time streaming incremental computation. Each type needs to interface with the storage service. For example, after the Flink image starts, there are two types of services: Master role (JobManager) and Slave role (TaskManager). The JobManager is responsible for coordinating the execution of the entire Flink application, managing task scheduling, resource allocation, and fault recovery. The TaskManager is the worker node that actually executes the computing tasks. It receives computing tasks from the JobManager, executes them according to the defined computing logic, and writes the results to the storage service after execution. The TaskManager can be configured with multiple replicas, and multiple replicas working simultaneously can improve processing efficiency and fault tolerance.

[0075] For example, when executing a real-time streaming computation task, Flink first reads streaming data from the data source in real time. The data is partitioned and sent to different TaskManagers for processing. After receiving the data, the TaskManager performs pipeline computation according to the operators defined by the JobManager. An operator is the basic unit in Flink that executes specific computational logic. A SQL statement is split into multiple operators. There may be dependencies between operators. Flink determines the execution order of operators based on these dependencies. For operators without dependencies, Flink will try to execute them in parallel to improve processing efficiency. After the computation is completed, the computation result data needs to be written to the storage service.

[0076] When a user requests a development framework, the computing framework is usually loaded first. If a computing framework already exists, the existing computing service can be used. When loading the development framework, computing service information needs to be configured. After the development service starts, the system will automatically identify the relevant computing services during user operation. For example, if Flink and Spark computing service information is configured, the system will display the corresponding SQL service options in the user interface after starting the development framework service. Users can switch between multiple computing services, selecting the appropriate service for SQL development. After completing the SQL development, the user submits the operation, and the system receives the SQL statement and adapts it according to the computing service selected by the user. The computing module creates a computing job based on the received SQL statement, subdivides the computing job into multiple subtasks, and distributes the subdivided tasks to the corresponding computing services. Multiple tasks are executed in parallel. After the system submits the job, it returns the relevant link or ID of the job. Users can view the execution status of the job through the link or ID, including whether it is successful, failed, or is in progress. If the job is running in the test environment, after confirming that the job is running normally in the test environment, a release application can be submitted through the production release process. The system triggers the approval process, and the relevant approvers approve the job. After approval, the system automatically submits the job to the production computing service, which receives the job and deploys and runs it.

[0077] It should be noted that the development framework serves as the user's window into the system, reducing development and coordination costs and improving work efficiency. Users are divided into regular users and super administrators. Regular users can only view their own interface and access authorized data and data from their department. Other data can only be obtained through authorization requests. Unauthorized operations will trigger alert messages. Super administrators have the highest privileges in the entire system, can view and manage the interface of the entire department, and have the authority to manage users, including adding users, deleting users, revoking user applications, and granting authorizations. Different departments or roles can customize different interface views to meet specific needs.

[0078] For example, ordinary users can use the interface to develop and model data, forming the final business data table. Modeling methods support various approaches such as multi-table merging, dimension association, deduplication, and incremental calculation. The developed data model can be tested in a test environment. After passing the test, it can be submitted to the production environment for one-click deployment. Ordinary users can also use the interface for data transmission and processing services, supporting the construction of the entire pipeline transmission path from data source to destination, including data source selection, data processing (such as finding maximum and average values), and data storage. Users can monitor the running status of the entire processing chain, including streaming and batch jobs. Through lineage tools, users can view the upstream and downstream relationships of data to ensure their correctness. Lineage tools extract data source and destination information by parsing user SQL statements and constructing lineage relationships. The system provides a clear hierarchical modeling structure, resolving the confusion caused by excessive layers and tables. For non-SQL processing tasks, an HTTP interface is provided for integration. The development framework already includes HTTP interface integration functionality, which users can access through page clicks. For functions not provided by the development framework and non-SQL functions, users need to implement the HTTP interface integration themselves. For example, in the development framework, when a user needs to upload their own implemented functions and wants these functions to be integrated into the framework's lineage tracing, they need to integrate through the HTTP interface. The interface mainly uses the POST method to send relevant information about the custom function (such as request ID, job name, input data source table name, input data source fields and types, output data table name, output data fields and types, etc.) to the framework's interface. After receiving this information, the framework will incorporate it into the lineage tracing system.

[0079] In an optional implementation, the method further includes:

[0080] Monitor the container's entire lifecycle status and obtain the container's runtime logs;

[0081] When an anomaly is detected in a container, a container anomaly alarm is generated based on the operation log, and the container anomaly alarm is returned to the resource requester so that the resource requester can handle the anomaly; wherein, the anomaly includes, but is not limited to, image loading anomaly, resource utilization anomaly, network anomaly, job execution anomaly, and database anomaly.

[0082] Specifically, the system monitors containers throughout their entire lifecycle, including creation, startup, running, and exit. It periodically retrieves runtime logs generated during container operation and sends them to a unified time-series database for unified storage and management based on time. A time-series database is a database system used to ingest, process, and store timestamped data. The log monitoring system typically provides a unified regular expression pattern for matching and monitoring specific log content. It uses a dedicated storage module to store log data and builds an inverted index when writing logs. This inverted index uses words in the document content as index items and the document IDs containing those words as records. Through the inverted index, the system can quickly find all log entries containing specific words or phrases, facilitating rapid querying and retrieval of log data for users.

[0083] When an anomaly is detected in a container, an alert will be issued on a container-by-container basis. Based on the acquired runtime logs, a deep localization process will be performed to generate corresponding container anomaly alert information. For example, if an image pull anomaly occurs during container creation, an image pull anomaly message will be generated. Upon receiving this message, the scheduler or related components will attempt to pull the image multiple times according to the configured strategy. The number of attempts and the interval can be adjusted according to actual needs. If the image cannot be successfully pulled after reaching the specified number of attempts, the scheduler or related components will consider the container abnormal and trigger the resource reclamation process. If an out-of-memory (OOM) exception occurs during container runtime, an OOM (Out of Memory) alert will be generated. Upon receiving an OutOfMemory (OOM) exception, the scheduler or related components will attempt to reschedule the container and restart it on an available node. If a container experiences multiple OutOfMemory errors, the scheduling module may deem the container misconfigured or the application defective and trigger a resource reclamation process, causing the container to exit the system. The container management platform periodically collects container resource usage data to monitor the container's health. Users can view container usage through the platform's interface or API. If memory is about to reach its limit or an exception occurs, the container's resource configuration can be flexibly adjusted by modifying resource templates to meet operational requirements.

[0084] It should be noted that if a container becomes a ghost container, meaning it cannot exit normally due to some anomaly exceeding a set fixed threshold (such as runtime, resource consumption, etc.), the container management platform's management process will forcibly reclaim the container and clear its occupied resources to ensure the normal operation of the system's lifecycle. Appropriate health check strategies can be formulated within the container, such as periodically accessing interfaces and executing SQL statements to monitor its own health status. If health checks fail multiple times, the container will automatically trigger an abnormal state and generate alarm information. The alarm information can be sent to the administrator or user so that they can take timely measures to resolve the problem.

[0085] By monitoring containers, this invention can effectively handle various abnormal situations, ensure the stable operation of containers and the rational utilization of resources, and help users to discover and solve problems in a timely manner. As the basic unit of resource scheduling and monitoring and management, containers make resource scheduling more flexible, efficient and scalable, and also provide strong support for system monitoring and management.

[0086] Secondly, embodiments of the present invention provide a containerized resource scheduling device, see [link to relevant documentation]. Figure 2 This is a schematic diagram of an embodiment of a containerized resource scheduling device provided by the present invention.

[0087] like Figure 2 As shown, the device includes:

[0088] The request receiving module 21 is used to receive and parse the resource request sent by the resource requester to obtain the parsed content;

[0089] The parsing and verification module 22 is used to verify the parsed content. When the verification is successful, the parsed content is added to a pre-built scheduling queue with containers as the basic unit.

[0090] Server allocation module 23 is used to sequentially obtain the container information of the container from the scheduling queue according to the specified scheduling method, and allocate a target server to the resource applicant according to the container information;

[0091] Image loading module 24 is used to create a container in the target server based on the container information, and load the resource image corresponding to the resource request in the container;

[0092] The resource scheduling module 25 is used to allocate resources to the resource requester after the resource image is loaded, so as to complete the resource scheduling.

[0093] In one optional implementation, the resource request includes, but is not limited to, the type of framework to be requested, the type of resource to be requested, the size of the resource to be requested, and the framework deployment order.

[0094] In an optional implementation, the parsing and verification module 22 is further configured to:

[0095] When verification fails, a parsing error message is generated and returned to the resource requester so that the resource requester can modify the resource request based on the parsing error message.

[0096] In an optional implementation, the server allocation module 23 is further configured to:

[0097] Obtain the resource usage status of all resources in each server node, and determine the available resources based on the resource usage status; wherein, the resource usage status includes resource utilization status and resource health status;

[0098] Based on the container information, the available resources are traversed, and a server node that meets the resource request requirements is selected as the target server for the resource requester.

[0099] In an optional implementation, the server allocation module 23 is further configured to:

[0100] When the container information contains tagged resources, server nodes with the same tags are preferentially matched as the target server for the resource requester.

[0101] In an optional implementation, the image loading module 24 is further configured to:

[0102] The type of framework to be requested is determined based on the resource request request;

[0103] Obtain the framework image corresponding to the framework type to be applied for from the image repository, and store the framework image in the local image library; wherein, the framework type to be applied for includes storage framework, computing framework and development framework;

[0104] The framework image is loaded and started in the container.

[0105] In one alternative embodiment, the apparatus further includes a container monitoring module for:

[0106] Monitor the container's entire lifecycle status and obtain the container's runtime logs;

[0107] When an anomaly is detected in a container, a container anomaly alarm is generated based on the operation log, and the container anomaly alarm is returned to the resource requester so that the resource requester can handle the anomaly; wherein, the anomaly includes, but is not limited to, image loading anomaly, resource utilization anomaly, network anomaly, job execution anomaly, and database anomaly.

[0108] Thirdly, embodiments of the present invention provide an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-mentioned container-based resource scheduling method. The electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0109] like Figure 3 As shown, Figure 3 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0110] The processor 301 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0111] The memory 302 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 302 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 302 and is called and executed by the processor 301 using the containerized resource scheduling method of the embodiments of this application.

[0112] Input / output interface 303 is used to implement information input and output;

[0113] The communication interface 304 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0114] Bus 305 transmits information between various components of the device (e.g., processor 301, memory 302, input / output interface 303, and communication interface 304);

[0115] The processor 301, memory 302, input / output interface 303, and communication interface 304 are connected to each other within the device via bus 305.

[0116] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed, implements the containerized resource scheduling method described in any of the above embodiments.

[0117] It should be understood that the implementation of all or part of the processes in the containerized resource scheduling method described above can also be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the containerized resource scheduling method described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0118] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. It should be noted that, for those skilled in the art, several equivalent obvious modifications and / or equivalent substitutions can be made without departing from the technical principles of the present invention, and these obvious modifications and / or equivalent substitutions should also be considered within the scope of protection of the present invention.

Claims

1. A containerized resource scheduling method, characterized in that, include: Receive and parse the resource request sent by the resource requester to obtain the parsed content; The parsed content is verified, and when the verification is successful, the parsed content is added to a pre-built scheduling queue with containers as the basic unit. The container information of the container is obtained sequentially from the scheduling queue according to the specified scheduling method, and a target server is allocated to the resource requester based on the container information; Based on the container information, a container is created in the target server, and the resource image corresponding to the resource request is loaded into the container; After the resource image is loaded, resources are allocated to the resource requester to complete resource scheduling.

2. The containerized resource scheduling method as described in claim 1, characterized in that, The resource request includes, but is not limited to, the type of framework to be requested, the type of resource to be requested, the size of the resource to be requested, and the deployment order of the framework.

3. The containerized resource scheduling method as described in claim 1, characterized in that, After verifying the parsed content, the process also includes: When verification fails, a parsing error message is generated and returned to the resource requester so that the resource requester can modify the resource request based on the parsing error message.

4. The containerized resource scheduling method as described in claim 1, characterized in that, The step of allocating a target server to the resource requester based on the container information includes: Obtain the resource usage status of all resources in each server node, and determine the available resources based on the resource usage status; wherein, the resource usage status includes resource utilization status and resource health status; Based on the container information, the available resources are traversed, and a server node that meets the resource request requirements is selected as the target server for the resource requester.

5. The containerized resource scheduling method as described in claim 1, characterized in that, The step of allocating a target server to the resource requester based on the container information further includes: When the container information contains tagged resources, server nodes with the same tags are preferentially matched as the target server for the resource requester.

6. The containerized resource scheduling method as described in claim 2, characterized in that, Loading the resource image corresponding to the resource request in the container includes: The type of framework to be requested is determined based on the resource request request; Obtain the framework image corresponding to the framework type to be applied for from the image repository, and store the framework image in the local image library; wherein, the framework type to be applied for includes storage framework, computing framework and development framework; The framework image is loaded and started in the container.

7. The containerized resource scheduling method as described in claim 1, characterized in that, The method further includes: Monitor the container's entire lifecycle status and obtain the container's runtime logs; When an anomaly is detected in a container, a container anomaly alarm is generated based on the operation log, and the container anomaly alarm is returned to the resource requester so that the resource requester can handle the anomaly; wherein, the anomaly includes, but is not limited to, image loading anomaly, resource utilization anomaly, network anomaly, job execution anomaly, and database anomaly.

8. A containerized resource scheduling device, characterized in that, include: The request receiving module is used to receive and parse the resource request sent by the resource requester to obtain the parsed content; The parsing and verification module is used to verify the parsed content. When the verification is successful, the parsed content is added to a pre-built scheduling queue with containers as the basic unit. The server allocation module is used to sequentially obtain the container information of the container from the scheduling queue according to the specified scheduling method, and allocate a target server to the resource requester based on the container information. The image loading module is used to create a container in the target server based on the container information, and load the resource image corresponding to the resource request into the container; The resource scheduling module is used to allocate resources to the resource requester after the resource image is loaded, so as to complete the resource scheduling.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program; Wherein, when the processor executes the computer program, it implements the containerized resource scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the containerized resource scheduling method as described in any one of claims 1 to 7.

Images