Method and device for deploying container to node in cluster

Abstract

The invention relates to the technical field of computer operating systems, in particular to a method and device for deploying a container to a node in a cluster, computing equipment and a computer readable storage medium. The method comprises the steps that to-be-deployed containers are ranked through a queue, a first container located at the first position in the queue is obtained, and the priority of to-be-deployed real-time containers in the queue is higher than that of to-be-deployed non-real-time containers; obtaining resource information of each node in a cluster, and screening out at least one node meeting the requirements of the first container as a candidate node according to the resource information; and selecting the node with the minimum load as a target node according to the resource information of each candidate node, and deploying the first container into the target node. In the embodiment of the invention, by introducing a scheduling strategy of real-time and non-real-time container queue sorting, deployment of real-time and non-real-time containers on a cluster level is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of computer operating systems, and in particular to a method, apparatus, computing device, and computer-readable storage medium for deploying a container to a node in a cluster. Background Art

[0002] Real-time containers are containers that run on real-time operating systems (RTOSs). They must meet strict real-time requirements to ensure that tasks are processed promptly within specific time intervals. Compared to non-real-time containers, real-time containers require higher reliability and predictability.

[0003] Although real-time containers have different requirements than non-real-time containers, existing container scheduling platforms primarily focus on the management and scheduling of non-real-time containers. However, with the rapid development of fields such as the Internet of Things, industrial automation, and edge computing, each node may contain both real-time and non-real-time containers. At the cluster level, composed of heterogeneous and diverse large, medium, and small devices, it is difficult to uniformly schedule containerized resources for both real-time and non-real-time operating systems.

[0004] In order to meet the needs of real-time containers, a scheduling management solution is needed that can uniformly manage real-time containers and non-real-time containers based on real-time operating systems. Summary of the Invention

[0005] In view of the above problems in the prior art, the present application provides a method, apparatus, computing device and computer-readable storage medium for deploying containers to nodes in a cluster, which can achieve unified scheduling and management of real-time and non-real-time containers at the cluster level.

[0006] To achieve the above objectives, the present application provides, in a first aspect, a method for deploying a container to a node in a cluster, comprising:

[0007] Sort the containers to be deployed by queue, and obtain a first container at the top of the queue, wherein the real-time container to be deployed in the queue has a higher priority than the non-real-time container to be deployed;

[0008] Obtain resource information of each node in the cluster, and select at least one node that meets the requirements of the first container as a candidate node based on the status;

[0009] A node with the least load is selected as a target node according to the resource information of each candidate node, and the first container is deployed to the target node.

[0010] This implementation introduces a container queue sorting strategy to prioritize containers for deployment based on real-time and non-real-time priorities, prioritizing the real-time container at the top of the queue. This ensures that real-time tasks are processed promptly within a specific time interval. Furthermore, by obtaining resource information from each node in the cluster and selecting candidate nodes that meet the requirements of the first container, the least loaded node is selected as the target node based on the candidate node's resource information. This improves resource utilization and system performance, achieving unified deployment and orchestration of real-time and non-real-time containers at the cluster level.

[0011] As a possible implementation of the first aspect, the resource information of the node includes at least one of the following:

[0012] The node's label indicating whether a real-time container can be deployed;

[0013] The hardware resource status of the node;

[0014] The load status of the node during runtime.

[0015] In this implementation, node labels are configured to identify nodes suitable for deploying real-time containers, thereby improving the deployment efficiency and performance of real-time containers. By monitoring the hardware resource status of nodes, it is possible to avoid deploying real-time containers on resource-constrained nodes, thereby ensuring that real-time containers have sufficient resources. Monitoring the node load status can help the scheduler select nodes with lower loads for deploying real-time containers, avoiding performance degradation caused by deploying real-time containers on overloaded nodes.

[0016] As a possible implementation of the first aspect, when the first container is a real-time container to be deployed, determining the target node includes:

[0017] Filtering, from each node in the obtained cluster, nodes having a label indicating that a real-time container can be deployed and whose hardware resource status meets the requirements for deploying the first container as candidate nodes;

