CN118101663A - 一种基于节点子网可用性的Kubernetes集群调度方法和系统 - Google Patents

Abstract

本申请提供了一种基于节点子网可用性的Kubernetes集群调度方法和系统；其中，基于节点子网可用性的Kubernetes集群调度方法，包括：获取Kubernetes集群中多个网络区域节点的子网资源信息；设备插件将所在网络区域节点的子网资源信息注册至网络区域节点的Kubelet，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server；控制平面的调度器调取Pod的子网需求和网络区域节点的子网资源信息；调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点。本申请的技术方案能解决现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点，无法根据子网可用性将Pod调度至与期望子网相匹配的节点的问题。

Description

一种基于节点子网可用性的Kubernetes集群调度方法和系统

技术领域

本申请涉及云计算技术领域，尤其涉及一种基于节点子网可用性的Kubernetes集群调度方法和系统。

背景技术

在现代分布式系统和云计算环境中，出于容灾和高可用性、就近性能优化等因素考虑，很多应用需要分布在集群的多个节点上，并且这些节点通常需要分布在不同地区或数据中心。由于不同地区或数据中心的网络规划和限制可能不同，导致某些区域的节点只能使用特定的子网。在此背景下，当应用的Pod期望使用期望子网(例如需要进行网络性能优化和安全隔离)时，需要将Pod调度到与期望子网相匹配的节点上。

Kubernetes的调度器是根据节点资源信息调度Pod到指定节点的。具体地，在定义应用的Pod时，Kubernetes为每个Pod选择性地指定资源请求，其中，资源请求最常见的节点资源包括CPU和内存。当为Pod指定资源请求时，Kubernetes的调度器会根据这些节点资源信息决定将该Pod调度到对应节点。调度器通常会考虑节点上的可用资源并尝试将Pod调度到有足够资源满足上述资源请求的节点。当为Pod指定的资源存在限制(例如：资源数量限制)时，kubelet会确保Pod不会使用超出限制的资源，这样能够防止Pod过度占用节点资源，确保节点上其他Pod和系统进程正常运行。

然而，目前Kubernetes的调度器仅支持CPU、内存和存储等资源的限制和请求，并不支持根据节点的子网可用性筛选期望的节点。这是因为节点的子网并不是Kubernetes的节点资源类型。子网是网络的一个概念，用于划分IP地址空间；而节点资源类型用于描述节点上可用的计算和存储资源，节点资源类型通常包括CPU、内存和存储等。Kubernetes调度器仅支持使用节点资源信息选择节点运行Pod。因此Kubernetes的调度器无法根据子网可用性将Pod调度到与期望子网相匹配的节点上。

申请内容

本申请提供一种基于节点子网可用性的Kubernetes集群调度方案，能够解决现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点，无法根据子网可用性将Pod调度至与期望子网相匹配的节点的问题。

为解决上述问题，根据本申请的第一方面，本申请提供了一种基于节点子网可用性的Kubernetes集群调度方法，Kubernetes集群包括多个网络区域节点和一个控制平面，Kubelet和设备插件部署在所述网络区域节点上，调度器、API Server、监听器、etcd部署在控制平面上；Kubernetes集群调度方法包括：

获取Kubernetes集群中多个网络区域节点的子网资源信息；

设备插件将所在网络区域节点的子网资源信息注册至网络区域节点的Kubelet，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server；

控制平面的调度器调取Pod的子网需求和网络区域节点的子网资源信息；

调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点。

优选的，上述Kubernetes集群调度方法中，获取Kubernetes集群中多个网络区域节点的子网资源信息的步骤，包括：

获取Kubernetes集群中多个网络区域节点；

分别为多个网络区域节点的每个网络区域节点创建Subnet CRD实例，其中，每个Subnet CRD实例包含对应网络区域节点的子网资源信息。

优选的，上述Kubernetes集群调度方法中，设备插件将所在网络区域节点的子网资源信息注册至所在网络区域节点的Kubelet，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server的步骤，包括：

网络区域节点的设备插件将子网资源信息注册至网络区域节点的Kubelet；

Kubelet将子网资源信息添加至网络区域节点的节点状态中，将节点状态发布至控制平面的API Server。

优选的，上述Kubernetes集群调度方法中，控制平面的调度器调取Pod的子网需求和API Server的子网资源信息的步骤，包括：

Kubernetes集群创建Pod时，为Pod配置对应的期望子网和请求的IP地址数量，作为Pod的子网需求；

控制平面的调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围。

优选的，上述Kubernetes集群调度方法中，调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的节点的步骤，包括：

调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围；

调度器从API Server中读取子网资源信息；

调度器按照Pod需求的子网IP地址范围匹配子网资源信息，得到期望子网；

调度器将Pod调度至期望子网对应的网络区域节点，网络区域节点的CNI插件为Pod分配期望子网的IP地址。

优选的，上述Kubernetes集群调度方法，在调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点的步骤之后还包括：

Kubelet将Pod的IP地址的分配结果打包为状态报告，将所述状态报告发送至APIServer；

API Server按照状态报告更新网络区域节点的节点状态；

控制平面的监听器访问API Server，获取网络区域节点的节点状态；

监听器按照节点状态更新Subnet CRD实例中对应网络区域节点的子网资源信息。

优选的，上述Kubernetes集群调度方法，调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点的步骤，包括：

调度器调取Pod的资源请求和节点的可分配资源情况；

调度器计算资源请求与可分配资源情况的匹配度；

当匹配度达到或超过预定匹配度阈值时，调度器选择空闲子网资源最多的网络区域节点，执行匹配子网需求和子网资源信息得到期望子网的步骤。

根据本申请的第二方面，本申请还提供了一种基于节点子网可用性的Kubernetes集群调度系统，包括：

子网资源获取模块，用于获取Kubernetes集群中多个网络区域节点的子网资源信息；

子网资源注册模块，用于控制设备插件将所在网络区域节点的子网资源信息注册至网络区域节点的Kubelet中，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server；

子网调取模块，用于控制上述控制平面的调度器调取Pod的子网需求和APIServer的子网资源信息；

节点调度模块，用于控制调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点。

优选的，上述Kubernetes集群调度系统中，节点调度模块，包括：

子网需求读取子模块，用于控制调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围；

子网资源读取子模块，用于控制调度器从API Server中读取子网资源信息；

子网资源匹配子模块，用于控制调度器按照Pod需求的子网IP地址范围匹配子网资源信息，得到期望子网；

Pod调度分配子模块，用于控制调度器将Pod调度至期望子网对应的网络区域节点，网络区域节点的CNI插件为Pod分配期望子网的IP地址。

根据本申请的第三方面，本申请还提供了一种基于节点子网可用性的Kubernetes集群调度系统，包括：

存储器、处理器及存储在存储器上并在处理器运行的基于节点子网可用性的Kubernetes集群调度程序，Kubernetes集群调度程序被处理器执行时实现如上述任一项技术方案提供的基于节点子网可用性的Kubernetes集群调度方法的步骤。

综上，本申请上述技术方案提供的基于节点子网可用性的Kubernetes集群的调度方案，通过获取Kubernetes集群中多个网络区域节点的子网资源信息，然后网络区域节点的设备插件将该子网资源信息注册至Kubelet，Kubelet将这些资源暴露到Node状态中，成为节点资源信息的一部分，这样Kubelet就能够将子网资源信息上报至Kubernetes集群中控制平面的API Server中，控制平面的调度器就能够从API Server中调取该子网资源信息，将Pod的子网需求与该子网资源信息进行匹配，在匹配成功时，将Pod调度至期望子网对应的网络区域节点，通过上述方式，子网资源信息注册至Kubelet后，Kubelet就能够将该子网资源信息上报至控制平面的API Server中，调度器通过访问该API Server，就能够获取到存储在控制平面的etcd中的该子网资源信息，从而将该子网资源信息匹配到对应的Pod的子网需求，实现根据节点的子网可用性筛选期望节点，将Pod调度至与期望子网相匹配的节点的目的。综上，本申请技术方案提供的基于节点子网可用性的Kubernetes集群的调度方案，能够解决现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点，无法根据子网可用性将Pod调度至与期望子网相匹配的节点的问题。

附图说明

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

图1是本申请实施例提供的一种Kubernetes集群的应用场景的示意图；

图2是本申请实施例提供的一种基于节点子网可用性的Kubernetes集群调度方法的流程示意图；

图3是图2所示实施例提供的一种子网资源信息的获取方法的流程示意图；

图4是图2所示实施例提供的一种子网资源信息的注册与上报方法的流程示意图；

图5是图2所示实施例提供的一种调度器对子网需求和子网资源信息的调取方法的流程示意图；

图6是图2所示实施例提供的第一种Pod至区域网络节点的调度方法的流程示意图；

