Pod从Pending到Running要经过队列、过滤、打分、绑定、kubelet处理和容器启动多个阶段。
Pending可能表示还在等待调度，也可能已经绑定节点但容器还没启动。排查时要先看事件中是否出现Successfully assigned。
相关主题可以结合 Kubernetes、AI基础设施、云原生安全 和 GPU调度 等站内内容一起阅读。
1. 先把Pending拆开看
Pending可能表示还在等待调度，也可能已经绑定节点但容器还没启动。排查时要先看事件中是否出现Successfully assigned。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
2. 调度器先做过滤
过滤阶段会排除资源不足、污点不容忍、亲和性不匹配、端口冲突或PVC不可用的节点。没有可用节点时，Pod会继续Pending。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
3. 过滤后再做打分
打分阶段会按资源、亲和性、拓扑分布等策略为节点排序。最高分节点会被选为目标节点。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
4. 绑定后工作交给kubelet
Scheduler完成绑定并不代表容器已经运行。kubelet还要准备Sandbox、挂载卷、拉取镜像并创建容器。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
| 检查项 | 关注点 | 风险信号 |
|---|---|---|
| 场景 | 是否匹配当前团队阶段 | 只按工具名判断 |
| 边界 | 是否说明适用条件 | 所有环境套一套方案 |
| 验证 | 是否能复测和回滚 | 只看一次演示结果 |
5. Running不等于Ready
容器运行后还需要通过readinessProbe，服务才应该接收流量。很多问题发生在Running到Ready之间。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
6. 调度流程图要覆盖组件协作
完整链路包括API Server、etcd、Scheduler、kubelet、CRI、CNI和CSI。只看Scheduler会漏掉很多真实故障点。
图解文章要让图本身解释主要链路，正文负责补边界和误区。
深入落地说明
1. Pending要先看是否已绑定
Pod Pending时，先看事件里是否出现Successfully assigned。如果没有，问题多半在调度过滤和打分阶段；如果已经绑定，问题可能转到kubelet、镜像、卷或容器启动。
这个分界能显著缩小排查范围。很多人把所有Pending都归因于Scheduler，其实并不准确。
2. 过滤阶段排除不合适节点
过滤会检查CPU、内存、GPU、亲和性、污点容忍、端口、PVC和拓扑约束。任何条件不满足，节点都会被排除。
事件中的Insufficient、taint、affinity mismatch等信息，通常直接指向过滤失败原因。
3. 打分阶段选择更合适节点
过滤后可能还有多个候选节点，调度器会根据打分插件选择更合适的节点。打分策略会影响负载分布、拓扑亲和和资源利用率。
如果业务对拓扑或可用区敏感，要检查亲和性、反亲和性和拓扑分布约束是否符合预期。
4. 绑定后kubelet接手
Scheduler只负责把Pod绑定到节点。之后kubelet负责创建Sandbox、调用CNI、挂载卷、拉取镜像、启动容器和执行探针。
因此调度成功不代表服务可用。镜像拉取失败、卷挂载失败和探针失败都会让Pod无法进入Ready。
5. Running和Ready不要混用
Running表示容器进程已经启动，Ready表示应用通过就绪检查并可以接收流量。服务发现和负载均衡通常依赖Ready状态。
排障时要看conditions和readinessProbe事件，避免把运行中但不可服务的Pod当成健康实例。
图解步骤：从Pending定位到Ready
- 看事件分界：先确认Pod是否已经Successfully assigned，用它区分调度问题和节点启动问题。
- 看过滤失败：资源不足、污点、亲和性、PVC和拓扑约束都会让Pod留在调度阶段。
- 看绑定结果：绑定完成后，问题转移到kubelet、CRI、CNI、CSI和镜像拉取。
- 看容器启动：Sandbox、网络、卷、镜像和启动命令任一失败，都会阻止Pod健康运行。
- 看Ready状态：Running不等于Ready，服务是否接流量要看readinessProbe和Endpoint状态。
图解类文章要让流程图能独立说明链路。正文的任务是补充分叉、误区和排查边界，让读者从图上找到定位入口。
场景化展开：调度流程图要帮助定位分界点
1. Pending阶段要先找分界线
Pod从Pending到Running，中间有多个控制面和节点侧环节。排查时最重要的是先找到分界线：事件里是否出现Successfully assigned。如果没有，问题多半在调度阶段；如果已经绑定节点，问题就转向kubelet、CRI、CNI、CSI或镜像拉取。
这个分界点能明显减少排查范围。没有绑定节点时，不必急着看容器日志；已经绑定节点后，就要关注节点事件、Sandbox创建、网络插件、卷挂载和镜像拉取。
2. Running不代表可以接收流量
很多新手看到Pod Running就认为服务正常，但Kubernetes是否把流量发给Pod，还要看readinessProbe和Endpoint状态。容器进程启动成功，只说明运行态存在；Readiness通过，才说明它可以作为服务后端。
因此流程图里要把Running和Ready分开。服务不可达时，如果Pod Running但NotReady，应继续看探针、应用监听端口、依赖服务和初始化逻辑，而不是只看Pod阶段。
3. 图解文章要把误区写在节点旁边
调度流程图如果只画组件，读者仍然不知道如何排查。更好的图应在每个节点旁标注常见失败原因：调度阶段看资源、污点、亲和性和PVC；节点启动阶段看镜像、网络、卷和运行时；Ready阶段看探针和Endpoint。
这样读者遇到Pending、ContainerCreating、ImagePullBackOff或Running NotReady时，都能从图上找到下一步。图解的价值不在装饰，而在把复杂链路变成可定位路径。
4. 把流程图转成排障手册
调度流程图适合做成排障手册的入口。每个状态对应一组检查项：Pending看调度事件，ContainerCreating看镜像、网络和卷，Running NotReady看探针和Endpoint，ImagePullBackOff看镜像名、凭证和节点网络。状态和命令组合绑定后，排障效率会明显提升。
手册中还应提醒哪些动作会改变现场，例如删除Pod、修改探针、临时扩容或更换镜像。图解帮助理解链路，手册帮助执行动作，两者结合才适合生产环境使用。
5. 面向新人时要解释控制面和节点侧职责
Pod调度流程涉及控制面和节点侧组件，新人常把所有问题都归到调度器。实际上调度器负责选择节点，kubelet负责在节点上驱动运行时创建容器，CNI负责网络，CSI负责存储，镜像仓库和CRI也会影响启动结果。职责分清后，排障路径才清楚。
在团队培训中，可以用同一个Pod示例演示不同失败点：资源不足停在调度阶段，镜像错误进入ImagePullBackOff，卷挂载失败停在ContainerCreating，探针失败导致NotReady。通过对照状态和组件，新人更容易建立完整链路。
6. 常见误区：只看Pod状态，不看事件顺序
Pod状态是结果，事件顺序才展示了过程。同一个Pending状态，可能经历了调度失败、PVC未绑定、节点资源不足或镜像拉取等待；同一个NotReady状态，可能来自启动探针、就绪探针或应用依赖。只看最终状态，很容易误判。
排查时应按时间顺序读取事件，找到状态变化的关键节点。什么时候绑定节点，什么时候创建Sandbox，什么时候拉取镜像，什么时候启动容器，什么时候探针失败。顺序清楚后，流程图里的每个节点才对应得上真实现场。
补充提醒：流程图可以和真实事件样例放在一起。每次遇到新的调度失败类型，就把事件关键字、状态变化和排查命令补回图解说明，长期会形成团队自己的定位地图。
对于平台团队来说，调度流程图还可以用于培训和复盘。新同事通过图理解Pod从提交到接流量的链路，事故复盘则可以把失败点标回图上。时间久了，团队会形成一套自己的故障地图，知道哪些节点最常出问题，哪些指标和事件最值得提前监控。
落地检查清单
- 先确认本文讨论的问题是否就是当前团队的主要矛盾。
- 再检查现有平台、流程和人员职责是否支持这些动作。
- 最后用小范围验证替代一次性大改，保留回滚窗口和复盘记录。
小结
图解Kubernetes调度流程：Pod如何从Pending到Running 的重点，是把读者正在搜索的问题落到真实场景、判断口径和执行顺序中。内容不应该停留在概念解释，也不应该把所有场景压成同一种答案。
发布和复盘时，可以重点检查三件事：标题承诺是否被正文兑现，图表是否帮助读者理解关键链路，FAQ是否回答了真实疑问。
常见问题
1. 这类问题应该先看工具还是先看场景？
建议先看场景。工具能力只有放到团队规模、业务风险、现有平台和运维流程中，才知道是否真的适合。
2. 如果测试环境能跑通，是否可以直接上生产？
不建议。生产环境还要验证权限、观测、告警、回滚、容量和多人协作流程，否则上线后问题会集中暴露。
3. 如何判断这篇文章中的方法是否适合自己的团队？
可以从目标、约束和验证成本三方面判断：目标是否一致，约束是否相近，是否能用小范围实验验证结论。