[0018] A candidate node with the smallest load status among the candidate nodes is selected as the target node.

[0019] This implementation selects nodes with the real-time container deployable label and satisfying hardware resource status requirements as candidate nodes. This allows for rapid identification of suitable nodes for real-time container deployment, avoiding deployment attempts on unsuitable nodes and improving deployment efficiency. Selecting the node with the lowest load among the candidate nodes as the target node ensures that the real-time container is deployed on a less-loaded node, avoiding performance degradation or failure of the real-time container due to excessive node load, thereby ensuring the performance and stability of the real-time container.

[0020] As a possible implementation of the first aspect, when the first container is a non-real-time container to be deployed, deploying the first container to the target node includes:

[0021] Filtering, from the obtained nodes in the cluster, nodes that have a label indicating that a non-real-time container can be deployed and whose hardware resource status meets the requirements for deploying the first container as candidate nodes;

[0022] A candidate node with the smallest load status among the candidate nodes is selected as the target node.

[0023] As a possible implementation of the first aspect, when selecting, from the nodes in the acquired cluster, nodes having a label indicating that a non-real-time container can be deployed and whose hardware resource status meets requirements for deploying the first container, the method further includes:

[0024] Filtering nodes in the obtained cluster that have a label indicating that a real-time container can be deployed, and selecting nodes whose hardware resource status meets the requirements for deploying the first container as candidate nodes;

[0025] A candidate node with the smallest load status among the candidate nodes is selected as the target node.

[0026] A second aspect of the present application provides an apparatus for deploying a container to a node in a cluster, comprising:

[0027] a container queue sorting module, configured to sort containers to be deployed by queue and obtain a first container at the top of the queue, wherein a real-time container to be deployed in the queue has a higher priority than a non-real-time container to be deployed;

[0028] A node screening module, configured to screen out at least one node that meets the requirements of the first container as a candidate node based on resource information of each node in the cluster;

[0029] A container deployment module is configured to select a node with the least load as a target node based on the resource information of each candidate node, and deploy the first container to the target node.

[0030] The third aspect of the present application provides a cluster architecture, including:

[0031] Management units and the nodes that make up the cluster;

[0032] The management unit is used to execute the method for deploying containers to nodes in a cluster as described above.

[0033] As a possible implementation of the third aspect, the nodes of the cluster include one or more real-time nodes deployed with a real-time operating system, and the real-time nodes are provided with a pre-configured kubelet in each node constituting the cluster. The pre-configured kubelet is used to interact with the scheduler of the real-time operating system, configure the scheduling parameters of the real-time container process, and perform real-time container deployment.

[0034] A fourth aspect of the present application provides a computing device, including:

[0035] processor, and

[0036] A memory stores program instructions thereon, which, when executed by the processor, cause the processor to execute the method for deploying containers to nodes in a cluster as described above.

[0037] In a fifth aspect, the present application provides a computer-readable storage medium having program instructions stored thereon. When the program instructions are executed by a computer, the computer executes the method for deploying containers to nodes in a cluster as described above.

