CN116204286B - 一种支持拓扑感知的Kubernetes调度方法 - Google Patents
一种支持拓扑感知的Kubernetes调度方法 Download PDFInfo
- Publication number
- CN116204286B CN116204286B CN202211646941.3A CN202211646941A CN116204286B CN 116204286 B CN116204286 B CN 116204286B CN 202211646941 A CN202211646941 A CN 202211646941A CN 116204286 B CN116204286 B CN 116204286B
- Authority
- CN
- China
- Prior art keywords
- pod
- machine room
- kube
- nodes
- information
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 17
- 238000001914 filtration Methods 0.000 claims description 4
- 238000011045 prefiltration Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种支持拓扑感知的Kubernetes调度方法，包括如下步骤：定义业务Pod在各个机房期望的部署比例；zoneConfig信息由控制器写入Pod template模版描述文件中，Pod在提交kube‑apiserver创建时包含zoneConfig部署比例信息。本发明使得kubernetes可以按照节点的拓扑信息在各个机房平均调度，即按照业务需求在各个机房部署指定数量的Pod。当一个机房发生故障时，其他机房的Pod继续提供服务，从而实现业务服务的高可用性。调度框架为实现自定义调度器带来了灵活性和扩展性。
Description
技术领域
本发明涉及云计算技术领域，具体来说，涉及一种支持拓扑感知的Kubernetes调度方法。
背景技术
随着云计算领域的兴起和发展，作为云计算领域的开源容器编排框， Kubernetes在企业中被越来越广泛的使用。越来越多的公司在生产环境中运行了一个或多个Kubernetes 集群。
为了保证业务应用的高可用性，有时需要在 Kubernetes 中将应用同时部署到多个机房，这样即使其中一个机房发生故障，其他机房正常工作，就可以保证业务服务不中断。Kubernetes用于自动部署、扩展和管理“容器化应用程序”的开源系统；Pod Kubernetes中创建和管理的、最小的可部署的计算单元。Kubernetes 从设计上支持同一集群跨多个机房来运行，对于业务应用来说，只需要在调度时将 Pod 同时部署到多个机房，每个机房都可以对外提供服务，就可以保证其高可用性。那么在 Kubernetes 中如何将 Pod 部署到多个机房呢。
kube-scheduler 是 Kubernetes 中专门负责调度 Pod 的组件，调度是指将 Pod放置到合适的节点上的过程，使对应节点上的 Kubelet 能够运行这些 Pod。kube-scheduler 的工作逻辑就是根据特定的调度算法和调度策略，将 Pod 调度到合适的节点上。
节点的区域、可用区、机房等信息我们可以称为节点的拓扑，事实上kube-scheduler 原生并不会感知节点的拓扑信息，也就无法按照拓扑信息来产生不同的调度策略。默认情况下 kube-scheduler 会在各个机房的节点上随机调度，无法保证每个机房都会部署 Pod。当kube-scheduler 将 Pod 调度到某个节点后，kubelet 如果发现节点的资源拓扑亲和性无法满足要求，会拒绝生产该 Pod，同时如果 Pod 的数量由外部循环控制（比如 deployment, replicaset）,将会产生 Pod 被反复创建、调度、生产失败的死循环。所以需要对 kube-sheduler 的工作逻辑做一些改造，让其支持对节点的拓扑感知。
针对上述问题，目前还没有有效的解决办法。
发明内容
针对相关技术中的上述技术问题，本发明提出一种支持拓扑感知的Kubernetes调度方法，能够克服现有技术的上述不足。
为实现上述技术目的，本发明的技术方案是这样实现的：
一种支持拓扑感知的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负责具体创建动作。
进一步地，步骤S2中所述zoneConfig表示Pod在各个机房期望的部署比例。
进一步地，步骤S43中，kube-scheduler按照顺序执行每个filter扩展，filter用于排除不能运行该Pod的节点，如果任何一个扩展标记该节点为不可选，则其余的filter扩展将不会执行。
进一步地，步骤S5中kube-scheduler的scoring用于对所有筛选出的节点执行打分，打分考虑的因素包含节点的负载、节点的亲和性和反亲和性、Pod打散、Pod亲和性和反亲和性，最终会为每个节点生成一个最终得分。
进一步地，步骤S6中kube-scheduler的binding用于将最终选出的节点和Pod进行绑定。
本发明的有益效果：本发明使得 kubernetes 可以按照节点的拓扑信息在各个机房平均调度，即按照业务需求在各个机房部署指定数量的 Pod。当一个机房发生故障时，其他机房的 Pod 继续提供服务，从而实现业务服务的高可用性。本发明依赖于 Kubernetes调度框架，调度框架是 Kubernetes 调度器的一种插件结构，它为集群中现有调度器kube-scheduler提供了一种新的插件 API，插件在编译时会随调度器一起编译，输出到一个可执行文件中。调度框架为实现自定义调度器带来了灵活性和扩展性。开发人员只需要编写不同的调度插件，而无需修改kube-scheduler 源码，即可以实现灵活扩展 kube-scheduler调度器的功能。调度框架定义了一组扩展点，开发人员可以通过实现扩展点定义的接口来注册自己的扩展。调度框架在执行调度工作流时，如果遇到注册的扩展点，则会调用该扩展。
具体实施方式
下面将对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。
根据本发明实施例所述的一种支持拓扑感知的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负责具体创建动作。
实施例中，步骤S2中所述zoneConfig表示Pod在各个机房期望的部署比例。
实施例中，步骤S43中，kube-scheduler按照顺序执行每个filter扩展，filter用于排除不能运行该Pod的节点，如果任何一个扩展标记该节点为不可选，则其余的filter扩展将不会执行。
实施例中，步骤S5中kube-scheduler的scoring用于对所有筛选出的节点执行打分，打分考虑的因素包含节点的负载、节点的亲和性和反亲和性、Pod打散、Pod亲和性和反亲和性，最终会为每个节点生成一个最终得分。
实施例中，步骤S6中kube-scheduler的binding用于将最终选出的节点和Pod进行绑定。
为了方便理解本发明的上述技术方案，以下通过具体使用方式上对本发明的上述技术方案进行详细说明。
在具体使用时，根据本发明所述的一种支持拓扑感知的Kubernetes调度方法，kube-scheduler 的调度过程包含以下几个重要阶段：
(1)pre-filter用于对 Pod 信息进行预处理，或者检查一些必须集群或者 Pod必须满足的前提条件，如果 pre-filter 返回了错误，则调度终止；
(2)filter 用于排除不能运行该 Pod 的节点。kube-scheduler 按照顺序执行每个 filter 扩展，如果任何一个扩展标记该节点为不可选，则其余的 filter 扩展将不会执行；
(3)post-filter 是一个通知类型的扩展点，可以记录一些日志或者更新内部状态；
(4)scoring 用于对所有筛选出的节点执行打分，打分考虑的因素包含 节点的负载，节点的亲和性和反亲和性，Pod 打散，Pod 亲和性和反亲和性等，最终会为每个节点生成一个最终得分；
(5)binding 用于将最终选出的节点和 Pod 进行绑定，由 kubelet 执行创建逻辑。
为了实现上述支持拓扑感知的目标，本发明提供了一种 kube-scheduler 扩展插件，该插件执行的具体步骤如下：
(1)获取当前已部署 Pod 的拓扑信息，即每个机房分别部署了多少 Pod；
(2)按照配置的调度比例，计算下一个 Pod 的最佳机房选择；
(3)对于步骤2中计算出的机房信息，对于集群中所有节点，如果节点的机房信息与该机房不匹配，则将该节点标记为不满足；对于其他节点，继续执行调度框架的其他插件。
上述 kuber-scheduler 扩展插件注册到 kube-scheduler调度框架的 pre-filter阶段，与kube-scheduler 一同编译，形成一个可执行文件，达到无需修改kube-scheduler 源码的方式，即可实现扩展 kube-scheduler 调度器的目的。经过扩展后形成自定义调度器，最终调度器执行的完整逻辑如下：
1. 定义业务 Pod 在各个机房期望的部署比例。比如有 A, B两个机房，希望 Pod在两个机房按照 1:1 比例调度，即两个机房 Pod 数量相等，则可以生成以下配置：{zoneConfig: {A: 1, B:1}}，其中 zoneConfig 表示 Pod 在各个机房期望的部署比例；
2. zoneConfig 信息由控制器写入 Pod template 模版描述文件中，使得 Pod在提交给 kube-apiserver 创建时，包含 zoneConfig 部署比例信息；
3. kube-scheduler 收到 kube-apiserver 的创建 Pod 请求，获取 Pod 的zoneConfig 信息；
4. kube-scheduler 调用扩展插件，计算出下一个 Pod 的最佳机房选择；
5. kube-scheduler 过滤掉机房信息不匹配的节点，对其余节点继续执行过滤、打分操作；
6. kube-scheduler 最终选出一个最佳节点，将 Pod 与该节点进行绑定，由kubelet 负责具体创建动作。
本发明提供一种支持拓扑感知的 Kubernetes 调度方法，通过该方法可以完成业务应用的多机房部署，保障业务服务的高可用性。
综上所述，借助于本发明的上述技术方案，使得 kubernetes 可以按照节点的拓扑信息在各个机房平均调度，即按照业务需求在各个机房部署指定数量的 Pod。当一个机房发生故障时，其他机房的 Pod 继续提供服务，从而实现业务服务的高可用性。本发明依赖于 Kubernetes 调度框架，调度框架是 Kubernetes 调度器的一种插件结构，它为集群中现有调度器kube-scheduler提供了一种新的插件 API，插件在编译时会随调度器一起编译，输出到一个可执行文件中。调度框架为实现自定义调度器带来了灵活性和扩展性。开发人员只需要编写不同的调度插件，而无需修改kube-scheduler 源码，即可以实现灵活扩展kube-scheduler 调度器的功能。调度框架定义了一组扩展点，开发人员可以通过实现扩展点定义的接口来注册自己的扩展。调度框架在执行调度工作流时，如果遇到注册的扩展点，则会调用该扩展。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (5)
1.一种支持拓扑感知的Kubernetes调度方法，其特征在于，包括如下步骤：
S1 定义业务Pod在各个机房期望的zoneConfig部署比例信息；
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负责具体创建动作。
2.根据权利要求1所述的支持拓扑感知的Kubernetes调度方法，其特征在于，步骤S2中所述zoneConfig表示Pod在各个机房期望的部署比例。
3.根据权利要求1所述的支持拓扑感知的Kubernetes调度方法，其特征在于，步骤S43中，kube-scheduler按照顺序执行每个filter扩展，filter用于排除不能运行该Pod的节点，如果任何一个扩展标记该节点为不可选，则其余的filter扩展将不会执行。
4.根据权利要求1所述的支持拓扑感知的Kubernetes调度方法，其特征在于，步骤S5中kube-scheduler的scoring用于对所有筛选出的节点执行打分，打分考虑的因素包含节点的负载、节点的亲和性和反亲和性、Pod打散、Pod亲和性和反亲和性，最终会为每个节点生成一个最终得分。
5.根据权利要求1所述的支持拓扑感知的Kubernetes调度方法，其特征在于，步骤S6中kube-scheduler的binding用于将最终选出的节点和Pod进行绑定。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211646941.3A CN116204286B (zh) | 2022-12-21 | 2022-12-21 | 一种支持拓扑感知的Kubernetes调度方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211646941.3A CN116204286B (zh) | 2022-12-21 | 2022-12-21 | 一种支持拓扑感知的Kubernetes调度方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116204286A CN116204286A (zh) | 2023-06-02 |
| CN116204286B true CN116204286B (zh) | 2023-12-12 |
Family
ID=86508472
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211646941.3A Active CN116204286B (zh) | 2022-12-21 | 2022-12-21 | 一种支持拓扑感知的Kubernetes调度方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116204286B (zh) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111522639A (zh) * | 2020-04-16 | 2020-08-11 | 南京邮电大学 | Kubernetes集群架构系统下多维资源调度方法 |
| CN111666131A (zh) * | 2020-07-03 | 2020-09-15 | 腾讯科技（深圳）有限公司 | 负载均衡分配方法、装置、计算机设备和存储介质 |
| CN113268337A (zh) * | 2021-07-20 | 2021-08-17 | 杭州朗澈科技有限公司 | Kubernetes集群中Pod调度的方法和系统 |
| CN114942845A (zh) * | 2022-05-20 | 2022-08-26 | 湖南快乐阳光互动娱乐传媒有限公司 | 跨集群资源调度方法及装置 |
| CN115396291A (zh) * | 2022-08-23 | 2022-11-25 | 度小满科技(北京)有限公司 | 一种基于kubernetes托管的redis集群故障自愈方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200314204A1 (en) * | 2019-03-27 | 2020-10-01 | Siemens Aktiengesellschaft | Method for operating a network-aware container orchestration system |
-
2022
- 2022-12-21 CN CN202211646941.3A patent/CN116204286B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111522639A (zh) * | 2020-04-16 | 2020-08-11 | 南京邮电大学 | Kubernetes集群架构系统下多维资源调度方法 |
| CN111666131A (zh) * | 2020-07-03 | 2020-09-15 | 腾讯科技（深圳）有限公司 | 负载均衡分配方法、装置、计算机设备和存储介质 |
| CN113268337A (zh) * | 2021-07-20 | 2021-08-17 | 杭州朗澈科技有限公司 | Kubernetes集群中Pod调度的方法和系统 |
| CN114942845A (zh) * | 2022-05-20 | 2022-08-26 | 湖南快乐阳光互动娱乐传媒有限公司 | 跨集群资源调度方法及装置 |
| CN115396291A (zh) * | 2022-08-23 | 2022-11-25 | 度小满科技(北京)有限公司 | 一种基于kubernetes托管的redis集群故障自愈方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116204286A (zh) | 2023-06-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110942387B (zh) | 基于微服务的电票业务功能构建方法和系统 | |
| CN109670951B (zh) | 一种区块链智能合约调试发布方法及系统 | |
| CN109684057A (zh) | 任务处理方法、装置和存储介质 | |
| CN104216912A (zh) | 一种无侵入式的业务表单工作流化的实现方法与装置 | |
| CN105260248B (zh) | 一种可动态调整的任务调度系统和调度方法 | |
| CN111124636A (zh) | 一种流程编排引擎及其控制方法 | |
| CN112463211A (zh) | 一种兼容多种开发架构的系统架构改造方法及系统架构 | |
| CN107294750B (zh) | 一种云集群能自识别的分布配置管理方法和装置 | |
| CN102368216A (zh) | 一种基于项目自动构造的流程实现方法 | |
| CN105955811A (zh) | 一种基于远程调用方式实现任务调度的系统及方法 | |
| CN103197927B (zh) | 一种柔性工作流的实现方法及其系统 | |
| CN112131315A (zh) | 多任务并行开发下的数据库同步方法及装置 | |
| CN115860451A (zh) | 一种流程运行方法、装置、电子设备及存储介质 | |
| US9466037B2 (en) | Versioning and effectivity dates for orchestration business process design | |
| CN116204286B (zh) | 一种支持拓扑感知的Kubernetes调度方法 | |
| US20090024424A1 (en) | System and method for dynamic linking of business processes | |
| CN110941422B (zh) | 代码自动生成方法、代码生成器及可读存储介质 | |
| CN111147541B (zh) | 基于参数服务器的节点处理方法、装置、设备及存储介质 | |
| CN109144486B (zh) | 一种无状态化的工作流程实现方法 | |
| CN116974689A (zh) | 集群容器调度方法、装置、设备及计算机可读存储介质 | |
| CN112068875B (zh) | 一种基于java动态加载实现线索过滤策略系统及方法 | |
| CN101996091B (zh) | 实现支持多种流程运行的图形执行虚拟机系统及其方法 | |
| CN105867892A (zh) | 多开发平台的集中管理方法及系统 | |
| CN115495465A (zh) | 一种数据更新方法、装置及电子设备 | |
| CN112418796B (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |