CN113448685B - 一种基于Kubernetes的Pod调度方法及系统 - Google Patents

Abstract

本发明提供一种一种基于Kubernetes的Pod调度方法及系统，包括：获取线上的Pod运行状态数据；调取预设的Pod运行许可条件；将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；根据所述对比结果生成调度任务；通过调用Kubernetes的API执行所述调度任务。通过此方法，能够解决现有的Kubernetes集群对有状态的服务无法精准调度的问题，尤其适用于MySQL等数据库服务，实现了部署调整自动化和运维智能化。

Description

一种基于Kubernetes的Pod调度方法及系统

技术领域

本发明涉及云计算技术领域，具体涉及一种基于Kubernetes的Pod调度方法及系统。

背景技术

Docker容器技术、K8S服务编排调度平台等的出现，提供了一种新的资源的调度解决思路。Kubernetes Master上的Scheduler服务负责实现Pod的调度，整个调度过程通过执行一系列复杂的算法，最终为每个Pod计算出一个最佳的目标节点。目前业界在K8S此类平台上实现的方案多数针对的是无状态的WEB服务，针对数据库这类有状态的服务还没有成熟的解决方案。尽管针对有状态的服务的调度管理Kubernetes提供了Operator解决方案。Operator为定义了一组在Kubernetes集群中打包和部署复杂业务应用的方法，Operator主要是为解决特定应用或服务关于如何运行、部署及出现问题时如何处理提供的一种特定的方式。Operator是在Kubernetes内部实现资源定义。

在实现本发明过程中，申请人发现现有技术中至少存在如下问题：

Kubernetes Scheduler服务调度过程是黑盒子，我们无法知道Pod最终会被调度到哪个节点上，虽然能设置一些条件，但是可设置的条件非常有限，粒度也非常粗糙。；而Kubernetes虽然也提供了Operator解决方案，但是只提供简单的条件设置，无法实现流量、IDC机房位置、业务服务特殊性、各种硬件配置自定义等。因此，目前Kubernetes针对有状态服务(例如MySQL数据库)如何实现精准资源调度，是需要解决的问题。

发明内容

本发明实施例提供一种基于Kubernetes的Pod调度方法及系统，用以解决现有的Kubernetes集群对有状态的服务无法精准调度的问题。

为达到上述目的，一方面，本发明实施例提供一种基于Kubernetes的Pod调度方法，其特征在于，包括：

获取线上的Pod运行状态数据；

调取预设的Pod运行许可条件；

将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

根据所述对比结果生成调度任务；

通过调用Kubernetes的API执行所述调度任务。

另一方面，本发明实施例提供一种基于Kubernetes的Pod调度系统，包括：

获取模块，用于获取线上的Pod运行状态数据；调取预设的Pod运行许可条件；

对比模块，用于将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

调度模块，用于根据所述对比结果生成调度任务；

执行模块，用于通过调用Kubernetes的API执行所述调度任务。

上述技术方案具有如下有益效果：

采技术方案从外部实现类似于Kubernetes Operator的方案，自动对接Kubernetes系统，灵活度更好，具备完全自定义能力，能够做到根据企业生产数据库环境来自定义调度条件，比如业务所需部署的物理位置，机架、流量、硬件配置等；并通过条件和权重算法来进行资源部署的灵活智能调度，因此能够实现精准资源调度，尤其适用于MySQL等数据库服务，实现了的部署调整自动化、运维智能化。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一种基于Kubernetes的Pod调度方法的流程图；

图2是本发明一种基于Kubernetes的Pod调度系统的结构框图；

图3是本发明的具体实施例中的系统架构图；

图4是本发明的具体实施例中的资源调度流程图；

图5是本发明的具体实施例中的设定Pod运行许可条件的界面示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明提供一种基于Kubernetes的Pod调度方法，包括：

S101、获取线上的Pod运行状态数据；

S102、调取预设的Pod运行许可条件；

S103、将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

S104、根据所述对比结果生成调度任务；

S105、通过调用Kubernetes的API(应用程序接口)执行所述调度任务。

进一步的，所述Pod运行状态数据，包括：线上可用的Pod数量；线上各个可用的Pod的位置；线上各个可用的Pod的服务器亲和性配置；