[0038] These and other aspects of the invention will be apparent from and elucidated with reference to the following description of the embodiment(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The following further illustrates the various features of the present invention and the relationships between the various features with reference to the accompanying drawings. The accompanying drawings are all exemplary, and some features are not shown in actual proportion. In addition, some drawings may omit features that are customary in the field to which this application relates and are not necessary for this application, or additional features that are not necessary for this application may be shown. The combination of the various features shown in the accompanying drawings is not intended to limit this application. In addition, throughout this specification, the same reference numerals refer to the same content. The specific description of the drawings is as follows:

[0040] Figure 1 This is a diagram of the kubernetes cluster architecture;

[0041] Figure 2 This is a flowchart of a method for deploying a container to a node in a cluster provided by an embodiment of the present application;

[0042] Figure 3 This is a flowchart of a method for deploying a container to a node in a cluster provided by another embodiment of the present application;

[0043] Figure 4 This is a schematic diagram of the process for creating real-time Deployment resources provided by the application implementation method;

[0044] Figure 5It is a schematic diagram of the scheduling process provided by the application implementation method;

[0045] Figure 6 It is a structural diagram of an apparatus 300 for deploying a container to a node in a cluster provided by an embodiment of the application;

[0046] Figure 7 It is a structural diagram of a cluster architecture 400 provided in an embodiment of the application;

[0047] Figure 8 It is a structural schematic diagram of a computing device 900 provided in an embodiment of the application. DETAILED DESCRIPTION

[0048] The technical solution provided by this application is further described below with reference to the accompanying drawings and examples. It should be understood that the system structure and business scenarios provided in the examples of this application are mainly for illustrating possible implementation methods of the technical solution of this application and should not be interpreted as the sole limitation of the technical solution of this application. It is known to those skilled in the art that with the evolution of the system structure and the emergence of new business scenarios, the technical solution provided by this application is also applicable to similar technical problems.

[0049] It should be understood that the embodiments of the present application provide solutions for deploying containers to nodes in a cluster, including methods for deploying containers to nodes in a cluster and computer-readable storage media. Because these technical solutions solve the same or similar problems, some repetitions may not be repeated in the following descriptions of the specific embodiments. However, these specific embodiments should be considered to have been referenced and can be combined with each other.

[0050] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art in the art of this application. In the event of any inconsistency, the meaning described in this specification or the meaning derived from the contents recorded in this specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application and are not intended to limit this application.

[0051] In order to accurately describe the technical content of this application and to accurately understand this application, the following explanations or definitions are given for the terms used in this specification before describing the specific implementation methods.

[0052] 1) Kubernetes, also known as K8s, is an open source framework for managing containerized applications on multiple hosts in a cloud platform. Kubernetes can deploy applications by deploying containers. Each application can be packaged into a container image and deployed to a container on the target node. Figure 1The following diagram shows the Kubernetes cluster architecture, including the Master and Node Pool. The Master is responsible for managing and controlling the operation of the entire cluster.

[0053] The Master includes the following core components:

[0054] Kubectl: It is a command-line tool for Kubernetes. It provides the ability to manage and operate Kubernetes clusters and can be used to expand and shrink resources.

[0055] API Server: As the front-end interface of the Kubernetes cluster, all management operations are performed through the API Server. It is responsible for receiving and processing requests from users, the kubectl command-line tool, and other components, and converting them into internal operations.

[0056] ETCD (Distributed Key-Value Store): Used to store the status information of the Kubernetes cluster, including cluster configuration, node status, Pod configuration, etc. etcd provides high reliability and consistency and is widely used as a data storage for distributed systems.

[0057] Scheduler: Assigns pods to nodes in the cluster based on user-defined scheduling policies. The scheduler considers factors such as node resource availability, load balancing, affinity, and anti-affinity to determine the best node to run the pod.

[0058] Node Pool: A node pool can include multiple nodes, each of which is responsible for running containerized applications. A node includes the following key components:

[0059] Networking: The node's networking component handles network communication between containers and nodes. It provides network isolation between containers, network address allocation, network policies, and service discovery.

[0060] Kubelet: Kubelet is a Kubernetes component that runs on each node and is responsible for managing containers and pods on the node. Kubelet communicates with the API server, receives instructions from the control plane, and ensures the correct operation and maintenance of pod status on the node. It is also responsible for monitoring and reporting on the health of pods.

[0061] Container Runtime: A container runtime is the software that runs and manages containers on a node. It is responsible for parsing and executing container images, creating and managing the container lifecycle, including starting, stopping, monitoring, and resource limiting. Common container runtimes include Docker, containerd, and CRI-O.

[0062] Operating System (OS): The operating system on a node provides the infrastructure necessary to run containers and Kubernetes components. Kubernetes runs on a variety of operating systems, including Linux (such as Ubuntu and CentOS) and Windows Server. The OS provides low-level resource management, process isolation, file system, and network support.

