CN113268337A - Kubernetes集群中Pod调度的方法和系统 - Google Patents

Abstract

本申请涉及一种Kubernetes集群中Pod调度的方法和系统，其中，集群中的多个工作节点组成单向环状的拓扑结构，并且多个工作节点中包括领导节点，该领导节点与管理面节点通信，该Kubernetes集群中Pod调度的方法包括：领导节点向管理面节点拉取元数据集合，从而确定待运行的Pod的列表，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行该Pod的工作节点，通过本申请，解决了相关技术中，Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大的问题，达到了减轻管理面节点调度压力的效果。

Description

Kubernetes集群中Pod调度的方法和系统

技术领域

本申请涉及计算机软件技术应用技术领域，特别是涉及一种Kubernetes集群中Pod调度的方法和系统。

背景技术

在容器编排引擎（Kubernetes，简称k8s）集群中，管理面节点的调度器组件负责为Pod选择合适的工作节点供其运行，管理面节点的规格需要能够支持调度管理大规模的工作节点，在相关技术中，Kubernetes集群最多支持5000个工作节点，在该工作节点数目上限值范围内，在Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大，随着工作节点数目增加，管理面节点的调度压力不断增大，可能会导致Kubernetes集群发生故障。

针对相关技术中，Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大的问题，尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种Kubernetes集群中Pod调度的方法和系统，以至少解决相关技术中，Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大的问题。

第一方面，本申请实施例提供了一种Kubernetes集群中Pod调度的方法，Kubernetes集群中的多个工作节点组成单向环状的拓扑结构，以构成大型节点，并且多个所述工作节点中包括领导节点，所述领导节点与管理面节点通信，所述方法包括：

所述领导节点向所述管理面节点拉取第一元数据集合，并根据所述第一元数据集合，确定第二元数据集合，其中，所述第一元数据集合为所述Kubernetes集群的待运行的Pod的元数据的集合，所述第二元数据集合为所述领导节点所在大型节点的待运行的Pod的元数据的集合；

所述领导节点根据所述第二元数据集合，确定待运行的Pod的列表，从所述领导节点开始，对于所述待运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行所述Pod的工作节点，其中，所述Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行所述列表中的Pod，若否，所述工作节点发送所述列表至所述拓扑结构中的下一个工作节点，若是，所述工作节点删除所述列表中的已确定在本节点运行的Pod，以更新所述列表，在更新后的所述列表不为空的情况下，所述工作节点发送更新后的所述列表至所述拓扑结构中的下一个工作节点。

在其中一些实施例中，所述方法包括：在所述拓扑结构中所有工作节点均无法运行所述Pod的情况下，所述领导节点向管理面节点上报无法运行所述Pod的信息。

在其中一些实施例中，所述方法包括：

在所述领导节点确定出所述第二元数据集合的情况下，从所述领导节点开始，对于所述第二元数据集合中的每个元数据，所述拓扑结构中的工作节点依次执行Pod同步操作，直至所有工作节点均存储所述元数据，其中，所述Pod同步操作包括：在工作节点得到所述元数据后，存储所述元数据，并发送所述元数据至所述拓扑结构中的下一个工作节点；

在所述拓扑结构确定出运行所述Pod的工作节点的情况下，所述工作节点根据所述元数据，运行所述Pod。

在其中一些实施例中，所述拓扑结构中的工作节点按照资源量的大小进行递增排列。

在其中一些实施例中，所述方法包括：

所述拓扑结构中的工作节点还发送本节点已运行的Pod的列表至指定工作节点；

在所述工作节点发生故障的情况下，故障节点的上一个工作节点和下一个工作节点均与所述故障节点断开连接，并且与所述故障节点的上一个工作节点与所述故障节点的下一个工作节点建立连接，从所述指定工作节点开始，对于所述已运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行所述Pod调度操作，直至确定运行所述Pod的工作节点。

在其中一些实施例中，所述方法包括：

在所述故障节点为领导节点的情况下，所述拓扑结构中的指定工作节点与所述管理面节点建立通信，成为领导节点。

第二方面，本申请实施例提供了一种Kubernetes集群中Pod调度的系统，所述系统包括管理面节点和多个工作节点，多个所述工作节点组成单向环状的拓扑结构，以构成大型节点，并且多个所述工作节点中包括领导节点，所述领导节点与所述管理面节点通信；