所述Pod运行许可条件，包括：业务所需的Pod的数量要求；业务所需的Pod的位置要求；业务所需的Pod的服务器亲和性配置要求；

所述服务器亲和性配置包括如下之一或任意组合：服务器类型；服务器CPU核心数；服务器网卡速度；操作系统类型；操作系统版本；磁盘类型；磁盘容量；IOPS(每秒进行读写操作的次数)。

进一步的，所述步骤S103具体包括：

S1031、逐一确定线上各个可用的Pod是否满足所述位置要求，在对比结果中对不满足所述位置要求的Pod作出需要下线的标记；

S1032、针对满足所述位置要求的Pod，逐一确定其是否满足所述服务器亲和性配置要求，在对比结果中对不满足所述服务器亲和性配置要求的Pod作出需要下线的标记；

S1033、针对同时满足所述位置要求和所述服务器亲和性配置要求的Pod，将其数量与所述数量要求进行对比；若大于所述数量要求，在对比结果中对超出所述数量要求的Pod作出需要下线的标记；若小于所述数量要求，在对比结果中作出需要Pod扩容的标记，并记录Pod扩容数量需求，所述Pod扩容是指上线新的Pod。

进一步的，所述步骤S104具体包括：

S1041、调取所述对比结果；

S1042、如果所述对比结果中包括Pod扩容数量需求，则进一步判断系统中的扩容资源是否满足所述Pod扩容数量需求，所述扩容资源，是指系统中能够上线Pod并同时满足所述位置要求和所述服务器亲和性配置要求的资源；

S10421、若不满足，则生成告警；

S10422、若满足，则生成相应的Pod扩容任务，并为所有需要下线的Pod生成下线任务；

S1043、如果所述对比结果中不包括Pod扩容数量需求，则为所有需要下线的Pod生成下线任务。

进一步的，在所述步骤S101之前，还包括：

S001、设定业务所需的Pod的数量要求；

S002、设定业务所需的Pod的位置要求；

S003、设定业务所需的Pod的服务器亲和性配置要求。

如图2所示，本发明提供一种基于Kubernetes的Pod调度系统，包括：

获取模块21，用于获取线上的Pod运行状态数据；调取预设的Pod运行许可条件；

对比模块22，用于将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

调度模块23，用于根据所述对比结果生成调度任务；

执行模块24，用于通过调用Kubernetes的API执行所述调度任务。

进一步的，所述Pod运行状态数据，包括：线上可用的Pod数量；线上各个可用的Pod的位置；线上各个可用的Pod的服务器亲和性配置；

所述Pod运行许可条件，包括：业务所需的Pod的数量要求；业务所需的Pod的位置要求；业务所需的Pod的服务器亲和性配置要求；

所述服务器亲和性配置包括如下之一或任意组合：服务器类型；服务器CPU核心数；服务器网卡速度；操作系统类型；操作系统版本；磁盘类型；磁盘容量；每秒进行读写操作的次数IOPS。

进一步的，所述对比模块22具体用于：

逐一确定线上各个可用的Pod是否满足所述位置要求，在对比结果中对不满足所述位置要求的Pod作出需要下线的标记；针对满足所述位置要求的Pod，逐一确定其是否满足所述服务器亲和性配置要求，在对比结果中对不满足所述服务器亲和性配置要求的Pod作出需要下线的标记；针对同时满足所述位置要求和所述服务器亲和性配置要求的Pod，将其数量与所述数量要求进行对比；若大于所述数量要求，在对比结果中对超出所述数量要求的Pod作出需要下线的标记；若小于所述数量要求，在对比结果中作出需要Pod扩容的标记，并记录Pod扩容数量需求，所述Pod扩容是指上线新的Pod。

进一步的，所述调度模块23具体用于：

调取所述对比结果；

如果所述对比结果中包括Pod扩容数量需求，则进一步判断系统的扩容资源是否满足所述Pod扩容数量需求；所述扩容资源，是指系统中能够上线Pod并同时满足所述位置要求和所述服务器亲和性配置要求的资源；若不满足，则生成告警；若满足，则生成相应的Pod扩容任务，并为所有需要下线的Pod生成下线任务；

