文档首页/ 云容器引擎 CCE/ 用户指南/ 调度/ Volcano调度/ 任务队列调度/ 队列资源管理调度（Capacity）
更新时间：2025-08-11 GMT+08:00
查看PDF
分享

队列资源管理调度（Capacity）

在Kubernetes集群中，多个团队或业务（如AI训练、大数据分析、在线服务）需要共享计算资源，且不同任务对资源的需求和优先级各不相同。如果所有任务直接竞争资源，则会导致：

  • 资源争抢：高负载任务挤占其他任务的CPU/内存，引发性能下降。
  • 不公平调度：关键业务可能因资源不足而延迟，低优先级任务却占用过多资源。
  • 缺乏隔离：某租户的异常任务（如内存泄漏的任务）可能耗尽节点资源，导致其他租户的正常服务不可用。

Volcano调度器通过队列资源管理机制解决以上问题。队列是Volcano的核心概念之一，用于支持多租户场景下的资源分配与任务调度。通过队列，用户可以实现多租户资源分配、任务优先级控制、资源抢占与回收等功能，显著提升集群的资源利用率和任务调度效率。队列具体功能如下：

表1 队列功能介绍

功能

说明

灵活的资源配置
  • 支持多维度资源配额控制(CPU、内存、GPU、NPU等)。
  • 提供三级资源配置机制，用于控制资源分配。进行三级资源配置时，需遵循“guarantee≤deserved≤capability”的原则。
    • capability：表示队列资源的使用上限。
    • deserved：表示队列资源的应得量。当无其他队列提交任务时，该队列内任务所占资源量可超过deserved值。当有多个队列提交任务且集群资源不够用时，超过值的资源量可以被其他队列回收。

      配置建议：在平级队列场景，建议所有队列的值总和等于集群资源总量。在层级队列场景，子队列的值总和等于父队列的值，但不能超过父队列的值。

    • guarantee：表示资源预留量，预留资源只可被该队列所使用，其他队列无法使用。
  • 支持动态资源配额调整。

层级队列管理
  • 支持多层级队列结构。
  • 提供父子队列间的资源继承与隔离。
  • 支持跨层级队列的资源共享与回收。

智能资源调度
  • 资源借用：允许队列使用其他队列的空闲资源。
  • 资源回收：当资源紧张时，优先回收超额使用的资源（超出deserved部分）。
  • 资源抢占：确保高优先级任务的资源需求。

多租户隔离
  • 严格的资源配额控制。
  • 基于优先级的资源分配。
  • 防止单个租户过度占用资源。

前提条件

约束与限制

该能力处于公测阶段，您可以体验相关特性，但稳定性暂未得到完全验证，不适用CCE服务SLA。

开启队列资源管理调度

您可以在“Volcano调度器 > 专家模式”中开启capacity插件和reclaim action，以实现队列资源的管理调度。capacity插件队列仅支持平级结构，缺乏层级概念，您可以结合层级队列能实现更加精细的多租资源分配。

  1. 登录CCE控制台，单击集群名称进入集群。
  2. 在左侧导航栏中选择“配置中心”，在右侧切换至“调度配置”页签。
  3. 在Volcano调度器配置中，“队列资源管理调度”默认关闭，需进一步修改调度器配置参数以开启该功能。

    1. 在“设置集群默认调度器 > 专家模式”中，单击“开始使用”。
      图1 “专家模式 > 开始使用”

    2. 在YAML配置文件中，添加如下参数，开启capacity插件，以实现队列资源的管理调度。同时需要打开reclaim action，实现队列间的资源回收。当队列资源紧张时，将触发资源回收机制，系统将优先回收超出队列deserved值的资源，并结合队列/任务优先级选择合适的回收对象。

      capacity和proportion插件是相互冲突的，请确保使用capacity插件时已移除proportion插件配置。

      ...
default_scheduler_conf:
  actions: allocate, backfill, preempt, reclaim    # 开启reclaim action
  metrics:
    interval: 30s
    type: ''
  tiers:
    - plugins:
        - name: priority
        - enableJobStarving: false
          enablePreemptable: false
          name: gang
        - name: conformance
    - plugins:
        - enablePreemptable: false
          name: drf
        - name: predicates
        - name: capacity             # 开启capacity插件
        - name: nodeorder
        - arguments:
            binpack.cpu: 1
            binpack.memory: 1
            binpack.resources: nvidia.com/gpu
            binpack.resources.nvidia.com/gpu: 2
            binpack.weight: 10
          name: binpack
    3. 参数填写完成后，在右下角单击“保存”。

  4. 完成上述配置后，单击右下角“确认配置”。在“确认配置”弹窗中，确认修改信息，无误后单击“保存”。
  5. 执行以下命令，创建队列。 

    vim queue.yaml

    文件内容如下，capacity插件支持通过显式配置值来设置队列资源应得量。

    apiVersion: scheduling.volcano.sh/v1beta1 
kind: Queue 
metadata: 
  name: capacity-queue 