所述领导节点向所述管理面节点拉取第一元数据集合，并根据所述第一元数据集合，确定第二元数据集合，其中，所述第一元数据集合为所述Kubernetes集群的待运行的Pod的元数据的集合，所述第二元数据集合为所述领导节点所在大型节点的待运行的Pod的元数据的集合；

所述领导节点根据所述第二元数据集合，确定待运行的Pod的列表，从所述领导节点开始，对于所述待运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行所述Pod的工作节点，其中，所述Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行所述列表中的Pod，若否，所述工作节点发送所述列表至所述拓扑结构中的下一个工作节点，若是，所述工作节点删除所述列表中的已确定在本节点运行的Pod，以更新所述列表，在更新后的所述列表不为空的情况下，所述工作节点发送更新后的所述列表至所述拓扑结构中的下一个工作节点。

在其中一些实施例中，在所述拓扑结构中所有工作节点均无法运行所述Pod的情况下，所述领导节点向管理面节点上报无法运行所述Pod的信息。

在其中一些实施例中，在所述领导节点确定出所述第二元数据集合的情况下，从所述领导节点开始，对于所述第二元数据集合中的每个元数据，所述拓扑结构中的工作节点依次执行Pod同步操作，直至所有工作节点均存储所述元数据，其中，所述Pod同步操作包括：在工作节点得到所述元数据后，存储所述元数据，并发送所述元数据至所述拓扑结构中的下一个工作节点；

在所述拓扑结构确定出运行所述Pod的工作节点的情况下，所述工作节点根据所述元数据，运行所述Pod。

在其中一些实施例中，所述拓扑结构中的工作节点按照资源量的大小进行递增排列。

相比于相关技术，本申请实施例提供的Kubernetes集群中Pod调度的方法，通过Kubernetes集群中的多个工作节点组成单向环状的拓扑结构，以构成大型节点，并且多个工作节点中包括领导节点，该领导节点与管理面节点通信，在进行Pod调度时，领导节点向管理面节点拉取第一元数据集合，并根据第一元数据集合，确定第二元数据集合，其中，第一元数据集合为Kubernetes集群的待运行的Pod的元数据的集合，第二元数据集合为领导节点所在大型节点的待运行的Pod的元数据的集合；领导节点根据第二元数据集合，确定待运行的Pod的列表，从领导节点开始，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行该Pod的工作节点，其中，Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行列表中的Pod，若否，工作节点发送列表至拓扑结构中的下一个工作节点，若是，工作节点删除列表中的已确定在本节点运行的Pod，以更新列表，在更新后的列表不为空的情况下，工作节点发送更新后的列表至拓扑结构中的下一个工作节点，解决了相关技术中，Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大的问题，达到了减轻管理面节点调度压力的效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的Kubernetes集群中Pod调度的方法的应用环境示意图；

图2是根据本申请第一实施例的Kubernetes集群中Pod调度的方法的流程图；

图3是根据本申请第二实施例的Kubernetes集群中同步Pod元数据的流程图；

图4是根据本申请第三实施例的Kubernetes集群中的不同视角下的Pod运行位置的示意图；

图5是根据本申请第四实施例的Kubernetes集群中Pod调度的示意图；

图6是根据本申请第五实施例的Kubernetes集群中Pod愈合过程的流程图；

图7是根据本申请第六实施例的Kubernetes集群中故障节点处理的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指大于或者等于两个。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本申请提供的Kubernetes集群中Pod调度的方法，可以应用于如图1所示的应用环境中，图1是根据本申请实施例的Kubernetes集群中Pod调度的方法的应用环境示意图，如图1所示，Kubernetes集群包括管理面节点和多个工作节点，各工作节点内部署有拓扑维持组件，该拓扑维持组件运行后，多个工作节点组成单向环状的拓扑结构，以构成大型节点，并且拓扑维持组件在多个工作节点中随机选择一个工作节点，作为与管理面节点通信的领导节点，Pod调度时，领导节点向管理面节点拉取整个Kubernetes集群的待运行的Pod的元数据的集合，并筛选出领导节点所在大型节点的待运行的Pod的元数据的集合，从而确定出待运行的Pod的列表，从领导节点开始，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行该Pod的工作节点，该工作节点根据从管理面节点获取到的Pod元数据，运行该Pod。