如果所述对比结果中不包括Pod扩容数量需求，则为所有需要下线的Pod生成下线任务。

进一步的，所述系统还包括：

预设模块，用于设定业务所需的Pod的数量要求；设定业务所需的Pod的位置要求；设定业务所需的Pod的服务器亲和性配置要求。

以下结合具体应用实例对本发明实施例上述技术方案进行详细说明：

该具体实施例本技术方案中创新的构建外部Operator，结合调度系统、执行组件和Kubernetes一起来针对MySQL的Pod进行调度和部署。将整个数据库运维的链路形成一个完整的闭环，从线上部署的检测，到发现问题、发起任务，再到执行任务、修改线上环境，最终将数据库运维的自动化、智能化提升到一个全新的高度。其中，kubernetes，简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制

其整体系统架构图参照图3，系统主要分为以下几个功能模块：

1、部署配置中心

DBA(数据库管理员)将规则通过部署配置中心录入系统(操作界面见图5)，形成规则条件(Pod运行许可条件)，用于后续调度系统使用。主要的规则有IDC位置、机架位置、流量QPS大小、响应时间等业务指标，另外还有服务器软硬件条件，比如OS类型、版本，磁盘类型SSD、VNME等，磁盘容量，IOPS等等。这些条件均被定义为亲和性条件。亲和性条件录入后会存储成yaml文件，用户也可以直接修改yaml文件。但是需要遵循yaml文件语法格式。yaml文件会被后面的智能服务调度平台Matrix程序读取解析并在程序逻辑中作为条件匹配使用。

2、智能服务调度平台Matrix

调度核心Matrix主要就是检测服务的部署情况与部署配置中心设置的条件是否一致，从而通过算法选定需要的资源和制定调度任务。

核心思想：判断"线上服务实际占用资源及历史占用资源情况"，评估未来需要分配多少的资源，并对相应的端口做配额调整。具体包含以下几个核心规则判断和计算。

1)、MySQL部署规则检测

调度中心程序检测和搜集线上实际实例(Pod)部署情况，供程序进行对比。

2)、Pod实例数是否等于期望值

判断线上实例数量需要与部署配置中心设定的实例数一致，如果少于设定的数值，就会自动发起扩容。

3)、机房部署是否符合预期

判断线上实际实例是否是部署配置中心设定的机房，如果不是，就会自动发起实例迁移。

4)、亲和性是否符合预期

针对网卡类型、磁盘类型等亲和性配置做检查，如果不符合预期就会自动搜索匹配的资源，将不符合亲和预期的数据库实例(Pod)进行自动迁移到符合亲和的资源上。

5)、宕机恢复策略

一个域名下down 1个实例、同时down N个实例、间隔down N个实例、同时全部down等多种情况的不同扩容策略。

6)、紧急扩容

临时修改配置规则时(比如增大实例个数)，如果不合预期，立即发起扩容。

另外例举发起调度任务的规则算法如下(如域名下要求5个实例为例)

4个满足配置，发起1个扩容任务；

4个满足配置，2个不满足配置时，发起1个扩容任务，发起2个下线任务(只记录到表，暂时不做具体动作)；

5个满足配置，1个不满足配置时，发起1个下线任务(只记录到表，暂时不做具体动作)；

6个满足配置，1个不满足配置时，发起2个下线任务(只记录到表，暂时不做具体动作)。

3、执行组件

执行组件包括众多场景下的执行组件，比如伸缩组件，迁移组件，自动扩容组件等等。

伸缩组件：根据流量、slave数量等规则进行自动添加(上线)Pod和减少(下线)Pod。集群弹性扩容(scale up/out)根据数据库性能指标，分析、预测未来一段时间内数据库的压力，进而发起扩容任务或调整数据库的资源配额。

迁移组件：指定源IP地址和目的IP地址，对其承载的MySQL Pod进行调度。看另外在IDC等大型故障场景下可以制定IDC维度进行自动迁移。

自动扩/缩容组件：在服务器宕机、流量增加、响应时间增加等规则条件触发情况下，自动按照承载模型计算需要扩容多少Pod。根据数据库的各项历史的监控数据(QPS、TPS、Bytes、慢查询等)，分析、预测未来一段时间内数据库所需要承载的压力，进而判断出是否需要扩/缩容。

