📚 课程目录第1章课程导论

1. 课程导论：Kubernetes 调度器（kube-scheduler）的核心职责、调度流程概述、为什么资源变更后需要一致性复核

1.1 kube-scheduler 的核心职责

kube-scheduler 是 Kubernetes 控制平面的核心组件之一，负责将待调度的 Pod 绑定到最合适的 Node 上。其决策直接影响集群的资源利用率、应用性能和故障域分布。

职责维度	具体说明
过滤（Predicates）	从集群中筛选出满足 Pod 资源请求、节点亲和性、端口冲突、污点容忍等硬性条件的 Node 集合。
打分（Priorities）	对过滤后的 Node 按资源余量、Pod 分布、自定义策略等维度进行加权评分，选出最优节点。
绑定（Bind）	将 Pod 与目标 Node 的绑定关系写入 etcd，完成调度决策的持久化。
缓存维护	维护集群中所有 Node 的资源快照（scheduler cache），避免每次调度都从 API Server 全量拉取。

  关键认知：kube-scheduler 并非实时调度器，它通过 Informer 机制监听 Pod 和 Node 的变化事件，将待调度 Pod 放入内部队列，以 异步循环的方式逐个执行过滤→打分→绑定。这种设计决定了调度一致性复核的必要性。

1.2 调度流程概述

一次完整的 Pod 调度周期包含以下阶段，每个阶段都可能因资源变更而产生偏差：

Pod 入队：kube-scheduler 通过 Informer 监听未指定 nodeName 的 Pod，将其加入调度队列。
预过滤：检查 Pod 是否满足基本的准入条件（如资源版本、调度器名称匹配）。
过滤：执行一组 Predicate 插件（如 NodeResourcesFit、NodeName、PodTopologySpread），生成候选 Node 列表。
打分：对候选 Node 执行 Priority 插件（如 LeastRequestedPriority、BalancedResourceAllocation），计算最终得分。
保留（Reserve）：在缓存中预占目标 Node 的资源，防止并发调度冲突。
绑定：向 API Server 发送 Binding 请求，将 Pod 绑定到 Node。
后处理：更新缓存、触发事件、记录调度指标。

1.3 为什么资源变更后需要一致性复核

Kubernetes 集群是动态系统，资源变更频繁发生。kube-scheduler 的缓存机制虽然提升了调度性能，但也引入了状态不一致的风险。以下场景是调度一致性复核的核心驱动力：

Node 资源变更：Node 的 CPU/内存容量、可分配资源、设备插件资源发生变化，但 scheduler cache 未及时更新，导致后续 Pod 调度到资源不足的节点。
污点与容忍度变更：Node 新增 NoSchedule 污点，但缓存中仍认为该节点可调度，Pod 被错误绑定。
标签与亲和性变更：Node 标签被修改，影响 nodeSelector 或 NodeAffinity 的匹配结果。
Pod 抢占与驱逐：高优先级 Pod 抢占低优先级 Pod 后，被抢占 Pod 的调度假设失效，需要重新调度。
调度器插件配置更新：自定义调度策略或评分权重调整后，已有调度决策可能不再符合新策略。

生产环境警示：某金融科技公司曾因 Node 内存从 64GiB 扩容至 128GiB 后，scheduler cache 未刷新，导致后续 12 个 Pod 仍按 64GiB 计算资源余量，最终触发 OOMKill 和 Pod 反复重启。事后复盘发现，kube-scheduler 的 cache 一致性检查周期默认长达 5 分钟，这 5 分钟的窗口期就是事故的根源。

1.4 一致性复核的核心目标

目标	说明
缓存与 etcd 对齐	确保 scheduler cache 中的 Node 资源数据与 etcd 中存储的 Node 对象一致。
调度决策可追溯	对每次调度决策记录当时的资源快照，便于事后审计和问题定位。
异常调度回滚	当检测到资源变更导致调度决策失效时，能够触发重新调度或 Pod 驱逐。
调度策略合规	验证调度结果是否仍然满足当前的 Pod 亲和性、拓扑分布、资源预留等策略。

学习建议：本章节是后续所有调度优化和网络拓扑排查的基础。建议读者在实验环境中手动触发 Node 资源变更（如 kubectl cordon、kubectl taint、修改 Node 的 status.allocatable），观察 kube-scheduler 日志和调度队列的变化，建立对一致性问题的直观认知。