本实施例提供了一种Kubernetes集群中Pod调度的方法，图2是根据本申请第一实施例的Kubernetes集群中Pod调度的方法的流程图，如图2所示，该流程包括如下步骤：

步骤S201，领导节点向管理面节点拉取第一元数据集合，并根据第一元数据集合，确定第二元数据集合，其中，第一元数据集合为Kubernetes集群的待运行的Pod的元数据的集合，且Pod的元数据中携带调度该Pod所分配的大型节点的信息，第二元数据集合为领导节点所在大型节点的待运行的Pod的元数据的集合；

步骤S202，领导节点根据第二元数据集合，确定待运行的Pod的列表，从领导节点开始，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行Pod的工作节点，其中，Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行列表中的Pod，若否，工作节点发送列表至拓扑结构中的下一个工作节点，若是，工作节点删除列表中的已确定在本节点运行的Pod，以更新列表，在更新后的列表不为空的情况下，工作节点发送更新后的列表至拓扑结构中的下一个工作节点，可选的，根据调度策略确定本节点是否运行Pod的过程包括，根据本节点剩余CPU和内存量确定能否运行该Pod。

通过步骤S201至S202，相对于相关技术中管理面节点调度压力较大的问题，本实施例通过将多个工作节点聚合为一个大型节点，该大型节点为单向环状的拓扑结构，在拓扑结构中选出一个工作节点作为与管理面节点进行通信的领导节点，Pod调度时，领导节点向管理面节点拉取整个Kubernetes集群的待运行的Pod的元数据的集合，并筛选出领导节点所在大型节点的待运行的Pod的元数据的集合，从而确定出待运行的Pod的列表，从领导节点开始，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行该Pod的工作节点，由于该Pod调度操作是在大型节点内部进行管控，该大型节点为管理面节点承担了大部分的Pod调度压力，从而减轻了管理面节点的调度压力，解决了相关技术中，Kubernetes集群中工作节点数目较多的情况下，管理面节点调度压力较大的问题，实现了减少Kubernetes集群中Pod调度压力的效果。

进一步的，考虑到在工作节点依次执行Pod调度操作时，存在拓扑结构中的所有工作节点均无法运行Pod的情况，在本实施例中，在拓扑结构中的所有工作节点均无法运行Pod的情况下，领导节点向管理面节点上报无法运行Pod的信息，从而该Pod可以在整个Kubernetes集群范围内寻找合适的工作节点，增大了该Pod找到合适工作节点的可能性。

考虑到确定出运行该Pod的工作节点之后，工作节点需要具备该Pod的元数据，才能运行Pod，在其中一些实施例中，每个工作节点上还部署有缓存同步组件，该缓存同步组件用于同步Pod的元数据，图3是根据本申请第二实施例的Kubernetes集群中同步Pod元数据的流程图，如图3所示，该流程包括如下步骤：

步骤S301，在领导节点确定出第二元数据集合的情况下，从领导节点开始，对于第二元数据集合中的每个元数据，拓扑结构中的工作节点依次执行Pod同步操作，直至所有工作节点均存储元数据，其中，Pod同步操作包括：在工作节点得到元数据后，存储元数据，并发送元数据至拓扑结构中的下一个工作节点；

步骤S302，在拓扑结构确定出运行Pod的工作节点的情况下，工作节点根据元数据，运行Pod。

通过步骤S301至S302，本实施例通过执行Pod同步操作，使得所有工作节点都存储Pod的元数据，在工作节点决定运行该Pod的情况下，该工作节点可以根据已同步的Pod的元数据，运行该Pod。

需要说明的是，为了缩短从开始进行Pod调度到该Pod真正运行的时间，使Pod可以较快地运行起来，在本申请实施例中，Pod元数据的同步过程和该Pod的调度过程可以并行，即Pod的调度过程无需等到Pod的元数据同步到所有工作节点后才开始，例如，在领导节点确定出第二元数据集合的情况下，一方面，从领导节点开始，对于第二元数据集合中的每个元数据，拓扑结构中的工作节点依次执行Pod同步操作，同时，另一方面，领导节点根据第二元数据集合，确定待运行的Pod的列表，从领导节点开始，对于待运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作。