spec: 
  capability: 
    cpu: "20" 
    memory: "40Gi"
  deserved: 
    cpu: "10" 
    memory: "20Gi"

    更多参数信息，请参见Queue | Volcano。

    表2 队列参数说明

    参数

    示例

    说明

    capability

    cpu: "20"

    memory: "40Gi"

    可选参数，用于指定该队列的资源上限。若不设置该字段，则队列的capability自动设置为realCapability，即集群的资源总量减去其他队列的总guarantee值。

    deserved

    cpu: "10"

    memory: "20Gi"

    用于指定该队列的资源应得量，需小于等于该队列的capability。当集群资源紧张时，将优先回收超出deserved的资源。若当前队列中已分配的资源量超过自身的deserved值，则该队列不可再回收其他队列中的资源。

    说明：

    当使用Cluster Autoscaler或Karpenter等集群弹性伸缩组件时，集群资源总量将动态变化。此时使用capacity插件时，需要手动调整队列的值以适应资源变化。

队列资源管理调度使用示例

本示例将呈现一个典型的队列资源管理场景，并以此说明队列资源的回收机制。

假设集群中CPU资源全部可用量为4核。初始状态下，集群存在一个default队列，该队列可以使用集群全部资源，默认使用的所有资源都可以回收。本示例将在default队列中创建两个任务占用集群全部CPU资源，再创建一个新队列并提交新任务。此时该任务无资源可用，Volcano将优先回收default队列中超出deserved配额的资源。具体流程如下：

  1. 依次执行以下命令，在default队列中创建两个Volcano job job1和job2，分别申请1核和3核的CPU资源。

    1. 执行以下命令，创建两个Volcano job job1和job2的YAML文件。 
      vim vcjob-a.yaml

      文件内容如下，job1和job2分别申请1核和3核的CPU资源。

      # job1
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: job1
spec:
  queue: default        # 属于default队列
  tasks:
    - replicas: 1
      template:
        spec:
          containers:
            - image: alpine
              name: alpine
              resources:
                requests:
                  cpu: "1"
---
# job2
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: job2
spec:
  queue: default
  tasks:
    - replicas: 1
      template:
        spec:
          containers:
            - image: alpine
              name: alpine
              resources:
                requests:
                  cpu: "3"
    2. 执行以下命令，在default队列中创建上述任务。 
      kubectl apply -f vcjob-a.yaml

      回显结果如下：

      job.batch.volcano.sh/job1 created
job.batch.volcano.sh/job2 created

  2. 执行以下命令，查看Pod的运行情况。 

    kubectl get pod

    回显结果如下，所有Pod的STATUS皆为Running，此时集群CPU资源皆已耗尽。

    NAME           READY        STATUS        RESTARTS       AGE
job1-test-0    1/1          Running       0              3h21m
job2-test-0    1/1          Running       0              3h31m

  3. 依次执行以下命令，创建新队列test。

    1. 执行以下命令，创建新队列的YAML文件。 
      vim new_queue.yaml

      文件内容如下：

      apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: test
spec:
  reclaimable: true
  deserved:
    cpu: 3
    2. 执行以下命令，创建test队列。 
      kubectl apply -f new_queue.yaml

      回显结果如下：

      queue.scheduling.volcano.sh/test created

  4. 依次执行以下命令，在test队列中创建Volcano job job3，并申请3核的CPU资源（未超过deserved），用于触发资源回收。

    1. 执行以下命令，创建Volcano job job3的YAML文件。 
      vim vcjob-b.yaml

      文件内容如下，申请3核的CPU资源。

      # job3
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: job3
spec:
  queue: test
  tasks:
    - replicas: 1
      template:
        spec:
          containers:
            - image: alpine
              name: alpine
              resources:
                requests:
                  cpu: "3"
    2. 执行以下命令，在test队列中创建上述任务。 
      kubectl apply -f vcjob-b.yaml

      回显结果如下：

      job.batch.volcano.sh/job3 created

      由于集群CPU资源已耗尽，job3将触发资源回收机制。

      • 系统回收default队列超出deserved的资源，由于job1（1核）资源不足以支撑job3运行，因此job2（3核）将被驱逐，job1（1核）保留运行。
      • job3（3核）开始运行。待job3任务完成后，被驱逐的任务将重新运行。

  5. 执行以下命令，查看Pod的运行情况。 

    kubectl get pod

    回显结果如下，则说明系统正在回收资源。

    NAME           READY        STATUS            RESTARTS       AGE
job1-test-0    1/1          Running           0              3h25m
job2-test-0    1/1          Terminating       0              3h25m
job3-test-0    0/1          Pending           0              1m

    稍等几分钟后，再次执行以上命令查看Pod的运行情况。回显结果如下，则说明系统已成功回收资源，供job3使用。待job3任务完成释放资源后，被抢占资源的Pod将重新运行。

    NAME           READY        STATUS            RESTARTS       AGE
job1-test-0    1/1          Running           0              3h27m
job2-test-0    0/1          Pending          0              3h27m
job3-test-0    1/1          Running           0              3m

  6. 待job3任务完成后，执行以下命令，再次查看Pod运行情况，验证job2是否重新运行。 

    kubectl get pod

    回显结果如下，则说明被回收资源的Pod已重新运行。

    NAME           READY        STATUS            RESTARTS       AGE
job1-test-0    0/1          Completed           0              3h37m
job2-test-0    1/1          Running             1              3h37m
job3-test-0    0/1          Completed           0              13m

相关文档

父主题： 任务队列调度

相关文档