图7是图2所示实施例提供的第二种Pod至区域网络节点的调度方法的流程示意图；

图8是图2所示实施例提供的一种资源配置信息和子网资源信息的更新方法的流程示意图；

图9是本申请实施例提供的第一种基于节点子网可用性的Kubernetes集群调度系统的流程示意图；

图10是图9所示实施例提供的一种节点调度模块的结构示意图；

图11是本申请实施例提供的第二种基于节点子网可用性的Kubernetes集群调度系统的结构示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

现有技术的技术方案存在如下技术问题：

现有的Kubernetes的调度器仅支持CPU、内存和存储等资源的限制和请求，并不支持根据节点的子网可用性筛选期望的节点。这是因为节点的子网并不是Kubernetes的节点资源类型。子网是网络的一个概念，用于划分IP地址空间；而节点资源类型用于描述节点上可用的计算和存储资源，节点资源类型通常包括CPU、内存和存储等。Kubernetes调度器仅支持使用节点资源信息选择节点运行Pod。这样，调度器会考虑节点的资源可用性、利用率及其他约束条件，以确保Pod能够得到合适的资源调度。因此Kubernetes的调度器无法根据子网可用性将Pod调度到与期望子网相匹配的节点上。

为了解决现有技术中的问题，本申请下述实施例提供了基于节点子网可用性的Kubernetes集群调度方案，旨在解决现有技术中Kubernetes集群的调度器无法根据子网可用性将Pod调度到与期望子网相匹配的节点上的问题。该基于节点子网可用性的Kubernetes集群调度方案，能够将子网转化为节点的资源，在此基础上利用Kubernetes调度器、基于资源请求的调度策略，以实现根据节点的子网资源可用性来筛选满足条件的节点，从而将Pod调度到与期望子网匹配的节点。

为达到上述目的，具体参见图1，图1为本申请实施例提供的一种Kubernetes集群的应用场景示意图。图1所示的Kubernetes集群的应用场景包括：控制平面、网络区域、交换机和节点子网。具体地，控制平面包括数据库etcd(一种高可用的分布式键值数据库)、调度器和监听器；网络区域包括网络区域1和网络区域2，其中，每个网络区域的节点分别包括Kubelet、设备插件和Pod。节点子网包括10.6.2.0/24和192.168.1.0/24，通过交换机实现网络区域节点对节点子网的访问。为了实现调度器对Pod和节点子网的调度，本申请的Kubernetes集群的调度方案如下：

分别创建两个网络区域节点对应的Subnet CRD实例(包含子网和子网的IP地址)。

设备插件(Device Plugin)将所在节点的子网资源注册到Kubelet中，Kubelet将这些资源暴露到Node状态中，方便后续调度器使用。

调度器获取有关Pod和子网的信息，包括Pod的子网需求和节点的子网资源。这里的“子网需求”是指Pod期望调度到的子网以及请求的IP地址数量。

调度器根据Pod的子网需求和节点的可用子网资源进行匹配，将Pod调度到与期望子网匹配的节点上。

Pod被调度到正确的节点上后，节点代理Kubelet返回Pod的IP地址分配的结果，并更新节点的资源配置信息。监听器同步更新Subnet CRD实例。

具体参见图2，图2为本申请实施例提供的一种基于节点子网可用性的Kubernetes集群调度方法的流程示意图。如图2所示，该基于节点子网可用性的Kubernetes集群调度方法，包括：

S110：获取Kubernetes集群中多个网络区域节点的子网资源信息。这里的子网资源信息包括多个网络区域节点的子网，每个子网的IP资源范围，所有可用的IP地址等信息。通常情况下每个网络区域节点对应一个子网。本申请实施例根据Kubernetes deviceplugin框架编写设备插件，负责获取多个网络区域节点的子网资源信息，能够将该子网资源信息注册至网络区域节点，并通过Kubelet上报至控制平面的API Server，从而方便调度器的调用，以实现Pod的子网需求与节点的可用子网资源进行匹配。

具体地，作为一种优选的实施例，如图3所示，上述Kubernetes集群调度方法中，步骤S110：获取Kubernetes集群中多个网络区域节点的子网资源信息的步骤，包括：

S111：获取Kubernetes集群中多个网络区域节点；结合图1所示实施例可知，Kubernetes集群中通常存在两个或两个以上的网络区域，每个网络区域都包括至少一个网络区域节点，这样通过轮询等方式就能够获取Kubernetes集群中的多个网络区域节点。通常情况下，这里的多个网络区域节点是指Kubernetes集群中所有数量的网络区域节点。