在其中一个实施例中，图4是根据本申请第三实施例的Kubernetes集群中的不同视角下的Pod运行位置的示意图，如图4所示，管理面视角的节点包括Node01、Node02两个大型节点，并且Pod1、Pod2和Pod3都运行于大型节点Node01内，而在工作节点视角，大型节点Node01由工作节点A、工作节点B和工作节点C组成，Pod1、Pod2和Pod3分别运行于3个不同工作节点内。

在其中一些实施例中，图5是根据本申请第四实施例的Kubernetes集群中Pod调度的示意图，如图5所示，Pod调度时，工作节点C向管理面节点拉取Pod4的元数据，在Node01的拓扑结构内执行Pod4同步操作，直至工作节点C、工作节点A和工作节点B都存储有该Pod4的元数据；并且工作节点C在拉取到Pod4的元数据之后，生成待运行的Pod的列表，该待运行的Pod的列表包含Pod4，在Node01的拓扑结构内执行Pod4同步操作的同时，从工作节点C开始，大型节点Node01的拓扑结构中的工作节点依次执行Pod4调度操作，直至确定运行该Pod4的工作节点，例如，工作节点C根据本节点的剩余CPU和内存量，判断本节点是否可以运行该Pod4，如果不能运行，则发送待运行的Pod的列表给工作节点A，工作节点A判断本节点是否可以运行该Pod4，如果不能运行，则发送待运行的Pod的列表给工作节点B，工作节点B判断本节点是否可以运行该Pod4，如果可以运行，则工作节点B根据本节点存储的Pod4的元数据，运行该Pod4，并且工作节点B删除列表中的Pod4，删除Pod4后列表内容为空，工作节点B不再发送列表至拓扑结构中的下一个工作节点。

在其中一些实施例中，拓扑结构中的工作节点按照资源量的大小进行递增排列，其中，资源量包括剩余CPU或内存量，例如，在对工作节点进行排列时，可以先按照剩余CPU大小递增的排序方式，对工作节点进行排列，在剩余CPU大小相同的情况下，再按照剩余内存量大小递增的排序方式，对工作节点进行排列，通过该排列方式，可以选择出满足Pod运行要求的、且资源量最小的工作节点，尽量减少碎片空间，例如，工作节点A期望Pod的最大内存使用不超过128MB，工作节点B期望Pod的最大内存不超过256MB，而待运行的Pod4的内存最大用量为100MB，显然，两个节点上都能运行Pod4，但如果Pod4运行在工作节点B，后续若待运行的Pod5内存最大用量为256MB，该Pod5就无法在工作节点A、工作节点B中的任何节点上运行了，而如果Pod4运行在工作节点A，Pod5是可以在工作节点B运行的，因此，让期望内存用量和Pod内存用量相近的节点运行Pod，可以减少节点内存空间的碎片化。

考虑到拓扑结构中的工作节点可能会发生故障，为了不影响故障节点上Pod的运行和后续Kubernetes集群中的Pod调度工作，需要对故障节点进行愈合，在其中一些实施例中，图6是根据本申请第五实施例的Kubernetes集群中Pod愈合过程的流程图，如图6所示，该流程包括如下步骤：

步骤S601，拓扑结构中的工作节点还发送本节点已运行的Pod的列表至下一个工作节点；

步骤S602，在工作节点发生故障的情况下，故障节点的上一个工作节点和下一个工作节点均与故障节点断开连接，并且故障节点的上一个工作节点与故障节点的下一个工作节点建立连接；

步骤S603，从故障节点的下一个工作节点开始，对于已运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行Pod的工作节点。

通过步骤S601至S603，本实例通过在各工作节点处于正常状态时，备份工作节点已运行的Pod的列表至下一个工作节点，使得一旦工作节点发生故障，故障节点的下一个节点可以根据预存储的故障节点已运行的Pod的列表，对列表中的Pod逐个进行调度操作，从而该故障节点所运行的Pod可以继续在拓扑结构内的其他节点上运行，对于管理面节点来说，该呈拓扑结构的大型节点依旧可用，仅仅是该大型节点的CPU、内存等资源总量发生变化，本申请实施例至少存在以下三个有益效果，第一，避免因为出现故障节点而导致该故障节点上的Pod无法继续运行，第二，保障后续Kubernetes集群中的Pod调度工作可以顺利执行，第三，大大减轻了工作节点发生故障时管理面节点的调度压力，只有在拓扑结构内的全部节点均拒绝该故障节点的已运行的Pod的情况下，才需要管理面节点参与调度。

