CN111831394B - 采用kubernetes部署有状态pod的方法及装置 - Google Patents

采用kubernetes部署有状态pod的方法及装置 Download PDF

Info

Publication number
CN111831394B
CN111831394B CN202010620544.3A CN202010620544A CN111831394B CN 111831394 B CN111831394 B CN 111831394B CN 202010620544 A CN202010620544 A CN 202010620544A CN 111831394 B CN111831394 B CN 111831394B
Authority
CN
China
Prior art keywords
pod
request
description
deploying
kubernetes
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
CN202010620544.3A
Other languages
English (en)
Other versions
CN111831394A (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.)
Sina Technology China Co Ltd
Original Assignee
Sina Technology China 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 Sina Technology China Co Ltd filed Critical Sina Technology China Co Ltd
Priority to CN202010620544.3A priority Critical patent/CN111831394B/zh
Publication of CN111831394A publication Critical patent/CN111831394A/zh
Application granted granted Critical
Publication of CN111831394B publication Critical patent/CN111831394B/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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, deleting, cloning virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例提供一种采用kubernetes部署有状态pod的方法及装置,包括:kubernetes API获取用户发送的部署有状态pod的请求;第一调度器监听API是否具有部署有状态pod的请求,当监听到API内具有部署有状态pod的请求后获取并创建相应的pod描述;当kubelet监听API具有部署有状态pod的请求后获取创建完成的pod描述并执行相应的pod部署;如果部署有状态pod的请求为更新现有pod请求,则kubelet在现有pod的原节点上根据获取到的pod描述更新现有pod。在更新pod时使用原有的kubelet节点创建,降低调度选取节点部署产生的调度计算量。

Description

