Volcano队列

资源规划

执行示例前，请确保集群满足以下资源要求：

• 至少有6核可分配CPU、12 GiB可分配内存和3个可分配GPU。
• 为系统组件预留额外资源。
• 两个配额内任务运行后，至少有一个GPU节点可以提供至少1核CPU、2 GiB内存和1个GPU，且没有其他业务占用该资源，以排除节点资源不足对验证结果的干扰。
• 其他Queue未在CPU、内存和GPU维度配置会影响本示例实际可用上限的预留资源。

步骤一：检查并配置Scheduler

1. 执行以下命令，查看当前Scheduler配置。

   kubectl get configmap volcano-scheduler-configmap -n volcano-system \
     -o jsonpath='{.data.volcano-scheduler\.conf}'

   确认配置满足以下要求：

   • actions：包含enqueue和allocate。
   • 插件列表：包含capacity，不包含proportion（二者不可同时启用）。

2. （可选）若当前配置不符合上述要求，修改前建议先备份当前配置，然后执行以下命令进行编辑。

   kubectl edit configmap volcano-scheduler-configmap -n volcano-system

   参考配置如下。请保留集群中其他业务需要的已有插件，不要直接覆盖整个ConfigMap。

   data:
     volcano-scheduler.conf: |
       actions: "enqueue, allocate, backfill"
       tiers:
       - plugins:
         - name: priority
         - name: gang
           enablePreemptable: false
         - name: conformance
       - plugins:
         - name: drf
           enablePreemptable: false
         - name: predicates
         - name: capacity
         - name: nodeorder
         - name: binpack

   关键配置说明如下表所示。

   配置项	类型	是否必选	描述
   enqueue	调度动作	是	检查任务最小运行资源是否满足Queue剩余配额。通过检查后，PodGroup由Pending变为Inqueue。
   allocate	调度动作	是	在Queue资源上限内为任务选择满足条件的节点并分配资源。
   backfill	调度动作	否	尝试利用调度周期中的剩余节点资源。
   capacity	插件	是	根据Queue的资源配置进行准入和分配检查。
   proportion	插件	否	按Queue权重计算资源份额，与capacity不能同时启用。
   gang	插件	否	按PodGroup的minAvailable检查任务最小运行条件。

3. 配置修改完成后，执行以下命令重启Volcano Scheduler，使配置生效。

   kubectl rollout restart deployment volcano-scheduler -n volcano-system
   kubectl rollout status deployment volcano-scheduler -n volcano-system

步骤二：创建两个Queue

1. 创建名为queue-isolation-demo.yaml的文件（文件名可自定义），内容如下：

   apiVersion: scheduling.volcano.sh/v1beta1
   kind: Queue
   metadata:
     name: queue-team-a
   spec:
     deserved:
       cpu: "2"
       memory: 4Gi
       nvidia.com/gpu: "1"
     capability:
       cpu: "2"
       memory: 4Gi
       nvidia.com/gpu: "1"
   ---
   apiVersion: scheduling.volcano.sh/v1beta1
   kind: Queue
   metadata:
     name: queue-team-b
   spec:
     deserved:
       cpu: "4"
       memory: 8Gi
       nvidia.com/gpu: "2"
     capability:
       cpu: "4"
       memory: 8Gi
       nvidia.com/gpu: "2"

   关键参数说明如下表所示。

   参数	类型	描述
   metadata.name	String	Queue名称，在集群内唯一，最长253个字符，并应符合DNS子域名格式。
   spec.deserved	ResourceList	Queue的应得资源。本文将其设置为与capability相同，使示例只关注固定配额边界。
   spec.capability	ResourceList	Queue可使用资源的硬上限。Queue中所有已分配及已进入Queue的任务不能突破该值。
   spec.guarantee.resource	ResourceList	可选。仅供当前Queue使用的预留资源，配置时应小于或等于deserved。本文最小示例不配置该字段。
   spec.parent	String	可选。父Queue名称；未指定时由系统关联到root。训练任务只能提交到叶子Queue。
   nvidia.com/gpu	Integer	NVIDIA GPU扩展资源名称，取值为非负整数。本示例使用该资源名称设置Queue的GPU配额；如果集群注册了其他GPU资源名称，请同步替换Queue和任务中的资源名称。

2. 创建Queue。

   kubectl apply -f queue-isolation-demo.yaml

   若回显类似如下，表示队列创建成功。

   queue.scheduling.volcano.sh/queue-team-a created 
   queue.scheduling.volcano.sh/queue-team-b created

3. 查看Queue状态。

   kubectl get queue queue-team-a queue-team-b \
     -o custom-columns='NAME:.metadata.name,STATE:.status.state,PARENT:.spec.parent'

   确认两个队列的status.state均为Open。