[0063] Hardware: A node's hardware includes infrastructure resources such as CPU, memory, storage, and networking. These hardware resources are managed and allocated by Kubernetes to ensure that pods and containers receive the resources they need on demand. The performance and scale of the hardware determine the capacity and scalability of the node.

[0064] Currently, existing container scheduling platforms on the market are mainly aimed at unified lifecycle management and scheduling of non-real-time operating systems and the non-real-time containers (containerd) they carry. They cannot achieve unified management of real-time containers based on real-time operating systems (RTOS) and unified deployment of non-real-time containers based on non-real-time operating systems.

[0065] This application is based on the Kubernetes cluster architecture. By expanding the Scheduler component and redeveloping the kubelet, the kubelet is modified to adapt to the scheduler interface of the real-time operating system, enabling the kubelet to deploy real-time containers, thereby realizing the scheduling and deployment of real-time and non-real-time containers at the cluster level.

[0066] Figure 2 The embodiment of the present application provides a flow chart of a method for deploying a container to a node in a cluster. Figure 2 The method for deploying a container to a node in a cluster provided by this embodiment includes the following steps:

[0067] S101: Containers to be deployed are sorted by queue. A real-time container to be deployed in the queue has a higher priority than a non-real-time container to be deployed.

[0068] Retrieve the first container at the top of the queue. Real-time containers in the queue have a higher priority than non-real-time containers. Specifically, the modified kubelet, based on the scheduler interface adapted to the real-time operating system, has the ability to deploy real-time containers, ensuring consistent scheduling decisions on nodes. This allows real-time containers to be deployed to the cluster, enabling cluster-level scheduling and deployment of both real-time and non-real-time containers.

[0069] By introducing a container queue sorting strategy, the containers to be deployed are sorted according to real-time containers and non-real-time priorities, and the real-time container at the top of the queue is deployed first. This ensures that real-time tasks are processed in a timely manner within a specific time interval.

[0070] S102: Filter out candidate nodes based on the resource information of the nodes.

[0071] Resource information of each node in the cluster is obtained, and at least one node that meets the requirements of the first container is selected as a candidate node based on the status.

[0072] Specifically, the resource information of a node may include: a label indicating whether a real-time container can be deployed; the hardware resource status of the node, etc.

[0073] By obtaining resource information for each node in the cluster, you can understand each node's hardware resource usage, load status, and operational status, enabling you to make appropriate node selections. By configuring node labels, you can identify nodes suitable for deploying real-time containers, thereby meeting real-time container deployment requirements and avoiding deploying real-time containers on unsuitable nodes. By screening node status, you can quickly identify nodes suitable for real-time container deployment, improving deployment efficiency and success rates. Furthermore, ensuring that real-time containers are deployed on nodes with sufficient hardware resources and meeting requirements ensures container feasibility and stability.

[0074] S103: Select a node with the least load as a target node according to resource information of each candidate node, and deploy the first container to the target node.

[0075] Based on the resource information of each candidate node, the node with the least load is selected as the target node, and the first container is deployed to the target node, thereby achieving node load balancing, avoiding excessive node load leading to container performance degradation or failure, and improving the performance and stability of the overall system.

[0076] In order to ensure the real-time performance of real-time tasks, real-time containers are deployed first. When a real-time system node exists in the target node and the resources of the node meet the deployment requirements, a corresponding non-real-time container is created and deployed on the real-time node.

[0077] In some implementations, if a real-time system node exists among the target nodes and its resources meet deployment requirements, the node needs to be tested before deployment to avoid impacting the real-time performance of the node after the real-time container is scheduled to the node. If the test passes, deployment is performed on the real-time node.

[0078] In some embodiments, when the deployed container type is a non-real-time container, a node that meets the creation conditions is determined and a corresponding non-real-time container is created. That is, if a non-real-time operating system node exists and the node's resources meet the deployment conditions, the corresponding non-real-time container is created at the node.