采用kubernetes部署有状态pod的方法及装置
技术领域
本发明涉及容器化部署领域,具体涉及一种采用kubernetes部署有状态pod的方法及装置。
背景技术
现有的kubernetes(管理容器化应用)部署有状态pod的方法为:
1.用户发起创建有状态pod的请求给kubernetes api服务,kubernetes api服务将本次创建请求存储起来。
2.默认的普通调度器监听kubernetes api服务,当发现有创建有状态pod时,执行调度和创建逻辑
3.默认调度器的逻辑
1)新建pod的逻辑
找到可以部署新pod的kubelet节点,并创建pod
2)更新pod的逻辑
按照pod的创建顺序,从后向前删除pod,然后在按照顺序从前向后创建pod。
在实现本发明过程中,申请人发现现有技术中至少存在如下问题:
当更新pod时,需要调度器重新选取kubelet节点来创建pod,造成了不必要的计算浪费。
发明内容
本发明实施例提供一种采用kubernetes部署有状态pod的方法及装置,在更新pod时不需要重新调度,使用原有的kubelet节点创建,降低调度选取kubelet节点部署产生的调度计算量。
为达上述目的,一方面,本发明实施例提供一种采用kubernetes部署有状态pod的方法,包括:
管理容器化应用kubernetes通过其应用程序接口API获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
管理容器化应用kubernetes的第一调度器监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetesAPI获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
管理容器化应用kubernetes的执行器kubelet监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
如果部署有状态pod的请求为更新现有pod请求,则kubelet在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
如果部署有状态pod的请求为创建新pod请求,则kubelet在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
另一方面,本发明实施例提供一种采用kubernetes部署有状态pod的装置,包括:
设置在管理容器化应用kubernetes中,包括:
管理容器化应用kubernetes应用程序接口API,用于获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
管理容器化应用kubernetes的第一调度器,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetes API获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在管理容器化应用kubernetes的执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
管理容器化应用kubernetes的执行器kubelet,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
更新子模块,用于当部署有状态pod的请求为更新现有pod请求时,在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
创建子模块,用于当部署有状态pod的请求为创建新pod请求时,在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
上述技术方案具有如下有益效果:本发明部署有状态pod时,会尽量在原有的kubelt节点创建,需要拉取的镜像资源非常少,因为镜像资源具有分层的特性,所以只需要更新少量的镜像数据即可;也就是在更新pod时不需要重新调度,使用原有的kubelet节点创建,对调度器选取kubelet节点部署没有额外的调度计算。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例的采用kubernetes部署有状态pod的方法流程图;
图2是本发明实施例的采用kubernetes部署有状态pod的装置结构图;
图3是本发明实施例的具有第一调度器和第二调度器的结构图;
图4是部署有状态pod的逻辑示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
如图1所示,结合本发明的实施例,提供一种采用kubernetes部署有状态pod的方法,包括:
S101:管理容器化应用kubernetes通过其应用程序接口API获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
S102:管理容器化应用kubernetes的第一调度器监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetes API获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
S103:管理容器化应用kubernetes的执行器kubelet监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
S1031:如果部署有状态pod的请求为更新现有pod请求,则kubelet在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
S1032:如果部署有状态pod的请求为创建新pod请求,则kubelet在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
优选地,步骤102具体包括:
S1021:第一调度器解析部署有状态pod的请求,得到部署pod的有状态资源部署描述;
S1022:通过执行解析得到的有状态资源部署描述内的策略创建相应的pod描述
优选地,步骤102具体包括:
S1023:当监听到kubernetes API内具有n个部署有状态pod的请求时,第一调度器同时创建各部署有状态pod的请求对应的pod描述;或者,
S1024:将n个部署有状态pod的请求分为m组,第一调度器以组为单位随机选取每一组,并逐一针对每一组同时创建当前组内的各部署有状态pod的请求对应的pod描述;其中n>1,m>1,n>m。
优选地,针对前述采用不同方式创建的pod描述来更新或创建pod时,更新或创建pod可以采用分组进行,也可以全部同时进行,也可以一个一个的依次进行。
优选地,步骤1031具体包括:
kubelet根据所述第一pod描述,更新现有pod的原节点中与创建的第一pod描述相关的容器。
优选地,步骤103还包括:
S1033:如果kubelet在新节点上根据创建获取到的第二pod描述创建新pod失败,则kubelet在另一新节点上根据创建新pod请求创建的第二pod描述重新创建新pod。
优选地,所述部署有状态pod的请求还包括在新节点创建pod以更新现有pod的请求;
所述采用kubernetes部署有状态pod的方法,还包括:
S104:管理容器化应用kubernetes的第二调度器监听kubernetes API内是否具有在新节点创建pod以更新现有pod的请求;当监听到具有在新节点创建pod以更新现有pod的请求,则第二调度器根据在新节点创建pod以更新现有pod的请求创建第三pod描述,以便在执行器kubelet从本第二调度器获取创建完成的第三pod描述时推送给kubelet;
S105:kubelet在新节点上根据获取到的第三pod描述创建新pod以更新现有pod。
如图2所示,结合本发明的实施例,提供一种采用kubernetes部署有状态pod的装置,设置在管理容器化应用kubernetes中,包括:
管理容器化应用kubernetes应用程序接口API21,用于获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
管理容器化应用kubernetes的第一调度器22,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetes API获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在管理容器化应用kubernetes的执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
管理容器化应用kubernetes的执行器kubelet23,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
更新子模块231,用于当部署有状态pod的请求为更新现有pod请求时,在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
创建子模块232,用于当部署有状态pod的请求为创建新pod请求时,在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
优选地,所述第一调度器22包括:
解析子模块221,用于解析部署有状态pod的请求,得到部署pod的有状态资源部署描述;
Pod描述创建子模块222,用于通过执行解析得到的有状态资源部署描述内的策略创建相应的pod描述。
优选地,所述第一调度器22具体用于:
当监听到kubernetes API内具有n个部署有状态pod的请求时,同时创建各部署有状态pod的请求对应的pod描述;或者,
将n个部署有状态pod的请求分为m组,以组为单位随机选取每一组,并逐一针对每一组同时创建当前组内的各部署有状态pod的请求对应的pod描述;其中n>1,m>1,n>m。
优选地,所述更新子模块231具体用于:
根据所述第一pod描述,更新现有pod的原节点中与创建的第一pod描述相关的容器。
优选地,所述执行器kubelet23,还包括:
重建子模块232,用于当创建子模块在新节点上根据创建获取到的第二pod描述创建新pod失败时,在另一新节点上根据创建新pod请求创建的第二pod描述重新创建新pod。
优选地,所述部署有状态pod的请求还包括在新节点创建pod以更新现有pod的请求;
所述采用kubernetes部署有状态pod的装置,还包括:
管理容器化应用kubernetes的第二调度器24,用于监听kubernetes API内是否具有在新节点创建pod以更新现有pod的请求;当监听到具有在新节点创建pod以更新现有pod的请求,则根据在新节点创建pod以更新现有pod的请求创建第三pod描述,以便在执行器kubelet从本第二调度器获取创建完成的第三pod描述时推送给kubelet;
执行器kubelet 23,还用于在新节点上根据获取到的第三pod描述创建新pod以更新现有pod.。
本发明实施例所取得的有益效果:
1.当对pod进行更新时,不需要像现有技术一样来重新分配ip地址(因为kubelet提供接口允许只更新镜像版本kubelet发现镜像版本变化了就会重启container(一个pod可以包含很多的container;只更新其中一个container其他的container不会受到影响)来用于更新pod,而不会重新创建整个pod这样网络资源就不会变化),上层应用不需要变更,不会对服务注册发现服务造成压力;
2.本发明的方法部署有状态pod时,会尽量在原有的kubelt节点创建,需要拉取的镜像资源非常少,因为镜像资源具有分层的特性,新的方法只需要更新少量的镜像数据即可;
2.在更新pod时不需要重新调度,使用原有的kubelet节点创建,对调度器选取kubelet节点部署没有额外的调度计算;
3.非串行发布,优化发布策略,可以同时进行多个和多批次的部署更新,提升部署效率;
4.增加错误重试,当某一个pod的创建发生错误时,重新再其他节点创建,不会造成阻塞,不会导致后续的创建失败、僵死的部署发生。
下面结合具体的应用实例对本发明实施例上述技术方案进行详细说明,实施过程中没有介绍到的技术细节,可以参考前文的相关描述。
本发明涉及的缩略语释义如下:
kubernetes:一个开源的容器编排工具
pod:一类数据结构,kubernetes可以编排调度的最小单元
容器:一个包含了某个软件完整运行时的环境,本文中容器是pod的一部分
有状态pod:这样的pod具有一些状态属性,有唯一的序号,需要按照顺序启动,拥有需要持久存储的数据等
Kubelet节点:用来执行创建pod的组件
pod描述:一种通过结构化的文本表述一个pod的所具有的属性,当创建pod时,根据描述创建。
本发明为一种提高kubernetes的有状态pod部署效率的方法,属于产品运维容器化应用,能够提高kubernetes有状态pod的部署和更新效率,以及增加kubernetes有状态pod的部署容错,
其步骤如下:
如附图3的A所示,高效调度器(第一调度器)监听kubernetes api,当发现具有部署新的有状态资源请求时,则会被高效调度器捕获,高效调度器按照有状态资源更新描述执行其相应的策略,按照策略将有状态资源更新描述转换成pod描述(即创建pod描述)。
当发现部署pod请求是更新pod时,不需要重新选取创建pod的kubelet节点,而是在原有pod节点根据pod描述进行更新。
如附图3的B所示,kubelet(kubelet是一个执行器,用来创建、监控、删除pod和container等工作)监听kubernetes api,查找需要被kubelet创建(此处为部署)的pod,当查找到需要被部署pod时,则自高效调度器获取已经创建好的pod描述,通过pod描述创建(此处为部署)pod。具体地,当发现pod描述包含的是有状态资源更新描述时,近在原节点更新pod中的容器,不需重新创建pod。并且同时等待kubelet创建(此处指更新)pod创建成功与否的报告,如果没有报告或者报告失败,则选取新的kubelet节点创建pod以达到更新pod的目的。还有,如果部署pod请求为创建新pod请求,kubelet则在新节点根据创建新pod请求创建的pod描述创建pod。
如附图4所示为本发明的另一流程图。
附图4中的步骤1是用户发起创建或者更新;
步骤2是普通调度器(第二调度器)监听kubernetes api,当监听到具有更新现有pod的请求、且更新现有pod的请求提出在新节点创建pod,那么第一调度器根据更新现有pod的请求创建pod描述,并将创建好的pod描述推送给kubelet。即在kubernetes api中发现创建和更新pod请求中属于普通调度器自身来处理的更新pod请求,此种更新pod请求为必须通过在新节点创建pod来更新pod,其他请求则不会处理。另外第二调度器还服务根据算法进行时随机调度kubelet。
步骤3步骤是高效调度器监听kubernetes api,发现有状态资源的名称是statefulsets.apps.example.io,则本次用户的部署(创建或者更新)会被高效调度器处理,并按有状态资源照描述规则创建pod描述。当采用kubelet创建或者更新pod时监听kubernetes api,等待kubelet创建pod创建成功与否的报告(因为kubernetes api还是数据中心,所有的数据都要经过kubernetes api sever)。
其中,一个有状态资源更新描述实例:
那么针对增加一种新的kubernetes有状态资源,并对此新增的有状态资源更新描述,比如有状态资源的名称为statefulsets.apps.example.io,资源名称可以自定义。
1.有状态资源更新描述如下:
updateStrategy:注释:pod更新策略
rollingUpdate:注释:更新策略的名称
maxUnavailable:value注释:value是一个正整数,当value为0时,高效调度器会触发同时更新所有的pod,当value为大于0的正整数时,高效调度器循序同时更新value个pod。
partition:value注释:value是一个正整数,当value为0时候,只可以同时更新一批pod分组,当value为大于0的正整数时,可以同时更新value批pod分组。
podUpdatePolicy:policy注释:policy有InPlaceIfPossible和InPlace,InPlaceIfPossible表示尽量在原来的pod所在的位置创建,当创建不成功则重新创建一个新的pod,InPlace表示必须在原来的位置创建,即使创建不成功,也不可以创建新的pod。
步骤4,kubelet节点根据pod描述创建pod,将创建结果汇报给kubernetes api。
本发明实施例所取得的有益效果:
1.当对pod进行更新时,不需要像现有技术一样来重新分配ip地址(因为kubelet提供接口,允许只更新镜像版本kubelet发现镜像版本变化了就会重启container(一个pod可以包含很多的container;只更新其中一个container其他的container不会受到影响)来用于更新pod,而不会重新创建整个pod这样网络资源就不会变化),上层应用不需要变更,不会对服务注册发现服务造成压力;
2.本发明的方法部署有状态pod时,会尽量在原有的kubelt节点创建,需要拉取的镜像资源非常少,因为镜像资源具有分层的特性,新的方法只需要更新少量的镜像数据即可;
2.在更新pod时不需要重新调度,使用原有的kubelet节点创建,对调度器选取kubelet节点部署没有额外的调度计算;
3.非串行发布,优化发布策略,可以同时进行多个和多批次的部署更新,提升部署效率;
4.增加错误重试,当某一个pod的创建发生错误时,重新再其他节点创建,不会造成阻塞,不会导致后续的创建失败、僵死的部署发生。
应该明白,公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好,应该理解,过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素,并且不是要限于所述的特定顺序或层次。
在上述的详细描述中,各种特征一起组合在单个的实施方案中,以简化本公开。不应该将这种公开方法解释为反映了这样的意图,即,所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反,如所附的权利要求书所反映的那样,本发明处于比所公开的单个实施方案的全部特征少的状态。因此,所附的权利要求书特此清楚地被并入详细描述中,其中每项权利要求独自作为本发明单独的优选实施方案。
为使本领域内的任何技术人员能够实现或者使用本发明,上面对所公开实施例进行了描述。对于本领域技术人员来说;这些实施例的各种修改方式都是显而易见的,并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此,本公开并不限于本文给出的实施例,而是与本申请公开的原理和新颖性特征的最广范围相一致。
上文的描述包括一个或多个实施例的举例。当然,为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的,但是本领域普通技术人员应该认识到,各个实施例可以做进一步的组合和排列。因此,本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外,就说明书或权利要求书中使用的术语“包含”,该词的涵盖方式类似于术语“包括”,就如同“包括,”在权利要求中用作衔接词所解释的那样。此外,使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。
本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block),单元,和步骤可以通过电子硬件、电脑软件,或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability),上述的各种说明性部件(illustrative components),单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用,可以使用各种方法实现所述的功能,但这种实现不应被理解为超出本发明实施例保护的范围。
本发明实施例中所描述的各种说明性的逻辑块,或单元都可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地,存储媒介可以与处理器连接,以使得处理器可以从存储媒介中读取信息,并可以向存储媒介存写信息。可选地,存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中,ASIC可以设置于用户终端中。可选地,处理器和存储媒介也可以设置于用户终端中的不同的部件中。
在一个或多个示例性的设计中,本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现,这些功能可以存储与电脑可读的媒介上,或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如,这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置,或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外,任何连接都可以被适当地定义为电脑可读媒介,例如,如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘,磁盘通常以磁性复制数据,而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (12)