S112：分别为多个网络区域节点的每个网络区域节点创建Subnet CRD实例，其中，每个Subnet CRD实例包含对应网络区域节点的子网资源信息。其中，节点的子网资源信息能够从节点node capacity中获取。

本申请实施例分别为每个网络区域节点创建Subnet CRD实例，本申请的技术方案使用CRD的方式定义子网的IP资源范围，这样就设计了Subnet CRD对象，每个Subnet CRD对象对应一个子网，该Subnet CRD实例存储了该子网下所有可用的IP地址。

结合图1所示实施例提供的Kubernetes集群的应用场景图可知，图1所示的网络区域1的节点和网络区域2的节点对应的Subnet CRD实例Subnet1和Subnet2分别如下：

由上表可知，Subnet CRD实例包括该网络区域节点下的接入的子网、子网下所有可用的IP地址、子网所有可用的IP地址数和已分配的IP地址数。

图2所示实施例提供的技术方案，在获取Kubernetes集群中多个网络区域节点的子网资源信息后，还包括以下步骤：

S120：设备插件将所在网络区域节点的子网资源信息注册至该网络区域节点的Kubelet，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server。具体地，网络区域节点中的设备插件，向网络区域节点内的Kubelet注册其所在节点的子网资源信息。在子网资源信息注册成功后，子网资源就成为节点状态的一部分，Kubelet负责将包含子网资源信息的节点状态发布到控制平面的API Server中，将子网资源信息作为节点状态更新的一部分，即将子网资源信息融合至节点资源信息中，方便调度器调用。需要说明的是，节点状态中关于节点资源的描述分为节点资源总量(Capacity)和节点可分配资源量(Allocatable)，子网资源信息融入到节点状态中，也将包括子网资源总量和子网可分配资源量。

具体地，作为一种优选的实施例，如图4所示，上述Kubernetes集群调度方法中，步骤S120：将多个网络区域节点的子网资源信息注册至Kubelet，Kubelet将子网资源信息作为节点状态一部分进行上报的步骤，包括：

S121：网络区域节点的设备插件将子网资源信息注册至网络区域节点的Kubelet。结合图1所示的Kubernetes集群的结构可知，每个网络区域至少存在一个网络区域节点，而网络区域节点的设备插件直接负责注册节点资源信息，这样在网络区域节点获取到子网资源信息后，设备插件就能够将该子网资源信息注册到网络区域节点的Kubelet中，从而成为Kubelet的节点资源信息的一部分。

S122：Kubelet将子网资源信息添加至网络区域节点的节点状态中，将节点状态发布至控制平面的API Server，作为节点状态更新的一部分。因为Kubernetes集群的调度器是根据pod资源请求request和节点可用资源的匹配度，调度Pod至指定节点的，所以Kubelet将节点状态发布至控制平面的API Server中，能够实现调度器对Pod的调度，这样就解决了现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点的问题。包含有子网资源信息的节点状态在发布至API Server后，API Server会将这些信息存储至控制平面的数据库etcd中，等到后续调度器调用时，API Server再从etcd中取出。

结合图1所示的Kubernetes集群的应用场景图可知：网络区域节点的Kubelet负责将这些资源信息发布到API Server，作为节点状态更新的一部分。更新后，网络区域1节点(左)和网络区域2节点(右)的资源总量和可分配资源量具体如下：

节点的资源总量：

其中，网络区域1节点的子网资源总量为253个IP地址，网络区域2节点的子网资源总量为253个IP地址。

节点可分配的资源量：

其中，网络区域1节点的可分配子网资源量为250个IP地址，网络区域2节点的可分配子网资源量为249个IP地址。

图2所示实施例提供的技术方案，在将多个网络区域节点的子网资源信息注册至Kubelet的节点资源信息后，还包括以下步骤：

S130：控制平面的调度器调取Pod的子网需求和网络区域节点的子网资源信息。本申请实施例在创建Pod时请求子网的子网资源信息，具体的请求该子网的IP地址资源。结合图1所示实施例提供的Kubernetes集群的应用场景可知，在下述实例中，为Pod指定一个子网“subnet1”，同时Pod请求该子网的IP地址资源。具体地，Pod需要1个的“subnet-ip”资源，而且只能够被调度到接入子网“subnet1”的节点上，此处为网络区域1的节点。