[0079] In some implementations, if the deployed container type is a non-real-time container and a non-real-time system node does not exist or exists but has insufficient resources, a real-time node with sufficient resources is searched for under the real-time operating system node to create the corresponding non-real-time container. Because deployment is performed on a real-time node, the node must be tested before deployment to prevent the real-time performance of the real-time node from being affected by scheduling the non-real-time container there.

[0080] The following is a further introduction to the embodiment of the method of deploying containers to nodes in a cluster provided by this application in conjunction with a specific implementation method. Figures 3 to 5 , Figure 3 This is a flowchart of a method for deploying a container to a node in a cluster provided by an embodiment of the present application; Figure 4 This is a schematic diagram of the process of creating a real-time Deployment resource provided by an embodiment of the present application; Figure 5 It is a schematic diagram of the scheduling process provided by the implementation method of this application.

[0081] This implementation uses the example of creating a real-time Deployment resource and deploying it to a cluster.

[0082] S201: Pre-configure the node resource manager, kubelet, and scheduler.

[0083] A pre-configured node resource manager is applied to the real-time operating system, hereinafter referred to as RT-Node-Manager. It can read information related to container process interrupts, memory usage, CPU utilization, and the number of I / O requests per second from system file directories such as / proc and / cgroups, and report it to the master node at preset time intervals.

[0084] The pre-configured kubelet is a redeveloped version of the original kubelet, hereafter referred to as the RT kubelet, adapted to the RTOS scheduler interface. For example, the RT kubelet can interact with the RT-Node-Manager in the RTOS to obtain information such as available resources and node load, and execute scheduling decisions made by the RT Scheduler on RTOS nodes (the RT Scheduler is the scheduler used to schedule real-time containers).

[0085] Pre-configuring the RT Scheduler may include developing an extension to the Scheduler component for final screening and determining the best node on which to deploy the container.

[0086] For example, configure the QueueSort extension to sort the queue of pods waiting to be scheduled, prioritize real-time container pods, and reduce real-time container latency. Configure the Filter extension to filter and select nodes based on the current container, filtering out nodes whose resource requirements do not meet the current pod's requirements and nodes that affect the stability of real-time containers on the node. Configure the Scoring extension to first sort nodes based on resource availability and then use data such as process interrupts, memory, and CPU utilization reported by the RT Node Manager to calculate the node with the lowest load as a candidate node.

[0087] S202: Create real-time Deployment resources.

[0088] like Figure 4 As shown, users configure Deployment identifiers, definitions, authentication information, and command parameters through the Kubernetes kubectl command line component. For example, defining a container identifier (metadata.labels.rtContainer) and assigning it a value of true indicates the deployment of real-time container resources. Furthermore, the real-time container's CPU runtime (metadata.annotations.rtCpu) and period (metadata.annotations.rtPeriod) can be defined and configured as input parameters for the CPU scheduler when deploying real-time containers.

[0089] kubectl sends the user's command-line request data to the API-Server component. The API-Server receives the request from kubectl and performs authentication and authorization checks. If authentication and authorization checks pass, the API-Server saves the Deployment definition and other data to ETCD, Kubernetes' distributed key-value store for persistent cluster state and configuration information. The API-Server returns the results of the Deployment creation to kubectl, including the Deployment's unique identifier and status information. kubectl then displays the results returned by the API-Server to the user, allowing them to understand the Deployment creation status.

[0090] After the API-Server saves the Deployment data to ETCD, the Deployment controller (the component used to manage and control Deployment resources) will monitor changes in Deployment resources in ETCD through the watch-list mechanism. When new Deployment resources are created or existing Deployment resources change, the Deployment controller will send a request to the API-Server to obtain information about other resources related to the Deployment, such as ReplicaSet (Deployment replica) and Pod. The API-Server will respond to the Deployment controller's request and return detailed information about the resources related to the Deployment. Based on the information returned by the API-Server, the Deployment controller monitors the status of ReplicaSet and Pod and creates Pods as needed.