1.一种采用kubernetes部署有状态pod的方法,其特征在于,包括:
管理容器化应用kubernetes通过其应用程序接口API获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
管理容器化应用kubernetes的第一调度器监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetes API获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
管理容器化应用kubernetes的执行器kubelet监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
如果部署有状态pod的请求为更新现有pod请求,则kubelet在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
如果部署有状态pod的请求为创建新pod请求,则kubelet在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
2.根据权利要求1所述的采用kubernetes部署有状态pod的方法,其特征在于,所述第一调度器根据部署有状态pod的请求创建相应的pod描述,具体包括:
第一调度器解析部署有状态pod的请求,得到部署pod的有状态资源部署描述;
通过执行解析得到的有状态资源部署描述内的策略创建相应的pod描述。
3.根据权利要求1所述的采用kubernetes部署有状态pod的方法,其特征在于,所述当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetes API获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,具体包括:
当监听到kubernetes API内具有n个部署有状态pod的请求时,第一调度器同时创建各部署有状态pod的请求对应的pod描述;或者,
将n个部署有状态pod的请求分为m组,第一调度器以组为单位随机选取每一组,并逐一针对每一组同时创建当前组内的各部署有状态pod的请求对应的pod描述;其中n>1,m>1,n>m。
4.根据权利要求1所述的采用kubernetes部署有状态pod的方法,其特征在于,如果部署有状态pod的请求为更新现有pod请求,则kubelet在现有pod的原节点上根据获取到的第一pod描述更新现有pod,具体包括:
kubelet根据所述第一pod描述,更新现有pod的原节点中与创建的第一pod描述相关的容器。
5.根据权利要求1所述的采用kubernetes部署有状态pod的方法,其特征在于,还包括:
如果kubelet在新节点上根据创建获取到的第二pod描述创建新pod失败,则kubelet在另一新节点上根据创建新pod请求创建的第二pod描述重新创建新pod。
6.根据权利要求1所述的采用kubernetes部署有状态pod的方法,其特征在于,所述部署有状态pod的请求还包括在新节点创建pod以更新现有pod的请求;
所述采用kubernetes部署有状态pod的方法,还包括:
管理容器化应用kubernetes的第二调度器监听kubernetes API内是否具有在新节点创建pod以更新现有pod的请求;当监听到具有在新节点创建pod以更新现有pod的请求,则第二调度器根据在新节点创建pod以更新现有pod的请求创建第三pod描述,以便在执行器kubelet从本第二调度器获取创建完成的第三pod描述时推送给kubelet;kubelet在新节点上根据获取到的第三pod描述创建新pod以更新现有pod。
7.一种采用kubernetes部署有状态pod的装置,其特征在于,设置在管理容器化应用kubernetes中,包括:
管理容器化应用kubernetes应用程序接口API,用于获取用户发送的部署有状态数据结构pod的请求并存储;其中,所述部署有状态pod的请求包括更新现有pod请求或创建新pod请求;
管理容器化应用kubernetes的第一调度器,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自kubernetesAPI获取部署有状态pod的请求;根据部署有状态pod的请求创建相应的pod描述,以便在管理容器化应用kubernetes的执行器kubelet从本第一调度器获取创建完成的pod描述时推送给kubelet;
管理容器化应用kubernetes的执行器kubelet,用于监听kubernetes API是否具有部署有状态pod的请求,当监听到kubernetes API内具有部署有状态pod的请求后,自第一调度器获取根据监听到的部署有状态pod的请求创建完成的pod描述,并根据获取到的pod描述执行相应的pod部署;其中,所述根据获取到的pod描述执行相应的pod部署,具体包括:
更新子模块,用于当部署有状态pod的请求为更新现有pod请求时,在现有pod的原节点上根据获取到的第一pod描述更新现有pod,所述第一pod描述由第一调度器根据监听到的更新现有pod请求创建;
创建子模块,用于当部署有状态pod的请求为创建新pod请求时,在新节点上根据获取到的第二pod描述创建新pod,所述第二pod描述由第一调度器根据监听到的创建新pod请求创建。
8.根据权利要求7所述的采用kubernetes部署有状态pod的装置,其特征在于,所述第一调度器包括:
解析子模块,用于解析部署有状态pod的请求,得到部署pod的有状态资源部署描述;
Pod描述创建子模块,用于通过执行解析得到的有状态资源部署描述内的策略创建相应的pod描述。
9.根据权利要求7所述的采用kubernetes部署有状态pod的装置,其特征在于,所述第一调度器监具体用于:
当监听到kubernetes API内具有n个部署有状态pod的请求时,同时创建各部署有状态pod的请求对应的pod描述;或者,
将n个部署有状态pod的请求分为m组,以组为单位随机选取每一组,并逐一针对每一组同时创建当前组内的各部署有状态pod的请求对应的pod描述;其中n>1,m>1,n>m。
10.根据权利要求7所述的采用kubernetes部署有状态pod的装置,其特征在于,所述更新子模块具体用于:
根据所述第一pod描述,更新现有pod的原节点中与创建的第一pod描述相关的容器。
11.根据权利要求7所述的采用kubernetes部署有状态pod的装置,其特征在于,所执行器kubelet,还包括:
重建子模块,用于当创建子模块在新节点上根据创建获取到的第二pod描述创建新pod失败时,在另一新节点上根据创建新pod请求创建的第二pod描述重新创建新pod。
12.根据权利要求7所述的采用kubernetes部署有状态pod的装置,其特征在于,所述部署有状态pod的请求还包括在新节点创建pod以更新现有pod的请求;
所述采用kubernetes部署有状态pod的装置,还包括:
管理容器化应用kubernetes的第二调度器,用于监听kubernetes API内是否具有在新节点创建pod以更新现有pod的请求;当监听到具有在新节点创建pod以更新现有pod的请求,则根据在新节点创建pod以更新现有pod的请求创建第三pod描述,以便在执行器kubelet从本第二调度器获取创建完成的第三pod描述时推送给kubelet;
执行器kubelet,还用于在新节点上根据获取到的第三pod描述创建新pod以更新现有pod。
CN202010620544.3A 2020-06-30 2020-06-30 采用kubernetes部署有状态pod的方法及装置 Active CN111831394B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010620544.3A CN111831394B (zh) 2020-06-30 2020-06-30 采用kubernetes部署有状态pod的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010620544.3A CN111831394B (zh) 2020-06-30 2020-06-30 采用kubernetes部署有状态pod的方法及装置