考虑到工作节点已运行的Pod的列表会随着工作节点实际运行的Pod的变化而不断发生改变，因此，需要及时更新下一个工作节点中存储的上一个工作节点已运行的Pod的列表，在本申请实施例中，该已运行的Pod的列表的发送时机可以是：拓扑结构中的工作节点实时发送本节点已运行的Pod的列表至下一个工作节点，或者，拓扑结构中的工作节点定时发送本节点已运行的Pod的列表至下一个工作节点，或者，拓扑结构中的工作节点被其他动作触发，发送本节点已运行的Pod的列表至下一个工作节点，其中，该触发动作可以是，在工作节点更新待运行的Pod的列表时，该工作节点发送本节点已运行的Pod的列表至下一个工作节点。

在其中一个实施例中，图7是根据本申请第六实施例的Kubernetes集群中故障节点处理的示意图，如图7所示，在工作节点A正常运行的情况下，工作节点C上运行有Pod1，工作节点A上运行有Pod2，工作节点B上运行有Pod3，工作节点A发送本节点已运行的Pod的列表至工作节点B，在工作节点A发生故障的情况下，工作节点C作为工作节点A的上一个节点，与工作节点A断开连接，工作节点B作为工作节点A的下一个节点，与工作节点A断开连接，并且工作节点C和工作节点B建立连接；工作节点B根据预存储的工作节点A已运行的Pod的列表，根据调度策略确定本节点是否运行列表中的Pod2，若是，工作节点B运行Pod2，并删除列表中的Pod2，删除Pod2后列表内容为空，工作节点B不再发送列表至拓扑结构中的下一个工作节点；若否，工作节点B发送该列表至工作节点C，继续进行Pod2的调度，为Pod2找到合适的运行节点。

需要说明的是，由于在工作节点A正常运行的情况下，在调度Pod2并为Pod2选择出合适的工作节点（工作节点A）的过程中，拓扑结构内的所有节点已经同步了Pod2的元数据，所以，在该工作节点A发生故障的情况下，在确定出适合Pod2的新的工作节点之后，该新的工作节点可以根据预先同步好的Pod2的元数据，直接运行Pod2。

当然，在其他实施例中，拓扑结构中的工作节点也可以发送本节点已运行的Pod的列表至其它指定节点，例如，拓扑结构中的工作节点也可以发送本节点已运行的Pod的列表至上一个工作节点，在该工作节点发生故障的情况下，从该上一个工作节点开始，对于故障节点的已运行的Pod的列表中的每个Pod，大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行该Pod的工作节点。

考虑到故障节点也有可能是领导节点，为了避免缺失领导节点导致大型节点瘫痪，在故障节点为领导节点的情况下，该领导节点在拓扑结构中的下一个工作节点会与管理面节点建立通信，成为新的领导节点，从而在该故障节点是领导节点的情况下，该大型节点仍然可以正常拉取Pod元数据和向管理面节点反馈无法运行Pod的信息，因此，拓扑结构的任意节点发生故障，都不影响拓扑结构的正常运行，具有较好的稳定性。

在其他实施例中，在故障节点为领导节点的情况下，也可以让其它指定工作节点成为新的领导节点，例如，在故障节点为领导节点的情况下，该领导节点在拓扑结构中的上一个工作节点与管理面节点建立通信，成为新的领导节点。

本领域的技术人员应该明白，以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种Kubernetes集群中Pod调度的方法，其特征在于，Kubernetes集群中的多个工作节点组成单向环状的拓扑结构，以构成大型节点，并且多个所述工作节点中包括领导节点，所述领导节点与管理面节点通信，所述方法包括：

所述领导节点向所述管理面节点拉取第一元数据集合，并根据所述第一元数据集合，确定第二元数据集合，其中，所述第一元数据集合为所述Kubernetes集群的待运行的Pod的元数据的集合，所述第二元数据集合为所述领导节点所在大型节点的待运行的Pod的元数据的集合；

