一种支持拓扑感知的Kubernetes调度方法技术

本发明专利技术公开了一种支持拓扑感知的Kubernetes调度方法，包括如下步骤：定义业务Pod在各个机房期望的部署比例；zoneConfig信息由控制器写入Pod template模版描述文件中，Pod在提交kube

【技术实现步骤摘要】
一种支持拓扑感知的Kubernetes调度方法


[0001]本专利技术涉及云计算
，具体来说，涉及一种支持拓扑感知的Kubernetes调度方法。

技术介绍

[0002]随着云计算领域的兴起和发展，作为云计算领域的开源容器编排框， Kubernetes 在企业中被越来越广泛的使用。越来越多的公司在生产环境中运行了一个或多个 Kubernetes 集群。
[0003]为了保证业务应用的高可用性，有时需要在 Kubernetes 中将应用同时部署到多个机房，这样即使其中一个机房发生故障，其他机房正常工作，就可以保证业务服务不中断。Kubernetes用于自动部署、扩展和管理“容器化应用程序”的开源系统；Pod Kubernetes中创建和管理的、最小的可部署的计算单元。Kubernetes 从设计上支持同一集群跨多个机房来运行，对于业务应用来说，只需要在调度时将 Pod 同时部署到多个机房，每个机房都可以对外提供服务，就可以保证其高可用性。那么在 Kubernetes 中如何将 Pod 部署到多个机房呢。
[0004]kube
‑
scheduler 是 Kubernetes 中专门负责调度 Pod 的组件，调度是指将 Pod 放置到合适的节点上的过程，使对应节点上的 Kubelet 能够运行这些 Pod。kube
‑
scheduler 的工作逻辑就是根据特定的调度算法和调度策略，将 Pod 调度到合适的节点上。
[0005]节点的区域、可用区、机房等信息我们可以称为节点的拓扑，事实上kube
‑
scheduler 原生并不会感知节点的拓扑信息，也就无法按照拓扑信息来产生不同的调度策略。默认情况下 kube
‑
scheduler 会在各个机房的节点上随机调度，无法保证每个机房都会部署 Pod。当kube
‑
scheduler 将 Pod 调度到某个节点后，kubelet 如果发现节点的资源拓扑亲和性无法满足要求，会拒绝生产该 Pod，同时如果 Pod 的数量由外部循环控制（比如 deployment, replicaset）,将会产生 Pod 被反复创建、调度、生产失败的死循环。所以需要对 kube
‑
sheduler 的工作逻辑做一些改造，让其支持对节点的拓扑感知。
[0006]针对上述问题，目前还没有有效的解决办法。

技术实现思路

[0007]针对相关技术中的上述技术问题，本专利技术提出一种支持拓扑感知的Kubernetes调度方法，能够克服现有技术的上述不足。
[0008]为实现上述技术目的，本专利技术的技术方案是这样实现的：一种支持拓扑感知的Kubernetes调度方法，包括如下步骤：S1 定义业务Pod在各个机房期望的部署比例；S2 zoneConfig信息由控制器写入Pod template模版描述文件中，Pod在提交kube
‑
apiserver创建时包含zoneConfig部署比例信息；
S3 kube
‑
scheduler收到kube
‑
apiserver的创建Pod请求，获取Pod的zoneConfig信息；S4 kube
‑
scheduler调用扩展插件，计算出下一个Pod的最佳机房选择，具体步骤如下：S41 获取当前已部署Pod的拓扑信息；S42 按照步骤S1中Pod的部署比例计算下一个Pod的最佳机房选择；S43对于该最佳机房集群中所有节点，如果节点的机房信息与该机房不匹配，则将该节点标记为不满足；对于其他节点，继续执行调度框架的其他插件；S5 kube
‑
scheduler过滤掉最佳机房中信息不匹配的节点，对其余节点继续执行过滤、打分操作；S6 kube
‑
scheduler最终选出一个最佳节点，将Pod与该节点进行绑定，由kubelet负责具体创建动作。
[0009]进一步地，步骤S2中所述zoneConfig表示Pod在各个机房期望的部署比例。
[0010]进一步地，步骤S43中，kube
‑
scheduler按照顺序执行每个filter扩展，filter用于排除不能运行该Pod的节点，如果任何一个扩展标记该节点为不可选，则其余的filter扩展将不会执行。
[0011]进一步地，步骤S5中kube
‑
scheduler的scoring用于对所有筛选出的节点执行打分，打分考虑的因素包含节点的负载、节点的亲和性和反亲和性、Pod打散、Pod亲和性和反亲和性，最终会为每个节点生成一个最终得分。
[0012]进一步地，步骤S6中kube
‑
scheduler的binding用于将最终选出的节点和Pod进行绑定。
[0013]本专利技术的有益效果：本专利技术使得 kubernetes 可以按照节点的拓扑信息在各个机房平均调度，即按照业务需求在各个机房部署指定数量的 Pod。当一个机房发生故障时，其他机房的 Pod 继续提供服务，从而实现业务服务的高可用性。本专利技术依赖于 Kubernetes 调度框架，调度框架是 Kubernetes 调度器的一种插件结构，它为集群中现有调度器kube
‑
scheduler提供了一种新的插件 API，插件在编译时会随调度器一起编译，输出到一个可执行文件中。调度框架为实现自定义调度器带来了灵活性和扩展性。开发人员只需要编写不同的调度插件，而无需修改kube
‑
scheduler 源码，即可以实现灵活扩展 kube
‑
scheduler 调度器的功能。调度框架定义了一组扩展点，开发人员可以通过实现扩展点定义的接口来注册自己的扩展。调度框架在执行调度工作流时，如果遇到注册的扩展点，则会调用该扩展。
具体实施方式
[0014]下面将对本专利技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本专利技术一部分实施例，而不是全部的实施例。基于本专利技术中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本专利技术保护的范围。
[0015]根据本专利技术实施例所述的一种支持拓扑感知的Kubernetes调度方法，包括如下步骤：S1 定义业务Pod在各个机房期望的部署比例；
S2 zoneConfig信息由控制器写入Pod template模版描述文件中，Pod在提交kube
‑
apiserver创建时包含zoneConfig部署比例信息；S3 kube
‑
scheduler收到kube
‑
apiserver的创建Pod请求，获取Pod的zoneConfig信息；S4 kube
‑
scheduler调用扩展插件，计算出下一个Pod的最佳机房选择，具体步骤如下：S41 获取当前已部署Pod的拓扑信息；S本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种支持拓扑感知的Kubernetes调度方法，其特征在于，包括如下步骤：S1 定义业务Pod在各个机房期望的部署比例；S2 zoneConfig信息由控制器写入Pod template模版描述文件中，Pod在提交kube
‑
apiserver创建时包含zoneConfig部署比例信息；S3 kube
‑
scheduler收到kube
‑
apiserver的创建Pod请求，获取Pod的zoneConfig信息；S4 kube
‑
scheduler调用扩展插件，计算出下一个Pod的最佳机房选择，具体步骤如下：S41 获取当前已部署Pod的拓扑信息；S42 按照步骤S1中Pod的部署比例计算下一个Pod的最佳机房选择；S43对于该最佳机房集群中所有节点，如果节点的机房信息与该机房不匹配，则将该节点标记为不满足；对于其他节点，继续执行调度框架的其他插件；S5 kube
‑
scheduler过滤掉最佳机房中信息不匹配的节点，对其余节点继续执行过滤、打分操作；S6 kube
‑
scheduler最...

【专利技术属性】
技术研发人员：林萍萍，章云鹏，刘贞午，
申请(专利权)人：山东未来网络研究院紫金山实验室工业互联网创新应用基地，
类型：发明
国别省市：