Debian上K8S的资源调度策略有哪些

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为准。

常用调度策略与配置要点

服务质量 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 与专用硬件调度要点

• 使用nodeAffinity + Taints/Tolerations将 GPU 工作负载定向到带nvidia.com/gpu等资源的节点，并隔离普通业务。
• 通过调度框架插件（如 NodeResourcesFit、NodeLabel/NodeAffinity、VolumeBinding 等）启用或调优 GPU 相关打分与过滤逻辑；必要时启用共享 GPU能力的打分插件，优先选择显存/算力申请更合适的 GPU。
• 在云厂商或发行版增强组件中，可进一步开启Binpack/Spread、负载感知打分、抢占策略等，以在高利用率与高可用之间取得平衡。

落地配置建议

• 为关键工作负载设置合理的requests/limits，并选择恰当的QoS；对延迟敏感业务优先使用Guaranteed。
• 优先用nodeAffinity替代 nodeSelector，以表达“必须满足/尽量满足”的复杂约束；对需要共置或隔离的负载使用podAffinity/podAntiAffinity。
• 对大规模集群谨慎使用Inter-Pod Affinity/Anti-Affinity，其计算开销会随节点规模增大而显著增加。
• 通过Taints/Tolerations为专用节点（如GPU/高性能存储）建立“准入门槛”，避免误调度。
• 结合PodTopologySpread实现跨可用区/机架的高可用分布；为有状态/大数据负载提前验证VolumeBinding/Zone约束。
• 需要定制策略时，基于调度框架启用/调权插件（如Binpack、负载感知），或为特定负载指定自定义调度器（.spec.schedulerName）。