所述领导节点根据所述第二元数据集合，确定待运行的Pod的列表，从所述领导节点开始，对于所述待运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行所述Pod的工作节点，其中，所述Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行所述列表中的Pod，若否，所述工作节点发送所述列表至所述拓扑结构中的下一个工作节点，若是，所述工作节点删除所述列表中的已确定在本节点运行的Pod，以更新所述列表，在更新后的所述列表不为空的情况下，所述工作节点发送更新后的所述列表至所述拓扑结构中的下一个工作节点。

2.根据权利要求1所述的方法，其特征在于，所述方法包括：在所述拓扑结构中所有工作节点均无法运行所述Pod的情况下，所述领导节点向管理面节点上报无法运行所述Pod的信息。

3.根据权利要求1所述的方法，其特征在于，所述方法包括：

在所述领导节点确定出所述第二元数据集合的情况下，从所述领导节点开始，对于所述第二元数据集合中的每个元数据，所述拓扑结构中的工作节点依次执行Pod同步操作，直至所有工作节点均存储所述元数据，其中，所述Pod同步操作包括：在工作节点得到所述元数据后，存储所述元数据，并发送所述元数据至所述拓扑结构中的下一个工作节点；

在所述拓扑结构确定出运行所述Pod的工作节点的情况下，所述工作节点根据所述元数据，运行所述Pod。

4.根据权利要求1所述的方法，其特征在于，所述拓扑结构中的工作节点按照资源量的大小进行递增排列。

5.根据权利要求1所述的方法，其特征在于，所述方法包括：

所述拓扑结构中的工作节点还发送本节点已运行的Pod的列表至指定工作节点；

在所述工作节点发生故障的情况下，故障节点的上一个工作节点和下一个工作节点均与所述故障节点断开连接，并且与所述故障节点的上一个工作节点与所述故障节点的下一个工作节点建立连接，从所述指定工作节点开始，对于所述已运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行所述Pod调度操作，直至确定运行所述Pod的工作节点。

6.根据权利要求5所述的方法，其特征在于，所述方法包括：

在所述故障节点为领导节点的情况下，所述拓扑结构中的指定工作节点与所述管理面节点建立通信，成为领导节点。

7.一种Kubernetes集群中Pod调度的系统，其特征在于，所述系统包括管理面节点和多个工作节点，多个所述工作节点组成单向环状的拓扑结构，以构成大型节点，并且多个所述工作节点中包括领导节点，所述领导节点与所述管理面节点通信；

所述领导节点向所述管理面节点拉取第一元数据集合，并根据所述第一元数据集合，确定第二元数据集合，其中，所述第一元数据集合为所述Kubernetes集群的待运行的Pod的元数据的集合，所述第二元数据集合为所述领导节点所在大型节点的待运行的Pod的元数据的集合；

所述领导节点根据所述第二元数据集合，确定待运行的Pod的列表，从所述领导节点开始，对于所述待运行的Pod的列表中的每个Pod，所述大型节点的拓扑结构中的工作节点依次执行Pod调度操作，直至确定运行所述Pod的工作节点，其中，所述Pod调度操作包括：在工作节点得到Pod的列表后，根据调度策略确定本节点是否运行所述列表中的Pod，若否，所述工作节点发送所述列表至所述拓扑结构中的下一个工作节点，若是，所述工作节点删除所述列表中的已确定在本节点运行的Pod，以更新所述列表，在更新后的所述列表不为空的情况下，所述工作节点发送更新后的所述列表至所述拓扑结构中的下一个工作节点。

8.根据权利要求7所述的系统，其特征在于，在所述拓扑结构中所有工作节点均无法运行所述Pod的情况下，所述领导节点向管理面节点上报无法运行所述Pod的信息。

9.根据权利要求7所述的系统，其特征在于：

在所述领导节点确定出所述第二元数据集合的情况下，从所述领导节点开始，对于所述第二元数据集合中的每个元数据，所述拓扑结构中的工作节点依次执行Pod同步操作，直至所有工作节点均存储所述元数据，其中，所述Pod同步操作包括：在工作节点得到所述元数据后，存储所述元数据，并发送所述元数据至所述拓扑结构中的下一个工作节点；

在所述拓扑结构确定出运行所述Pod的工作节点的情况下，所述工作节点根据所述元数据，运行所述Pod。

10.根据权利要求7所述的系统，其特征在于，所述拓扑结构中的工作节点按照资源量的大小进行递增排列。

Images