具体地，作为一种优选的实施例，如图5所示，本申请实施例提供的Kubernetes集群调度方法中，上述步骤S130：控制平面的调度器调取Pod的子网需求和API Server的子网资源信息，包括：

S131：Kubernetes集群创建Pod时，为Pod配置对应的期望子网和请求的IP地址数量，作为Pod的子网需求。如背景技术所述，由于不同地区或数据中心的网络规划和限制可能不同，导致某些区域的节点只能使用特定的子网。在此背景下，当应用的Pod期望使用期望子网(例如需要进行网络性能优化和安全隔离)时，需要将Pod调度到与期望子网相匹配的节点上。本申请实施例在Kubernetes集群创建Pod时，为Pod配置对应的期望子网和请求的IP地址数量，从而作为Pod的子网需求。Pod的子网需求也能够只包含子网IP地址范围。

另外，在创建Pod时请求子网的IP地址资源只是在Pod创建前，在Pod YAML配置中指定Pod的IP资源。在Pod创建过程中，调度器会读取这个配置信息，将Pod分配到合适的节点上。

S132：控制平面的调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围。Pod的子网需求包含期望子网以及子网IP地址，这样就能够结合子网IP地址所在的子网IP地址范围确定该Pod期待接入的子网。

具体地，例如：Pod需要1个的“subnet-ip”资源，而且只能够被调度到接入子网“subnet1”的节点上，此处为网络区域1的节点。

以下是该Pod的配置示例：

apiVersion:v1

kind:Pod

metadata:

name:my-pod

annotations:

nominated-subnet:subnet1(为Pod指定子网)

spec:

containers:

-name:my-container

image:myimage

resources:

requests:

subnet_ip:1(请求1个子网IP地址资源)

通过上述配置示例可知，Pod的子网需求包括为Pod指定的子网以及请求该子网的IP地址资源。

图2所述实施例提供的技术方案，在调取Pod的子网需求和节点资源信息中的子网资源信息后，还包括以下步骤：

S140：调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点。调度器在读取上述Pod配置信息，即子网需求时，就能够确知Pod的IP地址分配范围所在的子网，这样调度器就能够对该子网需求与节点的子网资源信息进行匹配，另外通常情况下子网的IP地址若大于或等于1，就能够满足Pod的需求，因此调度器最终能够将该Pod调度至该网络区域节点上。

具体地，作为一种优选的实施例，如图6所示，上述Kubernetes集群调度方法中，步骤S140：调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的节点，具体包括：

S141：调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围；因为Pod创建时就存在Pod配置信息，所以调度器就能够读取该Pod配置信息，获取到Pod子网需求，从而获取到Pod需求的期望子网的子网IP地址范围。

S142：调度器从API Server中读取子网资源信息。因为子网资源信息注册至网络区域节点的Kubelet后，Kubelet将包含有子网资源信息的节点资源信息上传至控制平面的API Server中，这样调度器就能够从API Server中读取该子网资源信息。

S143：调度器按照Pod需求的子网IP地址范围匹配子网资源信息，得到期望子网。调度器获取到Pod的期望子网后，就能够提取得到Pod需求的子网IP地址范围，并且调度器已经从API Server中读取子网资源信息，这样调度器将能够将该子网IP地址范围与子网资源信息进行匹配，得到期望子网。

S144：调度器将Pod调度至期望子网对应的网络区域节点，网络区域节点的CNI插件为Pod分配期望子网的IP地址。

本申请实施例提供的技术方案，Kubernetes集群的调度器读取上述Pod配置信息，得知Pod的IP地址分配范围应在子网“subnet1”内。然后，调度器将该Pod配置信息与节点的可用子网资源进行匹配，且该子网上可用的IP地址大于等于1，满足Pod的需求。因此，调度器最终将该Pod调度到网络区域1的节点上。

另外，可能存在Kubernetes集群的调度器未匹配到Pod的子网需求对应的子网资源信息的情况，在该情况下，需要重新检索和注册子网资源信息，以满足Pod的子网需求。

具体地，作为一种优选的实施例，如图7所示，上述Kubernetes集群调度方法中，步骤S140：调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点，包括：

S145：调度器调取Pod的资源请求和节点的可分配资源情况；

S146：调度器计算资源请求与可分配资源情况的匹配度；

S147：当匹配度达到或超过预定匹配度阈值时，调度器选择空闲子网资源最多的网络区域节点，执行匹配所述子网需求和所述子网资源信息得到期望子网的步骤，将Pod调度至该网络区域节点。

