先说说咱们今天聊的啥子

火山这玩意儿，别kan名字像是地球上的喷发口，实际上它是 Kubernetes 里一个专门搞批处理调度的神器。

说实话，hen多小伙伴一听到 “火山”，第一反应就是“哎呀，是不是要去爬山？”哈哈，误会大了！

今天咱们就来掰开了讲——怎么把官方给的 pgyaml 文件拆开来kan，顺便把调度器内部的打分、资源借用这些细节给你整明白。

先抛个官方例子出来别急，我会一步步拆。

apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
  name: test
  namespace: default
spec:
  minMember: 3
  minResources:
    cpu: "4"
    memory: "8Gi"
  queue: default
status:
  phase: Pending

这个文件里Zui关键的几个字段：

minMember——Zui少要几只 pod 同时跑起来才算成功。

minResources——CPU、内存这些资源的下限，确保够用。

queue——这个 podGroup 属于哪个队列，后面我们会聊到队列是怎么抢资源的。

Volcano 在启动的时候，会把上面的 yaml 转成内部结构体。

// 简化版结构体定义
type PodGroup struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`
    Spec   PodGroupSpec   `json:"spec,omitempty"`
    Status PodGroupStatus `json:"status,omitempty"`
}

不对不对，这里还有一层 “JobInfo”。其实每个 PodGroup Zui终会被封装进一个 JobInfo 对象，用来统一管理调度逻辑。

下面这段代码是官方给出的计算资源装箱得分的函数，你kan着就知道它在干嘛了。

func ResourceBinPackingScore  {
    if capacity == 0 || weight == 0 {
        return 0, nil
    }
    usedFinally := requested + used
    if usedFinally> capacity {
        return 0, fmt.Errorf
    }
    // 使用率越高分数越高
    score := usedFinally * float64 / capacity
    return score, nil
}

简单说就是 “ / 节点总量 × 权重”。使用率高，得分高，调度器geng爱选这台机器。

Volcano 的核心思想是插件化。每个调度步骤叫 Action，每个 Action 又会调用一堆 Plugin 的实现函数。

type Action interface {
    Name string
    Initialize
    Execute
    UnInitialize
}

比如 enqueue、allocate、backfill 等，这几个顺序决定了先排队、再分配、Zui后填补空余。

这里有两个概念：deserved 和 guarantee。

deserved——队列理应拥有的资源量，比如 A 队列 deserved=10GPU。

guarantee——保底资源，即使全局紧张也一定Neng拿到的那块儿。这个一般配合 proportion 插件使用，让权重决定Zui终占比。

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: dev-queue
spec:
  weight: 5          # 相对权重
  reclaimable: true # Ke以被其他队列回收多余资源
  capability:
    cpu: "32"
    memory: "128Gi"

go
// 在 Session 初始化时注册插件函数
ssn.AddNodeOrderFn

不对不对，上面代码写错了我想说的是：

ssn.AddNodeOrderFn, nodeOrderFn)

POD Group 就是所谓的 gang，一组 pod 必须一起满足 minMember 才Neng真正跑起来。

func  OnSessionOpen {
    validJobFn := func *api.ValidateResult {
        job, ok := obj.
        if !ok {
            return &api.ValidateResult{
                Pass:false,
                Message:"convert fail",
            }
        }
        if job.CheckTaskValid == false {
            return &api.ValidateResult{
                Pass:false,
                Reason:"NotEnoughPodsOfTask",
                Message:"任务数不足",
            }
        }
        // ...
        return nil
    }
    ssn.AddJobValidFn, validJobFn)
}

这里相当于往 Session 注入了一个校验函数。Allocate 那一步会调用它，Ru果验证不通过就直接把整个 Gang 挂起，不会出现半吊子跑出来的尴尬局面。

下面给你整一个完整的小案例，假设我们有两支部门 A 和 B，各自dou有自己的 queue 配置，然后提交一个需要 GPU 的 podGroup。

# dev-queue.yaml
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: dev-queue
spec:
  weight: 8
  reclaimable: true
  capability:
    cpu: "64"
    memory: "256Gi"
---
# prod-queue.yaml
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: prod-queue
spec:
  weight: 12
  reclaimable: false   # 不让别人抢走它的保底资源 
...
# my-pg.yaml 
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
  name: ml-job-pg
spec:
  minMember: 4          # 至少四个 pod 同时跑 
  minResources:
    cpu: "16"
    memory: "32Gi"
    nvidia.com/gpu: "4"
  queue: dev-queue      # 指定所属队列 
...

A 部门实际用了12GPU，但它只 deserved=10GPU，于是系统会自动把多余的2GPU 借给 B 部门，只要 B 的 queue 是可回收，就Neng瞬间搞定跨部门抢占。

- 别忘了在 Deployment 或 Job 上加上注解 `schedulerName=volcano`，否则默认调度器会抢走你的 pod。哈哈，这点经常被新人忽视！

- 权重和比例插件一定要配合使用，否则 guarantee 会失效，你可Nengkan到某些 queue 永远拿不到资源。说实话，这种情况常见于刚装好 Volcano 没仔细阅读文档的小伙伴们。

- Ru果遇到 “tasks in gang unschedulable” 的错误信息，一般dou是因为 minMember 没达标或者节点上资源根本不够。Ke以先 `kubectl describe podgroup xxx` kan下具体原因。嗯，对，就是这样查！

- 想要观察调度过程？打开 `volcano-scheduler-configmap` 把 actions 从 `"enqueue, allocate"` 改成 `"enqueue, allocate, backfill"` 再观察日志。别担心改完记得恢复，不然生产环境可Neng被“回填”刷屏。哈哈哈~

好啦，今天的话题就聊到这儿。Ru果还有哪块儿不清楚，就在评论区甩出你的疑问吧，咱们一起啃硬骨头~ 哈哈！懂得dou懂，不懂的慢慢来呗~ 🚀​