WO2022062650A1 - 基于kubernetes的计算设备共享方法、装置、设备及存储介质 - Google Patents

基于kubernetes的计算设备共享方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2022062650A1
WO2022062650A1 PCT/CN2021/109627 CN2021109627W WO2022062650A1 WO 2022062650 A1 WO2022062650 A1 WO 2022062650A1 CN 2021109627 W CN2021109627 W CN 2021109627W WO 2022062650 A1 WO2022062650 A1 WO 2022062650A1
Authority
WO
WIPO (PCT)
Prior art keywords
pod
created
resource
computing device
gpu
Prior art date
Application number
PCT/CN2021/109627
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 苏州浪潮智能科技有限公司
Publication of WO2022062650A1 publication Critical patent/WO2022062650A1/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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • the present invention is designed in the field of communication, and in particular, relates to a method, device, device and storage medium for sharing computing equipment based on kubernetes (k8s).
  • k8s kubernetes
  • Containers emerge as a new cloud computing technology and are widely used in the development and deployment of distributed applications. As more and more new cloud-centric applications begin to rely on the high computational throughput of computing devices (such as GPUs (Graphics Processing Unit)), such as deep learning and high-performance applications, etc., It is necessary to efficiently support computing device operations in the container cloud.
  • computing devices such as GPUs (Graphics Processing Unit)
  • GPUs Graphics Processing Unit
  • the GPU device plugin (Nvidia device plugin) of kubernetes supports calling GPU computing resources in containers, but there is no fine-grained division of GPU computing resources, and each container needs to occupy at least one GPU.
  • the Gaia Schedule solution can also be used in the prior art. Please refer to Figure 1 to implement a GPU virtualization solution in a Kubernetes cluster to allocate and limit virtualized GPU resources for containers.
  • the Gaia Scheduler solution is not implemented.
  • the GPU is managed as a first-level resource, and resource managers and users cannot clearly define and select GPU resources, which is prone to performance interference in a resource-sharing environment; at the same time, it has poor scalability and cannot achieve cross-node allocation. Effective sharing of GPU computing resources in a GPU cluster.
  • a kubernetes-based computing device sharing method comprising:
  • the second resource requirement is less than or equal to the resource reserve of the computing device, determine a second to-be-created pod specification according to the second resource requirement and the first to-be-created pod specification, and determine the second to-be-created pod specification according to the second
  • the to-be-created pod specification creates and runs the second to-be-created pod on the computing device running the first to-be-created pod.
  • the computing device includes: GPU, FPGA, high-performance NIC (Network Interface Controller, network interface controller), InfiniBand and artificial intelligence chips.
  • the step of receiving the first resource demand of the first to-be-created pod includes:
  • the first resource demand is sent to the scheduler by using the interface invocation service.
  • the computing device is a GPU
  • the step of acquiring idle resource information of the computing device of several nodes in the kubernetes cluster includes:
  • the scheduler is used to query the information of several virtual GPUs from the virtual GPU pool, and according to the information of the several virtual GPUs, the GPU idle resource information of the node corresponding to the virtual GPU is determined.
  • the first pod specification to be created is determined according to the first resource requirement and idle resource information of computing devices of several nodes, and a node is selected according to the first pod specification to be created, and in the selected
  • the steps of creating and running the first pod to be created on the computing device of the node include:
  • the scheduler establishes the first pod specification to be created, and selects the target node from several nodes and randomly generates the GPUID;
  • the scheduler passes the updated first pod specification to be created to the device manager
  • the device manager detects that the randomly generated GPUID does not exist in the virtual GPU pool, a virtual GPU corresponding to the randomly generated GPUID is created, and the virtual GPU is linked with the real GPU corresponding to the randomly generated GPUID;
  • the step of acquiring the resource margin of the computing device running the first pod to be created includes:
  • determining a second to-be-created pod according to the second resource requirement and the first to-be-created pod specification The steps of creating and running the second pod to be created on the computing device running the first pod to be created according to the second specification of the pod to be created include:
  • the scheduler establishes the second to-be-created pod specification
  • the scheduler determines that the second resource requirement is less than or equal to the resource margin of the virtual GPU corresponding to the randomly generated GPUID, the scheduler updates the GPUID and the second resource requirement in the first to-be-created pod specification into the second to-be-created pod specification, and pass the updated second to-be-created pod specification to the device manager;
  • a kubernetes-based computing device sharing apparatus comprising:
  • a receiving module configured to receive the first resource demand of the first to-be-created pod
  • the idle resource acquisition module is used to acquire idle resource information of computing devices of several nodes in the kubernetes cluster
  • the first creation module is configured to determine the first pod specification to be created according to the first resource demand and the idle resource information of computing devices of several nodes, and select a node and select a node according to the first pod specification to be created. Create and run the first pod to be created on the computing device;
  • a resource surplus obtaining unit configured to obtain the resource surplus of the computing device running the first pod to be created if the second resource requirement of the second pod to be created is received;
  • a second creation module configured to determine a second to-be-created pod according to the second resource requirement and the first to-be-created pod specification when the second resource requirement is less than or equal to the computing device resource reserve specification, and create and run the second to-be-created pod on a computing device of a node according to the second to-be-created pod specification.
  • a computer device comprising: at least one processor;
  • a memory where the memory stores a computer program that can be executed on the processor, and when the processor executes the program, the foregoing kubernetes-based computing device sharing method is executed.
  • a computer-readable storage medium stores a computer program, and when the computer program is executed by the processor, executes the foregoing kubernetes-based computing device sharing method.
  • the above-mentioned Kubernetes-based computing device sharing method, device, device and storage medium realizes the task of computing device resource sharing by creating and managing custom resource type pod specifications.
  • KubeShare can achieve fine-grained division of computing resources, and also By managing technical equipment as a first-level resource, the running location of tasks can be selected according to user needs, and the isolation of computing equipment resources and cross-node scheduling are also realized, which effectively improves the resource utilization efficiency of computing equipment.
  • FIG. 1 is a schematic diagram of GPU virtualization in the Gaia Scheduler scheme in the prior art
  • FIG. 2 is a schematic flowchart of a method for sharing computing devices based on kubernetes in an embodiment of the present invention
  • Fig. 3 is the working flow chart of realizing GPU resource sharing in another embodiment of the present invention.
  • FIG. 4 is a schematic structural diagram of a kubernetes-based computing device sharing apparatus in another embodiment of the present invention.
  • FIG. 5 is an internal structural diagram of a computer device in another embodiment of the present invention.
  • FIG. 6 is a schematic structural diagram of a computer-readable storage medium proposed by the present invention.
  • the present invention provides a method for sharing computing devices based on kubernetes, and the method includes the following steps:
  • S300 Determine a first pod specification to be created according to the first resource demand and idle resource information of computing devices of several nodes, and select a node and create it on the computing device of the selected node according to the first pod specification to be created and run the first pod to be created;
  • the second resource demand is less than or equal to the computing device resource surplus according to the first resource demand and the idle resource information of computing devices of several nodes, then according to the second resource demand and the first A pod specification to be created determines a second pod specification to be created, and the second pod to be created is created and run on the computing device running the first pod to be created according to the second pod specification to be created.
  • the above-mentioned method for sharing computing equipment based on kubernetes realizes the task of sharing computing equipment resources by creating and managing custom resource type pod specifications.
  • KubeShare an open source container orchestration management tool based on Kubernetes
  • the technical equipment is managed as a first-level resource, and the running location of the task can be selected according to the user's needs, and the isolation of computing equipment resources and cross-node scheduling are also realized, which effectively improves the resource utilization efficiency of computing equipment. .
  • the computing device includes: GPU, FPGA, high-performance NIC, InfiniBand, and artificial intelligence chips.
  • a GPU is used as a computing device as an example for description below.
  • step S100 specifically includes the following sub-steps:
  • the client is the client that allocates GPU computing resources in kubernetes.
  • the user can specify the GPUID and node name (nodeName), and can also select the running location of the task according to the user's needs.
  • the interface calling service (ie kube-apiserverAP) client (Client) submits the configuration of GPU resources and interacts with the scheduler (KuberShare) through kube-apiserverAPI.
  • the aforementioned step S200 includes:
  • S210 configure the scheduler to manage GPUs of several nodes in the kubernetes cluster through a virtual GPU pool;
  • these shared GPUs managed by KubeShare are called virtual GPUs (virtual GPUs), and the virtual GPU pools (vGPU pools) use distributed storage, and the actual physical locations corresponding to vGPUs (virtual GPUs) can be scattered in a cluster.
  • a vGPU (virtual GPU) pool is used to represent the set of all vGPUs (virtual GPUs) managed by KubeShare.
  • GPUID unique identifier
  • S220 use the scheduler to query the information of several virtual GPUs from the virtual GPU pool, and determine the GPU idle resource information of the node corresponding to the virtual GPU according to the information of the several virtual GPUs.
  • step S300 specifically includes:
  • the scheduler establishes the first pod specification to be created, and selects a target node from several nodes and randomly generates a GPUID;
  • the scheduler transmits the updated first pod specification to be created to the device manager
  • the device manager (KubeShare-DevMgr) is responsible for creating the shared pod (sharePod) object, and then initializes the environment of the container according to the shared pod specification (SharePodSpec) received from the KuebShare scheduler KubeShare-Sched. Specifically, it sets the NVIDIA visible devices (NVIDIA_VISIBLE_DEVICES) environment variable and installs the gemini scheduler (gemini-scheduler) in the containers to isolate their GPU usage.
  • the KuebShare device manager (KubeShare-DevMgr) is also responsible for managing the vGPU (virtual GPU) pool on an on-demand or subscription basis;
  • step S400 specifically includes the following sub-steps:
  • step S500 specifically includes the following sub-steps:
  • the scheduler establishes the second specification of the pod to be created
  • S530 use the device manager to obtain the UUID of the real GPU linked with the randomly generated GPUID, create a pod by using the target node, and configure the environment variable of the newly created pod by using the second resource requirement.
  • the second to-be-created pod specification is determined according to the first resource demand and GPU idle resource information of several nodes, and according to the The second to-be-created pod specification creates and runs the second to-be-created pod on a GPU other than the first to-be-created pod; that is, when the computing resources of the GPU that has run the pod are insufficient to allocate to the to-be-created pod, Then, computing resources can be allocated from other nodes or other idle GPUs of the node.
  • pod1 and pod2 are created successively, assuming that pod1 requires 0.4 GPU, pod2 requires 0.6 GPU, and there are three nodes in the kubernetes cluster, namely node 1, node 2 and node 3, and There is an idle GPU on each node.
  • the specific creation process of pod1 and pod2 is as follows:
  • the scheduler (KubeShare-Sched) acquires cluster resources, and the KuebShare device manager (KubeShare-DevMgr) communicates with the clients (Client) on the three nodes. Client (Client) writes to the list of ⁇ GPU uuid> containers.
  • the gemini scheduler (gemini-scheduler) is synchronized with the list of ⁇ GPU uuid> containers.
  • the scheduler KerbeShare-Sched
  • the device manager KerbeShare-DevMgr obtains the real GPU UUID "UUID-GPU1" from the vGPU (virtual GPU) Pod linked with the GPUID "zxcvb";
  • the fine-grained division including the division of video memory and the division of GPU computing resources.
  • the division of video memory is the division of the size of the video memory space, and the division of GPU computing resources is implemented according to time slice polling.
  • the gemini library intercepts the GPU function calls. These GPU computing requests are scheduled one by one by the gemini scheduler (gemini-scheduler), thereby realizing that pod1 and pod2 share the computing resources of GPU1 on node 1.
  • the above-mentioned kubernetes-based computing device sharing method manages the GPU as a first-level resource.
  • the user can specify the GPUID and node name (nodeName), and also realizes the isolation of GPU computing resources and realizes cross-node scheduling and GPU. Allocation of computing resources.
  • a kubernetes-based computing device sharing apparatus 60 is provided, and the apparatus includes:
  • a receiving module 61 configured to receive the first resource demand of the first pod to be created
  • the idle resource acquisition module 62 is used to acquire idle resource information of computing devices of several nodes in the kubernetes cluster;
  • the first creation module 63 is configured to determine the first pod specification to be created according to the first resource requirement and the idle resource information of computing devices of several nodes, and select a node according to the first pod specification to be created and select a node on the selected node. Create and run the first pod to be created on the computing device;
  • the resource surplus obtaining unit 64 is configured to obtain the resource surplus of the computing device running the first pod to be created if the second resource requirement of the second to-be-created pod is received;
  • the second creation module 65 is configured to determine a second to-be-created pod according to the second resource requirement and the first to-be-created pod specification when the second resource requirement is less than or equal to the computing device resource reserve pod specification, and create and run the second to-be-created pod on a computing device of a node according to the second to-be-created pod specification.
  • Each module in the above-mentioned kubernetes-based computing device sharing apparatus may be implemented in whole or in part by software, hardware, and combinations thereof.
  • the above modules can be embedded in or independent of the processor in the computer device in the form of hardware, or stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
  • a computer device is provided, and the computer device may be a terminal, and its internal structure diagram may be as shown in FIG. 5 .
  • the computer equipment includes a processor, memory, a network interface, a display screen, and an input device connected by a system bus.
  • the processor of the computer device is used to provide computing and control capabilities.
  • the memory of the computer device includes a non-volatile storage medium, an internal memory.
  • the nonvolatile storage medium stores an operating system and a computer program.
  • the internal memory provides an environment for the execution of the operating system and computer programs in the non-volatile storage medium.
  • the network interface of the computer device is used to communicate with an external terminal through a network connection.
  • the computer program when executed by the processor, implements a kubernetes-based computing device sharing method.
  • the display screen of the computer equipment may be a liquid crystal display screen or an electronic ink display screen
  • the input device of the computer equipment may be a touch layer covered on the display screen, or a button, a trackball or a touchpad set on the shell of the computer equipment , or an external keyboard, trackpad, or mouse.
  • FIG. 5 is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer equipment to which the solution of the present application is applied. Include more or fewer components than shown in the figures, or combine certain components, or have a different arrangement of components.
  • a computer-readable storage medium 400 is provided, on which a computer program 402 is stored, and when the computer program 402 is executed by the processor 401, the above-mentioned kubernetes-based Computing device sharing method.
  • any reference to memory, storage, database or other medium used in the various embodiments provided in this application may include non-volatile and/or volatile memory.
  • Non-volatile memory may include read-only memory (Read-Only Memory, ROM), programmable ROM (Programmable Read-Only Memory, PROM), electrically programmable ROM (Erasable Programmable Read-Only Memory, EPROM), electrically erasable Except for programmable ROM (Electrically Erasable Programmable Read-Only Memory, EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory.
  • RAM random access memory
  • RAM is available in various forms, such as Static RAM (Static Dynamic Random Access Memory, SRAM), Dynamic RAM (Dynamic Random Access Memory, DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (Double Data Rate) Data Rate Sychronous Dynamic Random Access Memory, DDR SDRAM), Enhanced SDRAM (Enhanced Synchronous Dynamic Random Access Memory, ESDRAM), Synchronous Link (Synchlink) DRAM (Sync Link Dynamic Random Access Memory, SLDRAM), memory bus (Rambus) direct RAM (Rambus Direct Random Access Memory, RDRAM) etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种基于k8s的计算设备共享方法、装置、设备及存储介质。该方法包括：接收第一待创建pod的第一资源需求量；获取k8s集群内若干节点的计算设备空闲资源信息；根据第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，根据该规范选择节点并在选择的节点的计算设备上创建并运行第一待创建pod；若接收到第二待创建pod的第二资源需求量则获取运行第一待创建pod的计算设备资源余量；若第二资源需求量小于等于计算设备资源余量则根据第二资源需求量和第一待创建pod规范确定第二待创建pod规范，根据第二待创建pod规范在运行第一待创建pod的计算设备上创建并运行第二待创建pod。

Description

基于kubernetes的计算设备共享方法、装置、设备及存储介质
本申请要求于2020年09月28日提交中国国家知识产权局，申请号为202011042517.9，发明名称为“基于kubernetes的计算设备共享方法、装置、设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明设计通信领域，尤其涉及一种基于kubernetes(k8s)的计算设备共享方法、装置、设备及存储介质。
背景技术
近年来，Kubernetes是目前最受欢迎的容器编排工具，支持自定义配置，如负载均衡、容器复制、滚动更新、网络管理等。容器作为一种新的云计算技术出现并被广泛应用于分布式应用程序的开发和部署。随着越来越多的新的以云为中心的应用程序开始依赖计算设备(例如GPU(Graphics Processing Unit，图形处理器))的高计算吞吐量，如深度学习和高性能应用程序等，因此有必要在容器云中高效地支持计算设备运算。
目前kubernetes的GPU设备插件(Nvidia device plugin)方式支持在容器中调用GPU计算资源，但是并没有对GPU计算资源进行细粒度的划分，每一个容器至少需要占用1个GPU。当一个GPU设备由于GPU工作负载的突发性和有限的内存带宽而不能被单个应用程序充分利用时，导致GPU计算资源利用率的低下。另外，现有技术中还可采用Gaia Schedule方案， 请参照图1所示，在Kubernetes集群中做GPU虚拟化的方案，以实现为容器分配虚拟化GPU资源并加以限制，然而Gaia Scheduler方案没有实现将GPU作为一级资源进行管理，资源管理者和用户无法对GPU资源进行明确定义和选择，这在资源共享环境中容易产生性能干扰；同时它扩展性不好，无法实现跨节点分配，无法在一个GPU集群中实现对GPU计算资源的有效共享。
发明内容
有鉴于此，有必要针对以上技术问题提供能对计算设备资源的细粒度划分、计算资源的隔离并且实现跨节点的调度和计算资源分配的一种基于kubernetes的计算设备共享方法、装置、设备及存储介质。
根据本发明的一方面，提供了一种基于kubernetes的计算设备共享方法，所述方法包括：
接收第一待创建pod的第一资源需求量；
获取kubernetes集群内若干节点的计算设备空闲资源信息；
根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
若接收到第二待创建pod的第二资源需求量，则获取运行第一待创建pod的计算设备资源余量；
若所述第二资源需求量小于等于所述计算设备资源余量，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在运行所述第一待创建pod的计算设备上创建并运行所述第二待创建pod。
在其中一个实施例中，所述计算设备包括：GPU、FPGA、高性能NIC(Network Interface Controller，网络接口控制器)、InfiniBand和人工智能芯片。
在其中一个实施例中，所述接收第一待创建pod的第一资源需求量的步骤包括：
通过客户端获取输入的第一待创建pod的第一资源需求量；
利用接口调用服务将所述第一资源需求量发送至调度器。
在其中一个实施例中，所述计算设备为GPU，所述获取kubernetes集群内若干节点的计算设备空闲资源信息的步骤包括：
将调度器配置为通过虚拟GPU池管理所述kubernetes集群内若干节点的GPU；
利用调度器从所述虚拟GPU池查询若干虚拟GPU的信息，并根据所述若干虚拟GPU的信息确定对虚拟GPU对应的节点的GPU空闲资源信息。
在其中一个实施例中，所述根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod的步骤包括：
调度器建立第一待创建pod规范，并从若干节点选择目标节点和随机生成GPUID；
将所述目标节点和随机生成的GPUID更新到第一待创建pod规范中；
调度器将更新后的第一待创建pod规范传递给设备管理器；
若设备管理器监测到虚拟GPU池中没有所述随机生成的GPUID，则创建与所述随机生成的GPUID对应的虚拟GPU，并将虚拟GPU与随机生成的GPUID对应的真实的GPU进行链接；
利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID并利用所述目标节点创建pod，以及利用第一资源需求量配置该新创建pod的环境变量。
在其中一个实施例中，所述若接收到第二待创建pod的第二资源需求量，则获取运行第一待创建pod的计算设备资源余量的步骤包括：
通过客户端获取输入的第二待创建pod的第二资源需求量；
利用接口调用服务将所述第二资源需求量发送至调度器；
利用调度器查询虚拟GPU池中与所述随机生成的GPUID对应的虚拟GPU的资源余量。
在其中一个实施例中，所述若所述第二资源需求量小于等于所述计算设备资源余量，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在运行所述第一待创建pod的计算设备上创建并运行所述第二待创建pod的步骤包括：
调度器建立第二待创建pod规范；
若调度器确定所述第二资源需求量小于等于所述随机生成的GPUID对应的虚拟GPU的资源余量，则将所述第一待创建pod规范中的GPUID和所述第二资源需求量更新到第二待创建pod规范中，并将更新后的第二待创建pod规范传递给设备管理器；
利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID并利用所述目标节点创建pod，以及利用第二资源需求量配置该新创建pod的环境变量。
根据本发明的另一方面，提供了一种基于kubernetes的计算设备共享装置，所述装置包括：
接收模块，用于接收第一待创建pod的第一资源需求量；
空闲资源获取模块，用于获取kubernetes集群内若干节点的计算设备空闲资源信息；
第一创建模块，用于根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范在选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
资源余量获取单元，用于在若接收到第二待创建pod的第二资源需求量时，则获取运行第一待创建pod的计算设备资源余量；
第二创建模块，用于在所述第二资源需求量小于等于所述计算设备资源余量时，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在某一节点的计算设备上创建并运行所述第二待创建pod。
根据本发明的又一方面，还提供了一种计算机设备，包括：至少一个处理器；以及
存储器，所述存储器存储有可在所述处理器上运行的计算机程序，所述处理器执行所述程序时执行前述的基于kubernetes的计算设备共享方法。
根据本发明的再一方面，还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时执行前述的基于kubernetes的计算设备共享方法。
上述一种基于kubernetes的计算设备共享方法、装置、设备及存储介质，通过创建和管理自定义资源类型pod规范来实现计算设备资源共享的任务，KubeShare可以实现对计算资源的细粒度划分，同时还将技术设备作为一级资源进行管理，可以根据用户需求选择任务的运行位置，并且还实现了对计算设备资源的隔离、以及跨节点的调度，有效地提高了计算设备的资源利用效率。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的实施例。
图1为现有技术中Gaia Scheduler方案中GPU虚拟化示意图；
图2为本发明一个实施例中一种基于kubernetes的计算设备共享方法的流程示意图；
图3为本发明另一个实施例中实现GPU资源共享的工作流程图；
图4为本发明又一个实施例中一种基于kubernetes的计算设备共享装置的结构示意图；
图5为本发明另一个实施例中算机设备的内部结构图；
图6为本发明提出的一种计算机可读存储介质的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明实施例进一步详细说明。
需要说明的是，本发明实施例中所有使用“第一”和“第二”的表述均是为了区分两个相同名称非相同的实体或者非相同的参量，可见“第一”“第二”仅为了表述的方便，不应理解为对本发明实施例的限定，后续实施例对此不再一一说明。
在一个实施例中，请参照图2所示，本发明提供了一种基于kubernetes的计算设备共享方法，该方法包括以下步骤：
S100，接收第一待创建pod的第一资源需求量；
S200，获取kubernetes集群内若干节点的计算设备空闲资源信息；
S300，根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范在选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
S400，根据所述第一资源需求量和若干节点的计算设备空闲资源信息若接收到第二待创建pod的第二资源需求量，则获取运行第一待创建pod的计算设备资源余量；
S500，根据所述第一资源需求量和若干节点的计算设备空闲资源信息若所述第二资源需求量小于等于所述计算设备资源余量，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在运行所述第一待创建pod的计算设备上创建并运行所述第二待创建pod。
上述一种基于kubernetes的计算设备共享方法，通过创建和管理自定义资源类型pod规范来实现计算设备资源共享的任务，KubeShare(基于Kubernetes的开源容器编排管理工具)可以实现对计算资源的细粒度划分，同时还将技术设备作为一级资源进行管理，可以根据用户需求选择任务的运行位置，并且还实现了对计算设备资源的隔离、以及跨节点的调度，有效的提高了计算设备的资源利用效率。
在又一个实施例中，所述计算设备包括：GPU、FPGA、高性能NIC、InfiniBand和人工智能芯片。
在又一个实施例中，请参照图3所示，为了便于理解本发明的技术方案，下面以GPU作为计算设备为例进行说明。
优选地，前述步骤S100具体包括以下子步骤：
S110，通过客户端获取输入的第一待创建pod的第一资源需求量；
其中，客户端(Client)是kubernetes中分配GPU计算资源的客户端，利用客户端可以由用户指定GPUID及节点名称(nodeName)，也可以根据用户需求选择任务的运行位置。
S120，利用接口调用服务将所述第一资源需求量发送至调度器；
其中，接口调用服务(即kube-apiserverAP)客户端(Client)通过kube-apiserverAPI来提交GPU资源的配置与调度器(KuberShare)进行交互。
优选地，前述步骤S200具备包括：
S210，将调度器配置为通过虚拟GPU池管理所述kubernetes集群内若干节点的GPU；
其中，这些由KubeShare管理的共享的GPU称之为虚拟GPU(virtual GPU)，虚拟GPU池(vGPU pool)采用分布式存储，vGPU(虚拟GPU)对应的实际的物理位置可以分散在一个集群的多个节点上，使用vGPU(虚拟GPU)池来表示KubeShare管理的所有vGPU(虚拟GPU)的集合。当一个GPU加入vGPU(虚拟GPU)池时，它被分配一个唯一标识符(GPUID)，这样显式的GPU分配和可以支持绑定来解决碎片化和干扰的问题。
S220，利用调度器从所述虚拟GPU池查询若干虚拟GPU的信息，并根据所述若干虚拟GPU的信息确定对虚拟GPU对应的节点的GPU空闲资源信息。
优选地，前述步骤S300具体包括：
S310，调度器建立第一待创建pod规范，并从若干节点选择目标节点和随机生成GPUID；
S320，将所述目标节点和随机生成的GPUID更新到第一待创建pod规 范中；
S330，调度器将更新后的第一待创建pod规范传递给设备管理器；
其中，设备管理器(KubeShare-DevMgr)负责创建共享pod(sharePod)对象，然后根据从KuebShare调度器KubeShare-Sched接收到的共享pod规范(SharePodSpec)来初始化容器的环境。具体来说，它设置了英伟达可见设备(NVIDIA_VISIBLE_DEVICES)环境变量并在容器中安装了gemini调度器(gemini-scheduler)，以隔离它们的GPU使用情况。同时KuebShare设备管理器(KubeShare-DevMgr)还负责以按需或预订方式管理vGPU(虚拟GPU)池；
S340，若设备管理器监测到虚拟GPU池中没有所述随机生成的GPUID，则创建与所述随机生成的GPUID对应的虚拟GPU，并将虚拟GPU与随机生成的GPUID对应的真实的GPU进行链接；
S350，利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID(Universally Unique Identifier，通用唯一识别码)并利用所述目标节点创建pod，以及利用第一资源需求量配置该新创建pod的环境变量。
优选地，前述步骤S400具体包括以下子步骤：
S410，通过客户端获取输入的第二待创建pod的第二资源需求量；
S420，利用接口调用服务将所述第二资源需求量发送至调度器；
S430，利用调度器查询虚拟GPU池中与所述随机生成的GPUID对应的虚拟GPU的资源余量。
优选地，前述步骤S500具体包括以下子步骤：
S510，调度器建立第二待创建pod规范；
S520，若调度器确定所述第二资源需求量小于等于所述随机生成的GPUID对应的虚拟GPU的资源余量，则将所述第一待创建pod规范中的GPUID和所述第二资源需求量更新到第二待创建pod规范中，并将更新后 的第二待创建pod规范传递给设备管理器；
S530，利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID并利用所述目标节点创建pod，以及利用第二资源需求量配置该新创建pod的环境变量。
需要说明的是，若所述第二资源需求量大于等于所述GPU资源余量，则根据所述第一资源需求量和若干节点的GPU空闲资源信息确定第二待创建pod规范，并根据所述第二待创建pod规范在与运行所述第一待创建pod以外的GPU上创建并运行所述第二待创建pod；即已运行pod的GPU的计算资源不足以分配给待创建pod时，则从其他的节点或者该节点的其他空闲GPU上为其分配计算资源即可。
在又一个实施例中，下面以先后分别创建pod1和pod2为例，假设pod1其要求0.4GPU，pod2其要求0.6GPU，kubernetes集群内有三个节点，分别是节点1、节点2和节点3，并且每个节点上均有一个空闲的GPU，具体的pod1和pod2创建过程如下：
(1)初始化阶段：调度器(KubeShare-Sched)获取集群资源，KuebShare设备管理器(KubeShare-DevMgr)与三个节点上的客户端(Client)通信。客户端(Client)写入<GPU uuid>容器列表。gemini调度器(gemini-scheduler)与<GPU uuid>容器列表同步。
(2)用户通过客户端输入待创建pod的名称和0.4GPU的资源需求量，调度器(KubeShare-Sched)随即在三个节点的空闲GPU上创建pod1，假设它选择从节点1，并随机生成一个GPUID(zxcvb)，然后更新到pod1的pod规范(podSpec)中。
(3)设备管理器(KubeShare-DevMgr)发现了GPUID“zxcvb”是从节点1(slave1)上的新GPUID，然后它创建了一个vGPU(虚拟GPU)Pod， nvidia.com/gpu＝1；
(4)设备管理器(KubeShare-DevMgr)从与GPUID“zxcvb”链接的vGPU(虚拟GPU)Pod获取真实的GPU UUID“UUID-GPU1”；
(5)设备管理器(KubeShare-DevMgr)创建一个名为“pod1”的Pod，其中包括环境变量，如NVIDIA_VISIBLE_DEVICES＝UUID-GPU1，LD_PRELOAD＝GEMINI_LIB_PATH，Pod_NAME＝pod1；在资源分配时可以对GPU计算资源的细粒度划分：包括对显存的划分以及对GPU计算资源的划分，对显存的划分是对显存空间大小的划分，对GPU计算资源的划分是按照时间片轮询的方式实现。
(6)用户再次通过客户端输入pod2的名称和其需要的资源需求量0.6GPU，假设节点1上未运行其他容器，其剩余计算资源为0.6GPU，则调度器(KubeShare-Sched)决定在“pod1”使用的GPU上创建“pod2”(最佳匹配算法)。它使用nodeName＝slave1和GPUID＝zxcfb更新pod2的pod规范(podSpec)。KubeShare-DevMgr注意到GPUID“zxcvb”具有相应的GPUUUID。因此，KuebShare设备管理器(KubeShare-DevMgr)可以直接创建一个名为“pod2”的pod，其设置与“pod1”相同(除了pod名称)。
(7)当pods开始运行时，gemini库拦截了GPU函数调用。这些GPU计算请求由gemini调度器(gemini-scheduler)逐一调度，进而实现了pod1和pod2共享节点1上GPU1的计算资源。
上述一种基于kubernetes的计算设备共享方法，同时将GPU作为一级资源进行管理，可以由用户指定GPUID及节点名称(nodeName)，还实现了对GPU计算资源的隔离并且实现跨节点的调度和GPU计算资源的分配。
根据本发明的另一方面，请参照图4所示，提供了一种基于kubernetes的计算设备共享装置60，所述装置包括：
接收模块61，用于接收第一待创建pod的第一资源需求量；
空闲资源获取模块62，用于获取kubernetes集群内若干节点的计算设备空闲资源信息；
第一创建模块63，用于根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
资源余量获取单元64，用于在若接收到第二待创建pod的第二资源需求量时，则获取运行第一待创建pod的计算设备资源余量；
第二创建模块65，用于在所述第二资源需求量小于等于所述计算设备资源余量时，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在某一节点的计算设备上创建并运行所述第二待创建pod。
需要说明的是，关于基于kubernetes的计算设备共享装置的具体限定可以参见上文中对于基于kubernetes的计算设备共享方法的限定，在此不再赘述。上述基于kubernetes的计算设备共享装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。 该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现基于kubernetes的计算设备共享方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解，图5中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
如图6所示，根据本发明的又一方面，提供了一种计算机可读存储介质400，其上存储有计算机程序402，计算机程序402被处理器401执行时实现以上所述的基于kubernetes的计算设备共享方法。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、可编程ROM(Programmable Read-Only Memory，PROM)、电可编程ROM(Erasable Programmable Read-Only Memory，EPROM)、电可擦除可编程ROM(Electrically Erasable Programmable Read-Only Memory，EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(Static Dynamic Random Access Memory，SRAM)、动态RAM(Dynamic Random Access Memory，DRAM)、同步DRAM(SDRAM)、双数据率 SDRAM(Double Data Rate Sychronous Dynamic Random Access Memory，DDRSDRAM)、增强型SDRAM(Enhanced Synchronous Dynamic Random Access Memory，ESDRAM)、同步链路(Synchlink)DRAM(Sync Link Dynamic Random Access Memory，SLDRAM)、存储器总线(Rambus)直接RAM(Rambus Direct Random Access Memory，RDRAM)等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

  1. 一种基于kubernetes的计算设备共享方法，其特征在于，所述方法包括：
    接收第一待创建pod的第一资源需求量；
    获取kubernetes集群内若干节点的计算设备空闲资源信息；
    根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
    若接收到第二待创建pod的第二资源需求量，则获取运行第一待创建pod的计算设备资源余量；
    若所述第二资源需求量小于等于所述计算设备资源余量，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在运行所述第一待创建pod的计算设备上创建并运行所述第二待创建pod。
  2. 根据权利要求1所述的方法，其特征在于，所述计算设备包括：GPU、FPGA、高性能NIC、InfiniBand和人工智能芯片。
  3. 根据权利要求1所述的方法，其特征在于，所述接收第一待创建pod的第一资源需求量的步骤包括：
    通过客户端获取输入的第一待创建pod的第一资源需求量；
    利用接口调用服务将所述第一资源需求量发送至调度器。
  4. 根据权利要求3所述的方法，其特征在于，所述计算设备为GPU，所述获取kubernetes集群内若干节点的计算设备空闲资源信息的步骤包括：
    将调度器配置为通过虚拟GPU池管理所述kubernetes集群内若干节点的 GPU；
    利用调度器从所述虚拟GPU池查询若干虚拟GPU的信息，并根据所述若干虚拟GPU的信息确定对虚拟GPU对应的节点的GPU空闲资源信息。
  5. 根据权利要求4所述的方法，其特征在于，所述根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod的步骤包括：
    调度器建立第一待创建pod规范，并从若干节点选择目标节点和随机生成GPUID；
    将所述目标节点和随机生成的GPUID更新到第一待创建pod规范中；
    调度器将更新后的第一待创建pod规范传递给设备管理器；
    若设备管理器监测到虚拟GPU池中没有所述随机生成的GPUID，则创建与所述随机生成的GPUID对应的虚拟GPU，并将虚拟GPU与随机生成的GPUID对应的真实的GPU进行链接；
    利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID并利用所述目标节点创建pod，以及利用第一资源需求量配置新创建pod的环境变量。
  6. 根据权利要求5所述的方法，其特征在于，所述若接收到第二待创建pod的第二资源需求量，则获取运行第一待创建pod的计算设备资源余量的步骤包括：
    通过客户端获取输入的第二待创建pod的第二资源需求量；
    利用接口调用服务将所述第二资源需求量发送至调度器；
    利用调度器查询虚拟GPU池中与所述随机生成的GPUID对应的虚拟GPU的资源余量。
  7. 根据权利要求6所述的方法，其特征在于，所述若所述第二资源需求量小于等于所述计算设备资源余量，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在运行所述第一待创建pod的计算设备上创建并运行所述第二待创建pod的步骤包括：
    调度器建立第二待创建pod规范；
    若调度器确定所述第二资源需求量小于等于所述随机生成的GPUID对应的虚拟GPU的资源余量，则将所述第一待创建pod规范中的GPUID和所述第二资源需求量更新到第二待创建pod规范中，并将更新后的第二待创建pod规范传递给设备管理器；
    利用设备管理器获取与所述随机生成的GPUID链接的真实的GPU的UUID并利用所述目标节点创建pod，以及利用第二资源需求量配置新创建pod的环境变量。
  8. 一种基于kubernetes的计算设备共享装置，其特征在于，所述装置包括：
    接收模块，用于接收第一待创建pod的第一资源需求量；
    空闲资源获取模块，用于获取kubernetes集群内若干节点的计算设备空闲资源信息；
    第一创建模块，用于根据所述第一资源需求量和若干节点的计算设备空闲资源信息确定第一待创建pod规范，并根据所述第一待创建pod规范选择节点并在选择的节点的计算设备上创建并运行所述第一待创建pod；
    资源余量获取单元，用于在若接收到第二待创建pod的第二资源需求量时，则获取运行第一待创建pod的计算设备资源余量；
    第二创建模块，用于在所述第二资源需求量小于等于所述计算设备资源 余量时，则根据所述第二资源需求量和所述第一待创建pod规范确定第二待创建pod规范，并根据所述第二待创建pod规范在某一节点的计算设备上创建并运行所述第二待创建pod。
  9. 一种计算机设备，其特征在于，包括：
    至少一个处理器；以及
    存储器，所述存储器存储有可在所述处理器上运行的计算机程序，所述处理器执行所述程序时执行权利要求1-7任意一项所述的方法。
  10. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时执行权利要求1-7任意一项所述的方法。
PCT/CN2021/109627 2020-09-28 2021-07-30 基于kubernetes的计算设备共享方法、装置、设备及存储介质 WO2022062650A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011042517.9A CN112231049A (zh) 2020-09-28 2020-09-28 基于kubernetes的计算设备共享方法、装置、设备及存储介质
CN202011042517.9 2020-09-28

Publications (1)

Publication Number Publication Date
WO2022062650A1 true WO2022062650A1 (zh) 2022-03-31

Family

ID=74120865

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/109627 WO2022062650A1 (zh) 2020-09-28 2021-07-30 基于kubernetes的计算设备共享方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN112231049A (zh)
WO (1) WO2022062650A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114679460A (zh) * 2022-05-26 2022-06-28 天津理工大学 建筑运维监控报警系统
CN114706690A (zh) * 2022-06-06 2022-07-05 浪潮通信技术有限公司 一种Kubernetes容器共享GPU方法及系统
CN114938378A (zh) * 2022-04-22 2022-08-23 新华智云科技有限公司 一种基于kubernetes的资源过滤方法、系统、设备及存储介质
CN115550371A (zh) * 2022-12-05 2022-12-30 安超云软件有限公司 基于Kubernetes的Pod调度方法、系统及云平台

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112231049A (zh) * 2020-09-28 2021-01-15 苏州浪潮智能科技有限公司 基于kubernetes的计算设备共享方法、装置、设备及存储介质
CN112835695B (zh) * 2021-01-28 2022-12-23 北京市商汤科技开发有限公司 Pod间通信的方法和分布式计算系统
CN113127192B (zh) * 2021-03-12 2023-02-28 山东英信计算机技术有限公司 一种多个服务共享同一个gpu的方法、系统、设备及介质
US11768704B2 (en) 2021-04-28 2023-09-26 Red Hat, Inc. Increase assignment effectiveness of kubernetes pods by reducing repetitive pod mis-scheduling
CN113296950B (zh) * 2021-05-28 2022-08-19 重庆紫光华山智安科技有限公司 处理方法、装置、电子设备及可读存储介质
CN113268356B (zh) * 2021-07-20 2021-10-29 西安芯瞳半导体技术有限公司 基于LINUX系统的多GPU板卡bounding的系统、方法及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110502340A (zh) * 2019-08-09 2019-11-26 广东浪潮大数据研究有限公司 一种资源动态调整方法、装置、设备及存储介质
CN110888743A (zh) * 2019-11-27 2020-03-17 中科曙光国际信息产业有限公司 一种gpu资源使用方法、装置及存储介质
CN111506404A (zh) * 2020-04-07 2020-08-07 上海德拓信息技术股份有限公司 一种基于Kubernetes的共享GPU调度方法
KR102154446B1 (ko) * 2019-11-14 2020-09-09 한국전자기술연구원 분산·협업형 컨테이너 플랫폼 환경에서의 자원 균등 배분을 위한 고속 스케줄링 방법
CN112231049A (zh) * 2020-09-28 2021-01-15 苏州浪潮智能科技有限公司 基于kubernetes的计算设备共享方法、装置、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110502340A (zh) * 2019-08-09 2019-11-26 广东浪潮大数据研究有限公司 一种资源动态调整方法、装置、设备及存储介质
KR102154446B1 (ko) * 2019-11-14 2020-09-09 한국전자기술연구원 분산·협업형 컨테이너 플랫폼 환경에서의 자원 균등 배분을 위한 고속 스케줄링 방법
CN110888743A (zh) * 2019-11-27 2020-03-17 中科曙光国际信息产业有限公司 一种gpu资源使用方法、装置及存储介质
CN111506404A (zh) * 2020-04-07 2020-08-07 上海德拓信息技术股份有限公司 一种基于Kubernetes的共享GPU调度方法
CN112231049A (zh) * 2020-09-28 2021-01-15 苏州浪潮智能科技有限公司 基于kubernetes的计算设备共享方法、装置、设备及存储介质

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114938378A (zh) * 2022-04-22 2022-08-23 新华智云科技有限公司 一种基于kubernetes的资源过滤方法、系统、设备及存储介质
CN114938378B (zh) * 2022-04-22 2023-06-27 新华智云科技有限公司 一种基于kubernetes的资源过滤方法、系统、设备及存储介质
CN114679460A (zh) * 2022-05-26 2022-06-28 天津理工大学 建筑运维监控报警系统
CN114706690A (zh) * 2022-06-06 2022-07-05 浪潮通信技术有限公司 一种Kubernetes容器共享GPU方法及系统
CN114706690B (zh) * 2022-06-06 2022-09-16 浪潮通信技术有限公司 一种Kubernetes容器共享GPU方法及系统
CN115550371A (zh) * 2022-12-05 2022-12-30 安超云软件有限公司 基于Kubernetes的Pod调度方法、系统及云平台

Also Published As

Publication number Publication date
CN112231049A (zh) 2021-01-15

Similar Documents

Publication Publication Date Title
WO2022062650A1 (zh) 基于kubernetes的计算设备共享方法、装置、设备及存储介质
US11553034B2 (en) Server computer management system for supporting highly available virtual desktops of multiple different tenants
US10778798B2 (en) Remote service access in a container management system
CN108293041B (zh) 分布式系统、资源容器的分配方法、资源管理器及应用控制器
US9999030B2 (en) Resource provisioning method
US10061619B2 (en) Thread pool management
CN103810023B (zh) 一种云平台中分布式应用的智能部署方法及系统
US8141090B1 (en) Automated model-based provisioning of resources
US10686728B2 (en) Systems and methods for allocating computing resources in distributed computing
CN111880936A (zh) 资源调度方法、装置、容器集群、计算机设备和存储介质
CN110166507B (zh) 多资源调度方法和装置
CN113037794A (zh) 计算资源配置调度方法、装置及系统
Vanmechelen et al. Conservative distributed discrete event simulation on Amazon EC2
KR20130089779A (ko) 클라우드 컴퓨팅 기반의 혼합형 콘텐츠 제공 방법 및 그 장치
CN111078516A (zh) 分布式性能测试方法、装置、电子设备
CN116010027A (zh) 管理任务处理集群的方法、执行任务的方法及容器集群
CN113382077A (zh) 微服务调度方法、装置、计算机设备和存储介质
WO2020108337A1 (zh) 一种cpu资源调度方法及电子设备
JP6721800B2 (ja) 協調分散システム、協調分散管理装置、協調分散方法、及びプログラム
WO2019034091A1 (zh) 分布式数据计算的分配方法、装置、服务器及存储介质
CN110727511B (zh) 应用程序的控制方法、网络侧设备和计算机可读存储介质
CN109165067B (zh) Android横竖屏数据同步方法、装置、终端及可读介质
US20170269968A1 (en) Operating system support for game mode
Byun et al. DynaGrid: A dynamic service deployment and resource migration framework for WSRF-compliant applications
CN112860442A (zh) 资源配额调整方法、装置、计算机设备和存储介质

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: 21871028

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: 21871028

Country of ref document: EP

Kind code of ref document: A1