WO2021208546A1 - Kubernetes集群架构***下多维资源调度方法 - Google Patents

Kubernetes集群架构***下多维资源调度方法 Download PDF

Info

Publication number
WO2021208546A1
WO2021208546A1 PCT/CN2021/072398 CN2021072398W WO2021208546A1 WO 2021208546 A1 WO2021208546 A1 WO 2021208546A1 CN 2021072398 W CN2021072398 W CN 2021072398W WO 2021208546 A1 WO2021208546 A1 WO 2021208546A1
Authority
WO
WIPO (PCT)
Prior art keywords
pod
resource
server
node
server node
Prior art date
Application number
PCT/CN2021/072398
Other languages
English (en)
French (fr)
Inventor
张登银
朱琳
李俊江
刘子捷
艾成万
Original Assignee
南京邮电大学
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 南京邮电大学 filed Critical 南京邮电大学
Priority to US17/395,728 priority Critical patent/US11983562B2/en
Publication of WO2021208546A1 publication Critical patent/WO2021208546A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/285—Clustering or classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/505—Clust

Definitions

  • the present invention relates to the field of Internet communication technology, in particular to a multi-dimensional resource scheduling method under a Kubernetes cluster architecture system.
  • Kubernetes container Cluster management tools are mainly used to manage computationally intensive large-scale task applications in the cloud computing environment.
  • container resource requests are dynamically changing.
  • resources such as storage and network bandwidth in addition to CPU and memory.
  • the types are diverse Yes, the corresponding resource type is also a multi-dimensional resource type, but the static scheduling algorithm of Kubernetes has a single input parameter, and the analysis of resource occupancy is rough.
  • the present invention proposes a multi-dimensional resource scheduling method under the Kubernetes cluster architecture system, which can dynamically find the optimal assignment of work nodes for each task in the cloud system, and solves the problem that the input parameters of the current scheduling algorithm are single and cannot be satisfied.
  • the problem of the task's demand for the various resource types of the node is not limited to the above.
  • the present invention provides the following solutions:
  • Multi-dimensional resource scheduling methods under the Kubernetes cluster architecture system include:
  • the initiating Pod creation request specifically includes:
  • it also includes:
  • the Pod creation request needs to pass the authentication and pass to the Api Server of the cluster master node, and the Api Server creates the corresponding Pod.
  • it also includes:
  • All Pod creation information will be persistently stored in the distributed storage database etcd.
  • serializing the Pod scheduling task into an object and sending it to the scheduler includes:
  • ⁇ i represents the i-th priority index Pod scheduling tasks
  • D i denotes the i th deadline constraints Pod scheduled task
  • a i represents the commit time of the i th Pod scheduled tasks
  • CP i denotes the i th Pod The length of the critical path of the scheduled task.
  • the binding of the Pod scheduling task in the scheduler to the target server node for execution specifically includes:
  • the priority scoring for the server nodes that can be run includes:
  • the Pod scheduling task event is a computationally intensive service or a normal service. If it is a computationally intensive service, score each server node in the cluster according to resource availability; if it is a normal service, according to the resource requirements of the Pod scheduling task , The resource priority of the server node and the resource balance of the server node score each server node in the cluster.
  • the scoring of each server node in the cluster according to resource availability specifically includes:
  • score indicates the server node score
  • cpu indicates CPU idleness
  • memory indicates memory idleness
  • capacity indicates the total amount of resources corresponding to the server node
  • requested indicates the amount of resources occupied by other running tasks of the server node.
  • the scoring of each server node in the cluster according to the resource requirements of the Pod scheduling task, the resource priority of the server node, and the resource balance of the server node includes:
  • T ijused cluster of server nodes i wherein the total amount of resources in the resource class j representing an internal T ij i-th cluster server node, the resource class j W ij representative of the i-th server within the cluster nodes
  • T ijreq represents the amount of resources of type j requested by the current Pod task to be scheduled
  • G i represents the resource priority of the i-th server node
  • C i represents the i-th
  • the resource types include cpu, memory, I/o reading and writing rate, network bandwidth, graphics card and hard disk;
  • B i represents the resource balance of the i-th server node
  • Scorei represents the score of the i-th server node
  • Scorei is positive, it indicates that this server node is available.
  • the present invention discloses the following technical effects:
  • the invention provides a multi-dimensional resource scheduling method based on a Kubernetes cluster system, which can schedule various resources of nodes in the cluster, meet diversified resource requests for various services, and increase the flexibility and scalability of the system.
  • Figure 1 is a system framework diagram of the Kubernetes cluster architecture of the present invention
  • Figure 2 is a physical flow chart of multi-dimensional resource scheduling under the Kubernetes cluster system of the present invention
  • Fig. 3 is a flowchart of a multi-dimensional resource scheduling algorithm under the Kubernetes cluster system of the present invention.
  • the purpose of the present invention is to provide a multi-dimensional resource scheduling method under the Kubernetes cluster architecture system, which can dynamically find the optimal work node allocation for each task in the cloud system, and solves the problem that the input parameters of the current scheduling algorithm are single and cannot satisfy the task.
  • the Kubernetes cluster architecture system of the present invention is as follows:
  • Cluster master node It is the core node of the entire cluster. All execution commands and operations for the Kubernetes cluster are executed by it. It is responsible for the scheduling and management of the entire cluster. It is generally an independent server in the cluster. Master includes a lot of components, mainly including API Server, controller and scheduler. Api Server is the data bus and data center of the entire system. It provides the addition, deletion, and modification of various resource objects of the cluster system, the REST API interface for cluster management (including authentication and authorization, data verification, and cluster status changes) and other modules. Data exchange and communication. Other modules query or modify data through Api Server, and only Api Server can directly operate etcd. The controller is the internal management and control center of the cluster.
  • API Server is the data bus and data center of the entire system. It provides the addition, deletion, and modification of various resource objects of the cluster system, the REST API interface for cluster management (including authentication and authorization, data verification, and cluster status changes) and other modules. Data exchange and communication. Other modules query or modify data through Api Server, and only Api
  • the scheduler accepts the tasks sent by the controller, monitors the legitimacy of the Pod, finds a suitable node for the Pod to run according to the scheduling strategy, and sends the bound information to etcd through the API Server for storage.
  • Node Except for the cluster master node (Master) in the Kubernetes cluster, the rest of the nodes are called nodes (Node), Node nodes are all working nodes, and each Node node will be allocated to a reasonable value by the Master node according to the scheduling rules.
  • the workload is the executor of the task.
  • Each Node node runs a kubelet service process, monitors the port, receives and executes the instructions from the Master, and manages the Pod and the containers in the Pod.
  • Each kubelet process will register its own information on the Api Server, report resource usage to the Master node regularly, and monitor the resources of nodes and containers through cAdvisor.
  • kubectl is generally installed on the client. It can manage the cluster itself, and can install and deploy containerized applications on the cluster. As a command line tool of Kubernetes, kubectl is mainly responsible for operating the resource objects in the cluster. These operations include the creation, deletion, and viewing of resource objects, so as to realize the management of the kebernetes cluster.
  • etcd is a very important component in the Kubernetes cluster, which is used to store all the network configuration of the cluster and the state information of all objects.
  • the present invention provides a multi-dimensional resource scheduling method under the Kubernetes cluster architecture system, including:
  • Step 1) Initiating a Pod creation request, including: a. A request initiated through the command line of the kubectl client; b. A Pod request created by the controller to complement the copy; c. An external request initiated through the Api Server.
  • All Pod creation requests need to pass authentication and pass to the Api Server of the cluster master node. After authentication and authentication, it is confirmed whether the creation request is passed. If the Pod creation request is legal, the Api server creates the corresponding Pod, and at the same time , All Pod creation information will be persistently stored in the distributed storage database etcd.
  • the controller and scheduler in the cluster master node (Master) query Pod creation information by accessing Api Server in real time. When there is a new creation object, the controller is responsible for obtaining the development dependency library, system configuration and other related parameters required by the Pod.
  • the Pod scheduling task is generated and sent to the scheduler, and the Pod scheduling task is added to the suspended queue.
  • the controller serializes the Pod scheduling tasks into objects and sends them to the scheduler.
  • the scheduler receives the tasks sent by the controller, monitors the legitimacy of the tasks, and the scheduler scans these tasks asynchronously.
  • Step 2 The scheduler queries whether there are Pod tasks to be scheduled by accessing Api Server. If it exists, obtain the Pod resource information to be scheduled and the resource usage of all Node nodes in the cluster. Then schedule according to the established scheduling strategy, bind the Pod task to the target Node node, and write the binding information into etcd; if it does not exist, no operation is performed and continue to wait for the next round of notification and query.
  • a Pod When a Pod is submitted, it will carry the creation information of the Pod and the required resource information.
  • the former is to build an environment for the specific deployment of the Pod, and the latter is to complete the resources required for scheduling tasks, such as computing resources such as cpu and memory, and also include Diversified resources such as i/o reading and writing rate, network bandwidth, graphics card, hard disk, etc.
  • This information is usually set in the yaml file of the Pod.
  • the scheduling strategy consists of two parts:
  • the feasibility check is mainly carried out, specifically as follows:
  • the scheduler uses filtering rules to filter out the server nodes that do not meet the requirements, and find out the server nodes on which the task can run.
  • the server nodes that can be run are given priority points, specifically,
  • Score the server nodes filtered out in the previous stage select the server node with the highest score and the Pod task for binding operation, and deploy the container to run the task on the corresponding node. If there are enough available resources to meet the constraints of the job, the scheduler will assign the task to the node. Scanning from high priority to low priority is adjusted through a round-robin scheme within the priority to ensure fairness between users and avoid front-end blocking after large jobs.
  • the specific implementation process of the scheduling strategy is:
  • the scheduling event that is the Pod task to be scheduled, pops up in the first-in first-out scheduling queue, and enters the scheduling process;
  • the operating port According to the scheduling event, the operating port, resource requirements (such as cpu, memory, I/O read and write speed, etc.), and a series of personalized custom requirements;
  • the scheduling strategy of the present invention takes into account the different resource type requests of each Pod, and provides a specific scheduling service for each scheduling task.
  • the final scheduling result is to select the server node with the highest score according to the needs of the task and consider some overall optimization strategies, and then bind the server node with the scheduling task, and deploy the container environment to run the task on the server node.
  • Step 3 The kubelet located on the Node node performs regular visits, receives scheduling tasks from the scheduler and executes these scheduling tasks.
  • a new Pod is bound, download the container image required by the Pod and apply for the corresponding
  • the resource deploys the Pod, and the result is returned to the scheduler after the execution is completed.
  • the kubelet in the target node will monitor the scheduling information and be responsible for the specific creation of the node.
  • Step 4) The kubelet obtains the latest state of the Pod according to the container startup time, and updates the new state to etcd through ApiServer.
  • Step 1) kublectl sends a Pod creation request to the Kubernetes cluster, and confirms whether the creation request is passed after authentication and authentication. If the Pod creation request is legal, the API server creates the corresponding Pod. At the same time, all creation information will be persistently stored in the distributed storage database etcd.
  • the controller and scheduler in the Master query the Pod creation information by accessing the API Server.
  • the controller is responsible for obtaining the development dependency library, system configuration and other related parameters required by the Pod and generating these parameters into the Pod scheduling
  • the task is sent to the scheduler, and the Pod scheduling task is added to the suspended queue.
  • the controller serializes the Pod scheduling task into an object and sends it to the scheduler, and the scheduler will check the validity of the object.
  • controller serializes Pod scheduling tasks into objects and sends them to the scheduler, including:
  • the tasks to be scheduled in etcd are sorted in descending order based on this value to form a first-in first-out queue, which is passed to the scheduler in the order of the queue.
  • Step 2 The scheduler obtains the events to be scheduled by accessing the Api Server. If a new scheduling event appears in the first-in first-out queue, the scheduler executes the scheduling process. If the latest scheduling request is not collected, no operation will be performed and the next round of notification and query will continue to wait.
  • filter according to the Kubernetes default filtering algorithm Mainly includes the following five steps:
  • PodFitsPorts Check whether the port requested by the Pod conflicts with the port that has been used, and filter whether the port required by the Pod is occupied. If the port is occupied, the node will be filtered if the port is already in use.
  • PodFitsResources Filter whether the resources required by the Pod are met, that is, check the main feature requirements of the Pod, such as CPU, memory, IO resources, and network resources. If not, filter the node.
  • NoDiskConflict Filter whether there is a conflict between the disk volume label on the node and the disk volume label in the Pod, and filter the node if there is a conflict.
  • PodSelectorMatches If the Pod specifies the NodeSelector attribute, the nodes that match the PodNodeSelector attribute are screened out; whether the node selected by the Pod's node selector or node affinity matches the node to be inspected.
  • PodCFitsHost If the Pod specifies the HostName, the nodes that match the HostName will be filtered out.
  • the score ranges from 0 to 10.
  • the final scheduling result is the server node with the highest score. Then the server node is bound to the task, and the server node is bound to the task.
  • the node name field writes the final scheduling node name.
  • the scoring process is as follows:
  • the Pod type and resource requirements determine whether the scheduling event is a computationally intensive service or an ordinary service.
  • the Pod type is determined according to the resource demand type of the Pod. If the resource demand information required by the Pod scheduling task only contains computing resources such as cpu and memory, it is a computationally intensive service. If the resource demand information required by the Pod scheduling task includes Resource types are relatively diverse and complex. For example, a combination of diverse resources such as cpu, memory, i/o read/write rate, network bandwidth, graphics card, and hard disk is a common service.
  • cpu indicates CPU idleness
  • memory indicates memory idleness
  • capacity indicates the total amount of resources corresponding to the server node
  • requested indicates the amount of resources occupied by other running tasks of the server node, which are all known.
  • the scoring strategy of resource priority in the default scheduler is adopted here.
  • the resource priority method is actually to select the node with the most free resources (CPU and Memory) in the cluster. After scoring each available server node in the cluster according to the above scoring criteria, the server node with the highest score is the best server node bound by the Pod at last. Since computing-intensive services often require a large amount of CPU and memory support, when processing resource-intensive tasks, the use of resource priority scoring strategies can quickly and efficiently process scheduled tasks.
  • a resource proportion list is automatically generated according to the resource requirements of the scheduling task, and each server node in the cluster is dynamically scored according to the resource proportion list and coefficients. Due to the diversity of resource requirements, here, ignore the type of resources, according to the label of the task, find out the factors that account for the larger task demand and affect the performance of the task, and generate a multi-dimensional list of resource proportions:
  • the server nodes in the cluster are:
  • N [n 1 , n 2 , n 3 ,...n k ], k represents the number of server nodes;
  • the list of resource types required by the Pod task sequence is:
  • T [t 1 , t 2 ...t n ]
  • G [G 1 , G 2 ,...G k ],
  • the resource quota of each server node is determined according to the resource requirements of tasks in the work task flow, and the resource proportion coefficient is:
  • Resources include cpu, memory, i/o read and write rate, network bandwidth, Graphics card, hard disk, etc.
  • c i can be dynamically set according to task requirements. For which resource requirement is higher, the resource proportion coefficient is larger, and the resource demand requirement is lower, the resource proportion coefficient is smaller.
  • Resource priority A new task container is scheduled to a node.
  • the resource priority of this node is the ratio of the idle part of the node to the total capacity, that is, the total resource capacity minus the used resources on the node minus the new task scheduling resources Determined by the ratio of total resources, the calculation formula is as follows:
  • T ij of the i-th Of the total resources of the j-class internal resources on behalf of the cluster nodes T ij of the i-th, j-class resources on behalf of W ij internal nodes of the cluster i-th priorities, internal T ijused i-node cluster deployed
  • the total amount of type j resources consumed by Pod and other applications T ijreq represents the amount of type j resources requested by the current pod to be scheduled
  • G i represents the resource priority of the i-th node, and this value counts the priority of each resource
  • Resource balance It is the relative proportion of various resources of idle nodes. This setting is mainly to reduce Pod deployment on nodes with unbalanced node resources. It is also another method for comparing nodes with exhausted resources and more resources remaining. The better the node resource balance is, the more likely the node is to be selected. According to the reference formula of the two-dimensional resource balance:
  • the formula is mainly to find the relative proportion of the two resources of the node's cpu and memory, so as to select the node with the most balanced allocation of various resources among all nodes after scheduling, so as to avoid a large amount of CPU allocation on a node and a large amount of memory remaining Case.
  • the invention designs a multi-dimensional resource balance evaluation formula:
  • B i represents the resource balance of the i-th server node.
  • Scorei K(G i +B i ).
  • Scorei negative, it means this node is unavailable; when Scorei is positive, it means this node is available.
  • server node with the highest score is selected.
  • Step 3 loop the above steps until the list of tasks to be scheduled is empty.
  • the default scheduler When the default scheduler deploys the physical nodes that Pod runs, it usually takes memory and CPU as important index parameters to measure the performance of various nodes. Based on these two types of factors, each node is scored and sorted, and various optimizations of the default scheduling algorithm are also used. Merely adding indicator parameters such as network load and IO reading speed, ignoring the diversity of service resource requirements in the service task group, often the indicator parameters of various services are different, and resource diversified scheduling In the cluster scheduling strategy, it is not limited to the types of resources, and nodes are scored according to the task's self-labeled preferred resource requirement list, and different resource requirements. When scheduling and deploying Pod, static scheduling can keep the cluster relatively balanced.
  • the dynamic load balancing mechanism is also combined in the scheduling process. , Adopting the dynamic proportion coefficient to ensure that the cluster maintains the stability and balance of the cluster system in the case of long-term operation, so as to better maintain the stability of the cluster system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Multi Processors (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

一种Kubernetes集群架构***下多维资源调度方法，对于计算密集型服务根据资源空闲度给集群内各个服务器节点打分，对于普通型服务，则根据调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，选取分值最高的服务器节点绑定pod调度任务并执行。满足各类服务的多样化资源请求，增加***的灵活性和可扩展性。

Description

Kubernetes集群架构***下多维资源调度方法
本申请要求于2020年4月16日提交中国专利局、申请号为202010300356.2、发明名称为“Kubernetes集群架构***下多维资源调度方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及互联网通信技术领域，特别是涉及Kubernetes集群架构***下多维资源调度方法。
背景技术
随着云计算，分布式存储等各类技术的蓬勃发展，由于成本低、效率高以及测试轻量级的特点，Kubernetes集群架构***的研究已经成为了互联网通信技术领域的大热方向，Kubernetes容器集群管理工具主要应用于管理云计算环境下计算密集型的大规模任务应用，然而容器资源请求是动态变化的，存在着除CPU、内存之外还包括存储、网络带宽等其他资源，类型是多样的，所对应的资源类型也是多维资源类型，但是Kubernetes的静态调度算法输入参数单一，对资源的占用情况分析粗糙，存在非常大的局限性，并不能充分利用各个服务器中的多种资源(包括架构中边缘节点上的异构资源)，也不能针对容器多维资源请求提供相应的帮助。现有的调度算法无法满足需要调度多维资源类型的需求。
发明内容
鉴于上述，本发明提出了一种Kubernetes集群架构***下多维资源调度方法，能够动态地为云***中的每个任务寻找最优的工作节点分配，解决了现阶段调度算法输入参数单一，无法满足任务对节点多样的资源类型需求的问题。
为实现上述目的，本发明提供了如下方案：
Kubernetes集群架构***下多维资源调度方法，包括：
发起Pod创建请求；
获取Pod所需要参数生成Pod调度任务；
将Pod调度任务序列化为对象送入调度器；
将调度器内Pod调度任务绑定到目标Node节点上执行。
可选的，所述发起Pod创建请求，具体包括：
通过kubectl客户端命令行发起的请求；
控制器为补足副本而创建的Pod请求；
通过Api Server发起的外部请求。
可选的，还包括：
Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，由Api Server创建相应的Pod。
可选的，还包括：
所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。
可选的，所述将Pod调度任务序列化为对象送入调度器，包括：
计算Pod调度任务的优先级指数，将Pod调度任务按优先级指数作降序排序，形成先入先出队列，按照队列顺序传入调度器；
所述优先级指数计算如下：
Figure PCTCN2021072398-appb-000001
其中，α i表示第i个Pod调度任务的优先级指数，D i表示第i个Pod调度任务的截止期约束，A i表示第i个Pod调度任务的提交时间，CP i表示第i个Pod调度任务的关键路径长度。
可选的，所述将调度器内Pod调度任务绑定到目标服务器节点上执行，具体包括：
对服务器节点进行可行性检查，筛选出Pod调度任务能够运行的服务器节点；
为能够运行的服务器节点进行打分；
将Pod调度任务绑定到打分最高的服务器节点上。
可选的，采用kubernetes默认的过滤算法筛选服务器节点：
过滤掉Pod所需端口已经被占用服务器节点，
过滤掉Pod所需资源无法满足的服务器节点，
过滤掉与Pod中的磁盘卷标存在冲突的服务器节点，
筛选出与Pod NodeSelector属性匹配以及HostName匹配的服务器节点。
可选的，所述为能够运行的服务器节点进行优先级打分，具体包括：
判定此次Pod调度任务事件是计算密集型服务还是普通型服务，如果是计算密集型服务则根据资源空闲度给集群内各个服务器节点打分；如果是普通型服务，则根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分。
可选的，所述根据资源空闲度给集群内各个服务器节点打分，具体包括：
Figure PCTCN2021072398-appb-000002
其中，score表示服务器节点分值，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示服务器节点其他运行的任务占用的资源量。
可选的，所述根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，具体包括：
计算服务器节点的资源优先级：
W ij＝T ij-T ijused-T ijreq；
Figure PCTCN2021072398-appb-000003
其中，T ij代表集群内部第i个服务器节点的第j类资源的资源总量，W ij代表集群内部第i个服务器节点的第j类资源的优先级，T ijused集群内部第i个服务器节点已部署的Pod和其他应用消耗的第j类资源总量，T ijreq代表当前待调度Pod任务请求的第j类资源量，G i表示第i个服务器节点的 资源优先级，C i表示第i个服务器节点的资源比重系数，i＝1，2，…k，j＝1，2，…s，k表示服务器节点数，s表示服务器节点中资源类型总数，所述资源类型包括cpu、内存、i/o读写速率、网络带宽、显卡和硬盘；
计算服务器节点的资源均衡度：
Figure PCTCN2021072398-appb-000004
其中，B i表示第i个服务器节点的资源均衡度；
计算服务器节点打分：
Scorei＝K(G i+B i)
其中，Scorei表示第i个服务器节点分值，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1，Scorei为负值时，表示此服务器节点不可用，Scorei为正时表示此服务器节点可用。
根据本发明提供的具体实施例，本发明公开了以下技术效果：
本发明提供一种基于Kubernetes集群***下多维资源的调度方法，能够针对集群内节点的各类资源进行调度，满足各类服务的多样化资源请求，增加***的灵活性和可扩展性。
说明书附图
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明的Kubernetes集群架构***框架图；
图2为本发明的Kubernetes集群***下多维资源调度物理流程图；
图3为本发明的Kubernetes集群***下多维资源调度算法流程图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进 行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明的目的是提供一种Kubernetes集群架构***下多维资源调度方法，能够动态地为云***中的每个任务寻找最优的工作节点分配，解决了现阶段调度算法输入参数单一，无法满足任务对节点多样的资源类型需求的问题。
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
参见图1，本发明的Kubernetes集群架构***如下：
集群主节点(Master)：它是整个集群的核心节点，所有对于Kubernetes集群的执行命令操作都是由它执行，它负责整个集群的调度和管理工作，一般是集群中独立的服务器。Master包括非常多的组件，主要包括Api Server、控制器以及调度器。Api Server是整个***的数据总线和数据中心，提供了集群***的各类资源对象的增删改查，集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)以及其他模块之间的数据交互和通信。其他模块通过Api Server查询或修改数据，只有Api Server才直接操作etcd。控制器是集群内部管理和控制中心，负责获取用户所需要的开发依赖库、***配置等相关参数并将这些参数生成任务发送至调度器。调度器接受控制器发送的任务，监测Pod合法性并将Pod根据调度策略找到一个合适的节点运行，并将绑定的信息通过API Server发送到etcd中存储。
节点(Node)：Kubernetes集群中除了集群主节点(Master)以外，其余的节点都称为节点(Node)，Node节点都是工作节点，每一个Node节点都会被Master节点按照调度规则分配到合理的工作负载，是任务的执行者。每个Node节点上都运行一个kubelet服务进程，监听端口，接收并执行Master发来的指令，管理Pod以及Pod中的容器。每个kubelet进程会在Api Server上注册节点自身信息，定期向Master节点汇报资源使用情况， 并通过cAdvisor监控节点和容器的资源。
命令行工具(kubectl)：kubectl一般安装在客户端，它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。kubectl作为Kubernetes的命令行工具，主要的职责就是对集群中的资源的对象进行操作，这些操作包括对资源对象的创建、删除和查看等，从而实现对kebernetes集群的管理。
分布式存储数据库(etcd)：etcd是Kubernetes集群中的一个十分重要的组件，用于保存集群所有的网络配置和所有对象的状态信息。
基于上述Kubernetes集群架构***，本发明提供一种Kubernetes集群架构***下多维资源调度方法，包括：
步骤1)，发起Pod创建请求，包括：a、通过kubectl客户端命令行发起的请求；b、控制器为补足副本而创建的Pod请求；c、通过Api Server发起的外部请求。
所有的Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，经过鉴权认证后确认该创建请求是否通过，若Pod创建请求合法，Api server则创建相应的Pod，与此同时，所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。集群主节点(Master)中的控制器以及调度器通过实时访问Api Server来查询Pod创建信息，当有新的创建对象时，控制器负责获取Pod所需要的开发依赖库、***配置等相关参数并生成Pod调度任务发送至调度器，同时将Pod调度任务添加到挂起队列当中。控制器将Pod调度任务序列化为对象送入调度器中。调度器接受到控制器发送的任务，监测任务合法性并且调度程序异步的扫描这些任务。
步骤2)调度器通过访问Api Server查询是否存在待调度的Pod任务。若存在，则获取待调度的Pod资源信息和集群中所有的Node节点资源使用情况。然后根据制定的调度策略进行调度，将Pod任务绑定到目标Node节点上，并将绑定信息写入etcd中；若不存在，则不执行任何操作，继续等待下一轮通知查询。
Pod在提交时会携带Pod的创建信息以及需要的资源信息，前者是为了Pod在具体部署的时候搭建环境，后者是为了完成调度任务所需要的 资源，例如cpu、内存等计算资源，还包括i/o读写速率、网络带宽、显卡、硬盘等多样化的资源。这些信息通常在Pod的yaml文件中设置。
调度策略包括两个部分：
预选阶段，主要进行可行性检查，具体为：
调度器用过滤规则过滤掉不符合要求的服务器节点，找出任务可以运行的服务器节点。
优选阶段，为可以运行的服务器节点进行优先级打分，具体为，
将上一阶段过滤出来的服务器节点进行打分，选择打分最高的服务器节点和Pod任务进行绑定操作，并在相应节点上部署容器运行任务。如果有足够的可用资源满足作业的约束，调度程序就将任务分配给节点。从高优先级到低优先级的扫描，通过一个优先级内的循环方案进行调整，以确保用户之间的公平性，并避免在大型作业之后的前端阻塞。
调度策略的具体实施过程为：
在先入先出调度队列中弹出调度事件即待调度的Pod任务，进入调度流程；
根据调度事件对运行端口、资源要求(例如cpu、内存、I/O读写速度等)以及一系列个性化的自定义需求；
调用一组过滤算法进行可行性检查，通过对调度器缓存区内集群中所有节点的节点信息进行过滤，得到符合要求的一组节点，就是所有可以运行该调度事件的服务器节点列表。在这一过程中，可用资源比任务需要的资源少的服务器节点就会被过滤掉；
然后为可以运行的服务器节点列表中的各个服务器节点进行打分。
本发明的调度策略考虑到每个Pod的不同的资源类型请求，为每个调度任务提供特定的调度服务。最终的调度结果，就是根据任务的需求并考虑一些整体的优化策略，选择得分最高的那个服务器节点，进而将该服务器节点与调度任务进行绑定，在该服务器节点上部署容器环境运行任务。
步骤3)位于Node节点上的kubelet进行定期的访问，接收从调度器传来的调度任务并执行这些调度任务，当有新的Pod绑定时，则下载Pod所需要的容器镜像并申请相应的资源进行Pod的部署，执行完毕将结果 返回至调度器。同时，目标节点中的kubelet会监听调度信息以及负责节点的具体创建工作。
步骤4)kubelet通过容器启动时间取得Pod的最新状态，并将新的状态通过ApiServer更新到etcd中。
调度过程中，Kubernetes集群***工作流程如图2所示。
作为本发明的一个优选实施例，具体实施过程参见图3，如下：
步骤1)，kublectl向Kubernetes集群发送Pod创建请求，经过鉴权认证后确认该创建请求是否通过，若Pod创建请求合法，Api server则创建相应的Pod。与此同时，所有的创建信息都将被持久化存储在分布式存储数据库etcd中。
Master中的控制器以及调度器通过访问Api Server来查询Pod创建信息，当有新的创建对象时，控制器负责获取Pod所需要的开发依赖库、***配置等相关参数并将这些参数生成Pod调度任务发送至调度器，同时将Pod调度任务添加到挂起队列当中。控制器将Pod调度任务序列化为对象送入调度器，调度器将检测对象合法性。
进一步的，控制器将Pod调度任务序列化为对象送入调度器，包括：
根据etcd中待调度任务，获取任务Wi的提交时间A i和截止期约束D i，并计算出关键路径的长度CP i，计算任务优先级指数：
Figure PCTCN2021072398-appb-000005
α i该值越小表示任务的CP i越接近与D i-A i，即此调度任务就越紧急，需要优先处理，CP i主要是通过节点提供的cpu以及内存资源预测Pod任务运行时间。
将etcd中待调度任务基于此值作降序排序，形成先入先出队列，按照队列顺序传入调度器。
步骤2)，调度器经过访问Api Server获取待调度事件，如查询到先入先出队列中出现了新的调度事件，则由调度器执行调度流程。若未收集到有最新的调度请求，则不执行任何操作，继续等待下一轮通知查询。
执行调度流程，首先调用一组过滤算法，根据调度器缓存区中拿到的调度事件信息对集群内所有节点进行过滤，得到任务可以运行的服务器节 点，在此，按照Kubernetes默认的过滤算法进行过滤，主要包括以下五个步骤：
2-1)PodFitsPorts:检查Pod申请的端口是不是与已经被使用的端口有冲突，筛选Pod所需端口是否被占用，如果被占用即存在端口已经被使用的情况则过滤该节点。
2-2)PodFitsResources：筛选Pod所需资源是否满足，即检查Pod的主要特征需求字段，例如CPU、内存、IO资源以及网络资源等需求，如果不满足则过滤该节点。
2-3)NoDiskConflict：筛选节点上的磁盘卷标与Pod中的磁盘卷标是否存在冲突，如果存在冲突则过滤该节点。
2-4)PodSelectorMatches：如果Pod指定了NodeSelector属性，则筛选出与PodNodeSelector属性匹配的节点；Pod的节点选择器或者节点亲和性指定的节点，是否与待考察节点匹配。
2-5)PodCFitsHost：如果Pod指定了HostName，则筛选出与HostName匹配的节点。
然后为可以运行的服务器节点列表中的各个服务器节点进行打分，分数范围为0～10，最终的调度结果，就是得分最高的那个服务器节点，进而将该服务器节点与任务进行绑定，并在服务器节点名称字段写入最终的调度节点名称。
打分过程如下：
根据Pod类型与资源需求判定此次调度事件是计算密集型服务还是普通型服务。Pod类型是根据Pod的资源需求类型决定的，如果Pod调度任务所需要的资源需求信息中只包含cpu、内存等计算资源则是计算密集型服务，若Pod调度任务所需要的资源需求信息中包含资源类型比较多样复杂，例如cpu、内存、i/o读写速率、网络带宽、显卡、硬盘等多样化的资源的组合则为普通型服务。
若属于计算密集型服务，则根据资源空闲度(CPU和内存)给集群内各个服务器节点打分并记录分值：
Figure PCTCN2021072398-appb-000006
其中，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示本服务器节点其他运行的任务占用的资源量，都是已知的。
此处采用了默认调度器中资源优先级的打分策略。资源优先级方法实际上就是在选择集群内部空闲资源(CPU和Memory)最多的节点。根据上述打分准则给集群内各个可用服务器节点打分后，得分最高的服务器节点就是最后被Pod绑定的最佳服务器节点。由于计算密集型服务往往需要大量CPU以及内存的支撑，所以在处理资源密集型任务时，采用资源优先级打分策略能够快速高效的处理调度的任务。
若属于普通型服务，则根据调度任务的资源需求，自动生成资源比重列表，根据资源比重列表以及系数动态的给集群内各个服务器节点进行打分。由于资源需求多样，在这里，忽略资源的类型，根据任务的标签，找出任务需求占重较大，影响任务性能的要素，生成多维的资源比重列表：
假设待调度的Pod任务序列为：
P＝[p 1，p 2，p 3，…p n]；
其中，p i，i＝1，2，…n表示第i个待调度Pod任务；
集群内服务器节点为：
N＝[n 1，n 2，n 3，…n k]，k表示服务器节点数；
Pod任务序列需要的资源类型列表为：
T＝[t 1，t 2…t n]；
其中，t i，i＝1，2，…n，表示第i个待调度Pod任务需要的资源类型；
集群内服务器节点的资源优先级为：
G＝[G 1，G 2，…G k]，
其中，G i，i＝1，2，…k，表示第i个服务器节点的资源优先级；
每个服务器节点的资源配额根据工作任务流中任务的资源需求而定，资源比重系数为：
Figure PCTCN2021072398-appb-000007
其中，c j，j＝1,2,…s为服务器节点中第j个资源的比重系数，s为服务器节点中资源类型总数，资源包括cpu、内存、i/o读写速率、网络带宽、显卡、硬盘等。c i可以根据任务需求动态的设定，对哪项资源需求要求较高则资源比重系数较大，资源需求要求较低则资源比重系数较小。
通过动态的调节资源比重系数，来控制各项资源在优先级评判中的比重。
资源优先级：新的任务容器调度到一个节点上，这个节点的资源优先级为节点空闲的那部分与总容量的比值所得，即资源总容量减去节点上已用资源减去新任务调度资源与总资源量的比值决定，计算公式如下：
W ij＝T ij-T ijused-T ijreq；
Figure PCTCN2021072398-appb-000008
其中，T ij代表集群内部第i个节点的第j类资源的资源总量，W ij代表集群内部第i个节点的第j类资源的优先级，T ijused集群内部第i个节点已部署的Pod和其他应用消耗的第j类资源总量T ijreq代表当前待调度Pod请求的第j类资源量，G i表示第i个节点的资源优先级，该值统计了各项资源的优先级之和，比值越大，节点的优先级就越高，i＝1，2，…k，j＝1，2，…s。
资源均衡度：就是空闲节点的各类资源的相对比例。此设置主要是减少Pod部署在节点资源不均衡的节点上，也是比较节点出现资源耗尽，另一种资源剩余较多的手段。节点资源均衡度越好选择该节点的可能性就越大，根据二维资源均衡度的参考公式：
B＝1-abs(W cpu-W mem)
该公式主要是求节点的cpu以及内存这两种资源的相对比例，从而选择调度后，所有节点里各种资源分配最均衡的那个节点，从而避免一个节点上CPU被大量分配、而Memory大量剩余的情况。本发明设计出多维资源均衡度评判公式：
Figure PCTCN2021072398-appb-000009
其中，B i表示第i个服务器节点的资源均衡度。
然后，综合资源优先级以及资源均衡度，给各个服务器节点进行打分：
Scorei＝K(G i+B i)。
其中，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1。Scorei为负值时，表示此节点不可用；Scorei为正时表示此节点可用。
最终选取打分最高的服务器节点。
步骤3)，循环上述步骤直至待调度任务列表为空。
默认调度器在部署Pod所运行的物理节点时，通常把内存、CPU作为衡量各类节点性能的重要指标参数，基于这两类因素对各个节点进行打分排序，对于默认调度算法的各类优化也仅仅加上了类似网络负载量、IO读取速度等指标参数，忽略了在服务任务组中，各类服务资源需求的多样性，往往各类服务的指标参数各不相同，资源的多样化调度集群调度策略中，不局限于资源的种类，根据任务自带标签优选资源需求列表，不同资源需求进行节点打分。在调度部署Pod时，静态调度可以使集群保持负载的相对均衡，然而，在集群长时间的运行之后，集群***会出现负载不均衡的问题，因此，在调度过程中，也结合动态负载均衡机制，采用动态比重系数保证集群在长时间运行的情况下，维持集群***的稳定均衡性，从而更好地保持集群***的稳定。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (10)

  1. Kubernetes集群架构***下多维资源调度方法，其特征在于，包括：
    发起Pod创建请求；
    获取Pod所需要参数生成Pod调度任务；
    将Pod调度任务序列化为对象送入调度器；
    将调度器内Pod调度任务绑定到目标Node节点上执行。
  2. 根据权利要求1所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述发起Pod创建请求，具体包括：
    通过kubectl客户端命令行发起的请求；
    控制器为补足副本而创建的Pod请求；
    通过Api Server发起的外部请求。
  3. 根据权利要求1所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，还包括：
    Pod创建请求需要通过鉴权认证后传入集群主节点的Api Server中，由Api Server创建相应的Pod。
  4. 根据权利要求3所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，还包括：
    所有的Pod创建信息都将被持久化存储在分布式存储数据库etcd中。
  5. 根据权利要求1所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述将Pod调度任务序列化为对象送入调度器，具体包括：
    计算Pod调度任务的优先级指数，将Pod调度任务按优先级指数作降序排序，形成先入先出队列，按照队列顺序传入调度器；
    所述优先级指数计算如下：
    Figure PCTCN2021072398-appb-100001
    其中，α i表示第i个Pod调度任务的优先级指数，D i表示第i个Pod调度任务的截止期约束，A i表示第i个Pod调度任务的提交时间，CP i表 示第i个Pod调度任务的关键路径长度。
  6. 根据权利要求1所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述将调度器内Pod调度任务绑定到目标服务器节点上执行，具体包括：
    对服务器节点进行可行性检查，筛选出Pod调度任务能够运行的服务器节点；
    为能够运行的服务器节点进行打分；
    将Pod调度任务绑定到打分最高的服务器节点上。
  7. 根据权利要求6所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，采用kubernetes默认的过滤算法筛选服务器节点：
    过滤掉Pod所需端口已经被占用服务器节点，
    过滤掉Pod所需资源无法满足的服务器节点，
    过滤掉与Pod中的磁盘卷标存在冲突的服务器节点，
    筛选出与Pod NodeSelector属性匹配以及HostName匹配的服务器节点。
  8. 根据权利要求6所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述为能够运行的服务器节点进行优先级打分，具体包括：
    判定此次Pod调度任务事件是计算密集型服务还是普通型服务，如果是计算密集型服务则根据资源空闲度给集群内各个服务器节点打分；如果是普通型服务，则根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分。
  9. 根据权利要求8所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述根据资源空闲度给集群内各个服务器节点打分，具体包括：
    Figure PCTCN2021072398-appb-100002
    其中，score表示服务器节点分值，cpu表示CPU空闲度，memory表示内存空闲度，capacity表示服务器节点对应资源的资源总量，requested表示服务器节点其他运行的任务占用的资源量。
  10. 根据权利要求8所述的Kubernetes集群架构***下多维资源调度方法，其特征在于，所述根据Pod调度任务的资源需求，服务器节点的资源优先级以及服务器节点的资源均衡度给集群内各个服务器节点打分，具体包括：
    计算服务器节点的资源优先级：
    W ij＝T ij-T ijused-T ijreq；
    Figure PCTCN2021072398-appb-100003
    其中，T ij代表集群内部第i个服务器节点的第j类资源的资源总量，W ij代表集群内部第i个服务器节点的第j类资源的优先级，T ijused集群内部第i个服务器节点已部署的Pod和其他应用消耗的第j类资源总量，T ijreq代表当前待调度Pod任务请求的第j类资源量，G i表示第i个服务器节点的资源优先级，C i表示第i个服务器节点的资源比重系数，i＝1，2，…k，j＝1，2，…s，k表示服务器节点数，s表示服务器节点中资源类型总数，所述资源类型包括cpu、内存、i/o读写速率、网络带宽、显卡和硬盘；
    计算服务器节点的资源均衡度：
    Figure PCTCN2021072398-appb-100004
    其中，B i表示第i个服务器节点的资源均衡度；
    计算服务器节点打分：
    Scorei＝K(G i+B i)
    其中，Scorei表示第i个服务器节点分值，K为+1或者-1表示经过过滤流程后的结果，通过过滤阶段K＝+1，未通过过滤阶段K＝-1，Scorei为负值时，表示此服务器节点不可用，Scorei为正时表示此服务器节点可 用。
