第3章 选址与落地：从调度器到kubelet

第3章 选址与落地：从调度器到 kubelet

章节摘要：本章跟着一条线走——orders-api 的 3 个 Pod 副本从账本里的"待调度条目"，变成 3 台节点上真正运行、探针盖章就绪的容器。途中经过资源请求的量化、调度器的过滤与打分、kubelet 与容器运行时的造箱作业，最后由探针接管健康裁判权。

一条主线

第2章结束时，声明已入账，控制器也据此创建了 3 个 Pod 对象——但它们此刻只是账本里的三行记录，没有 IP、没有进程，字段 nodeName 还是空的。本章的主线就是填上这个空：谁有权填（调度器）、按什么依据填（资源与规则）、填完之后谁来兑现（kubelet 与容器运行时）、兑现之后谁说了算（探针）。

这条线上每一步都可能卡壳，而且卡法各异：资源写得不合理会常年 Pending，污点没容忍会无人接单，镜像拉不下来会卡在 ContainerCreating，探针配得太狠会陷入重启循环。本章四节按流水线顺序展开，任何一节诊断的问题都发生在特定工位上。

图 3-1：两段式选址的漏斗

沿途站点

本章四节，对应声明的四个工位：

• 3.1 资源请求与限制：requests 是给调度器看的报价单，limits 是给容器上的封顶线。这一节讲清两者的区别、QoS 等级与"不写资源等于埋雷"的原因，是选址的数字依据。
• 3.2 过滤与打分：调度器的两段式选址：预选淘汰不可行节点，优选给可行节点打分排序。这一节教你用 describe 读懂 Pending 的证据链，并理解亲和性与污点这两类精细控制。
• 3.3 kubelet 与容器运行时：节点上的工头领到任务后，如何按 CRI 接口指挥运行时造沙箱、拉镜像、启容器、上报状态。
• 3.4 探针接管：容器跑起来不等于能接活。readiness 决定进不进负载均衡，liveness 决定要不要重启，startup 护送慢启动应用。三种探针的参数与误杀案例都在这一节。

四节是一条流水线：3.1 产出调度依据，3.2 完成选址，3.3 兑现运行，3.4 判定就绪。任何一环出问题，表现都落在 Pod 的状态列上——这也是第7章排障手册的骨架。

拐点与结论

本章的认知拐点在 3.1 与 3.4 各有一个。前者的拐点是理解调度看的是 requests 而不是实际用量——你以为节点很空闲，调度器却说资源不足，因为它只认报价单；后者的拐点是readiness 与 liveness 的职权分离——就绪探针失败是"暂时别给我流量"，存活探针失败是"处决重启"，两者配反了就是事故制造机。

结论一句话：从 Pending 到 Ready 的每一步，都有明确的责任主体与状态落账；学完本章，任何卡在中间状态的 Pod 你都能指出卡在哪个工位、该向谁要证据。

读完你应该

• 写出带 requests 与 limits 的容器声明，并预测它对调度结果的影响；
• 解释 QoS 三等级的判定规则与节点资源吃紧时的驱逐顺序；
• 用 describe 的事件段定位 Pending 与 FailedScheduling 的具体原因；
• 说明 nodeSelector、节点亲和、污点容忍各自解决的问题与优先级；
• 描述 kubelet 经 CRI 指挥容器运行时的完整过程与状态上报路径；
• 为 Web 服务与慢启动应用分别配出合理的探针参数，并识别误杀型配置。

下一章的接力

3 个副本全部 Ready，声明第一次完整兑现。但集群是动态的：节点会坏、版本要升、流量会涨。第4章看控制器如何守住这份声明——副本少了补、版本旧了换，以及这一切背后的调和循环机制。