本申请实施例提供的技术方案，Kubernetes调度器有其固定的调度算法。调度器在根据资源request进行调度决策时，是根据容器的资源request(pod yaml中声明)和节点的可分配资源情况的匹配度进行判断的。Kubelet将该子网资源信息上传至API Server中，进而方便调度器从API Server中调取该子网资源信息，以与Pod的子网需求进行匹配。通过上述方式，能够提高子网资源信息与子网需求的匹配度。

另外，作为一种优选的实施例，如图8所示，上述Kubernetes集群调度方法，在步骤S140：调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点的步骤之后还包括：

S150：Kubelet将Pod的IP地址的分配结果打包为状态报告，将状态报告发送至APIServer；

S160：API Server按照状态报告更新网络区域节点的节点状态。这些IP地址分配结果在上传至API Server后，API Server会将这些IP地址分配结果存储在etcd中，作为节点状态的一部分。

S170：控制平面的监听器访问API Server，获取网络区域节点的节点状态。

S180：监听器按照节点状态更新Subnet CRD实例中对应网络区域节点的子网资源信息。

Pod被调度到正确的网络区域节点后，Pod会被分配到子网“subnet1”范围内的一个IP地址，Kubelet返回Pod IP地址分配的结果(包括Pod分配的IP地址和网关)，并更新相应节点的资源配置信息。此时，节点的资源总量不变，可分配资源量发生变化。更新后网络区域1节点的资源配置信息如下所示：

Allocatable:

cpu:16

ephemeral-storage:48294789041

hugepages-2Mi:0

memory: 16328232Ki

subnet-ip: 249(子网IP地址资源减少1个)

pods: 106(节点上剩余可容纳的Pod数量减少1个)

同时，结合图1所示，控制平面的监听器通过访问API Server监听到网络区域1节点的子网IP资源减少一个，便对Subnet CRD实例subnet1进行更新。更新后的subnet1如下：

kind:Subnet

metadata:

name:subnet1

spec:

subnet:10.6.2.0/24

ips:

-10.6.2.2-10.6.2.254

gateway:10.6.2.1

status:

totalIPCount:253

allocatedIPCount:4(已分配IP地址数增加1个)

综上，本申请实施例提供的基于节点子网可用性的Kubernetes集群调度方法，通过获取Kubernetes集群中多个网络区域节点的子网资源信息，然后网络区域节点的设备插件将该子网资源信息注册至Kubelet，Kubelet将这些子网资源信息暴露到Node状态，成为节点资源信息的一部分，这样子网资源信息就能够作为节点资源信息的一部分上报至Kubernetes集群中控制平面的API Server中，控制平面的调度器就能够从API Server中调取该子网资源信息，将Pod的子网需求与该子网资源信息进行匹配，在匹配成功时，将Pod调度至期望子网对应的网络区域节点，通过上述方式，子网资源信息注册至Kubelet后，Kubelet就能够将该子网资源信息上报至控制平面的API Server中，调度器通过访问该APIServer，就能够获取到存储在控制平面的etcd的该子网资源信息，从而将该子网资源信息匹配到对应的Pod的子网需求，实现根据节点的子网可用性筛选期望节点，将Pod调度至与期望子网相匹配的节点的目的。综上，本申请技术方案提供的基于节点子网可用性的Kubernetes集群的调度方案，能够解决现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点，无法根据子网可用性将Pod调度至与期望子网相匹配的节点的问题。

另外，基于上述方法实施例的同一构思，本申请实施例还提供了基于节点子网可用性的Kubernetes集群调度系统，用于实现本申请的上述方法，由于该系统实施例解决问题的原理与方法相似，因此至少具有上述实施例的技术方案所带来的所有有益效果，在此不再一一赘述。

另外，作为一种优选的实施例，参见图9，图9为本申请实施例提供的一种基于节点子网可用性的Kubernetes集群调度系统的结构示意图。如图9所示，该基于节点子网可用性的Kubernetes集群调度系统，包括：

子网资源获取模块110，用于获取Kubernetes集群中多个网络区域节点的子网资源信息；

子网资源注册模块120，用于控制设备插件将所在网络区域节点的子网资源信息注册至网络区域节点的Kubelet中，Kubelet将子网资源信息作为节点状态一部分上报至控制平面的API Server；

子网调取模块130，用于控制控制平面的调度器调取Pod的子网需求和API Server的子网资源信息；