4、Kubernetes集群

Kubernetes集群是实际承载MySQL等有状态服务的组件，调度中心Matrix发起的调度最终通过执行组件调用Kubernetes API上线最终部署。Kubernetes API需要符合幂等性。

5、Dashboard展示组件

Dashboard展示组件会搜集调度任务完成情况，进行汇总分析，状态跟踪。让数据库管理员能够了解调度系统运行全貌，保证服务整体稳定。

该技术方案的主要调度流程如图4所示，部署配置中心、智能服务调度平台Matrix、Kubernetes集群、执行组件等服务和组件会进行相互协作，完成状态对比、调度和执行这一整套流程，达到数据库应用实例自动调度到合适的资源这一最终目标。

现举一个例子说明应用该具体实施例后的调度方法和调度系统工作原理：

假如要开展A业务，该业务需要使用MySQL数据库服务资源。数据库管理员会针对该业务的特点来进行Pod运行许可条件的部署：例如要求Pod实例个数为3、IDC机房需要部署在“北京”，并进行了服务器亲和条件的设定。

当出现如下业务运维场景时调度系统就会有相对应的自动操作：

1、假如因为人为或其他意外因素，造成线上3个实例中的一个Pod部署在了“天津”IDC机房，系统通过比对就会发现这个条件不合理，并对其作出“需要下线”的标记；另一个Pod尽管部署在了“北京”IDC机房，但其服务器亲和性条件与预设的亲和性要求不符，系统也会通过比对就会发现这个条件不合理，也对其作出“需要下线”的标记；此时线上只有1个满足IDC机房位置条件和服务器亲和性条件的Pod，需要“扩容2个Pod、并将两个做标记的Pod下线”。这时，系统在“北京”IDC机房内寻找2个能够满足预设服务器亲和性条件的资源，以便扩容。如果找不到匹配的资源，会进行告警，转到人工处理；如果找到了，生成调度任务(包括扩容2个Pod，下线两个做标记的Pod)，并通过执行组件进行处理(先扩容两个Pod，之后将两个问题Pod下线)。

2、假如流量因为业务推广持续增长，数据库管理员会进行实例扩容，例如流量增加需要7个实例来承载，数据库管理员会手动更新配置将实例数由“3”修改为“7”。调度系统会感知到配置更新，会自动进行资源匹配，会发起2个实例的扩容，等待2个实例扩容完毕后，再发起2个实例扩容(短时间内大量扩容可能会导致网络拥塞，影响系统负载等，因此需要采取前述的宕机恢复策略，逐步扩容)。

与现有技术的Kubernetes Scheduler服务调度或Kubernetes Operator相比，本技术方案具有以下优势：

更好的可维护性：不受Kubernetes限制，Operator本身升级或者Kubernetes版本升级都会互不影响。同时针对Operator有自己的单独的服务监控，更容易维护。

更好的可配置性：可以随意根据自己企业生产需要来进行增删配置，粒度更细，配置更灵活，调度条件采用yaml文件格式，提升了效率和增加便利性。

更好的稳定性：不会因为Operator异常导致Kubernetes和Pod里的服务异常。最坏的情况也只是调度异常，通过报警可以尽快处理。针对Operator的操作也不会影响Kubernetes服务本身的任何异常。

为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本申请定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本申请给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (6)

1.一种基于Kubernetes的Pod调度方法，其特征在于，包括：

获取线上的Pod运行状态数据；

调取预设的Pod运行许可条件；

将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

根据所述对比结果生成调度任务；

通过调用Kubernetes的API执行所述调度任务；

所述Pod运行状态数据，包括：

线上可用的Pod数量；

线上各个可用的Pod的位置；

线上各个可用的Pod的服务器亲和性配置；

所述Pod运行许可条件，包括：

业务所需的Pod的数量要求；

业务所需的Pod的位置要求；

业务所需的Pod的服务器亲和性配置要求；

所述服务器亲和性配置包括如下之一或任意组合：

服务器类型；服务器CPU核心数；服务器网卡速度；操作系统类型；操作系统版本；磁盘类型；磁盘容量；每秒进行读写操作的次数IOPS；

所述将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果，包括：

