Kubernetes调度器工作原理是什么?Pod为什么会被调度到某个节点

Kubernetes调度器是控制平面中的关键组件,它负责决定新创建的 Pod 应该运行在哪个节点上。很多人看到 Pod 进入 Running 状态时,只知道它“被 Kubernetes 跑起来了”,但不清楚背后经历了哪些判断。理解调度器工作原理,有助于排查 Pod Pending、资源不足、亲和性不匹配、污点容忍度不满足等常见问题。

一、Kubernetes调度器负责什么

调度器的核心职责是:为尚未绑定节点的 Pod 选择一个合适的 Node。

它不会真正启动容器。真正拉起容器的是目标节点上的 kubelet 和容器运行时。

调度器更像一个决策组件,负责回答:

  • 这个 Pod 能运行在哪些节点上
  • 哪个节点更适合运行它
  • 最终应该绑定到哪台节点

二、Pod调度大致经过哪些步骤

Pod 调度通常可以拆成几个阶段:

  1. 发现待调度 Pod
  2. 过滤不满足条件的节点
  3. 对候选节点进行打分
  4. 选择得分最高或最合适的节点
  5. 将 Pod 和目标节点绑定
  6. 目标节点 kubelet 拉起容器

也就是说,调度不是随机选择,而是基于资源、约束和策略做出的综合判断。

三、过滤阶段会看什么

过滤阶段会排除不适合运行 Pod 的节点。常见判断因素包括:

  • 节点资源是否足够
  • 节点是否 Ready
  • Pod 的 nodeSelector 是否匹配
  • 节点污点是否能被容忍
  • 亲和性或反亲和性规则是否满足
  • PVC 对存储拓扑是否有限制

如果所有节点都被过滤掉,Pod 就会保持 Pending,并在事件中显示调度失败原因。

四、打分阶段会看什么

过滤后,调度器会对候选节点进行打分,选择更合适的节点。

打分可能考虑:

  • 资源利用是否更均衡
  • 是否更符合亲和性偏好
  • 镜像是否已经存在于节点上
  • 拓扑分布是否更合理
  • 是否满足工作负载分散策略

打分阶段不是判断“能不能运行”,而是判断“哪个节点更适合”。

Kubernetes调度器工作流程

Kubernetes调度器工作流程

五、requests为什么会影响调度

调度器主要根据 requests 评估资源需求,而不是根据应用实际运行瞬时资源使用量。

如果 requests 设置过大,可能导致 Pod 无法调度;如果设置过小,则可能让调度器误判节点还有足够容量,运行后出现资源争抢。

因此,资源请求配置是否合理,会直接影响调度质量。

六、亲和性和污点容忍度有什么作用

亲和性用于表达 Pod 希望调度到哪里,或不希望和哪些 Pod 放在一起。

污点和容忍度则更像节点侧的限制机制:节点打上污点后,只有能容忍该污点的 Pod 才能调度上去。

常见场景包括:

  • 专用节点池
  • GPU 节点
  • 关键业务隔离
  • 不同环境或团队资源隔离

这些策略能让调度结果更符合业务和运维要求。

七、Pod一直Pending和调度器有什么关系

Pod Pending 并不一定是调度器本身故障,更多时候是调度条件不满足。

常见原因包括:

  • 资源不足
  • 节点不可用
  • 亲和性规则过严
  • 污点没有对应容忍度
  • PVC 未绑定
  • Namespace 配额不足

查看 Pod 事件通常可以看到类似“没有可用节点满足条件”的提示。

结语

Kubernetes调度器的核心职责,是把待运行的 Pod 放到合适的节点上。它通过过滤和打分机制综合判断节点资源、调度约束、亲和性、污点容忍度和存储条件。理解调度器工作原理,不仅能帮助你解释 Pod 为什么运行在某个节点,也能更快定位 Pending、资源不足和调度策略配置错误等问题。

FAQ

调度器会启动容器吗?

不会。调度器负责选择节点,真正启动容器的是目标节点上的 kubelet 和容器运行时。

Pod Pending一定是资源不足吗?

不一定。亲和性、污点容忍度、PVC、配额和节点状态都可能导致 Pending。

requests和limits哪个影响调度?

调度器主要根据 requests 判断资源需求,limits 更多影响运行时资源上限。

原创声明:本文为 CNBPA 云原生社区原创技术内容,非商业转载须注明出处:https://www.cloudnative-tech.com/p/6230/。文中原创图示、架构图和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
(0)
上一篇 2026年4月15日 下午3:52
下一篇 2026年4月16日 下午8:09

相关推荐