节点调度模块140，用于控制调度器匹配子网需求和子网资源信息得到期望子网，将Pod调度至期望子网对应的网络区域节点。

其中，作为一种优选的实施例，如图10所示，上述Kubernetes集群调度系统中，节点调度模块140包括：

子网需求读取子模块141，用于控制调度器读取Pod的子网需求，获取Pod需求的子网IP地址范围；

子网资源读取子模块142，用于控制调度器从API Server中读取子网资源信息；

子网资源匹配子模块143，用于控制调度器按照Pod需求的子网IP地址范围匹配子网资源信息，得到期望子网；

Pod调度分配子模块144，用于控制调度器将Pod调度至期望子网对应的网络区域节点，网络区域节点的CNI插件为Pod分配期望子网的IP地址。

综上，本申请上述技术方案提供的基于节点子网可用性的Kubernetes集群的调度系统，通过获取Kubernetes集群中多个网络区域节点的子网资源信息，然后网络区域节点的设备插件将该子网资源信息注册至Kubelet，Kubelet将这些资源暴露到Node状态中，成为节点资源信息的一部分，这样子网资源信息就能够作为节点资源信息的一部分上报至Kubernetes集群中控制平面的API Server中，控制平面的调度器就能够从API Server中调取该子网资源信息，将Pod的子网需求与该子网资源信息进行匹配，在匹配成功时，将Pod调度至期望子网对应的网络区域节点，通过上述方式，子网资源信息注册至Kubelet后，Kubelet就能够将该子网资源信息上报至控制平面的API Server中，调度器通过访问该APIServer，就能够获取到存储在控制平面的etcd中的该子网资源信息，从而将该子网资源信息匹配到对应的Pod的子网需求，实现根据节点的子网可用性筛选期望节点，将Pod调度至与期望子网相匹配的节点的目的。综上，本申请技术方案提供的基于节点子网可用性的Kubernetes集群的调度方案，能够解决现有技术中Kubernetes集群调度器不支持根据节点的子网可用性筛选期望节点，无法根据子网可用性将Pod调度至与期望子网相匹配的节点的问题。

另外，参见图11，图11为本申请实施例提供的一种基于节点子网可用性的Kubernetes集群调度系统的结构示意图，如图11所示，该Kubernetes集群调度系统，包括：

处理器1001、通信总线1002.、通信模块1003、存储器1004及存储在存储器1004上并在处理器1001上运行的基于节点子网可用性的Kubernetes集群调度程序，Kubernetes集群调度程序被处理器执行时实现如上述任一项实施例提供的基于节点子网可用性的Kubernetes集群调度方法的步骤。

综上，本申请上述技术方案提供的基于节点子网可用性的Kubernetes集群调度方案，能够将子网转化为节点的资源，并利用Kubernetes调度器的资源请求调度策略，根据节点的子网资源可用性来筛选满足条件的节点。这样能够满足应用跨网络区域部署时的网络规划要求，提供灵活的网络部署方案。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM和光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

应当注意的是，在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本申请可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种基于节点子网可用性的Kubernetes集群调度方法，其特征在于，所述Kubernetes集群包括多个网络区域节点和控制平面，所述网络区域节点包括Kubelet和设备插件，所述控制平面包括调度器和API Server；所述Kubernetes集群调度方法包括：

获取Kubernetes集群中多个网络区域节点的子网资源信息；

所述设备插件将所在网络区域节点的子网资源信息注册至所述网络区域节点的Kubelet，所述Kubelet将所述子网资源信息作为节点状态一部分上报至控制平面的APIServer；

所述控制平面的调度器调取Pod的子网需求和所述网络区域节点的子网资源信息；

所述调度器匹配所述子网需求和所述子网资源信息得到期望子网，将所述Pod调度至所述期望子网对应的网络区域节点。

2.根据权利要求1所述的Kubernetes集群调度方法，其特征在于，所述获取Kubernetes集群中多个网络区域节点的子网资源信息的步骤，包括：

获取所述Kubernetes集群中多个网络区域节点；

分别为所述多个网络区域节点中每个网络区域节点创建Subnet CRD实例，其中，每个Subnet CRD实例包含对应网络区域节点的子网资源信息。

3.根据权利要求1所述的Kubernetes集群调度方法，其特征在于，所述设备插件将所在网络区域节点的子网资源信息注册至所述网络区域节点的Kubelet，所述Kubelet将所述子网资源信息作为节点状态一部分上报至控制平面的API Server的步骤，包括：