Publications (2)

Publication Number Publication Date
CN111831394A CN111831394A (zh) 2020-10-27
CN111831394B true CN111831394B (zh) 2023-10-24

Family

ID=72899903

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010620544.3A Active CN111831394B (zh) 2020-06-30 2020-06-30 采用kubernetes部署有状态pod的方法及装置

Country Status (1)

Country Link
CN (1) CN111831394B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112783646A (zh) * 2021-01-13 2021-05-11 中国工商银行股份有限公司 有状态应用容器化部署方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109614226A (zh) * 2018-11-20 2019-04-12 武汉烽火信息集成技术有限公司 一种基于Kubernetes的有状态应用存储管理方法
CN109684420A (zh) * 2018-12-21 2019-04-26 郑州云海信息技术有限公司 一种基于kubernetes的高可用部署harbor镜像仓库的方法及装置
CN110768833A (zh) * 2019-10-25 2020-02-07 北京宝兰德软件股份有限公司 基于kubernetes的应用编排部署方法及装置
CN111290834A (zh) * 2020-01-21 2020-06-16 苏州浪潮智能科技有限公司 一种基于云管理平台实现业务高可用的方法、装置及设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562341B2 (en) * 2004-05-24 2009-07-14 Sap Ag Deploy callback system with bidirectional containers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109614226A (zh) * 2018-11-20 2019-04-12 武汉烽火信息集成技术有限公司 一种基于Kubernetes的有状态应用存储管理方法
CN109684420A (zh) * 2018-12-21 2019-04-26 郑州云海信息技术有限公司 一种基于kubernetes的高可用部署harbor镜像仓库的方法及装置
CN110768833A (zh) * 2019-10-25 2020-02-07 北京宝兰德软件股份有限公司 基于kubernetes的应用编排部署方法及装置
CN111290834A (zh) * 2020-01-21 2020-06-16 苏州浪潮智能科技有限公司 一种基于云管理平台实现业务高可用的方法、装置及设备

