CN116340005B - 容器集群的调度方法、装置、设备及存储介质 - Google Patents

容器集群的调度方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN116340005B
CN116340005B CN202310603202.4A CN202310603202A CN116340005B CN 116340005 B CN116340005 B CN 116340005B CN 202310603202 A CN202310603202 A CN 202310603202A CN 116340005 B CN116340005 B CN 116340005B
Authority
CN
China
Prior art keywords
scheduling
container
pod
scheduled
node
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202310603202.4A
Other languages
English (en)
Other versions
CN116340005A (zh
Inventor
陈冠伟
徐锋
黄一鹏
郑少勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Good Feeling Health Industry Group Co ltd
Original Assignee
Beijing Haoxin Internet Hospital Co ltd
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 Beijing Haoxin Internet Hospital Co ltd filed Critical Beijing Haoxin Internet Hospital Co ltd
Priority to CN202310603202.4A priority Critical patent/CN116340005B/zh
Publication of CN116340005A publication Critical patent/CN116340005A/zh
Application granted granted Critical
Publication of CN116340005B publication Critical patent/CN116340005B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5077Logical partitioning of resources; Management or configuration of virtualized resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供一种容器集群的调度方法、装置、设备及存储介质,属于电数字数据处理技术领域,方法通过确定待调度容器的资源需求;基于不同节点的负载情况和待调度容器的资源需求,确定调度节点;基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用配置文件,调整调度节点的标签和污点;基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度,本发明具体结合节点的负载情况和待调度容器的资源需求确定的调度策略,更加智能化,能够有效地提高容器集群的资源利用率,提升容器调度效率。

Description

容器集群的调度方法、装置、设备及存储介质
技术领域
本发明涉及电数字数据处理技术领域,尤其涉及一种容器集群的调度方法、装置、设备及存储介质。
背景技术
随着云计算和容器技术的飞速发展,容器集群调度和管理平台成为了容器应用的关键。容器集群是由多个容器组成的集合,由于容器之间的依赖性和多个容器的协调,管理容器集群变得非常困难。为此,出现了大量的容器集群调度和管理平台,如Kubernetes、Docker Swarm等。Kubernetes是目前广泛应用的容器集群调度和管理平台,它具有良好的可扩展性和可维护性,已经成为容器集群调度和管理的事实标准。
但是,Kubernetes平台的调度算法不够灵活,导致容器调度效率相对较低。
发明内容
本发明提供一种容器集群的调度方法、装置、设备及存储介质,用以解决现有技术中容器调度效率低的缺陷。
本发明提供一种容器集群的调度方法,包括:
确定待调度容器的资源需求;
基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点;
基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;
利用所述配置文件,调整所述调度节点的标签和污点;
基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度。
根据本发明提供的一种容器集群的调度方法,所述利用所述配置文件,调整所述调度节点的标签和污点,包括:
利用tolerations字段调整所述待调度容器对污点节点的容忍度,使所述污点节点的容忍度符合所述待调度容器的容忍度;
识别所述待调度容器的特定标签,通过tolerations和nodeSelector的组合调整所述调度节点的标签为所述特定标签。
根据本发明提供的一种容器集群的调度方法,所述基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点,包括:
通过kube-proxy监视Kubernetes 的不同节点的负载情况;
基于每个所述节点的负载情况、轮替、最少链接、目标地址哈希、源地址哈希、最短预期延迟和从不排队,确定调度节点。
根据本发明提供的一种容器集群的调度方法,还包括:
检查容器集群中每个容器内的应用程序状态和应用程序可用性;
当所述应用程序状态表示对应的容器不健康时,重新启动对应的容器进行恢复;
当所述应用程序可用性表示对应的容器不可用时,将所述不可用容器的流量定向至可用容器。
根据本发明提供的一种容器集群的调度方法,还包括:
当所述容器集群内的Pod数量小于预设期望状态数时,自动创建新的Pod替代故障Pod;
当出现节点宕机或不可用时,重新调度Pod至可用节点。
根据本发明提供的一种容器集群的调度方法,还包括:
创建Horizontal Pod Autoscaler对象,确定扩容限制条件和缩容限制条件;
按照预设时间间隔监控目标Pod,确定所述目标Pod的中央处理器使用率和内存使用率;
基于所述中央处理器使用率和所述内存使用率,调整Pod实例数量。
根据本发明提供的一种容器集群的调度方法,所述基于所述中央处理器使用率和所述内存使用率,调整Pod数量,包括:
基于容器集群中的可用资源,通过Autoscaler调度新的Pod实例或停止已有的Pod实例;
所述通过Autoscaler调度新的Pod实例或停止已有的Pod实例,包括:
若所述中央处理器使用率和所述内存使用率,均超出所述扩容限制条件,则通过Autoscaler增加Pod实例数量;
若所述中央处理器使用率和所述内存使用率,均小于所述缩容限制条件,则通过Autoscaler减少Pod实例数量。
本发明还提供一种容器集群的调度装置,包括:
第一确定模块,用于确定待调度容器的资源需求;
第二确定模块,用于基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点;
修改模块,用于基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;
调整模块,用于利用所述配置文件,调整所述调度节点的标签和污点;
调度模块,用于基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度。
本发明还提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现如上述任一种所述容器集群的调度方法。
本发明还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如上述任一种所述容器集群的调度方法。
本发明提供的一种容器集群的调度方法、装置、设备及存储介质,方法通过确定待调度容器的资源需求;基于不同节点的负载情况和待调度容器的资源需求,确定调度节点;基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用配置文件,调整调度节点的标签和污点;基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度,本发明具体结合节点的负载情况和待调度容器的资源需求确定的调度策略,更加智能化,能够有效地提高容器集群的资源利用率,提升容器调度效率。
附图说明
为了更清楚地说明本发明或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的容器集群的调度方法的流程示意图;
图2是本发明实施例提供的容器集群的调度装置的结构示意图;
图3是本发明实施例提供的电子设备的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合本发明中的附图,对本发明中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
Pod:Pod是Kubernetes的最小管理单元,它可以包含一个或多个容器,并共享相同的网络命名空间和存储卷。Pod是部署应用程序的基本单元,它可以在同一主机上或跨多个主机上运行。
节点:节点是Kubernetes集群中的一个工作机器,它可以是物理机器或虚拟机。每个节点都运行Kubernetes代理程序,并接受来自Kubernetes主控制平面的指令。节点可以运行多个Pod,并提供容器运行环境。
容器:容器是一种轻量级的虚拟化技术,它将应用程序和其依赖项封装在一个独立的环境中,以便它们可以在任何地方运行。在Kubernetes中,容器是Pod的基本构建块,它们可以通过Kubernetes管理和编排来自动化进行应用程序的部署和管理。
集群:集群是由多个节点组成的Kubernetes环境。集群提供了高可用性、负载均衡、自动化扩展和故障恢复等功能,以确保应用程序始终可用并具有高可靠性。
图1是本发明实施例提供的容器集群的调度方法的流程示意图。
如图1所示,本发明实施例提供的一种容器集群的调度方法,本发明的执行主体可以是基于Kubernetes平台,构建的容器集群调度和管理平台。该平台由Master节点和多个Worker节点组成,Master节点负责集群的管理和调度,Worker节点负责容器的运行和管理。容器集群的调度方法主要包括以下步骤:
101、确定待调度容器的资源需求。
在一个具体的实现过程中,定义需要进行调度的容器为待调度容器,为了使得容器调度过程更加智能化,首先确定待调度容器的资源需求,也就是确定待调度容器所需要的资源,包括内存、容量等等,以确保待调度容器被调度后的正常运行。
102、基于不同节点的负载情况和待调度容器的资源需求,确定调度节点。
不同的节点有不同的负载情况,从而不同的节点所能提供的资源条件也是不同的,因此,需要基于不同节点所能提供的资源条件选择调度节点,确定待调度容器被调度到调度节点之后能够正常运行。
通过负载情况和待调度容器的资源需求确定出的调度节点,能够确保调度节点能够真正的运行Pod。
103、基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件。
拥有一个足够的资源配置对于 Kubernetes 集群的稳定性非常重要,因此需要确定调度节点的中央处理器(Central Processing Unit, CPU)资源、内存资源、存储容量和网络带宽。
其中,针对CPU 资源,Kubernetes 使用的 CPU 资源包括内核、容器运行及其他服务。在管理 Kubernetes 集群时需为每个节点分配指定大小的 CPU 资源,以避免过度利用CPU。
针对内存资源,如果 Kubernetes 节点内存不足,那么 Pod 容器就无法正常运行。因此,需确定节点的内存需求,并为其分配足够的内存资源。
针对存储容量, Kubernetes 中的 Pod 将数据挂载到节点上的持久卷中。因此,在选择 Kubernetes 节点时,必须确保每个节点都有足够的存储容量来支持所需的持久卷。
针对网络带宽,在 Kubernetes 中,节点之间的通信也需要消耗带宽,而且,如果Pod 容器需要访问外部服务,那么需要足够的带宽来支持网络通信。
因此,在确定出调度节点的中央处理器资源、内存资源、存储容量和网络带宽之后,便修改Kubernetes的配置文件,以确保最终的调度节点的资源分配能够满足调度节点的资源需求。
104、利用配置文件,调整调度节点的标签和污点。
对配置文件进行修改之后,能够有效地提高资源分配的精度,为了保证待调度容器被调度到节点上能够正常启动,利用配置文件调整调度节点的标签和污点。通过对污点和标签进行调整,能够避免待调度容器被分配到资源不足的节点上,确保被调度的容器的正常启动运行。
105、基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度。
通过调整后的标签和污点,确定出合理地调度策略,保证容器的高效运行。通过标签和污点选择的调度策略,确保调度节点的资源满足Pod的运行需求,保证Pod的正常运行,且调度策略能够提高容器集群的资源利用率,提升系统的稳定性,降低运维成本。
本实施例提供的一种容器集群的调度方法,通过确定待调度容器的资源需求;基于不同节点的负载情况和待调度容器的资源需求,确定调度节点;基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用配置文件,调整调度节点的标签和污点;基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度,本发明具体结合节点的负载情况和待调度容器的资源需求确定的调度策略,更加智能化,能够有效地提高容器集群的资源利用率,提升容器调度效率。
进一步的,在上述实施例的基础上,本实施例中的利用配置文件,调整调度节点的标签和污点,包括:利用tolerations字段调整待调度容器对污点节点的容忍度,使污点节点的容忍度符合待调度容器的容忍度;识别待调度容器的特定标签,通过tolerations和nodeSelector的组合调整调度节点的标签为特定标签。
具体的,Kubernetes调度器默认使用一些基本的调度规则:资源限制、亲和性规则和反亲和性规则等等,但在Kubernetes中,本实施例中通过PodSpec中的tolerations字段来自定义调度规则,该字段会告诉Kubernetes调度程序,哪些节点可以接受被调度的Pod。
利用tolerations字段调整待调度容器对污点节点的容忍度,使污点节点的容忍度符合待调度容器的容忍度。确保有一个污点节点仍可以接受Pod被调度的情况。某些节点只能运行特定标签的Pod。有时候,便需要特定标签的Pod仅运行在某些节点上。
还可以识别待调度容器的特定标签,将特定标签的nodeSelector添加到PodSpec中,如果这个标签只存在于某些节点上,那么只有这些节点才能运行该标签的Pod。可以使用kubectl命令来为Pod添加tolerations和nodeSelector字段,然后通过tolerations和nodeSelector的组合调整调度节点的标签为特定标签。从而能够保证容器的高效运行。
进一步的,在上述实施例的基础上,本实施例中的基于不同节点的负载情况和待调度容器的资源需求,确定调度节点,包括:通过kube-proxy监视Kubernetes 的不同节点的负载情况;基于每个节点的负载情况、轮替、最少链接、目标地址哈希、源地址哈希、最短预期延迟和从不排队,确定调度节点。
具体的,当在 ipvs 模式下时,通过kube-proxy 监视 Kubernetes 的不同节点的负载情况,调用 netlink 接口相应地创建 IPVS 规则, 并定期将 IPVS 规则与Kubernetes 服务和端点同步。
IPVS规则还提供了更多选项来平衡调度节点中容器的流量,包括:rr:轮替(Round-Robin)、lc:最少链接(Least Connection),即打开链接数量最少者优先、dh:目标地址哈希(Destination Hashing)、sh:源地址哈希(Source Hashing)、sed:最短预期延迟(Shortest Expected Delay)、nq:从不排队(Never Queue)。该控制循环可确保IPVS 状态与所需状态匹配,从而更好地确定出最终的调度节点。调度节点能够支持更高的网络流量吞吐量,且重定向通信的延迟更短,具有更好地性能。
进一步的,在上述实施例的基础上,本实施例中还包括:检查容器集群中每个容器内的应用程序状态和应用程序可用性;当应用程序状态表示对应的容器不健康时,重新启动对应的容器进行恢复;当应用程序可用性表示对应的容器不可用时,将不可用容器的流量定向至可用容器。当容器集群内的Pod数量小于预设期望状态数时,自动创建新的Pod替代故障Pod;当出现节点宕机或不可用时,重新调度Pod至可用节点。
具体的,在节点发生故障或容器发生故障时,能够实现自动进行故障恢复,保证容器的高可用性。通过检查容器内的应用程序状态来检测健康状况,当发现容器不健康时,通过重新启动容器来自动恢复。通过检查容器内应用程序的可用性来检测健康状况,当容器不可用时,自动剥夺它的流量并将流量重定向到健康的容器。还可以自行定义一个预设期望状态数,当Pod数量小于期望状态数时,Kubernetes自动创建新的Pod并替换故障的Pod。还可以在进行应用程序更新时,自动保持过程中的可用性,如果更新失败,自动回退到之前的版本。 当出现节点宕机或不可用时,Kubernetes会自动重新调度Pod到其他可用的Node。通过故障检测与自恢复的机制,可以帮助Kubernetes应对故障并自动恢复应用程序的可用性,确保应用程序始终处于可接受的状态。
进一步的,在上述实施例的基础上,本实施例中还包括:创建Horizontal PodAutoscaler对象,确定扩容限制条件和缩容限制条件;按照预设时间间隔监控目标Pod,确定目标Pod的中央处理器使用率和内存使用率;基于中央处理器使用率和内存使用率,调整Pod实例数量。其中,基于中央处理器使用率和内存使用率,调整Pod数量,包括:基于容器集群中的可用资源,通过Autoscaler调度新的Pod实例或停止已有的Pod实例,通过Autoscaler调度新的Pod实例或停止已有的Pod实例:若中央处理器使用率和内存使用率,均超出扩容限制条件,则通过Autoscaler增加Pod实例数量;若中央处理器使用率和内存使用率,均小于缩容限制条件,则通过Autoscaler减少Pod实例数量。
具体的,当容器集群的负载过高或过低时,为保证容器集群的高效运行。本实施例结合业务需求,智能地进行容器的扩容和缩容,提高系统的灵活性和可扩展性。
首先,创建一个Horizontal Pod Autoscaler(HPA)对象,并设置最小Pod实例数量和最大的Pod实例数量,以及扩容限制条件和缩容限制条件,扩容限制条件和缩容限制条件均包括CPU使用率和内存使用率等。HPA控制器按照预设时间间隔(默认30秒)监控指定的目标Pod,如果发现目标Pod的资源使用率即中央处理器使用率和内存使用率,超出了HPA中设置的限制条件,则自动增加Pod实例数量;如果资源使用率低于缩容限制条件,就会自动减少Pod实例数量。并且 Pod实例数量的增加和减少会由Kubernetes集群的Autoscaler来负责完成,它会基于集群中可用的资源,自动调度新的Pod实例或者停止已有的Pod实例,以实现自动扩容和缩容。
整体而言,自动扩容和缩容的整个过程都是由Kubernetes集群的自动化机制自动完成的,用户只需要按照指定的方式设置好HPA,就可以享受到这种高效且无需手动干预的自动化扩缩容功能。采用水平扩容和垂直扩容相结合的方式,结合容器集群的负载情况和业务需求,智能地进行容器的扩容和缩容,扩容缩容方式更加智能化。
本实施例的容器集群调度和管理平台适用于任何需要部署和管理应用程序的场景,特别适用于需要高可用性、高可扩展性、自动化部署的应用程序。并具有很好的实用性和推广价值,可以在云计算、大数据等领域中得到广泛应用。
基于同一总的发明构思,本发明还保护一种容器集群的调度装置,下面对本发明提供的容器集群的调度装置进行描述,下文描述的容器集群的调度装置与上文描述的容器集群的调度方法可相互对应参照。
图2是本发明实施例提供的容器集群的调度装置的结构示意图;
如图2所示,本发明实施例提供的一种容器集群的调度装置,包括:
第一确定模块201,用于确定待调度容器的资源需求;
第二确定模块202,用于基于不同节点的负载情况和待调度容器的资源需求,确定调度节点;
修改模块203,用于基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;
调整模块204,用于利用配置文件,调整调度节点的标签和污点;
调度模块205,用于基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度。
本实施例提供的一种容器集群的调度装置,通过确定待调度容器的资源需求;基于不同节点的负载情况和待调度容器的资源需求,确定调度节点;基于调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用配置文件,调整调度节点的标签和污点;基于标签和污点,确定调度策略,并基于调度策略,对待调度容器进行调度,本发明具体结合节点的负载情况和待调度容器的资源需求确定的调度策略,更加智能化,能够有效地提高容器集群的资源利用率,提升容器调度效率。
进一步的,本实施例中的调整模块204,具体用于:
利用tolerations字段调整所述待调度容器对污点节点的容忍度,使所述污点节点的容忍度符合所述待调度容器的容忍度;
识别所述待调度容器的特定标签,通过tolerations和nodeSelector的组合调整所述调度节点的标签为所述特定标签。
进一步的,本实施例中的第二调度模块202,具体用于:
通过kube-proxy监视Kubernetes 的不同节点的负载情况;
基于每个所述节点的负载情况、轮替、最少链接、目标地址哈希、源地址哈希、最短预期延迟和从不排队,确定调度节点。
进一步的,本实施例中还包括:故障恢复模块,用于:
检查容器集群中每个容器内的应用程序状态和应用程序可用性;
当所述应用程序状态表示对应的容器不健康时,重新启动对应的容器进行恢复;
当所述应用程序可用性表示对应的容器不可用时,将所述不可用容器的流量定向至可用容器。
进一步的,本实施例中的故障恢复模块,还用于:
当所述容器集群内的Pod数量小于预设期望状态数时,自动创建新的Pod替代故障Pod;
当出现节点宕机或不可用时,重新调度Pod至可用节点。
进一步的,本实施例中还包括扩缩容模块,用于:
创建Horizontal Pod Autoscaler对象,确定扩容限制条件和缩容限制条件;
按照预设时间间隔监控目标Pod,确定所述目标Pod的中央处理器使用率和内存使用率;
基于所述中央处理器使用率和所述内存使用率,调整Pod实例数量。
进一步的,本实施例中的扩缩容模块,具体用于:
基于容器集群中的可用资源,通过Autoscaler调度新的Pod实例或停止已有的Pod实例;
若所述中央处理器使用率和所述内存使用率,均超出所述扩容限制条件,则通过Autoscaler增加Pod实例数量;
若所述中央处理器使用率和所述内存使用率,均小于所述缩容限制条件,则通过Autoscaler减少Pod实例数量。
图3是本发明实施例提供的电子设备的结构示意图。
如图3所示,该电子设备可以包括:处理器(processor)310、通信接口(Communications Interface)320、存储器(memory)330和通信总线340,其中,处理器310,通信接口320,存储器330通过通信总线340完成相互间的通信。处理器310可以调用存储器330中的逻辑指令,以执行容器集群的调度方法,该方法包括:确定待调度容器的资源需求;基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点;基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用所述配置文件,调整所述调度节点的标签和污点;基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度。
此外,上述的存储器330中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
另一方面,本发明还提供一种计算机程序产品,所述计算机程序产品包括计算机程序,计算机程序可存储在非暂态计算机可读存储介质上,所述计算机程序被处理器执行时,计算机能够执行上述各方法所提供的容器集群的调度方法,该方法包括:确定待调度容器的资源需求;基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点;基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用所述配置文件,调整所述调度节点的标签和污点;基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度。
又一方面,本发明还提供一种非暂态计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现以执行上述各方法提供的容器集群的调度方法,该方法包括:确定待调度容器的资源需求;基于不同节点的负载情况和所述待调度容器的资源需求,确定调度节点;基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;利用所述配置文件,调整所述调度节点的标签和污点;基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (6)

1.一种容器集群的调度方法,其特征在于,包括:
确定待调度容器的资源需求;
通过kube-proxy监视Kubernetes 的不同节点的负载情况;
基于每个所述节点的负载情况、轮替、最少链接、目标地址哈希、源地址哈希、最短预期延迟和从不排队,确定调度节点;
基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;
利用所述配置文件,调整所述调度节点的标签和污点,包括:利用tolerations字段调整所述待调度容器对污点节点的容忍度,使所述污点节点的容忍度符合所述待调度容器的容忍度;识别所述待调度容器的特定标签,通过tolerations和nodeSelector的组合调整所述调度节点的标签为所述特定标签;
基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度;
创建Horizontal Pod Autoscaler对象,确定扩容限制条件和缩容限制条件;按照预设时间间隔监控目标Pod,确定所述目标Pod的中央处理器使用率和内存使用率;基于容器集群中的可用资源,通过Autoscaler调度新的Pod实例或停止已有的Pod实例;
所述通过Autoscaler调度新的Pod实例或停止已有的Pod实例,包括:若所述中央处理器使用率和所述内存使用率,均超出所述扩容限制条件,则通过Autoscaler增加Pod实例数量;若所述中央处理器使用率和所述内存使用率,均小于所述缩容限制条件,则通过Autoscaler减少Pod实例数量。
2.根据权利要求1所述的容器集群的调度方法,其特征在于,还包括:
检查容器集群中每个容器内的应用程序状态和应用程序可用性;
当所述应用程序状态表示对应的容器不健康时,重新启动对应的容器进行恢复;
当所述应用程序可用性表示对应的容器不可用时,将所述不可用容器的流量定向至可用容器。
3.根据权利要求2所述的容器集群的调度方法,其特征在于,还包括:
当所述容器集群内的Pod数量小于预设期望状态数时,自动创建新的Pod替代故障Pod;
当出现节点宕机或不可用时,重新调度Pod至可用节点。
4.一种容器集群的调度装置,其特征在于,包括:
第一确定模块,用于确定待调度容器的资源需求;
第二确定模块,用于通过kube-proxy监视Kubernetes 的不同节点的负载情况;基于每个所述节点的负载情况、轮替、最少链接、目标地址哈希、源地址哈希、最短预期延迟和从不排队,确定调度节点;
修改模块,用于基于所述调度节点的中央处理器资源、内存资源、存储容量和网络带宽,修改Kubernetes的配置文件;
调整模块,用于利用所述配置文件,调整所述调度节点的标签和污点,利用tolerations字段调整所述待调度容器对污点节点的容忍度,使所述污点节点的容忍度符合所述待调度容器的容忍度;识别所述待调度容器的特定标签,通过tolerations和nodeSelector的组合调整所述调度节点的标签为所述特定标签;
调度模块,用于基于所述标签和污点,确定调度策略,并基于所述调度策略,对所述待调度容器进行调度;
创建模块,用于创建Horizontal Pod Autoscaler对象,确定扩容限制条件和缩容限制条件;按照预设时间间隔监控目标Pod,确定所述目标Pod的中央处理器使用率和内存使用率;基于容器集群中的可用资源,通过Autoscaler调度新的Pod实例或停止已有的Pod实例;所述通过Autoscaler调度新的Pod实例或停止已有的Pod实例,包括:若所述中央处理器使用率和所述内存使用率,均超出所述扩容限制条件,则通过Autoscaler增加Pod实例数量;若所述中央处理器使用率和所述内存使用率,均小于所述缩容限制条件,则通过Autoscaler减少Pod实例数量。
5.一种电子设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述程序时实现如权利要求1至3任一项所述容器集群的调度方法。
6.一种非暂态计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至3任一项所述容器集群的调度方法。
CN202310603202.4A 2023-05-26 2023-05-26 容器集群的调度方法、装置、设备及存储介质 Active CN116340005B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310603202.4A CN116340005B (zh) 2023-05-26 2023-05-26 容器集群的调度方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310603202.4A CN116340005B (zh) 2023-05-26 2023-05-26 容器集群的调度方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN116340005A CN116340005A (zh) 2023-06-27
CN116340005B true CN116340005B (zh) 2023-08-15

Family

ID=86886181

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310603202.4A Active CN116340005B (zh) 2023-05-26 2023-05-26 容器集群的调度方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN116340005B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117009060B (zh) * 2023-09-27 2024-01-12 腾讯科技(深圳)有限公司 资源调度方法、装置、设备及存储介质
CN117421123B (zh) * 2023-11-03 2024-04-19 摩尔线程智能科技(上海)有限责任公司 一种gpu资源调整方法及系统、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111737003A (zh) * 2020-06-24 2020-10-02 重庆紫光华山智安科技有限公司 Pod均衡调度方法、装置、主节点及存储介质
CN113553140A (zh) * 2021-09-17 2021-10-26 阿里云计算有限公司 资源调度方法、设备及系统
CN114237894A (zh) * 2021-12-17 2022-03-25 中国电信股份有限公司 容器调度方法、装置、设备以及可读存储介质
CN114880100A (zh) * 2022-05-27 2022-08-09 中国工商银行股份有限公司 容器动态调度方法、装置、计算机设备和存储介质
CN115357459A (zh) * 2022-03-01 2022-11-18 中教云智数字科技有限公司 一种基于kubernetes的日志搜集方法
CN115865942A (zh) * 2022-11-17 2023-03-28 中国平安人寿保险股份有限公司 云平台资源监控方法、电子设备、计算机可读存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111522639B (zh) * 2020-04-16 2022-11-01 南京邮电大学 Kubernetes集群架构系统下多维资源调度方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111737003A (zh) * 2020-06-24 2020-10-02 重庆紫光华山智安科技有限公司 Pod均衡调度方法、装置、主节点及存储介质
CN113553140A (zh) * 2021-09-17 2021-10-26 阿里云计算有限公司 资源调度方法、设备及系统
CN114237894A (zh) * 2021-12-17 2022-03-25 中国电信股份有限公司 容器调度方法、装置、设备以及可读存储介质
CN115357459A (zh) * 2022-03-01 2022-11-18 中教云智数字科技有限公司 一种基于kubernetes的日志搜集方法
CN114880100A (zh) * 2022-05-27 2022-08-09 中国工商银行股份有限公司 容器动态调度方法、装置、计算机设备和存储介质
CN115865942A (zh) * 2022-11-17 2023-03-28 中国平安人寿保险股份有限公司 云平台资源监控方法、电子设备、计算机可读存储介质

Also Published As

Publication number Publication date
CN116340005A (zh) 2023-06-27

Similar Documents

Publication Publication Date Title
CN116340005B (zh) 容器集群的调度方法、装置、设备及存储介质
CN114138486B (zh) 面向云边异构环境的容器化微服务编排方法、系统及介质
CN111966500B (zh) 资源调度方法、装置、电子设备及存储介质
CN111818159B (zh) 数据处理节点的管理方法、装置、设备及存储介质
CN106133693B (zh) 虚拟机的迁移方法、装置及设备
CN110838939B (zh) 一种基于轻量级容器的调度方法及边缘物联管理平台
KR20130136449A (ko) 데이터-센터 서비스의 제어된 자동 힐링
WO2019160030A1 (ja) サービス提供システム、資源割り当て方法、及び資源割り当てプログラム
CN110221920B (zh) 部署方法、装置、存储介质及系统
CN106681839B (zh) 弹性计算动态分配方法
US20230266999A1 (en) Resource scheduling method, resource scheduling system, and device
CN112910937B (zh) 容器集群中的对象调度方法、装置、服务器和容器集群
CN111459641A (zh) 一种跨机房的任务调度和任务处理的方法及装置
CN115297124B (zh) 一种系统运维管理方法、装置及电子设备
CN111459642A (zh) 一种分布式系统中故障处理和任务处理方法及装置
US20230037293A1 (en) Systems and methods of hybrid centralized distributive scheduling on shared physical hosts
CN113918281A (zh) 一种提升容器云资源扩展效率的方法
CN114968601A (zh) 一种按比例预留资源的ai训练作业的调度方法和调度系统
CN113672391B (zh) 一种基于Kubernetes的并行计算任务调度方法与系统
CN113961353A (zh) 一种ai任务的任务处理方法和分布式系统
CN111064586B (zh) 一种分布式并行计费方法
CN116680078A (zh) 云计算资源调度方法、装置、设备以及计算机存储介质
CN112612604B (zh) 基于Actor模型的任务调度方法、装置
KR102231359B1 (ko) 고성능 클라우드 서비스를 위한 단일 가상화 시스템 및 프로세스 스케줄링 방법
CN109981731B (zh) 一种数据处理方法和设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20240123

Address after: Room 1502, 13th Floor, No. 52 North Fourth Ring West Road, Haidian District, Beijing, 102200

Patentee after: Good Feeling Health Industry Group Co.,Ltd.

Country or region after: China

Address before: Room 1101-2, Building 1, Yard 22, Longshui Road, Changping District, Beijing 102200

Patentee before: Beijing Haoxin Internet Hospital Co.,Ltd.

Country or region before: China