Linux中Kubernetes的资源调度策略有哪些

Kubernetes 资源调度策略全览

一 调度器工作流程与核心机制

• 调度器通过监听机制发现未绑定的 Pod，执行“两阶段”决策：先过滤（Predicate）再打分（Priority），最终将 Pod 绑定到得分最高的 Node。常见过滤包括：资源是否充足（PodFitsResources）、端口冲突（PodFitsHostPorts）、节点选择器（MatchNodeSelector）、污点容忍（PodToleratesNodeTaints）、亲和/反亲和（MatchInterPodAffinity）等；常见打分包括：最少请求优先（LeastRequestedPriority）、资源均衡（BalancedResourceAllocation）、节点/镜像亲和（NodeAffinityPriority/ImageLocalityPriority）、Pod 分布分散（SelectorSpreadPriority/InterPodAffinityPriority）等。若无可调度节点，Pod 将保持 Pending。该流程可通过调度框架扩展插件增强能力。

二 节点选择与亲和反亲和

• 定向调度
  • nodeName：在 PodSpec 直接指定节点名，优先级最高，绕过调度器；风险在于节点不存在或资源不足时仍会失败，生产不推荐。
  • nodeSelector：按节点标签进行硬性匹配，简单直观，适合稳定标签场景。
• 节点亲和（Node Affinity）
  • 支持“硬约束”（requiredDuringSchedulingIgnoredDuringExecution）与“软约束”（preferredDuringSchedulingIgnoredDuringExecution），可用操作符含 In/NotIn/Exists/DoesNotExist/Gt/Lt；可与 nodeSelector 叠加，需同时满足。
• Pod 亲和/反亲和（Pod Affinity/AntiAffinity）
  • 基于已有 Pod 的标签与 topologyKey（如 kubernetes.io/hostname、topology.kubernetes.io/zone）决定同域或跨域共置/隔离，同样支持硬/软约束；大规模集群中使用会增加调度耗时，需权衡。

三 污点与容忍、拓扑分散与节点维护

• 污点（Taints）与容忍（Tolerations）
  • 节点通过污点排斥一类 Pod，只有声明了相应容忍的 Pod 才能调度到该节点；常见效果为 NoSchedule/NoExecute，用于专用节点（如 GPU、特殊硬件）或维护场景隔离。
• 拓扑分散约束（Topology Spread Constraints）
  • 按指定 topologyKey（如 zone/rack/hostname）约束同类工作负载在多个拓扑域的最大偏差（maxSkew），提升容灾与分布均匀性，支持 DoNotSchedule/WhenUnsatisfiable 等策略。
• 节点维护操作
  • cordon：将节点标记为不可调度，新 Pod 不再落该节点；drain：驱逐节点上现有 Pod（遵循 PDB、优雅终止等），用于维护/下线；delete：删除节点对象（谨慎使用）。

四 资源请求与配额、QoS 与调度关联

• 资源模型与调度依据
  • 容器通过 requests/limits 声明资源；调度器以 requests 进行节点选择与装箱，运行时通过 cgroup 等机制对 limits 进行限额与隔离；可压缩资源（如 CPU）不足会限流，不可压缩资源（如 内存）不足可能触发 OOMKilled。
• 服务质量（QoS）
  • 根据 requests/limits 关系分为 Guaranteed（requests=limits）、Burstable（requests<limits）、BestEffort（未设置）；在资源紧张时影响调度与驱逐优先级，核心负载建议 Guaranteed。
• 命名空间级配额
  • ResourceQuota：限制命名空间内总 requests/limits、存储与对象数量；LimitRange：为容器/Pod 设置默认与最小/最大 requests/limits，避免“吵闹邻居”与配置漂移。

五 优先级抢占与调度优化实践

• 优先级与抢占
  • 通过 PriorityClass 定义优先级（数值越大越优先），高优先级 Pod 调度失败时触发抢占：尝试驱逐节点上低优先级 Pod 以让高优先级 Pod 就位；抢占过程受 PDB（PodDisruptionBudget）约束，以降低业务中断风险。
• 常见优化建议
  • 合理设置 requests/limits 并基于监控（如 Prometheus）持续校准；为关键负载使用 Guaranteed；结合 nodeAffinity/podAntiAffinity 与 topologySpreadConstraints 实现可用性与分布目标；必要时使用调度框架插件或 Descheduler 做再平衡。