逐一确定线上各个可用的Pod是否满足所述位置要求，在对比结果中对不满足所述位置要求的Pod作出需要下线的标记；

针对满足所述位置要求的Pod，逐一确定其是否满足所述服务器亲和性配置要求，在对比结果中对不满足所述服务器亲和性配置要求的Pod作出需要下线的标记；

针对同时满足所述位置要求和所述服务器亲和性配置要求的Pod，将其数量与所述数量要求进行对比；若大于所述数量要求，在对比结果中对超出所述数量要求的Pod作出需要下线的标记；若小于所述数量要求，在对比结果中作出需要Pod扩容的标记，并记录Pod扩容数量需求，所述Pod扩容是指上线新的Pod。

2.如权利要求1所述的基于Kubernetes的Pod调度方法，其特征在于，所述根据所述对比结果生成调度任务，包括：

调取所述对比结果；

如果所述对比结果中包括Pod扩容数量需求，则进一步判断系统中的扩容资源是否满足所述Pod扩容数量需求，所述扩容资源，是指系统中能够上线Pod并同时满足所述位置要求和所述服务器亲和性配置要求的资源；若不满足，则告警；若满足，则生成相应的Pod扩容任务，并为所有需要下线的Pod生成下线任务；

如果所述对比结果中不包括Pod扩容数量需求，则为所有需要下线的Pod生成下线任务。

3.如权利要求1所述的基于Kubernetes的Pod调度方法，其特征在于，在所述获取线上的Pod运行状态数据之前，还包括：

设定业务所需的Pod的数量要求；

设定业务所需的Pod的位置要求；

设定业务所需的Pod的服务器亲和性配置要求。

4.一种基于Kubernetes的Pod调度系统，其特征在于，包括：

获取模块，用于获取线上的Pod运行状态数据，以及调取预设的Pod运行许可条件；

对比模块，用于将所述Pod运行状态数据与所述Pod运行许可条件进行对比，生成对比结果；

调度模块，用于根据所述对比结果生成调度任务；

执行模块，用于通过调用Kubernetes的API执行所述调度任务；

所述Pod运行状态数据，包括：线上可用的Pod数量；线上各个可用的Pod的位置；线上各个可用的Pod的服务器亲和性配置；

所述Pod运行许可条件，包括：业务所需的Pod的数量要求；业务所需的Pod的位置要求；业务所需的Pod的服务器亲和性配置要求；

所述服务器亲和性配置包括如下之一或任意组合：服务器类型；服务器CPU核心数；服务器网卡速度；操作系统类型；操作系统版本；磁盘类型；磁盘容量；每秒进行读写操作的次数IOPS；

所述对比模块具体用于：逐一确定线上各个可用的Pod是否满足所述位置要求，在对比结果中对不满足所述位置要求的Pod作出需要下线的标记；针对满足所述位置要求的Pod，逐一确定其是否满足所述服务器亲和性配置要求，在对比结果中对不满足所述服务器亲和性配置要求的Pod作出需要下线的标记；针对同时满足所述位置要求和所述服务器亲和性配置要求的Pod，将其数量与所述数量要求进行对比；若大于所述数量要求，在对比结果中对超出所述数量要求的Pod作出需要下线的标记；若小于所述数量要求，在对比结果中作出需要Pod扩容的标记，并记录Pod扩容数量需求，所述Pod扩容是指上线新的Pod。

5.如权利要求4所述的基于Kubernetes的Pod调度系统，其特征在于，所述调度模块具体用于：

调取所述对比结果；

如果所述对比结果中包括Pod扩容数量需求，则进一步判断系统的扩容资源是否满足所述Pod扩容数量需求；所述扩容资源，是指系统中能够上线Pod并同时满足所述位置要求和所述服务器亲和性配置要求的资源；若不满足，则告警；若满足，则生成相应的Pod扩容任务，并为所有需要下线的Pod生成下线任务；

如果所述对比结果中不包括Pod扩容数量需求，则为所有需要下线的Pod生成下线任务。

6.如权利要求4所述的基于Kubernetes的Pod调度系统，其特征在于，还包括：

预设模块，用于设定业务所需的Pod的数量要求；设定业务所需的Pod的位置要求；设定业务所需的Pod的服务器亲和性配置要求。