[0091] In some implementations, when deploying a real-time operating system (RTOS) node to a cluster, users need to set the node's label to RTOS or another custom identifier when creating a real-time container resource, indicating that the node can deploy real-time containers. They also need to run the RT-Node-Manager program on the node and grant read permissions to system files to access data such as process interrupts, memory, and CPU utilization within the node. After this process, the RTOS node can be used as a candidate node after creating a real-time container.

[0092] S203: The RT Scheduler determines the candidate nodes.

[0093] After the Deployment controller creates a Pod, it sends the Pod's specification information and other data to the API-Server, which saves it to ETCD. The Scheduler monitors the creation of new Pods through ETCD's watch-list mechanism and then executes the scheduling process. The Scheduler will evaluate and select the node most suitable for running the Pod based on the resource status of the nodes in the cluster, the scheduling policy, and the scheduler configuration, taking into account the node's available resources (such as CPU and memory) and the node's load.

[0094] In this embodiment, when the RT Scheduler selects a suitable node, the required scheduling strategy can be implemented by configuring the Scheduler component extension to schedule the container to the appropriate node, such as Figure 5 Specifically, it may include:

[0095] First, when the RT Scheduler performs scheduling, it first obtains a queue-sorting-based scheduling strategy through the QueueSort extension. Specifically, the Pod queue waiting for scheduling is first sorted according to real-time containers and non-real-time containers. The real-time containers to be deployed in the queue have a higher priority than the non-real-time containers to be deployed. That is, the Pods of real-time containers are scheduled first, reducing the latency of real-time containers.

[0096] Then, through the Filter extension, different filtering and selection strategies are implemented based on whether the container is a real-time container or a non-real-time container. Nodes whose resource requirements do not meet the current Pod and nodes that affect the stability of real-time containers on the node are filtered out.

[0097] For example, when the container currently to be scheduled is a real-time container, the nodes of the real-time operating system with sufficient resources are screened out, and then the execution of the task is tested, such as checking the task's response time, latency, throughput and other indicators to check whether the task is completed on time and whether it meets the real-time requirements. If the above conditions are met, the node is selected as a candidate node.

[0098] In some embodiments, if the container currently being scheduled is a non-real-time container, if a non-real-time node with sufficient resources exists, that node is selected as a candidate node. If no non-real-time node with sufficient resources exists, a real-time node with sufficient resources is determined. Before scheduling, the node is tested to avoid impacting the real-time performance of the real-time node after the non-real-time container is scheduled to the real-time node. If the test passes, the real-time node is selected as a candidate node.

[0099] Finally, through the Scoring extension, the node resource conditions of the above candidate nodes are ranked, such as Figure 4As shown, the RT Node Manager program is used to read the system files of each candidate node to obtain system resource information, and report it to the API-Server through the RTkubelet. Finally, the RT Scheduler calculates the most suitable node as the target node for scheduling based on the process interruption, memory and CPU utilization data in the reported system resource information. The most suitable node may include the node with the smallest load and the node with the lowest latency, etc.

[0100] S204: Schedule and deploy the container to the target node.

[0101] like Figure 4 The following figure shows the execution process of the RT Scheduler component and the RT Kubelet. After the RT Scheduler selects the target node, it sends the scheduling decision to the API Server. The API Server updates the scheduling decision to the cluster's ETCD. After the RT Kubelet monitors the scheduling decision updates in ETCD through the watch list mechanism, it obtains the scheduling decision from the API Server and executes the corresponding operations to create and run the container on the target node. Simultaneously, the RT Kubelet obtains the node's operating data and node status information from the RT Node Manager within the node, and then reports it to the Master node through the API Server.

[0102] Please refer to Figure 6 , Figure 6 This is a structural diagram of an apparatus 300 for deploying a container to a node in a cluster provided in an embodiment of the present application. The apparatus can be implemented by a software system, a hardware device, or a combination of a software system and a hardware device.

[0103] The apparatus 300 for deploying a container to a node in a cluster includes a container queue sorting module 310 , a node screening module 320 , and a container deployment module 330 .

