volcano 使用必知: 从 vcjob 创建到 pod 运行

volcano无疑是当前最火热的调度器之一，尤其是1.0版本之后，关注和使用量都在快速增加。volcano的较丰富的项目文档和使用文章，都已能让我们很好地认识和了解它，包括它的主要特性，核心组件，调度过程等。

但是如果要生产环境使用，有些问题是必须清楚的，比如volcano包含哪些服务组件，它们的职责分别是什么？如果遇到问题，如何定位问题发生在哪个环节，如何定位是哪个组件的问题？带着这些问题，我们首先需要了解的是vcjob的整个生命周期中，创建的过程是如何在volcano组件执行的？

1 volcano调度架构简介

主要概念及解释：

• volcano调度对象是vcjob（volcano创建的CRD），即上图的JobInfo（这是scheduler组件内定义的类）。

• 一个vcjob包含一个或者多个pod，每个pod声明各自的资源要求（如cpu多少个core，memory多少GB，gpu多少卡）

• 每个vcjob对应一个PodGroup概念, 描述整个vcjob的状态，最低资源要求，资源队列等信息。



当我们向kube-apisever创建一个vcjob之后，scheduler组件会将其记录到Cache中。scheduler组件每隔（默认）1秒循环执行如下调度过程：

• OpenSession()初始化本次调度：加载所有plugins，并调用每个plugin的OnSessionOpen()方法

• 依次调用每个action（默认是enqueue，allocate，backfill)

• 每个action会遍历所有的JobInfo，分别对其进行处理

• enqueu过滤JobInfo是否需要进入下一轮allocate

• allocate是资源调度的主要过程，主要概念与kubernetes原生调度器相似，首先predicate过滤node节点，然后priority排序node节点，最后（如有则）绑定pod到一个node。

• CloseSession()结束本次调度：调用每个plugin的OnSessionClose()方法

2 volcano组件及vcjob创建过程

前面我们看到scheduler内部如何对vcjob做资源调度，但是pod和PodGroup是如何被创建的，以及volcano组件在整个vcjob的创建过程中的作用是如何？

2.1 volcano组件

首先，我们看下图，volcano组件及vcjob创建过程

当我们部署volcano完成后，可以看到在kubernetes机器上，主要创建了以上三个service：

• webhook-manager服务：通过向kubernetes服务注册MutatingWebhookConfigurations和ValidatingWebhookConfigurations，修改及校验vcjob。主要职责包括如下：

• mutate：设置schedulerName，queue，taskName等

• validate：检查jobSpec参数，tasks，plugins等合法性检查

• controller-manager服务：监听kube-apiserver上的所有vcjob，pod，PodGroup等资源，主要管理整个vcjob的生命周期，包括其相关的pod和PodGroup的创建，修改（如状态和事件），以及销毁。

• scheduler服务：pod资源调度及绑定

2.2 vcjob创建过程：webhook-manager校验

首先，我们看官方示例vcjob定义：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: job-1
spec:
  minAvailable: 1
  schedulerName: volcano
  queue: test
  policies:
    - event: PodEvicted
      action: RestartJob
  tasks:
    - replicas: 1
      name: nginx
      policies:
      - event: TaskCompleted
        action: CompleteJob
      template:
        spec:
          containers:
            - command:
              - sleep
              - 10m
              image: nginx:latest
              name: nginx
              resources:
                requests:
                  cpu: 1
                limits:
                  cpu: 1
          restartPolicy: Never



通过如下方式想kubernetes集群创建vcjob

kubectl create vcjob demo.yaml



该命令在执行过程中，kube-apiserver服务将调用webhook-manager服务注册的webhook操作，如下：

• webhook-manager将对vcjob做如下修改：

• 如果schedulerName未设置，则使用默认值volcano。这是用于指定使用哪个调度器，对pod资源进行调度。这个很关键，vcjob关联的pod将沿用该schedulerName值，否则该值如果为default或者未设置，则kubernetes调度服务将会处理该pod，这将导致冲突。

• 如果queue未设置，则使用默认值default，即使用默认的资源队列。注，volcano支持多个资源队列（queue），每个queue可配置资源大小及优先级

• 如果taskName未设置，则使用index创建默认名称。注：vcjob内的每个task定义，根据replica数量，对应到kubernetes内的多个pod。

• webhook-mananger对vcjob信息做如下校验：

• vcjob spec基本信息是否合法，包括MinAvailable，MaxRetry

• spec.Tasks信息：名称，Replicas， Policies

• spec.Plugins：是否合法，是被支持的

• spec.Queue：是否存在，且状态是Open

如果webhook-manager校验通过，则vcjob被成功创建。可通过如下命令查看到：

kubectl get vcjob

2.3 vcjob创建过程：controller-manager创建pod及PodGroup

当vcjob被创建后，controller-manager将监听到该信息，并开始管理整个vcjob生命周期的所有相关资源（包括pod及PodGroup），主要操作如下：

• 根据vcjob的spec，创建pod：

• 设置schedulerName（默认使用vcjob的schedulerName），这样该pod就不会被其他scheduler处理了。

• 设置annotations信息，主要包含GroupName信息，即将pod关联到PodGroup

• pod名称：使用job名称，task名称及index（task可能包含多个replicas）

• 设置labels

• 创建PodGroup：先有pod被创建，再有PodGroup被创建

• 设置annotations信息：从pod复制annotations信息

• 设置OwnerReferences：关联到pod

• 设置queue

当pod和PodGroup被创建之后，可以通过如下命令查看到：

kubectl get podgroup
kubectl get pods -owide --all-names|grep job-1

但这时因为pod还未被调度（如果在scheduler调度之前查看），将看到pod的状态是处于pending

2.4 vcjob创建过程：scheduler调度pod

当pod创建完成之后，scheduler服务将监听到该信息，并根据pod和PodGroup信息，对pod进行资源调度和绑定（bind），过程如第一节所述。

当绑定完成后，再通过kubect get pod查看时，可以看到pod状态已变成ContainerCreating或者Running，即相应node节点的kubelet服务已监听到该bind信息，并为该pod创建相应的Container。

3 小结

以上是从vcjob创建到pod运行的简略过程，由此我们可以了解volcano三个组件的主要职责，以及关键节点。这将有利于使用过程中的问题排查及效率优化。

不足之处，本文略过了很多其他细节信息，包括volume信息，queue，metrics等。这些将在后续文章补充。