步骤三：提交配额内任务

1. 创建命名空间。

   kubectl create namespace queue-demo

2. 创建名为jobs-within-quota.yaml的文件，内容如下。

   apiVersion: batch.volcano.sh/v1alpha1
   kind: Job
   metadata:
     name: team-a-within-quota
     namespace: queue-demo
   spec:
     queue: queue-team-a
     schedulerName: volcano
     minAvailable: 1
     tasks:
       - name: worker
         replicas: 1
         template:
           spec:
             restartPolicy: Never
             containers:
               - name: worker
                 image: busybox:1.36.1
                 command: ["sh", "-c", "sleep 3600"]
                 resources:
                   requests:
                     cpu: "1"
                     memory: 2Gi
                     nvidia.com/gpu: "1"
                   limits:
                     cpu: "1"
                     memory: 2Gi
                     nvidia.com/gpu: "1"
   ---
   apiVersion: batch.volcano.sh/v1alpha1
   kind: Job
   metadata:
     name: team-b-within-quota
     namespace: queue-demo
   spec:
     queue: queue-team-b
     schedulerName: volcano
     minAvailable: 1
     tasks:
       - name: worker
         replicas: 1
         template:
           spec:
             restartPolicy: Never
             containers:
               - name: worker
                 image: busybox:1.36.1
                 command: ["sh", "-c", "sleep 3600"]
                 resources:
                   requests:
                     cpu: "2"
                     memory: 4Gi
                     nvidia.com/gpu: "1"
                   limits:
                     cpu: "2"
                     memory: 4Gi
                     nvidia.com/gpu: "1"

   GPU扩展资源不能超配，因此示例将每个容器的GPU requests和limits设置为相同的整数。busybox容器不会执行GPU计算，但Pod仍会占用所请求的GPU资源。如果集群无法直接拉取busybox:1.36.1，请将镜像同步到SWR并替换image字段。

3. 提交任务。

   kubectl apply -f jobs-within-quota.yaml

4. 查看任务状态。

   kubectl get vcjob -n queue-demo -o wide
   kubectl get podgroup -n queue-demo -o wide
   kubectl get pod -n queue-demo -o wide

   当集群节点资源满足要求时，预期结果如下：

   • team-a-within-quota和team-b-within-quota的任务状态均变为Running。
   • 对应PodGroup状态均变为Running。
   • 两个Pod均处于Running状态。
   • queue-team-a已分配1 CPU、2GiB和1 GPU，剩余1 CPU、2GiB和0 GPU配额。
   • queue-team-b已分配2 CPU、4GiB和1 GPU，剩余2 CPU、4GiB和1 GPU配额。

5. 查看Queue已分配资源。

   kubectl get queue queue-team-a \
     -o jsonpath='{.status.state}{"\n"}{.status.allocated}{"\n"}'
   kubectl get queue queue-team-b \
     -o jsonpath='{.status.state}{"\n"}{.status.allocated}{"\n"}'

   Queue状态同步可能存在短暂延迟。如果数值尚未更新，请等待一个调度周期后再次查询。

步骤四：提交超过Queue剩余配额的任务

1. 创建名为job-over-quota.yaml的文件。

   apiVersion: batch.volcano.sh/v1alpha1
   kind: Job
   metadata:
     name: team-a-over-quota
     namespace: queue-demo
   spec:
     queue: queue-team-a
     schedulerName: volcano
     minAvailable: 1
     tasks:
       - name: worker
         replicas: 1
         template:
           spec:
             restartPolicy: Never
             containers:
               - name: worker
                 image: busybox:1.36.1
                 command: ["sh", "-c", "sleep 3600"]
                 resources:
                   requests:
                     cpu: "1"
                     memory: 2Gi
                     nvidia.com/gpu: "1"
                   limits:
                     cpu: "1"
                     memory: 2Gi
                     nvidia.com/gpu: "1"

   该任务请求1 CPU、2 GiB和1 GPU。其CPU和内存请求未超过queue-team-a剩余的1 CPU和2 GiB配额，但该Queue的GPU剩余配额为0，因此GPU请求超过Queue剩余配额。

2. 提交任务。

   kubectl apply -f job-over-quota.yaml

