Kubernetes调度器调度Pod依赖哪些指标？是否参考节点历史资源利用率？

Kubernetes调度器的调度流程分为过滤、打分两个核心阶段，依赖的核心指标如下：

• Pod自身定义的资源申请值：即spec.containers[].resources.requests中声明的CPU、内存、GPU等常规/扩展资源的申请量，是调度计算的核心基础
• 节点可分配资源量：对应节点状态上报的status.allocatable值，该值已经扣除了节点操作系统预留、kubelet组件预留的资源，并非节点硬件总资源
• 节点污点与Pod容忍度的匹配规则：无法匹配节点污点的Pod会直接被过滤出可选节点范围
• 亲和性/反亲和性规则：包含节点亲和性/反亲和性、Pod亲和性/反亲和性两类用户自定义的拓扑调度约束
• 节点运行状态：节点是否就绪、是否存在内存压力/磁盘压力/PID压力等异常状态，存在异常状态的节点默认会被过滤
• 存储匹配规则：Pod关联的PVC的拓扑约束、存储类挂载要求、节点已有存储挂载冲突等
• 端口占用规则：Pod声明的hostPort是否已经被节点上其他进程占用

原生Kubernetes默认调度器的调度决策仅基于调度快照时刻的静态元数据，仅用Pod申请资源量、节点已分配资源总量（即所有已经调度到该节点的Pod的requests之和）计算节点剩余可分配资源，不会纳入节点的实时负载、历史资源利用率作为参考。
这个设计是为了保证调度的一致性和性能：调度器本身无状态，仅依赖etcd中存储的集群元数据快照做决策，不需要对接监控系统采集实时/历史负载，也避免了监控数据延迟、波动导致的调度决策震荡问题。
如果需要将节点实际资源利用率纳入调度参考，可以扩展自定义调度插件，比如社区开源的Trimaran插件，就可以对接监控数据基于节点历史负载做调度优化，但这属于额外扩展能力，并非原生调度器的默认逻辑。

内容的提问来源于stack exchange，提问作者Saeid Ghafouri