CN112214323B - 一种资源回收方法、装置及计算机可读存储介质 - Google Patents

一种资源回收方法、装置及计算机可读存储介质 Download PDF

Info

Publication number
CN112214323B
CN112214323B CN202011081914.7A CN202011081914A CN112214323B CN 112214323 B CN112214323 B CN 112214323B CN 202011081914 A CN202011081914 A CN 202011081914A CN 112214323 B CN112214323 B CN 112214323B
Authority
CN
China
Prior art keywords
pod
sidecar
container
sidecar container
restart
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
CN202011081914.7A
Other languages
English (en)
Other versions
CN112214323A (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.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology 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 Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202011081914.7A priority Critical patent/CN112214323B/zh
Publication of CN112214323A publication Critical patent/CN112214323A/zh
Application granted granted Critical
Publication of CN112214323B publication Critical patent/CN112214323B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022Mechanisms to release resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明提供了一种资源回收方法、装置及计算机可读存储介质,属于网络设备的技术领域,解决了Jenkins架构中主从节点失联后资源无法得到回收且失联任务执行失败的技术问题。一种资源回收方法,应用于Jenkins架构的从节点,方法包括以下步骤:在pod中设置第一sidecar容器和第二sidecar容器;第一sidecar容器持续检测pod中其他容器的健康状态;当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;若pod重启成功,pod继续执行任务;若pod重启失败,所述第二sidecar容器重启pod对应的任务,第一sidecar容器删除pod。

Description

一种资源回收方法、装置及计算机可读存储介质
技术领域
本发明涉及网络设备技术领域,尤其是涉及一种主节点资源回收方法及计算机可读存储介质。
背景技术
随着网络技术的不断发展,Jenkins(一种持续集成工具,用于监控持续重复的工作)架构的应用率越来越高,Jenkins架构的自动回收机制对于Jenkins架构的技术优化起到关键作用。
目前,Jenkins是典型的主-从(master-slave)架构,具有主节点和从节点。主节点是管理节点,负责将用户提交的作业调度派发至满足资源需求的从节点运行。从节点是工作节点,只负责运行主节点分配的作业,并定时汇报作业的状态信息和节点的资源使用情况到主节点。如果作业异常退出或者运行超时,需及时释放作业占用的资源,以供其他作业使用。当任务过多时,会造成Jenkins被压死,进而导致Jenkins自动重启,Jenkins自动重启时,已经启动起来的从节点上的pod(容器组群)与主节点失联,按照机制,从节点会一直尝试与主节点重新获取连接,如果最终未能取得连接,那么从节点的pod就会一直处于失联状态,资源无法得到回收。在Jenkins中任务的状态也会一直显示为进程中,底层pod为节点驱逐状态。但是Jenkins的主节点与从节点的交互机制中已经指定了nodeName(节点名称)这个参数,导致从节点的pod在资源不足的时候无法调度到别的节点,只能一直处于节点驱逐状态。
因此,现有的Jenkins意外重启时,主节点与从节点就会失联,pod会长期处于节点驱逐状态,驱逐状态的pod会占用从节点的位置,进而导致从节点不能执行新的任务,资源无法得到回收,并且失联pod上的任务也会执行失败。
发明内容
本发明的目的在于提供一种资源回收方法、装置及计算机可读存储介质,以解决Jenkins架构中主从节点失联后资源无法得到回收且失联任务执行失败的技术问题。
第一方面,本发明提供一种资源回收方法,应用于Jenkins架构的从节点,所述方法包括以下步骤:
在pod中设置第一sidecar容器和第二sidecar容器;
第一sidecar容器持续检测pod中其他容器的健康状态;
当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;
若pod重启成功,pod继续执行任务;
若pod重启失败,所述第二sidecar容器重启pod对应的任务,第一sidecar容器删除pod。
进一步的,第一sidecar容器或第二sidecar容器伴随pod的整个生命周期。
进一步的,在所述第二sidecar容器重启pod对应的任务的步骤,包括:
所述第二sidecar容器生成pod重启失败的信息;
从节点模拟客户端访问主节点重启pod对应的任务。
进一步的,从节点模拟客户端访问主节点重启pod对应的任务的步骤之后,还包括:触发主节点分配重启失败的pod对应的任务。
进一步的,触发主节点分配重启失败的pod对应的任务的步骤之后,还包括:接收到主节点分配的重启失败的pod对应的任务。
进一步的,在接收到主节点分配的重启失败的pod对应的任务的步骤之后,还包括:基于接收到的任务启动pod,并在pod中设置第一sidecar容器和第二sidecar容器。
第二方面,本发明还提供一种资源回收装置,应用于基于Jenkins架构的从节点,所述装置包括:
设置模块,用于在pod中设置第一sidecar容器和第二sidecar容器;
第一sidecar容器,用于持续检测pod中其他容器的健康状态;当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;若pod重启成功,pod继续执行任务;若pod重启失败,第一sidecar容器删除pod。
第二sidecar容器,用于重启pod,若pod重启失败,第二sidecar容器重启pod对应的任务。
第三方面,本发明还提供一种计算机可读存储介质,所述计算机可读存储介质存储有机器可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令促使所述处理器运行第一方面的方法。
本发明提供的一种资源回收方法,应用于基于Jenkins架构的从节点,所述方法包括以下步骤:在pod中设置第一sidecar(边车)容器和第二sidecar容器;第一sidecar容器持续检测pod中其他容器的健康状态;当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;若pod重启成功,pod继续执行任务;若pod重启失败,所述第二sidecar容器重启pod对应的任务,第一sidecar容器删除pod。也就是当从节点与主节点失联时,失联从节点对应pod中的容器健康为异常状态,此时第一sidecar容器可以检测到该健康异常的容器,第二sidecar容器会重启健康异常的容器所在的pod。如果重启成功,那么pod正常工作,如果重启失败,那么第二sidecar容器会重启失联pod对应的任务,在失联任务重启后第一sidecar容器删除失联pod。失联从节点上的资源得到了释放,又可以继续接收新的任务。不仅达到了资源回收的目的,并且失联的任务也能够重新被执行。采用本发明提供的资源回收方法,利用第一sidecar可以检测到健康异常的容器并删除此容器所在的pod,及第二sidecar可以重启失联pod,且可以在失联pod重启失败后继续重启失联pod对应的任务的方法,使得从节点资源得到了释放,从而主节点资源得到了回收,且失联任务也可以被重新执行。
相应地,本发明实施例提供的一种资源回收装置及计算机可读存储介质,也同样具有上述技术效果。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例中的Jenkins架构示意图;
图2为本发明实施例提供的资源回收方法流程图;
图3为本发明实施例提供的资源回收装置示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图对本发明的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例中所提到的术语“包括”和“具有”以及它们的任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括其他没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。
Jenkins是一个广泛用于持续构建的可视化web工具的服务交付,就是各种项目的"自动化"编译、打包、分发部署。自动化部署有很多优点,比如降低成本,提高生产力,高可用,更可靠,性能优化等。Jenkins是典型的主-从(master-slave)架构。主从节点,节点可以理解成集群中提供计算资源的机器。集群作业调度系统一般采用主从结构,即集群中存在2种类型的节点,主节点和从节点主节点是管理节点,负责将用户提交的作业调度派发至满足资源需求的从节点运行。从节点是工作节点,只负责运行主节点分配的作业,并定时汇报作业的状态信息和节点的资源使用情况到主节点。主从节点的实现一般是通过分布式锁,先启动的节点获取到分布式锁后,就是主节点,没有获取到分布式锁的节点就是从节点。作业执行器一般运行在从节点,负责接收主节点派发的作业请求,在从节点将作业运行起来,并监控作业的状态和资源使用情况,定时汇报到主节点。如果作业异常退出或者运行超时,需及时释放作业占用的资源,以供其他作业使用。表现在Jenkins上面就是主/从节点,相当于Server(服务)和agent(一种软硬件系统)的概念。主节点提供web(网络)接口让用户来管理工作和从节点,工作可以运行在主节点本机或者被分配到从节点上运行。一个主节点可以关联多个从节点用来为不同的工作或相同的工作的不同配置来服务。当工作被分配到从节点上运行的时候,此时主节点和从节点其实是建立的双向字节流的连接。
以ICKS云管理平台的为例,配置完流水线任务后对流水线进行执行,正常情况下,基于kubernetes(用于部署,规划,更新,维护的一种机制)插件,由主节点调度资源,在从节点生成对应的pod,运行任务并且与主节点维持通信。一旦出现异常情况,比如Jenkins高负担重启/或者网络不通/某些镜像拉取不到,造成主节点与从节点失联,pod状态会变为evicted(即节点驱逐状态)。由于这是主节点调度从节点创建一个pod,而没有底层类似的deployment(部署)或者sts资源,导致一旦出现驱逐状态或者其他kubernetes的pod状态不会重启,而且nodename(节点名称)这个字段即使重启也不会调度到其他的从节点上面,从而也会导致失联pod对应的任务执行失败。
因此,现有的Jenkins意外重启时,主节点与从节点就会失联,pod会长期处于节点驱逐状态,驱逐状态的pod会占用从节点的位置,进而导致从节点不能执行新的任务,资源无法得到回收,并且失联pod上的任务也会执行失败。
为解决以上问题,本发明实施例提供一种资源回收方法。
实施例1:
如图1、图2所示,本发明实施例提供一种资源回收方法,应用于Jenkins架构的从节点,方法包括以下步骤:
S1:在pod中设置第一sidecar容器和第二sidecar容器。设置第一sidecar容器用于资源回收,设置第二sidecar容器用于重启pod及重启失联任务。
S2:第一sidecar容器持续检测pod中其他容器的健康状态。这样可以随时检测到健康异常的容器,保证了资源的及时回收。
S3:当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod。发现失联pod后,首先尝试重启pod,有可能重启成功的情况下,尽量不去做干预。
S4:若pod重启成功,pod继续执行任务。若pod重启成功,此时pod就恢复了正常状态,从而能够正常执行任务。
S5:若pod重启失败,第二sidecar容器重启pod对应的任务,第一sidecar容器删除pod。第二sidecar容器会在第一sidecar容器删除失联pod前,将失联pod上对应的任务进行重启,从而不仅达到了资源回收的目的,也确保了失联任务可以重新被执行。
例如:以ICKS云管理平台idevops(Development和Operations的组合词:过程、方法与系统的统称)为例,支持基于代码源的多运行环境的一次创建,持续集成、持续交付、持续部署,同时可以设置定时任务保证自动化构建,这个过程是基于底层Jenkins做的。当使用定时策略定时构建的时候,由于触发的模块很多,比如10个项目同时触发定时任务,Jenkins主节点调度器执行调度任务,从集群中挑选出满足资源需求的节点,将作业派发到节点运行。通过提供的调度策略如先来先服务、抢占、独占和公平共享等,满足不同的作业调度需求。作业执行器一般运行在从节点,负责接收主节点派发的作业请求,在从节点将作业运行起来,并监控作业的状态和资源使用情况,定时汇报到主节点。当任务过多,一次性无法完成这样的调度,就需要放在队列里面等待。而且集群中可以支配的资源也是有限的,经常看到任务的涌入压迫,造成Jenkins被压死,造成自动重启,这个时候已经启动起来的从节点pod与主节点失联,按照机制,从节点会一直尝试与主节点重新获取连接,如果最终未能取得连接,那么从节点的pod就会一直处于失联状态,资源无法得到回收,在Jenkins中任务的状态也会一直显示为进程中,底层pod为驱逐状态。但是Jenkins的主节点与从节点的交互机制中已经指定了nodeName这个参数,导致从节点pod在由于资源不足的时候无法调度到别的节点,只能一直处于驱逐状态。导致从节点的pod在资源不足的时候无法调度到别的节点,只能一直处于节点驱逐状态。
当从节点与主节点失联时,失联从节点对应pod中的容器健康为异常状态,第一sidecar可以检测到该健康异常的容器。此时第二sidecar重启异常pod,若重启成功,则pod正常执行任务,若重启失败,第二sidecar将重启pod对应的任务,失联的任务将被重新执行。任务重启后,第一sidecar删除异常pod,失联从节点上的资源得到了释放,原本失联从节点又可以继续接收新的任务,从而达到了主节点资源回收的目的。
采用本发明提供的资源回收方法,利用第一sidecar可以检测到健康异常的容器并删除此容器所在的pod,及第二sidecar可以重启失联pod,且可以在失联pod重启失败后继续重启失联pod对应的任务的方法,使得从节点资源得到了释放,从而主节点资源得到了回收,且失联任务也可以被重新执行。
在一种可能的实施方式中,第一sidecar容器或第二sidecar容器伴随pod的整个生命周期。这样第一sidecar容器就可以持续检测并删除重启失败的异常pod,且第二sidecar容器在异常pod被删除前,可以重启失联任务,这样失联从节点上的任务可以被重新执行,满足了CICD(Continuous Integration,Continuous Deployment,ContinuousDelivery:持续集成,持续部署,持续交付)的需求,优化了从节点的资源回收机制。
在一种可能的实施方式中,在第二sidecar容器重启pod对应的任务的步骤,包括:第二sidecar容器生成pod重启失败的信息,从节点模拟客户端访问主节点重启pod对应的任务。主从节点失联后,从节点依然可以模拟客户端访问主节点,从而触发了主节点重启失联任务。
基于此,从节点模拟客户端访问主节点重启pod对应的任务的步骤之后,还包括:触发主节点分配重启失败的pod对应的任务。主节点将失联任务重新分配给任意从节点,确保失联任务的顺利执行。
基于此,触发主节点分配重启失败的pod对应的任务的步骤之后,还包括:接收到主节点分配的重启失败的pod对应的任务,接收到任务的从节点将正常执行工作。
基于此,在接收到主节点分配的重启失败的pod对应的任务的步骤之后,还包括:基于接收到的任务启动pod,并在pod中设置第一sidecar容器和第二sidecar容器。从节点将继续在pod中设置sidecar容器,确保意外重启后,失联任务的重新执行及主节点的资源可以得到回收。
实施例2:
如图3所示,本发明实施例还提供一种资源回收装置,应用于Jenkins架构的从节点,装置包括:
设置模块,用于在pod中设置第一sidecar容器和第二sidecar容器;
第一sidecar容器,用于持续检测pod中其他容器的健康状态;当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;若pod重启成功,pod继续执行任务;若pod重启失败,第一sidecar容器删除pod。
第二sidecar容器,用于重启pod,若pod重启失败,第二sidecar容器重启pod对应的任务。
实施例3:
本发明实施例还提供一种计算机可读存储介质,计算机可读存储介质存储有机器可运行指令,计算机可运行指令在被处理器调用和运行时,计算机可运行指令促使处理器运行实施例1提供的方法。
在本发明所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
又例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,再例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明提供的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上所述实施例,仅为本发明的具体实施方式,用以说明本发明的技术方案,而非对其限制,本发明的保护范围并不局限于此,尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本发明实施例技术方案的范围。都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。

Claims (7)

1.一种资源回收方法,其特征在于,应用于Jenkins架构的从节点,所述方法包括以下步骤:
在pod中设置第一sidecar容器和第二sidecar容器;
第一sidecar容器持续检测pod中其他容器的健康状态;
当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;
若pod重启成功,pod继续执行任务;
若pod重启失败,所述第二sidecar容器重启pod对应的任务,第一sidecar容器删除pod;
第一sidecar容器或第二sidecar容器伴随pod的整个生命周期。
2.根据权利要求1所述的资源回收方法,其特征在于,在所述第二sidecar容器重启pod对应的任务的步骤,包括:
所述第二sidecar容器生成pod重启失败的信息;
从节点模拟客户端访问主节点重启pod对应的任务。
3.根据权利要求2所述的资源回收方法,其特征在于,从节点模拟客户端访问主节点重启pod对应的任务的步骤之后,还包括:
触发主节点分配重启失败的pod对应的任务。
4.根据权利要求3所述的资源回收方法,其特征在于,触发主节点分配重启失败的pod对应的任务的步骤之后,还包括:
接收到主节点分配的重启失败的pod对应的任务。
5.根据权利要求4所述的资源回收方法,其特征在于,在接收到主节点分配的重启失败的pod对应的任务的步骤之后,还包括:
基于接收到的任务启动pod,并在pod中设置第一sidecar容器和第二sidecar容器。
6.一种资源回收装置,其特征在于,应用于Jenkins架构的从节点,所述装置包括:
设置模块,用于在pod中设置第一sidecar容器和第二sidecar容器;
第一sidecar容器,用于持续检测pod中其他容器的健康状态;当第一sidecar容器检测到其他容器的健康状态异常时,第二sidecar容器重启pod;若pod重启成功,pod继续执行任务;若pod重启失败,第一sidecar容器删除pod;
第二sidecar容器,用于重启pod,若pod重启失败,第二sidecar容器重启pod对应的任务;
第一sidecar容器或第二sidecar容器伴随pod的整个生命周期。
7.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有机器可运行指令,所述计算机可运行指令在被处理器调用和运行时,所述计算机可运行指令促使所述处理器运行所述权利要求1至5任一项所述的方法。
CN202011081914.7A 2020-10-12 2020-10-12 一种资源回收方法、装置及计算机可读存储介质 Active CN112214323B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011081914.7A CN112214323B (zh) 2020-10-12 2020-10-12 一种资源回收方法、装置及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011081914.7A CN112214323B (zh) 2020-10-12 2020-10-12 一种资源回收方法、装置及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN112214323A CN112214323A (zh) 2021-01-12
CN112214323B true CN112214323B (zh) 2022-06-14

Family

ID=74054414

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011081914.7A Active CN112214323B (zh) 2020-10-12 2020-10-12 一种资源回收方法、装置及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN112214323B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108628613A (zh) * 2018-05-02 2018-10-09 山东汇贸电子口岸有限公司 基于国产cpu和os的容器集群有状态服务的实现方法
CN109558260A (zh) * 2018-11-20 2019-04-02 北京京东尚科信息技术有限公司 Kubernetes故障排除系统、方法、设备及介质
CN110798375A (zh) * 2019-09-29 2020-02-14 烽火通信科技股份有限公司 一种增强容器集群高可用性的监控方法、系统及终端设备
WO2020119060A1 (zh) * 2018-12-14 2020-06-18 深圳市网心科技有限公司 容器资源调度方法和系统、服务器及计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108628613A (zh) * 2018-05-02 2018-10-09 山东汇贸电子口岸有限公司 基于国产cpu和os的容器集群有状态服务的实现方法
CN109558260A (zh) * 2018-11-20 2019-04-02 北京京东尚科信息技术有限公司 Kubernetes故障排除系统、方法、设备及介质
WO2020119060A1 (zh) * 2018-12-14 2020-06-18 深圳市网心科技有限公司 容器资源调度方法和系统、服务器及计算机可读存储介质
CN110798375A (zh) * 2019-09-29 2020-02-14 烽火通信科技股份有限公司 一种增强容器集群高可用性的监控方法、系统及终端设备

Also Published As

Publication number Publication date
CN112214323A (zh) 2021-01-12

Similar Documents

Publication Publication Date Title
CN102981931B (zh) 虚拟机备份方法及装置
EP2614436B1 (en) Controlled automatic healing of data-center services
US7779298B2 (en) Distributed job manager recovery
US8191072B2 (en) System and method for shifting workloads across platform in a hybrid system
CN109408210B (zh) 分布式定时任务管理方法及系统
CN103414712B (zh) 一种分布式虚拟桌面管理系统和方法
CN113569987A (zh) 模型训练方法和装置
CN105354113B (zh) 一种服务器、管理服务器的系统和方法
US20070206611A1 (en) Effective high availability cluster management and effective state propagation for failure recovery in high availability clusters
CN106156939B (zh) 基于作业流的分布式调度系统及应用方法
US20080141065A1 (en) Parallel computer system
US20110131448A1 (en) Performing a workflow having a set of dependancy-related predefined activities on a plurality of task servers
JP2006011992A (ja) クラスタ構成コンピュータシステムの系切替方法
CN109558260B (zh) Kubernetes故障排除系统、方法、设备及介质
WO2015139510A1 (zh) 一种集群部署方法
CN112199178B (zh) 一种基于轻量化容器的云服务动态调度方法及系统
CN105589756A (zh) 批处理集群系统以及方法
CN113312153A (zh) 一种集群部署方法、装置、电子设备及存储介质
CN110798339A (zh) 一种基于分布式任务调度框架的任务容灾方法
CN112214323B (zh) 一种资源回收方法、装置及计算机可读存储介质
CN116339911A (zh) 一种基于K8S的弹性仿真Modelica模型的方法、系统、设备及介质
CN112612604B (zh) 基于Actor模型的任务调度方法、装置
CN115964142A (zh) 应用服务的管理方法、设备及存储介质
CN115499493A (zh) 异步事务处理方法、装置、存储介质及计算机设备
CN110188008B (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