[0104] A container queue sorting module 310 is configured to sort the containers to be deployed by queue and obtain a first container at the top of the queue, wherein the priority of the real-time container to be deployed in the queue is higher than that of the non-real-time container to be deployed;

[0105] A node screening module 320 is configured to screen out at least one node that meets the requirements of the first container as a candidate node based on resource information of each node in the cluster;

[0106] In one embodiment, the node screening module 320 further includes:

[0107] The real-time node screening unit 321 is configured to, when determining that the first container is a real-time container to be deployed, screen out nodes from the obtained nodes in the cluster that have a label indicating that the real-time container can be deployed and whose hardware resource status meets the requirements for deploying the first container as candidate nodes.

[0108] The container deployment module 330 is configured to select a node with the least load as a target node according to the resource information of each candidate node, and deploy the first container to the target node.

[0109] The specific implementation of each functional module in this embodiment can be found in the introduction of the above method embodiment, and will not be described in detail in this embodiment.

[0110] Based on the same inventive concept, this application also provides a cluster architecture, please refer to Figure 7 , Figure 7 4 is a schematic diagram of a cluster architecture 400 provided in an embodiment of the present application, including:

[0111] A management unit 410 and each node constituting a cluster; wherein, in some embodiments, the nodes of the cluster include one or more real-time nodes deployed with a real-time operating system, and the real-time nodes are provided with a pre-configured kubelet, and the pre-configured kubelet is used to interact with the scheduler of the real-time operating system, configure the scheduling parameters of the real-time container process, and perform real-time container deployment.

[0112] The management unit is used to execute the method of deploying the container to the node in the cluster in steps S101 to S103 and its various optional implementations, which will not be described in detail.

[0113] Figure 8 900 is a schematic structural diagram of a computing device provided in an embodiment of the present application. The computing device can execute the various optional embodiments of the above-mentioned phase sequence optimization method for trunk traffic. The computing device can be a terminal, or a chip or chip system inside the terminal. Figure 8 As shown, the computing device 900 includes: a processor 910 , a memory 920 , and a communication interface 930 .

[0114] It should be understood that Figure 8 The communication interface 930 in the computing device 900 shown may be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0115] The processor 910 may be connected to a memory 920. The memory 920 may be used to store the program code and data. Therefore, the memory 920 may be a storage unit within the processor 910, an external storage unit independent of the processor 910, or a component including both a storage unit within the processor 910 and an external storage unit independent of the processor 910.

[0116] Optionally, the computing device 900 may further include a bus. The memory 920 and the communication interface 930 may be connected to the processor 910 via a bus. The bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 A line without an arrow is used to represent the bus, but this does not mean that there is only one bus or one type of bus.

[0117] It should be understood that in the embodiment of the present application, the processor 910 can adopt a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 910 adopts one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0118] The memory 920 may include a read-only memory and a random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include a non-volatile random access memory. For example, the processor 910 may also store information about the device type.

[0119] When the computing device 900 is running, the processor 910 executes the computer-executable instructions in the memory 920 to perform any operation step of the above method and any optional embodiment thereof.

[0120] It should be understood that the computing device 900 according to the embodiment of the present application can correspond to the corresponding subject in executing the method according to each embodiment of the present application, and the above-mentioned and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of each method of the present embodiment. For the sake of brevity, they will not be repeated here.

[0121] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or computer software, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. For example, the devices described in the above embodiments, or the units or modules contained in each device, can be implemented through processes or software modules, wherein the software modules can be units obtained by splitting according to functional logic. Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0123] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0124] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0125] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0126] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the program is used to execute the above method, which includes at least one of the solutions described in the above embodiments.

[0127] The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media.Computer-readable media can be computer-readable signal media or computer-readable storage media.Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or components, or any combination thereof.More specific examples (non-exhaustive list) of computer-readable storage media include: electrical connection with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination thereof.In this document, computer-readable storage media can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0128] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0129] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0130] The computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, and the programming language includes an object-oriented programming language - such as Java, Smalltalk, C++, and also includes a conventional procedural programming language - such as "C" language or similar programming language. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, using an Internet service provider to connect through the Internet). In addition, the words "first, second, third, etc." or module A, module B, module C and the like in the specification and claims are only used to distinguish similar objects and do not represent a specific order for the objects. It is understandable that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0131] In the above description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the steps can be interchanged or they can be executed simultaneously.

