华为云CCE调度器原理深度剖析：从kube-scheduler到Volcano

在Kubernetes集群中，调度器的工作就是将处于Pending状态的Pod分配到合适的节点上运行。这个过程看起来简单，但背后涉及一系列精妙的算法设计。本文将从Kubernetes默认调度器kube-scheduler的工作原理出发，深入剖析华为云CCE中Volcano调度器的增强能力，包括负载感知调度、重调度（Descheduler）以及装箱调度（Binpack）等核心机制。

一、kube-scheduler：两阶段调度的经典设计

kube-scheduler为每一个新创建的Pod选择最优节点，整个过程分为过滤和打分两个阶段。

过滤阶段：调度器遍历集群中的所有节点，排除那些不满足Pod调度需求的节点。过滤条件包括节点资源是否充足（CPU、内存是否满足Pod的Request）、节点选择器是否匹配、节点亲和性/反亲和性规则、污点和容忍度等。过滤完成后，剩下的节点构成一个候选节点集合。

打分阶段：调度器对候选集合中的每个节点进行打分，分数最高的节点被选中运行Pod。打分机制基于一系列优先级函数，例如节点资源均衡分布、Pod亲和性、镜像本地存在性等。每个优先级函数会给出一个分数，最终加权求和得出总分。

这套设计清晰、可扩展，但在生产环境中，它暴露了一个根本性的缺陷：调度决策基于静态的Resource Request，而非动态的真实资源使用情况。

二、Request与真实使用的错配：问题的根源

Kubernetes调度器在做决策时，依据的是Pod声明的Resource Request和节点剩余的可分配资源。但业务的资源申请量和实际使用量经常不一致。

以Java应用为例，启动阶段可能瞬时占用大量CPU，稳定运行后资源消耗反而下降。有些业务内存申请得比较保守，实际使用量远低于Request。更有甚者，BestEffort类型的Pod没有设置Request和Limit，调度器完全无法从资源声明中判断它们会消耗多少资源。

更隐蔽的问题是监控数据更新和调度决策之间存在时间差。短时间批量创建Pod时，调度器可能已经把多个Pod分配到同一个节点，但这些新Pod的资源消耗还没有进入监控数据。从监控曲线看，节点仍然很空，后续Pod可能继续被调度到这个节点。等负载真正跑起来后，这个节点已经变成了热点。

在CCE生产集群的真实案例中，业务的内存Request和Limit通常相差2GB左右，典型配置是Request=12GB、Limit=14GB。滚动变更时，如果某个节点因旧Pod被删除导致真实内存水位短暂下降（例如从60%降到40%），调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位的节点，导致新Pod集中调度。等业务真正启动并接近实际内存使用后，该节点迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。

单个Pod调度不准，影响可能有限。但Deployment批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。

三、Volcano负载感知调度：让调度器看见真实负载

为了解决上述问题，华为云CCE在Volcano调度器中集成了负载感知调度能力。其核心思路是：将节点的真实CPU和内存利用率纳入调度决策，让新Pod更合理地分布到集群中。

CCE的负载感知调度架构引入了两个关键机制：

真实负载采集：Volcano负载感知调度插件从CCE云原生监控插件中获取节点当前的CPU和内存使用率，让调度器知道节点现在的真实资源利用率，而不是仅仅依赖静态的可分配资源。

影子负载机制：对于已经被调度、但还没有被监控系统采集到的Pod，CCE引入了影子负载缓存与Pod资源预估模型。这些Pod的资源消耗会被预估并暂存，在后续调度决策中一并考虑，避免因监控延迟导致的连续热点。

通过将静态指标与动态感知有机结合，负载感知调度能够有效避免将新Pod集中调度到瞬时低水位的节点上，保障集群在发布和扩缩容过程中的平稳运行。

四、重调度（Descheduler）：让集群持续保持均衡

调度器只在Pod创建时做一次决策。Pod一旦被绑定到某个节点，就不会触发重新调度。但Kubernetes集群的环境是动态变化的——节点需要维护、负载发生变化、新节点加入集群。这些变化会导致集群在一段时间之后出现不均衡的状态。

Volcano调度器的重调度（Descheduler）功能正是为了解决这个问题。它可以根据配置的策略，驱逐不符合策略的Pod，让其重新调度，达到均衡集群负载、减少资源碎片化的目的。

重调度最核心的策略是负载感知重调度（LoadAware）。它通过实时监控节点的资源使用率，构建集群资源视图，在观测到节点资源率较高时自动干预，将热点节点上的一些Pod迁移到利用率低的节点上。

LoadAware策略定义了三个节点状态区间：

正常节点：资源利用率在30%到80%之间，这是期望达到的合理水位区间。

热点节点：资源利用率高于80%的节点。重调度器会从热点节点驱逐一部分Pod，将负载水位降至不超过80%。

空闲节点：资源利用率低于30%的节点，可以作为迁移的目标。

除了负载感知重调度，Volcano还提供了资源碎片率整理策略（HighNodeUtilization） 。该策略从资源分配率低的节点上驱逐Pod，必须与Volcano调度器的Binpack策略或kube-scheduler的MostAllocated策略配合使用。通过将分散在各节点的Pod重新聚拢，释放出完整的节点资源，减少资源碎片。

五、装箱调度（Binpack）：最大化资源利用率的反向思路

与负载均衡的思路相反，装箱调度（Binpack）的目标是最小化资源使用量，将资源合理地分配给每个任务，使所有资源实现最大化的利用。

Binpack调度算法为满足调度条件的节点打分，节点的资源利用率越高得分越高。这意味着调度器会优先将Pod调度到已经比较"满"的节点上，而不是均匀分散。这种策略的优势在于可以减少各节点的空闲资源碎片，提高集群整体的资源利用率。

Binpack策略适合资源敏感型场景，例如批处理任务或成本敏感型业务。但需要注意的是，Binpack策略与负载均衡策略是两种不同的优化目标，需要根据实际业务场景选择合适的调度策略。

六、调度器选型：kube-scheduler还是Volcano

CCE集群中，Pod的调度依赖于kube-scheduler或Volcano调度器。两者如何选择？

kube-scheduler适合常规的微服务类工作负载，调度逻辑成熟稳定，能满足大部分场景的需求。

Volcano调度器适合需要批量调度、异构资源管理（GPU/NPU）、公平调度、队列管理等高级调度能力的场景。例如AI训练、大数据处理等批处理任务，以及需要精细化管理GPU资源的推理服务。

在实际生产环境中，两者并非互斥关系。CCE支持在集群中同时安装Volcano插件，由Volcano接管特定工作负载的调度，而kube-scheduler继续处理普通微服务Pod的调度。

总结

从kube-scheduler的两阶段过滤打分，到Volcano的负载感知调度、重调度和装箱调度，Kubernetes的调度能力正在从"能用"走向"好用"。负载感知调度解决了Request与真实使用错配的核心痛点；重调度让集群在动态变化中持续保持均衡；装箱调度则提供了另一种资源优化的思路。

理解这些调度器的工作原理，有助于在实际运维中做出更合理的调度策略配置——是追求负载均衡还是追求资源利用率最大化，是依赖静态Request还是引入动态负载感知，是让调度一次完成还是配合重调度持续优化。这些决策背后，是对集群调度本质的深刻理解。