Debian上Kubernetes资源调度策略全览
在Debian上部署的 Kubernetes 与在其他 Linux 发行版上的调度机制一致，核心由kube-scheduler完成。调度流程分为两步：先进行一组过滤（Predicate）排除不合适的节点，再对通过过滤的节点进行打分（Priority/Score）并选出最优节点。常用过滤包括：PodFitsResources（资源是否充足）、PodFitsHostPorts（主机端口是否冲突）、MatchNodeSelector（节点标签匹配）、PodToleratesNodeTaints（是否容忍节点污点）、NoVolumeZoneConflict（卷与可用区是否冲突）、CheckNodeMemoryPressure/DiskPressure（节点是否处于资源压力状态）等；常用打分包括：LeastRequestedPriority（空闲资源占比高者优先）、BalancedResourceAllocation（CPU/内存使用更均衡者优先）、NodeAffinityPriority、InterPodAffinityPriority、TaintTolerationPriority、ImageLocalityPriority等。调度器只会按照 Pod 的requests进行调度决策，而真正设置 cgroups 限制时以limits为准。
常用调度策略与配置要点
| 策略 | 作用 | 关键字段/插件 | 示例场景 |
|---|---|---|---|
| nodeSelector | 按节点标签进行硬性选择 | spec.nodeSelector | 将某业务固定到带有disktype=ssd的节点 |
| nodeAffinity | 更灵活的节点选择，支持硬/软约束 | spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution / preferredDuringSchedulingIgnoredDuringExecution | 优先调度到GPU节点，如无则回退到普通节点 |
| podAffinity / podAntiAffinity | Pod 间亲和/反亲和，支持软硬约束 | spec.affinity.podAffinity / podAntiAffinity | 将前端+后端放同一节点降时延；将同类副本分散到不同节点提升高可用 |
| Taints & Tolerations | 节点“排斥/容忍”机制，实现专用/隔离 | spec.taints / spec.tolerations | 给GPU节点打污点，仅允许带容忍的 GPU 工作负载调度 |
| 拓扑分散与卷绑定 | 跨拓扑域（节点/机架/可用区）分散；卷可用性校验 | PodTopologySpread、VolumeBinding/VolumeZone | 跨可用区打散副本；确保PVC能绑定到合适节点/区域 |
| 调度框架与多调度器 | 通过插件扩展调度阶段；可为不同工作负载指定不同调度器 | KubeSchedulerConfiguration profiles、queueSort/filter/score、.spec.schedulerName | 启用/调优Binpack或负载感知打分；为AI/GPU类负载使用专用调度器 |
服务质量 QoS 与驱逐优先级
Kubernetes 依据容器requests/limits将 Pod 分为三类 QoS：Guaranteed（每个容器都设置了 requests=limits）、Burstable（至少有一个容器设置了 requests）、BestEffort（未设置 requests/limits）。当节点发生MemoryPressure/DiskPressure或资源紧张触发驱逐时，kubelet 按优先级回收：BestEffort最先被驱逐，其次是Burstable（且实际使用超过 requests 者），最后才是Guaranteed（通常仅在超过 limits 或节点本身处于内存压力时）。此外，调度与驱逐决策均以requests为依据，limits 主要作用于运行时 cgroups 限制。
GPU 与专用硬件调度要点
落地配置建议