[0132] The term "comprising" as used in the specification and claims should not be construed as limiting to what is listed thereafter; it does not exclude other elements or steps. Thus, it should be interpreted as specifying the presence of the features, integers, steps, or components mentioned, but not excluding the presence or addition of one or more other features, integers, steps, or components, or groups thereof. Thus, the expression "a device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0133] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure.

[0134] Note that the above are only preferred embodiments of the present application and the technical principles employed. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments and may include many other equivalent embodiments without departing from the scope of protection of the present application, all of which fall within the scope of protection of the present application.

Claims

1. A method for deploying a container to a node in a cluster, characterized in that: include: Sort the containers to be deployed by queue, and obtain a first container at the top of the queue, wherein the real-time container to be deployed in the queue has a higher priority than the non-real-time container to be deployed; Obtain resource information of each node in the cluster, and select at least one node that meets the requirements of the first container as a candidate node based on the resource information; A node with the least load is selected as a target node according to the resource information of each candidate node, and the first container is deployed to the target node.

2. The method according to claim 1, characterized in that The resource information of the node includes at least one of the following: The node's label indicating whether a real-time container can be deployed; The hardware resource status of the node; The load status of the node during runtime.

3. The method according to claim 2, characterized in that When the first container is a real-time container to be deployed, determining the target node includes: Filtering, from each node in the obtained cluster, nodes having a label indicating that a real-time container can be deployed and whose hardware resource status meets the requirements for deploying the first container as candidate nodes; A candidate node with the smallest load status among the candidate nodes is selected as the target node.

4. The method according to claim 2, characterized in that When the first container is a non-real-time container to be deployed, deploying the first container to the target node includes: Filtering, from the obtained nodes in the cluster, nodes having a label indicating that a non-real-time container can be deployed and whose hardware resource status meets the requirements for deploying the first container as candidate nodes; A candidate node with the smallest load status among the candidate nodes is selected as the target node.

5. The method according to claim 4, characterized in that When no node having a label capable of deploying a non-real-time container and whose hardware resource status meets the requirements for deploying the first container can be screened out from the obtained nodes in the cluster, the method further includes: Filtering nodes with a label indicating that a real-time container can be deployed from among the nodes in the acquired cluster, and selecting nodes whose hardware resource status meets the requirements for deploying the first container as candidate nodes; A candidate node with the smallest load status among the candidate nodes is selected as the target node.

6. A device for deploying a container to a node in a cluster, characterized in that: include: a container queue sorting module, configured to sort containers to be deployed by queue and obtain a first container at the top of the queue, wherein a real-time container to be deployed in the queue has a higher priority than a non-real-time container to be deployed; A node screening module, configured to screen out at least one node that meets the requirements of the first container as a candidate node based on resource information of each node in the cluster; A container deployment module is configured to select a node with the least load as a target node based on the resource information of each candidate node, and deploy the first container to the target node.

7. A cluster architecture, characterized in that: include: Management units and the nodes that make up the cluster; The management unit is used to execute the method of deploying a container to a node in a cluster according to any one of claims 1 to 5.

8. The cluster architecture according to claim 7, characterized in that: The nodes of the cluster include one or more real-time nodes deployed with a real-time operating system. The real-time nodes are provided with a pre-configured kubelet. The kubelet is used to interact with the scheduler of the real-time operating system, configure the scheduling parameters of the real-time container process, and perform real-time container deployment.

9. A computing device, characterized in that include: A processor and a memory storing program instructions, wherein when the program instructions are executed by the processor, the processor executes the method for deploying a container to a node in a cluster according to any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that Program instructions are stored thereon, and when the program instructions are executed by a computer, the computer is caused to execute the method for deploying a container to a node in a cluster according to any one of claims 1 to 5.

Images