调度与资源：Pod 如何落到 Node 上

3.1scheduler 是个控制器

scheduler 监听 spec.nodeName 为空的 Pod，为其选一个节点，再把这个决定（binding）写回 api-server——它没有"启动容器"，只是填了一个字段。

底层机制（比文档深一层）

很多人把 scheduler 想象成一个"分配器"，仿佛它直接命令某台机器去运行 Pod。实际上它从不与节点通信。它的整个工作闭环都发生在 api-server 这一侧：

• 观测：通过 watch 机制订阅 Pod 对象，筛出 spec.nodeName == "" 且尚未被处理的那些（处于 Pending）。
• 决策：在内存里对所有节点跑两阶段算法（下一节展开），选出一个节点。
• 调谐：创建一个 Binding 子资源 POST 回 api-server，效果等同于把 pod.spec.nodeName 设为选中的节点名。

写回那一刻，scheduler 的工作就结束了。后续交给目标节点上的 kubelet——它也在 watch，发现"有一个 nodeName 等于自己的 Pod 出现了"，于是开始拉镜像、起容器。scheduler 和 kubelet 之间没有直接调用，只有共享的 api-server 状态作为媒介。这正是第 2 章那条主线的再次落地：所有组件都对着同一份声明状态做调谐，彼此不耦合。

与下一节的关系：已经知道 scheduler 的动作是"选一个节点写回去"。那它怎么选？这就是两阶段算法——先排除不可行的，再给可行的打分。

3.2两阶段：Filter 过滤，Score 打分

调度分两步：Filter 先把"放不下/不满足约束"的节点全部排除，得到一批可行节点；Score 再给每个可行节点打分，选分最高的，平手则随机。

底层机制（比文档深一层）

Filter 阶段（历史上叫 predicates）逐个节点判定一组布尔条件，任何一条不满足，该节点立即出局。常见的过滤器：

• PodFitsResources：节点的可分配资源减去其上已有 Pod 的 requests 之和，还够不够装下新 Pod 的 requests。这是本章最关键的一条——下一节专讲。
• nodeSelector / node affinity：节点的标签是否匹配 Pod 指定的标签要求。
• taint 检查：节点上的污点是否被 Pod 的 toleration 容忍（§3.6 展开）。
• volume 相关：Pod 要挂的卷能否在该节点访问（如某些卷有可用区限制）。

Filter 跑完，得到一批"可行节点"。如果这批是空的，Pod 就停在 Pending，并在事件里写 FailedScheduling——这是排查 Pending 的第一现场。

Score 阶段（历史上叫 priorities）只在可行节点里进行：每个打分插件给每个节点打 0–100 分，加权求和，scheduler 选总分最高的那个。若多个节点同分，则在它们之间随机挑一个（避免总往同一台堆）。常见打分维度：让 Pod 尽量分散到资源更空闲的节点、满足 pod affinity 偏好、镜像已在节点上缓存等。

与下一节的关系：图 3.1 反复强调 Filter 看的是 requests。但 requests 到底是什么、它和 limits 差在哪、为什么调度只认它一个？下一节是本章的核心。

3.3requests vs limits：调度只看 requests

requests 是"承诺给你的最小量"——调度与驱逐都按它算；limits 是"运行时上限"——只在节点上由内核约束。调度器对 limits 完全视而不见。

底层机制（比文档深一层）

这里有一个极其反直觉、却必须记牢的事实：

把两个字段的职责并排看：

resources:
  requests:        # 调度按这个占位；保证最小量
    cpu: "250m"    # 0.25 核
    memory: "256Mi"
  limits:          # 运行时上限；只在节点上由内核约束
    cpu: "500m"    # 最多 0.5 核（超了被限流）
    memory: "512Mi" # 最多 512Mi（超了被 OOMKill）

上面这个 Pod 在调度时只占 250m CPU、256Mi 内存的"坑位"；至于 limits 里的 500m / 512Mi，调度器看都不看，它们要到 Pod 落地后才由内核登场——而 CPU 和内存这两个 limit 在内核里的下场截然不同，这是下一节的主题。

3.4可压缩 vs 不可压缩：CPU 变慢，内存被杀