所述网络区域节点的设备插件将所述子网资源信息注册至所述网络区域节点的Kubelet；

所述Kubelet将所述子网资源信息添加至所述网络区域节点的节点状态中，将所述节点状态发布至控制平面的API Server。

4.根据权利要求1所述的Kubernetes集群调度方法，其特征在于，所述控制平面的调度器调取Pod的子网需求和所述API Server的子网资源信息的步骤，包括：

所述Kubernetes集群创建Pod时，为所述Pod配置对应的期望子网和请求的IP地址数量，作为所述Pod的子网需求；

所述控制平面的调度器读取所述Pod的子网需求，获取所述Pod需求的子网IP地址范围。

5.根据权利要求1所述的Kubernetes集群调度方法，其特征在于，所述调度器匹配所述子网需求和所述子网资源信息得到期望子网，将所述Pod调度至所述期望子网对应的节点的步骤，包括：

所述调度器读取所述所述Pod的子网需求，获取所述Pod需求的子网IP地址范围；

所述调度器从API Server中读取所述子网资源信息；

所述调度器按照所述Pod需求的子网IP地址范围匹配所述子网资源信息，得到期望子网；

所述调度器将所述Pod调度至所述期望子网对应的网络区域节点，所述网络区域节点的CNI插件为所述Pod分配所述期望子网的IP地址。

6.根据权利要求5所述的Kubernetes集群调度方法，其特征在于，所述调度器匹配所述子网需求和所述子网资源信息得到期望子网，将所述Pod调度至所述期望子网对应的网络区域节点的步骤之后，所述方法还包括：

所述Kubelet将所述Pod的IP地址的分配结果打包为状态报告，将所述状态报告发送至所述API Server；

所述API Server按照所述状态报告更新所述网络区域节点的节点状态；

所述控制平面的监听器访问所述API Server，获取所述网络区域节点的节点状态；

所述监听器按照所述节点状态更新Subnet CRD实例中对应所述网络区域节点的子网资源信息。

7.根据权利要求1所述的Kubernetes集群调度方法，其特征在于，所述调度器匹配所述子网需求和所述子网资源信息得到期望子网，将所述Pod调度至所述期望子网对应的网络区域节点的步骤，包括：

所述调度器调取所述Pod的资源请求和所述网络区域节点的可分配资源情况；

所述调度器计算所述资源请求与所述可分配资源情况的匹配度；

当所述匹配度达到或超过预定匹配度阈值时，所述调度器选择空闲子网资源最多的网络区域节点，执行匹配所述子网需求和所述子网资源信息得到期望子网的步骤。

8.一种基于节点子网可用性的Kubernetes集群调度系统，其特征在于，包括：

子网资源获取模块，用于获取Kubernetes集群中多个网络区域节点的子网资源信息；

子网资源注册模块，用于控制设备插件将所在网络区域节点的子网资源信息注册至所述网络区域节点的Kubelet，所述Kubelet将所述子网资源信息作为节点状态一部分上报至控制平面的API Server；

子网调取模块，用于控制所述控制平面的调度器调取Pod的子网需求和所述网络区域节点的子网资源信息；

节点调度模块，用于控制所述调度器匹配所述子网需求和所述子网资源信息得到期望子网，将所述Pod调度至所述期望子网对应的网络区域节点。

9.根据权利要求8所述的Kubernetes集群调度系统，其特征在于，所述节点调度模块，包括：

子网需求读取子模块，用于控制所述调度器读取所述所述Pod的子网需求，获取所述Pod需求的子网IP地址范围；

子网资源读取子模块，用于控制所述调度器从API Server中读取所述子网资源信息；

子网资源匹配子模块，用于控制所述调度器按照所述Pod需求的子网IP地址范围匹配所述子网资源信息，得到期望子网；

Pod调度分配子模块，用于控制所述调度器将所述Pod调度至所述期望子网对应的网络区域节点，所述网络区域节点的CNI插件为所述Pod分配所述期望子网的IP地址。

10.一种基于节点子网可用性的Kubernetes集群调度系统，其特征在于，包括：

存储器、处理器及存储在所述存储器上并在所述处理器运行的基于节点子网可用性的Kubernetes集群调度程序，所述Kubernetes集群调度程序被所述处理器执行时实现如权利要求1至7中任一项所述的基于节点子网可用性的Kubernetes集群调度方法的步骤。