3. 查看任务和PodGroup状态。

   kubectl get vcjob team-a-over-quota -n queue-demo -o wide
   kubectl get podgroup team-a-over-quota -n queue-demo -o wide
   kubectl describe podgroup team-a-over-quota -n queue-demo

   预期结果如下：

   • team-a-over-quota保持Pending。
   • 对应PodGroup保持Pending，不会变为Inqueue或Running。
   • PodGroup事件中包含Queue资源配额不足以及nvidia.com/gpu不足等信息。
   • 在启用了延迟创建Pod的主调度流程中，该任务通过Queue配额检查前不会创建业务Pod；不同版本或配置下也可能创建Pending Pod，但任务均不能获得超过Queue上限的资源。
   • queue-team-b剩余的1 GPU配额不会被team-a-over-quota使用。
   • 已运行的team-a-within-quota和team-b-within-quota不受影响。

   至此，已验证两个Queue分别管理CPU、内存和GPU资源用量，并通过capability阻止任务突破所属Queue的GPU资源上限。

步骤六：清理示例资源

删除Queue前，请确保其中不存在处于Running或Inqueue状态的PodGroup，也不存在需要保留的其他业务任务。

1. 删除示例任务。

   kubectl delete vcjob team-a-over-quota team-a-within-quota team-b-within-quota -n queue-demo

2. 确认相关PodGroup和Pod已删除。

   kubectl get podgroup,pod -n queue-demo

3. 删除示例Queue和命名空间。

   kubectl delete queue queue-team-a queue-team-b
   kubectl delete namespace queue-demo

创建训练任务时报错"unable to find job queue"

• 可能原因：目标Queue不存在，或Volcano Admission组件的Queue缓存尚未完成同步。
• 排查步骤：
  1. 执行以下命令，确认Queue是否存在。

     kubectl get queue

  2. 检查任务中spec.queue的值是否与上述输出中的Queue名称完全一致。
  3. Queue刚创建时可能存在短暂延迟，请等待数秒后重试。

创建训练任务时报错"can only submit job to queue with state Open"？

• 可能原因：目标Queue未处于Open状态。
• 排查步骤：
  1. 查看Queue详细状态与事件。

     kubectl get queue <queue-name> -o yaml
     kubectl get events --field-selector involvedObject.kind=Queue,involvedObject.name=<queue-name>

  2. 等待Queue状态恢复为Open后再提交任务。
     

     请勿手动修改status.state字段以绕过Queue生命周期管理。

训练任务长时间处于Pending状态？

• 可能原因：通常由资源不足、调度策略冲突或节点异常导致。
• 排查步骤：
  1. 检查PodGroup状态，确认Pending原因。

     kubectl describe podgroup -n <namespace> <podgroup-name>

  2. 查看Queue配置和当前已分配资源。

     kubectl get queue <queue-name> -o yaml

     确认任务请求资源是否超过Queue的capability，或已达当前allocated上限。

  3. 检查任务的最小运行资源与Queue剩余配额。如果已分配资源 + 已进入Queue的资源 + 任务最小运行资源超过Queue实际可用上限，任务会保持Pending。
  4. 检查Scheduler是否启用了enqueue、allocate和capacity，并确认未同时启用proportion。
  5. 如果Queue配额充足，继续检查节点可分配资源、污点、标签、节点亲和性和设备插件状态。
  6. 查看Scheduler日志，关注异常调度事件。

     kubectl logs -n volcano-system <volcano-scheduler-pod>

配置Queue时提示资源大小关系不合法？

• 可能原因：违反了capacity插件的资源约束公式。
• 排查步骤：逐资源维度检查并确保满足以下关系。

  guarantee.resource <= deserved <= capability

  同时检查资源名称与单位是否正确。例如，CPU使用4或000m，内存使用16 Gi，GPU使用nvidia.com/gpu: "1"。

Queue配额充足，但任务仍无法运行？

Queue配额检查只是调度流程的一部分。任务还必须满足以下条件：

• 集群存在足够的CPU、内存、GPU/NPU或其他扩展资源。
• Pod的节点选择、节点亲和性、污点和容忍条件能够匹配节点。
• PodGroup的minAvailable能够同时满足。
• 镜像能够被节点正常拉取。

若需排查具体原因，请执行以下命令查看详情。

kubectl describe podgroup -n <namespace> <podgroup-name>
kubectl describe pod -n <namespace> <pod-name>

Queue配额未满，但新任务仍提示配额不足？

Queue的status.allocated主要展示已分配资源，Scheduler在enqueue阶段还会统计已经进入Queue、尚未完成分配的任务资源。因此，仅根据status.allocated计算的表面剩余量可能高于Scheduler实际可接收的剩余量。

请同时检查同一Queue下处于Inqueue和Pending状态的PodGroup：

kubectl get podgroup -A -o wide

GPU/NPU仍有空闲，但任务因Queue配额无法调度？

这是Queue资源上限生效的预期结果。capability限制的是当前Queue可以使用的最大资源量，不以整个集群是否仍有空闲资源为判断依据。

如果需要允许该Queue使用更多资源，应由管理员评估其他Queue配置和集群容量后调整capability，而不是修改任务使其绕过目标Queue。