Pod 落到节点后，requests/limits 被翻译成 Linux cgroup 参数。CPU 是可压缩资源——超限只是被限流变慢；内存是不可压缩资源——超限直接被内核 OOMKill。

底层机制（比文档深一层）

kubelet 把资源字段写进容器的 cgroup。四条映射，逐条看下场：

• CPU request → cpu.shares：这是一个相对权重，不是硬上限。节点 CPU 紧张时，各容器按 shares 比例分配时间片；CPU 空闲时，容器可以用超过自己 request 的量。所以 CPU request 决定的是"抢不过来时你能保底拿到的比例"。
• CPU limit → CFS cfs_quota_us / cfs_period_us：这是硬性限流。内核按 period（默认 100ms）为周期，每周期最多让容器跑 quota 微秒。一旦用完配额，容器在本周期内被节流（throttled）暂停，进程不会被杀，只是变慢。
• 内存 request：只参与调度占位与 QoS 判定，内核层面不强约束（不会因为低于 request 就保护你不被回收页缓存）。
• 内存 limit → cgroup memory.limit_in_bytes：硬墙。容器内存用量触到这个值时，内核的 OOM killer 介入，直接杀掉容器内进程（退出码 137 = 128 + SIGKILL 的 9），kubelet 随后将该容器状态标记为 OOMKilled 并按重启策略重启。

与下一节的关系：requests 和 limits 的相对关系（相等？只设 request？都不设？）不只影响内核约束，还把 Pod 分成三个服务质量等级，决定节点内存吃紧时谁先被赶走。这就是 QoS。

3.5QoS 三档：谁先被驱逐

Kubernetes 按 requests/limits 的设置把 Pod 自动归入 Guaranteed / Burstable / BestEffort 三档；节点资源吃紧需要驱逐 Pod 时，从最低档（BestEffort）开始赶。

底层机制（比文档深一层）

三档的判定规则很机械——逐个容器看 requests 和 limits 的关系：

两点要拎清：其一，QoS 是整个 Pod 级别的，但判定要看 Pod 里每个容器——只要有一个容器不满足"request==limit"，整个 Pod 就掉出 Guaranteed。其二，QoS 同时映射到内核的 oom_score_adj：当节点真的触发内核级 OOM 时，分值越高的越优先被内核选中杀掉，方向和 kubelet 的主动驱逐一致——BestEffort 永远是第一个倒霉的。

3.6约束落点：nodeSelector / affinity / taint

资源够只是"能放下"，约束机制再叠加"该不该放这里"：nodeSelector 是硬标签匹配，affinity 表达亲和/反亲和偏好，taint + toleration 让节点主动"排斥"除非 Pod 明确"容忍"。

底层机制（比文档深一层）

• nodeSelector：最简单的硬约束。Pod 写 nodeSelector: {disktype: ssd}，调度器在 Filter 阶段只保留带 disktype=ssd 标签的节点。不匹配则该节点出局，没有"偏好"余地——要么匹配，要么排除。
• node affinity：nodeSelector 的增强版，支持硬性（requiredDuringScheduling，不满足就过滤掉，等价于强约束）和软性（preferredDuringScheduling，不满足只是 Score 阶段扣分，仍可调度）两种强度，还支持 In/NotIn/Exists 等更丰富的匹配。
• pod affinity / anti-affinity：约束对象不是节点标签，而是其他 Pod 的位置。affinity 表达"想和某类 Pod 待在一起"（如缓存与应用同节点降延迟）；anti-affinity 表达"想躲开某类 Pod"（如同一 Deployment 的副本互相排斥，强制分散到不同节点/可用区）。
• taint + toleration：方向反过来——前几种是 Pod 挑节点，taint 是节点排斥 Pod。给节点打污点 kubectl taint nodes node1 key=value:NoSchedule 后，默认所有 Pod 都不会被调度到它上面，除非 Pod 显式声明了能"容忍"这个污点的 toleration。常用于专用节点（GPU 节点只接受声明了 GPU toleration 的 Pod）和节点维护（打 NoExecute 污点会驱逐不容忍的现有 Pod）。

3.7三个高频失败模式

本章的机制对应三类反复出现的线上故障，逐一点明"误解 → 正解"。