1. 课程导入与生产视角建立

在测试环境里，Kubernetes 调度往往表现得“很聪明”：Pod 提交后几秒内就被分配到某个节点，服务正常启动，一切看起来顺理成章。但一旦进入生产环境，问题会迅速变得复杂——关键业务 Pod 因为节点资源碎片而 Pending；两个延迟敏感型服务被调度到同一台高负载节点上互相争抢 CPU；某个节点磁盘打满导致其上所有 Pod 被驱逐；一次滚动发布因为副本数配置不当，把整个集群的可用资源挤爆。这些现象背后，其实都指向同一个问题域：调度决策与资源治理。

本课程要建立的第一个认知是：调度不是“把 Pod 放到节点上”这么简单，它是集群资源分配的第一道闸门，也是可靠性治理的起点。调度器（kube-scheduler）在每次决策时，面对的是一个多维约束问题：节点可用资源、亲和与反亲和规则、污点与容忍、拓扑分布、优先级与抢占、镜像本地性等。它必须在毫秒级时间内给出一个“足够好”的答案，而这个答案会直接影响后续的资源竞争、故障域隔离和扩缩容行为。

从生产视角看，调度与资源治理可以拆成四个相互关联的问题域。第一是放置问题：Pod 应该落在哪个节点、哪个可用区、哪组故障域中，才能同时满足性能、成本和容灾要求。第二是配额与边界问题：Namespace 级别的 ResourceQuota、LimitRange，以及 Pod 级别的 requests/limits，决定了每个工作负载能申请多少、能用多少、超用后会被如何处理。第三是竞争与优先级问题：当资源不足时，谁先被调度、谁可以抢占、谁应该被驱逐，这直接关系到核心链路的稳定性。第四是弹性与反馈问题：HPA、VPA、Cluster Autoscaler 如何根据真实负载调整副本数和节点数，以及这些调整是否会与调度策略产生冲突。

可靠性治理的目标并不是“让所有 Pod 都 Running”，而是让系统在资源压力、节点故障、流量突增等条件下，仍然能维持可接受的服务水平。这里需要引入几个关键指标作为判断依据：调度成功率、Pending 时长、节点资源分配率（requests 与 allocatable 的比值）、实际利用率、驱逐次数、OOMKilled 次数、HPA 扩缩容延迟。它们分别对应调度层、资源层和弹性层的健康度。一个常见的生产误区是只看节点 CPU 利用率，却忽略了 requests 已经接近 100%——这意味着新 Pod 根本调度不上去，而现有 Pod 的实际利用率可能只有 30%。

课程整体学习路径按照“先建立判断力，再掌握工具，最后形成治理闭环”来组织。前半部分聚焦调度机制本身：从 Pod 生命周期中的调度阶段、调度器框架、Filter/Score 插件，到亲和性、污点容忍、拓扑分布等约束的实际写法与常见陷阱。中间部分进入资源治理：requests/limits 的语义差异、QoS 等级对驱逐顺序的影响、ResourceQuota 与 LimitRange 的配合、命名空间资源规划。后半部分处理生产高频问题：优先级与抢占、PDB、节点压力驱逐、HPA/VPA 调优、集群自动扩缩容，以及调度器性能与大规模集群下的调优手段。

实战环境方面，课程默认使用一个可复现的多节点 Kubernetes 集群。建议至少准备 1 个控制平面节点和 3 个工作节点，节点规格可以不对等，以便观察资源碎片和调度偏好。工作节点上需要预留可标记的标签（如 disktype=ssd、zone=a、workload=latency-sensitive），用于演示亲和性与拓扑分布。集群需要启用 Metrics Server，以便观察实际利用率并驱动 HPA。如果使用云环境，可以额外开启 Cluster Autoscaler；如果使用本地环境，可以用 kind 或 k3s 搭建，但要注意本地环境无法真实模拟节点自动扩缩容，此时可以用手动添加/删除节点来替代。

为了让后续章节的示例有统一参照，这里先约定几个基础对象：一个名为 prod-web 的 Namespace，配额为 8 核 CPU、16Gi 内存；一个名为 latency-critical 的 PriorityClass，值为 100000；一个名为 batch-low 的 PriorityClass，值为 1000。后续的调度策略、抢占和驱逐实验都会围绕这些对象展开。示例中的参数和结果均为教学假设，实际生产数值需要根据业务压测和容量规划确定。