第八章 Kubernetes调度器 - 调度器概念
一、前置知识回顾与本章学习目标
本章前序内容已覆盖云计算基础概念、Kubernetes核心组件、网络拓扑结构、Pod定义与生命周期、Pod控制器、Service、存储等核心知识点。
在实验过程中会发现，Pod默认调度到哪个节点是不可控的，而实际业务场景中往往需要精准控制Pod的调度位置（例如GPU图像识别任务需要调度到搭载GPU的节点）。本章将讲解调度器核心逻辑，解决上述调度控制问题。
本章核心内容分为四个部分：调度器概念、调度亲和性、容忍与污点、固定节点调度。
二、调度器核心概念
Kubernetes集群中的独立组件Scheduler（调度器）核心功能为：将处于Pending状态的Pod，分配到集群的Node节点上运行。
调度器的核心特性
- 独立运行：调度器是独立运行的程序，可剥离出集群；剥离后集群将失去默认调度能力，支持用户自定义开发调度器替代默认实现。
- 监听机制：启动后会持续监听
APIServer，筛选满足以下两个条件的Pod进行调度：- Pod的
spec.schedulerName字段为空（未指定自定义调度器） - Pod的
spec.nodeName字段为空（未指定固定目标节点）
- Pod的
- 设计原则：默认调度器需要满足四个核心要求：
- 公平性：保证所有节点都能获得调度机会，避免调度偏向部分节点
- 资源高效利用：最大化使用集群全量资源（CPU、内存、磁盘、GPU、网络等），避免资源倾斜浪费，保证各节点资源消耗均衡
- 调度效率：能够快速完成大批量Pod的调度，不能过度追求调度合理性导致耗时过长
- 灵活性：支持用户自定义调度规则，允许管理员干预调度结果
三、自定义调度器演示
默认调度器名称为default-scheduler，若Pod未指定schedulerName则默认使用该调度器。用户可自定义开发调度器，通过指定Pod的schedulerName参数切换使用的调度器。
简易自定义调度器实现（演示用，生产环境不推荐）
以下为简化版自定义调度器实现逻辑，仅用于演示调度原理，不具备生产环境的资源判断等高级特性：
- 启动
APIServer本地代理，暴露无认证的访问接口：
该接口仅绑定本地回环地址，避免外部网络访问风险，生产环境如需安全访问需配置kubectl proxy --port=8001RBAC权限。 - 编写调度脚本，核心逻辑如下：
- 循环监听
APIServer，筛选schedulerName为自定义名称（如my-schedule）且nodeName为空的Pod列表，通过jq解析APIServer返回的Pod列表JSON数据完成筛选 - 获取当前集群可用节点列表，随机选择一个节点作为调度目标
- 调用
APIServer接口，提交Pod与目标节点的绑定关系 - 休眠1秒后重复上述流程
- 循环监听
- 安装依赖工具
jq（JSON解析工具），执行脚本即可完成自定义调度。
演示效果
- 创建指定
schedulerName: my-schedule的Deployment后，对应Pod初始处于Pending状态 - 运行自定义调度器脚本后，Pod被成功调度到
Node02，状态变为Running，完成绑定 - 若Pod未指定
schedulerName，则默认使用default-scheduler完成调度
四、K8s调度流程
K8s调度分为预选和优选两个核心阶段：
1. 预选阶段（过滤不符合条件的节点）
预选阶段会遍历所有节点，应用预选规则过滤掉不满足Pod运行要求的节点，所有预选规则必须全部满足，节点才会通过预选，只要有一条规则不满足直接淘汰。
常见预选规则包括：
- 节点剩余资源（CPU、内存等）大于等于Pod请求的资源
- 若Pod指定了
nodeName，则节点名称必须与指定值匹配 - 节点已使用的端口与Pod申请的端口不冲突（适用于
HostNetwork模式的Pod） - 节点标签与Pod指定的节点选择器标签匹配
- 节点挂载的存储卷与Pod指定的卷不冲突
预选结果处理： - 如果没有满足条件的节点，Pod会保持
Pending状态并不断重试调度（重试频率逐渐降低），直到有节点满足条件 - 如果有多个满足条件的节点，进入优选阶段
2. 优选阶段（对通过预选的节点打分排序）
优选阶段会对所有通过预选的节点，按照预设规则计算得分，选择得分最高的节点作为最终调度目标。
常见优选规则包括：
- 节点CPU、内存使用率越低，权重越高
- 节点CPU、内存使用率越接近（资源使用越均衡），权重越高（与上一条规则叠加使用，避免单维度使用率低但另一维度过载的节点被优先选择）
示例：Node01 CPU使用率90%、内存使用率10%，Node02 CPU和内存使用率均为50%，仅按「CPU/内存使用率越低权重越高」规则，两者得分接近；叠加「资源使用越均衡权重越高」规则后，Node02的得分会明显高于Node01，更符合调度预期。
- 节点已存在的镜像总大小越大，权重越高（Pod所需镜像在节点上已存在的概率更高，可减少镜像拉取时间，实际实现中收集节点镜像列表的代价与收益不成正比，生产环境通常不采用该规则）
调度流程示例
- 预选阶段：
Node03因内存不足（Pod请求2G内存，节点总内存仅1.4G）被淘汰，Node01和Node02通过预选 - 优选阶段：
Node02资源使用更均衡，得分高于Node01，最终被选中 - 绑定阶段：调度器向
APIServer提交Pod与Node02的绑定关系，随后kubelet调用CRI接口在节点上创建Pod
AI 总结
本章讲解了Kubernetes调度器的核心概念、自定义调度器的实现逻辑，以及调度过程的预选、优选两个阶段的核心规则，帮助读者掌握Pod调度的控制方法，解决业务场景中的精准调度需求。