PCT/CN2021/072398 2020-04-16 2021-01-18 Kubernetes集群架构***下多维资源调度方法 WO2021208546A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/395,728 US11983562B2 (en) 2020-04-16 2021-08-06 Multidimensional resource scheduling method in Kubernetes cluster architecture system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010300356.2 2020-04-16
CN202010300356.2A CN111522639B (zh) 2020-04-16 2020-04-16 Kubernetes集群架构***下多维资源调度方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/395,728 Continuation US11983562B2 (en) 2020-04-16 2021-08-06 Multidimensional resource scheduling method in Kubernetes cluster architecture system

Publications (1)

Publication Number Publication Date
WO2021208546A1 true WO2021208546A1 (zh) 2021-10-21

Family

ID=71910641

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/072398 WO2021208546A1 (zh) 2020-04-16 2021-01-18 Kubernetes集群架构***下多维资源调度方法

Country Status (3)

Country Link
US (1) US11983562B2 (zh)
CN (1) CN111522639B (zh)
WO (1) WO2021208546A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113900822A (zh) * 2021-10-27 2022-01-07 哈尔滨理工大学 一种新的权重可变的资源调度方法
CN114826964A (zh) * 2022-04-11 2022-07-29 京东科技信息技术有限公司 一种资源监控方法、装置和***
CN114840343A (zh) * 2022-05-16 2022-08-02 江苏安超云软件有限公司 基于分布式***的任务调度方法及***
CN115237608A (zh) * 2022-09-21 2022-10-25 之江实验室 一种基于多集群统一算力的多模式调度***和方法
CN116541134A (zh) * 2023-07-05 2023-08-04 苏州浪潮智能科技有限公司 多架构集群中容器的部署方法及装置
CN117170812A (zh) * 2023-09-07 2023-12-05 中国人民解放军国防科技大学 一种基于研发运维一体化架构的数值预报计算云***

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111522639B (zh) * 2020-04-16 2022-11-01 南京邮电大学 Kubernetes集群架构***下多维资源调度方法
CN112019628A (zh) * 2020-09-01 2020-12-01 江西凌峰售电有限公司 一种基于物联网的低延迟低能耗的智慧平台***
CN112231075B (zh) * 2020-09-07 2023-09-01 武汉市九格合众科技有限责任公司 一种基于云服务的服务器集群负载均衡控制方法及***
CN112130961B (zh) * 2020-09-29 2023-08-25 中国工商银行股份有限公司 基于numa架构的容器绑定方法及***
CN112379971B (zh) * 2020-11-17 2021-09-14 深圳前海微众银行股份有限公司 应用容器管理方法、装置及设备
CN112416523A (zh) * 2020-11-24 2021-02-26 浪潮云信息技术股份公司 一种使用RuntimeClass实现多容器运行时的方法
CN112540829A (zh) * 2020-12-16 2021-03-23 恒生电子股份有限公司 容器组驱逐方法、装置、节点设备及存储介质
CN112671923B (zh) * 2020-12-29 2021-11-30 深圳一科互联有限公司 一种统一接口服务通讯调度方法及装置
CN112799837A (zh) * 2021-01-27 2021-05-14 浪潮云信息技术股份公司 一种容器动态平衡调度方法
CN112764886B (zh) * 2021-01-29 2024-06-25 上海弘积信息科技有限公司 一种基于Kubernetes平台的负载均衡控制器
CN112835714B (zh) * 2021-01-29 2023-07-28 中国人民解放军国防科技大学 云边环境中面向cpu异构集群的容器编排方法、***及介质
CN112532751B (zh) * 2021-02-09 2021-05-07 中关村科学城城市大脑股份有限公司 城市大脑ai计算中心分布式异构算力的调度方法及***
CN113114715B (zh) * 2021-02-24 2024-01-23 网宿科技股份有限公司 一种基于边缘计算的调度方法及边缘设备集群
CN112925611A (zh) * 2021-03-11 2021-06-08 南京邮电大学 一种基于共享式gpu的分布式容器调度方法及其***
CN113110923B (zh) * 2021-03-25 2023-10-20 南京飞灵智能科技有限公司 基于k8s的工作流引擎的使用方法及装置
CN112835989B (zh) * 2021-03-31 2024-02-09 中国工商银行股份有限公司 一种单应用多MySQL Set的部署方法及***
US11768713B2 (en) * 2021-04-19 2023-09-26 Microsoft Technology Licensing, Llc Dynamic relocation of pods to optimize inter-pod networking
CN113590255A (zh) * 2021-05-19 2021-11-02 北京中电飞华通信有限公司 基于YARN和Kubernetes的容器化双层调度方法及***
CN113448685B (zh) * 2021-06-07 2024-03-22 新浪技术（中国）有限公司 一种基于Kubernetes的Pod调度方法及***
US20220398134A1 (en) * 2021-06-11 2022-12-15 International Business Machines Corporation Allocation of services to containers
CN113391921B (zh) * 2021-06-16 2023-04-28 浪潮云信息技术股份公司 一种应用实例的资源配额校验方法
US11928503B2 (en) 2021-06-22 2024-03-12 International Business Machines Corporation Cognitive scheduler for Kubernetes
US11778045B2 (en) 2021-07-12 2023-10-03 Red Hat, Inc. Communication system for micro-frontends of a web application
US11838206B2 (en) * 2021-07-23 2023-12-05 Vmware, Inc. Edge node with datapath split between pods
CN113645300B (zh) * 2021-08-10 2023-11-28 上海道客网络科技有限公司 一种基于Kubernetes集群的节点智能调度方法和***
CN113672391B (zh) * 2021-08-23 2023-11-28 烽火通信科技股份有限公司 一种基于Kubernetes的并行计算任务调度方法与***
CN113687935A (zh) * 2021-09-10 2021-11-23 大连华信计算机技术股份有限公司 一种基于超融合设计的云原生存储调度方式
CN114374696A (zh) * 2021-12-15 2022-04-19 深圳前海微众银行股份有限公司 一种容器负载均衡方法、装置、设备及存储介质
CN113934515A (zh) * 2021-12-17 2022-01-14 飞诺门阵(北京)科技有限公司 一种基于数据域和计算域的容器组调度方法、装置
CN114301911B (zh) * 2021-12-17 2023-08-04 杭州谐云科技有限公司 一种基于边边协同的任务管理方法和***
CN114064296B (zh) * 2022-01-18 2022-04-26 北京建筑大学 一种Kubernetes调度方法、装置和存储介质
CN114928606B (zh) * 2022-01-29 2024-04-23 上海瀚银信息技术有限公司 一种服务器资源的调度方法及***
CN116644119A (zh) * 2022-02-16 2023-08-25 华为技术有限公司 一种数据存储***及方法
CN114679451B (zh) * 2022-02-18 2023-04-25 北京邮电大学 面向边缘计算的服务调度***及其调度方法
CN114327841B (zh) * 2022-03-16 2022-06-21 上海闪马智能科技有限公司 一种资源调度方法、装置、存储介质及电子装置
CN114390106B (zh) * 2022-03-24 2022-07-05 广州医科大学附属第五医院 基于Kubernetes容器资源的调度方法、调度器及调度***
CN114840304B (zh) * 2022-04-15 2023-03-21 中兴通讯股份有限公司 一种容器调度方法、电子设备和存储介质
CN114826908B (zh) * 2022-05-09 2024-03-26 新华智云科技有限公司 kubernetes集群服务保障方法、组件、***
CN115250197B (zh) * 2022-06-02 2024-04-12 苏州思萃工业互联网技术研究所有限公司 一种自动化创建容器发现服务的装置
CN114995961A (zh) * 2022-08-04 2022-09-02 浙江大学 一种请求调度方法、装置及存储介质
CN115543577B (zh) * 2022-08-08 2023-08-04 广东技术师范大学 基于协变量的Kubernetes资源调度优化方法、存储介质及设备
CN115426373A (zh) * 2022-08-23 2022-12-02 浪潮软件科技有限公司 私有云中部署分布式存储***的方法及部署***
CN115168057B (zh) * 2022-09-02 2022-12-20 浙江大华技术股份有限公司 基于k8s集群的资源调度方法及装置
CN115242660B (zh) * 2022-09-21 2022-12-13 之江实验室 基于中心化的异构算力联邦***及组网和执行方法
CN115562870B (zh) * 2022-10-25 2023-07-21 北京京航计算通讯研究所 一种集群的任务节点资源构建方法
CN115665157B (zh) * 2022-11-14 2023-03-14 杭州谐云科技有限公司 一种基于应用资源类型的均衡调度方法和***
CN115550371B (zh) * 2022-12-05 2023-03-21 安超云软件有限公司 基于Kubernetes的Pod调度方法、***及云平台
CN116204286B (zh) * 2022-12-21 2023-12-12 山东未来网络研究院(紫金山实验室工业互联网创新应用基地) 一种支持拓扑感知的Kubernetes调度方法
CN116132498A (zh) * 2022-12-22 2023-05-16 北京蔚领时代科技有限公司 适用于应用更新期间的云渲染调度方法、***及存储介质
CN115827206B (zh) * 2023-01-18 2023-05-05 太极计算机股份有限公司 一种基于机器学习的显卡任务资源的调度方法及***
CN115834714B (zh) * 2023-02-09 2023-06-16 中国证券登记结算有限责任公司 一种跨平台任务调度方法、服务器和***
CN116010111B (zh) * 2023-03-22 2023-12-22 安超云软件有限公司 一种跨集群资源调度方法、***及终端设备
CN116170518B (zh) * 2023-04-26 2023-07-18 北京太极信息***技术有限公司 一种国产芯片容器云跨架构管理的方法及设备
CN116340005B (zh) * 2023-05-26 2023-08-15 北京好心情互联网医院有限公司 容器集群的调度方法、装置、设备及存储介质
CN116860461B (zh) * 2023-09-04 2023-12-19 深圳大道云科技有限公司 K8s集群的资源调度方法、设备及存储介质
CN117170811A (zh) * 2023-09-07 2023-12-05 中国人民解放军国防科技大学 一种基于volcano的节点分组作业调度方法及***
CN117114623B (zh) * 2023-09-18 2024-04-26 广东泰一高新技术发展有限公司 一种园区内监控设备的智慧管理方法及***
CN117519994B (zh) * 2024-01-05 2024-04-16 银河麒麟软件(长沙)有限公司 一种基于k8s的NUMA感知调度方法及***
CN117729204B (zh) * 2024-02-06 2024-05-10 山东大学 一种基于监控感知的k8s容器调度方法及***

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106027643A (zh) * 2016-05-18 2016-10-12 无锡华云数据技术服务有限公司 一种基于Kubernetes容器集群管理***的资源调度方法
CN108519911A (zh) * 2018-03-23 2018-09-11 上饶市中科院云计算中心大数据研究院 一种基于容器的集群管理***中资源的调度方法和装置
CN109783218A (zh) * 2019-01-24 2019-05-21 中国—东盟信息港股份有限公司 一种基于Kubernetes容器集群的与时间相关联的容器调度方法
CN110780998A (zh) * 2019-09-29 2020-02-11 武汉大学 基于Kubernetes的动态负载均衡资源调度方法
CN111522639A (zh) * 2020-04-16 2020-08-11 南京邮电大学 Kubernetes集群架构***下多维资源调度方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10191778B1 (en) * 2015-11-16 2019-01-29 Turbonomic, Inc. Systems, apparatus and methods for management of software containers
US8984519B2 (en) * 2010-11-17 2015-03-17 Nec Laboratories America, Inc. Scheduler and resource manager for coprocessor-based heterogeneous clusters
US11243807B2 (en) * 2017-05-04 2022-02-08 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a scheduler and workload manager with workload re-execution functionality for bad execution runs
US10514951B2 (en) * 2017-05-04 2019-12-24 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a stateless, deterministic scheduler and work discovery system with interruption recovery
US11294726B2 (en) * 2017-05-04 2022-04-05 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a scalable scheduler with heterogeneous resource allocation of large competing workloads types using QoS
US10545796B2 (en) * 2017-05-04 2020-01-28 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a scheduler with preemptive termination of existing workloads to free resources for high priority items
CN109960585B (zh) * 2019-02-02 2021-05-14 浙江工业大学 一种基于kubernetes的资源调度方法
US11422844B1 (en) * 2019-11-27 2022-08-23 Amazon Technologies, Inc. Client-specified network interface configuration for serverless container management service
US11392422B1 (en) * 2019-11-27 2022-07-19 Amazon Technologies, Inc. Service-managed containers for container orchestration service

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106027643A (zh) * 2016-05-18 2016-10-12 无锡华云数据技术服务有限公司 一种基于Kubernetes容器集群管理***的资源调度方法
CN108519911A (zh) * 2018-03-23 2018-09-11 上饶市中科院云计算中心大数据研究院 一种基于容器的集群管理***中资源的调度方法和装置
CN109783218A (zh) * 2019-01-24 2019-05-21 中国—东盟信息港股份有限公司 一种基于Kubernetes容器集群的与时间相关联的容器调度方法
CN110780998A (zh) * 2019-09-29 2020-02-11 武汉大学 基于Kubernetes的动态负载均衡资源调度方法
CN111522639A (zh) * 2020-04-16 2020-08-11 南京邮电大学 Kubernetes集群架构***下多维资源调度方法

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113900822A (zh) * 2021-10-27 2022-01-07 哈尔滨理工大学 一种新的权重可变的资源调度方法
CN114826964A (zh) * 2022-04-11 2022-07-29 京东科技信息技术有限公司 一种资源监控方法、装置和***
CN114826964B (zh) * 2022-04-11 2024-04-05 京东科技信息技术有限公司 一种资源监控方法、装置和***
CN114840343A (zh) * 2022-05-16 2022-08-02 江苏安超云软件有限公司 基于分布式***的任务调度方法及***
CN115237608A (zh) * 2022-09-21 2022-10-25 之江实验室 一种基于多集群统一算力的多模式调度***和方法
CN116541134A (zh) * 2023-07-05 2023-08-04 苏州浪潮智能科技有限公司 多架构集群中容器的部署方法及装置
CN116541134B (zh) * 2023-07-05 2023-09-19 苏州浪潮智能科技有限公司 多架构集群中容器的部署方法及装置
CN117170812A (zh) * 2023-09-07 2023-12-05 中国人民解放军国防科技大学 一种基于研发运维一体化架构的数值预报计算云***
CN117170812B (zh) * 2023-09-07 2024-05-03 中国人民解放军国防科技大学 一种基于研发运维一体化架构的数值预报计算云***

Also Published As

Publication number Publication date
CN111522639A (zh) 2020-08-11
CN111522639B (zh) 2022-11-01
US20210365290A1 (en) 2021-11-25
US11983562B2 (en) 2024-05-14

Similar Documents

Publication Publication Date Title
WO2021208546A1 (zh) Kubernetes集群架构***下多维资源调度方法
CN109960585B (zh) 一种基于kubernetes的资源调度方法
US11243805B2 (en) Job distribution within a grid environment using clusters of execution hosts
US8752055B2 (en) Method of managing resources within a set of processes
US6651125B2 (en) Processing channel subsystem pending I/O work queues based on priorities
CN110297699B (zh) 调度方法、调度器、存储介质及***
CN114138486B (zh) 面向云边异构环境的容器化微服务编排方法、***及介质
CN104050042B (zh) Etl作业的资源分配方法及装置
KR101013073B1 (ko) 태스크 분배 및 병렬 처리 시스템과 그 방법
CN113454614A (zh) 用于分布式计算中的资源划分的***和方法
US20050081208A1 (en) Framework for pluggable schedulers
CN1602468A (zh) 多策略资源调度的方法和***
CN107273200B (zh) 一种针对异构存储的任务调度方法
CN106201681B (zh) Hadoop平台下基于预释放资源列表的任务调度方法
Ungureanu et al. Kubernetes cluster optimization using hybrid shared-state scheduling framework
CN109150759B (zh) 一种渐进式非阻塞机会资源预留方法及***
Czarnul A model, design, and implementation of an efficient multithreaded workflow execution engine with data streaming, caching, and storage constraints
CN115964176B (zh) 云计算集群调度方法、电子设备和存储介质
CN109298949B (zh) 一种分布式文件***的资源调度***
Du et al. A combined priority scheduling method for distributed machine learning
US9110823B2 (en) Adaptive and prioritized replication scheduling in storage clusters
CN115061811A (zh) 一种资源调度方法、装置、设备及存储介质
EP1630671A1 (en) Framework for pluggable schedulers
CN112019628A (zh) 一种基于物联网的低延迟低能耗的智慧平台***
Olaniyan et al. Recent Developments in Resource Management in Cloud Computing and Large Computing Clusters

Legal Events

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

Ref document number: 21788369

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21788369

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 21788369

Country of ref document: EP

Kind code of ref document: A1