Kubernetes调度器为Pod挑选节点的过程可以概括为“先过滤、再打分、最后绑定”：它先剔除不满足硬性条件的节点，再对剩余节点按优先级量化评分，最终把Pod绑定到得分最高的节点上。这个决策过程发生在kube-scheduler组件内部，贯穿于Pod创建到Running状态之间的每一个环节，要理解这套机制，需要从调度框架、核心策略和实际操作三个维度去拆解。
调度器如何为Pod挑选节点的完整流程
Kubernetes调度器并不是拍脑袋选节点,它遵循一套严谨的Pipeline，这套流程在Kubernetes 1.x版本中由调度框架（Scheduling Framework）统一管理，分为调度周期和绑定周期两个大阶段。
调度周期：从Filter到Score的两步走
第一步是过滤，业内俗称预选（Predicates或Filter），调度器遍历集群中所有可调度的Node，把不满足Pod硬性要求的节点全部PASS掉，常见的过滤条件包括：
- 资源请求：Node的可用CPU和内存是否满足Pod的requests值。
- 端口冲突：Pod声明的hostPort是否被节点上其他Pod占用。
- 节点状态：Node是否处于Ready状态，是否存在磁盘压力或内存压力。
- 污点容忍：Node打了污点（Taint），而Pod没有对应容忍（Toleration）。
- 节点亲和性：Pod通过nodeSelector或nodeAffinity指定的标签是否匹配。
第二步是打分，行业内叫优选（Priorities或Score），过滤之后剩下的节点都是“候选者”，调度器按一系列评分策略给每个节点打分（满分100分），分数越高表示越适合运行这个Pod，评分策略涵盖资源均衡度、数据本地性、节点上已有Pod数量等维度，比如LeastRequestedPriority策略倾向于选择资源空闲比例高的节点，而SelectorSpreadPriority则尽量把同一Service的Pod分散在不同节点上，防止单点故障。
绑定周期：最终决策落地的过程
打分结束后,调度器选出最高分节点，如果分数相同，则用Round-Robin方式随机选择一个，随后调度器通过API Server创建一个Binding对象，把Pod与Node的绑定关系写死，这里有一个细节：调度器本身不直接启动Pod的容器进程，它只负责“指路”，真正去拉镜像、启容器的是节点上的kubelet，kubelet监听到Pod被绑定到自己身上，才会开始干活。
影响Kubernetes调度器挑选节点的三大核心机制
虽然默认调度器能处理大多数场景,但生产环境里我们经常需要人为干预调度结果，理解这三个机制，是掌握Pod调度到指定节点的方法的前提。
资源请求与限制：最底层的硬门槛
调度器看资源,不是看节点的总量，而是看节点的可分配量（Allocatable）减去已分配量（Requested）后的差值，这个计算只针对requests，不包含limits，举个例子，一个Node有4核CPU，已分配2.5核，那么对于一个requests为2核的Pod来说它就是不合格的，即使它的limits只设了1核也不行，行业共识认为，生产环境应当为系统组件预留资源（比如kubelet通过--system-reserved参数），否则调度器可能把节点塞满，引发CPU throttling或内存OOM。
节点亲和性与反亲和性：精细控制Pod分布
当需要把Pod部署到特定地域、特定机型的节点时，亲和性规则就派上用场了，这里要区分一下：
- requiredDuringSchedulingIgnoredDuringExecution：硬亲和，必须满足标签匹配，否则Pod无法调度，相当于nodeSelector的升级版，支持In、NotIn、Exists等操作符。
- preferredDuringSchedulingIgnoredDuringExecution：软亲和，尽量满足但不强制，不匹配时调度器会降低该节点分数，而不是直接排除。
反亲和性（podAntiAffinity）是另一个常用策略，它负责让Pod避开某些节点上的同类Pod，典型场景是把同一应用的多个副本打散到不同可用区，避免机房断电导致服务全挂。
污点与容忍度：决定谁能“上桌”
污点是打在Node上的标记,表示“我有特殊要求，闲人勿近”，容忍度则声明在Pod上，表示“我接受这个污点”，只有Pod的容忍度能匹配上Node的污点，它才有资格被调度到该节点，常见的操作场景是为专用节点打上污点，比如node-role.kubernetes.io/ingress=:NoSchedule，让普通业务Pod默认不占用这台机器，只有声明了对应容忍度的Ingress Controller才能部署上去。
Kubernetes节点亲和性配置方案是怎样的
搞清了三大机制,我们来看看具体的Kubernetes节点亲和性配置方案，这里以“把Pod优先部署到SSD节点”为例，给你一套可直接验证的YAML写法。
apiVersion: apps/v1
kind: Deployment
metadata:
name: disk-heavy-app
spec:
replicas: 3
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk-type
operator: In
values:
- ssd
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 40
preference:
matchExpressions:
- key: zone
operator: In
values:
- cn-east-1
containers:
- name: main
image: nginx:1.25
这段配置表达了两层意思：第一，Pod必须调度到label为disk-type=ssd的节点上；第二，如果同时存在多个SSD节点，节点标签为zone=cn-east-1的机器会获得额外40分加分。
如果你需要排查调度是否生效,一条命令就能看穿：
kubectl get pod -o wide | grep disk-heavy kubectl describe pod disk-heavy-app-xxxxx | grep -A 5 "Events"
在描述信息中,Events字段会按时间顺序展示调度器从“凑齐3个副本”到“成功绑定到节点”之间的真实决策轨迹，如果看到FailedScheduling，说明预选阶段就已经没有节点可选了，这时候要重点看平台侧输出的Filter失败原因。
自定义调度器与默认调度器区别在哪
默认的kube-scheduler已能应对大部分业务，但某些场景下你依然需要自己写一个调度器，理解自定义调度器与默认调度器区别，有助于衡量是否值得付出额外维护成本。
| 对比维度 | 默认调度器 kube-scheduler | 自定义调度器 |
|---|---|---|
| 策略扩展 | 通过调度插件（Plugin）扩展评分逻辑 | 完全重写调度算法，集成自研容量预测 |
| 对集群的影响 | 全局生效，所有未指定调度器的Pod都走它 | 通过schedulerName字段指定，只处理特定Pod |
| 开发成本 | 低，修改配置或启用插件即可 | 高，需要独立开发维护控制循环 |
| 适用场景 | 通用微服务、Web应用 | 高复杂度作业调度、批处理、GPU显存敏感型任务 |
| 生态兼容 | 与kubelet、controller-manager深度集成 | 需自行处理Bind、Reserve等操作 |
在大多数情况下,使用自定义调度器是得不偿失的，Kubernetes官方提供了丰富且稳定的调度插件体系，像NodeResourcesFit、InterPodAffinity这些内置策略，通过修改KubeSchedulerConfiguration文件就能完成80%的定制需求，只有当你面对的是算法高度定制化的批处理负载，或需要感知Mesos、Yarn等外部集群状态时，才建议考虑Multi-Scheduler方案。
调度到指定节点的实战排查思路
调度器是一个黑盒,当Pod卡在Pending状态时，我们往往需要一套系统排查方法。
第一步：确认Pod的调度器身份
如果Pod的schedulerName不是default-scheduler，那它根本不走默认调度流程，检查Deployment的YAML，确认没有误写schedulerName字段。
第二步：查看调度事件
kubectl describe pod <pod-name>的Events部分是最直接的线索，常见的错误消息有：
- 0/4 nodes are available: 4 node(s) didn\'t match node selector 说明节点亲和性或nodeSelector不匹配。
- 0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory 说明资源余量不足。
- 0/4 nodes are available: 3 node(s) had taint, that the pod didn\'t tolerate 这是污点过滤导致的问题。
第三步：借助调度器日志和可观测工具
如果事件信息不够细,需要查看kube-scheduler的日志文件（通常是/var/log/kube-scheduler.log），在较新版本中，可以通过kubectl logs -n kube-system <scheduler-pod>拿到决策时的原始打分记录，近年来社区也倾向于在调度器中接入Prometheus指标，scheduler_pending_pods和scheduler_pod_scheduling_duration_seconds这两个监控指标能帮你量化调度时延和Pending数量变化。
Kubernetes调度器挑选节点的底层逻辑就是过滤加打分两个阶段反复逼近最优解：过滤保证准确性，打分保证均衡性，无论使用亲和性、污点还是自定义调度器，最终目的一致让Pod落在最合适的机器上，同时让集群资源的使用率达到较高水平。
关于Kubernetes调度器如何为Pod挑选节点的常见问题
问：Pod处于Pending状态，但节点资源明明还有剩余，是什么原因？
答：优先查看节点上的污点情况，执行kubectl describe node <node-name>，在Taints字段查看是否存在NoSchedule或NoExecute污点，另外检查工作负载是否配置了storageClassName或hostPort端口占用，这些都可能绕过资源计算直接拒绝调度，使用kubectl get events --sort-by=.metadata.creationTimestamp能看到被过滤节点的完整原因链。
问：调度器打分阶段哪个策略权重最高？
答：在默认配置下，NodeResourcesFit策略的权重占比最大，它负责衡量节点CPU和内存的剩余资源比例，但权重并非静态值，云厂商的发行版和Kubernetes版本都会影响权重的最终数值，较长一段时间内，社区推荐的实践是优先关注PodTopologySpread策略，它能把同一个Deployment的副本均匀分布在拓扑域（如可用区）内，避免流量和故障集中在单区域。