Also Published As

Publication number Publication date
CN111831394A (zh) 2020-10-27

Similar Documents

Publication Publication Date Title
CN106888233B (zh) 数据更新系统及方法
CN111078504A (zh) 一种分布式调用链跟踪方法、装置、计算机设备及存储介质
US8185624B2 (en) Efficient on-demand provisioning of servers for specific software sets
CN109885316A (zh) 基于kubernetes的hdfs-hbase部署方法及装置
CN107210924B (zh) 用于配置通信系统的方法和设备
CN112667383B (zh) 一种任务执行及调度方法、系统、装置、计算设备及介质
KR20160061306A (ko) 펌웨어 가상화를 위한 방법 및 장치
CN109639818A (zh) 一种云环境下的服务发现方法、装置、服务器和存储介质
CN107066339A (zh) 分布式作业管理器及分布式作业管理方法
CN112910937A (zh) 容器集群中的对象调度方法、装置、服务器和容器集群
CN112181627A (zh) 定时任务调度方法、装置及系统
CN111831394B (zh) 采用kubernetes部署有状态pod的方法及装置
CN111258726A (zh) 任务调度方法和装置
CN110457132B (zh) 一种功能对象的创建方法、装置和终端设备
US20220182851A1 (en) Communication Method and Apparatus for Plurality of Administrative Domains
CN107463390B (zh) 一种软件升级方法及升级服务器
CN114168297A (zh) 一种归集任务调度方法、装置、设备及介质
CN116661978B (zh) 一种分布式的流程处理方法、装置及分布式业务流程引擎
CN113238849A (zh) 定时任务处理方法、装置、存储介质与电子设备
CN112953770B (zh) 边缘云网关免配置接入的方法、系统、介质及云端管理系统
CN111782373B (zh) 作业调度方法及装置
CN114020368A (zh) 基于状态机的信息处理方法、装置和存储介质
CN114327770A (zh) 容器集群管理系统及方法
CN113283742A (zh) 一种任务分配方法和装置
CN113760481A (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
TA01 Transfer of patent application right

Effective date of registration: 20230407

Address after: Room 501-502, 5/F, Sina Headquarters Scientific Research Building, Block N-1 and N-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Applicant after: Sina Technology (China) Co.,Ltd.

Address before: 100193 7th floor, scientific research building, Sina headquarters, plot n-1, n-2, Zhongguancun Software Park, Dongbei Wangxi Road, Haidian District, Beijing, 100193

Applicant before: Sina.com Technology (China) Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant