kube-batch

https://github.com/kubernetes-sigs/kube-batch

一. 做什么的？

官方介绍:

A batch scheduler of kubernetes for high performance workload, e.g. AI/ML, BigData, HPC

二. 使用方式

apiVersion: batch/v1

kind: Job

metadata:

  name: qj-1

spec:

  backoffLimit: 6 #最大失败重试次数

  completions: 6  #需要成功运行pod的次数

  parallelism: 6  #并行运行pod的个数

  template:

    metadata:

      annotations:

        scheduling.k8s.io/group-name: qj-1

    spec:

      containers:

      - image: busybox

        imagePullPolicy: IfNotPresent

        name: busybox

        resources:

          requests:

            cpu: "1"

      restartPolicy: Never

      schedulerName: kube-batch # 指定调度器是 kube-batch

---

apiVersion: scheduling.incubator.k8s.io/v1alpha1

kind: PodGroup

metadata:

  name: qj-1

spec:

  minMember: 6　# 最小可用数量，达到这个数量才将任务调度到节点上去

三. 调度的单位

一个task对应一个pod
一个job对应一个或多个task
Pod Group　记录该job内的pod的状态
一个job对应一个pod group

如果Job未声明一个对应的pod group ,kube-batch将会给一个默认的

Pod Group　定义：

{

    "metav1.TypeMeta":{},

    "metav1.ObjectMeta":{},

    "Spec":{

        //用来做gang schedule

        "MinMember":1,//default 1

        "Queue":"",

        "PriorityClassName":""

    },

    "Status":{

        "Phase":"",//Pending, Running,Unknown

        "Conditions":[],//optional

        "Running":0,//正在运行的pod的数量

        "Succeeded":0,//已经成功结束的pod的数量

        "Failed":0,//失败的pod的数量

    }

}

四. 整体结构

从数据流的角度给出项目框架结构：

主调度流程：

五. 几个plugin

５.1 DRF (Dominant　Resource　Fairness)

主要资源（cpu,memory,gpu）的均衡使用算法。

目的：　尽量避免集群内某一类资源　使用比例偏高，而其他类型资源使用比例却很低的不良状态

方式: 在调度时，让具有最低资源占用比例的任务具有高优先级

细节:

DRF计算了每个job的一个share值，share值的计算公式为:

share = Max(someKindOfResource.allocated / totalResourceInTheCluster)

share = 最大的某类资源申请比例

func (drf *drfPlugin) calculateShare(allocated, totalResource *api.Resource) float64 {

	res := float64(0)

	for _, rn := range totalResource.ResourceNames() {

		share := helpers.Share(allocated.Get(rn), totalResource.Get(rn))

		if share > res {

			res = share

		}

	}

	return res

}

DRF 定义两个Function　，分别是preemptableFn　和　jobOrderFn:

jobOrderFn 是job的排序函数，会让share值越小的job排在最前面，即拥有最高的优先级，这个是实现DRF算法的关键。

preemptableFn　返回可抢占的job列表，job的筛选规则是　：如果待选job的share值大于将被调度的job的share值，则选中该待选job。

５.2 Gang

　

Gang策略要实现的功能：　只有当指定的某几个pod都分配到资源后，才正在地将pod调度到节点上.

定义的几个plugin function

preemptableFn 为避免Gang的策略被preempt　和　reclaiｍ干扰，定义了preemptableFn,排除那些还未准备就绪的job，避免被抢占。

虽然实际上这些job未真正调度到node上去，但是确实从逻辑上把资源分配给它了

jobOrderFn 为让已经就绪的job尽快被调度到节点，定义了jobOrderFn ,让已经就绪的job拥有更高的优先级
jobReadyFn 用来判断一个job是否已经就绪。

解析Kube-Batch 实现gang的方式：　

无论是k8s默认的scheduler，　还是kube-batch　，再进行调度时都是先从逻辑上分配资源给pod，等满足某一条件之后，才真正将pod　调度到某一个节点上。

kube-batch/pkg/scheduler/framework/session.go Line 281

if ssn.JobReady(job) {

  for _, task := range job.TaskStatusIndex[api.Allocated] {

    if err := ssn.dispatch(task); err != nil {

      glog.Errorf("Failed to dispatch task <%v/%v>: %v",task.Namespace, task.Name, err)

      return err

    }

  }

}

dispatch　内包bind job到node 等实际的调度动作.

jobReady会调用所有注册了的 plugin的 Ready　判定函数，只有都判定为 ready ,才返回true。

而gang　plugin里面定义的ready判定函数实际上是调用 job　自带的ready函数，定义在

kube-batch/pkg/scheduler/api/job_info.go#L415

// ReadyTaskNum returns the number of tasks that are ready.

func (ji *JobInfo) ReadyTaskNum() int32 {

	occupid := 0

	for status, tasks := range ji.TaskStatusIndex {

		if AllocatedStatus(status) ||

			status == Succeeded {

			occupid = occupid + len(tasks)

		}

	}

	return int32(occupid)

}

// Ready returns whether job is ready for run

func (ji *JobInfo) Ready() bool {

	occupied := ji.ReadyTaskNum()

	return occupied >= ji.MinAvailable

}

５.3 Proportion

Proportion　实现了队列.

type queueAttr struct {

	queueID api.QueueID // 队列的id

	name    string //队列的名字

	weight  int32 // 队列的权重,决定分配到的资源的多少

	share   float64 //参考 drf处的share

　

	deserved  *api.Resource　//声明的资源总量

	allocated *api.Resource  //实际分配到的资源总量

	request   *api.Resource  //该队列中所有job声明的要分配的资源总量

}

Proportion　根据各个队列声明的权重和全局的资源总量　初始化deserved的值，根据全局的job　初始化

allocated　和　request的值。并监听全局的资源释放　和　申请事件　更新队列的状态。

定义的几个plugin function：

QueueOrderFn

QueueOrderFn　会决定哪一个队列里的job在调度时会被优先考虑,这里沿用了DRF处jobOrderFn的逻辑，

即share值最小的queue　会最优先被考虑.

OverusedFn

判断queue的资源使用是否已经超出限制了，即 allocated > deserved == true

ReclaimableFn

判断一个task是否可以被召回，如果召回之后使得已经分配到的资源小于等于deserved　就不应该被召回。

５.4 其他几个plugin

略

六. 四个Action

　kube-batch　默认只开启了 Allocate　和 Backfill

6.1 Allocate

功能 : 将pod（task）分配到某个节点

6.2 Backfill

功能 : 调度未设置资源使用量的pod到节点（资源使用量　＝　工作容器和初始化容器的各维度资源的最大值）

6.3 Reclaim

功能 : 召回满足条件的pod

6.4 Preempt

功能: 抢占已经调度了的满足条件的pod,并将目标pod调度上去

巴特西

kube-batch　解析

kube-batch

一. 做什么的？

二. 使用方式

三. 调度的单位

四. 整体结构

五. 几个plugin

５.1 DRF (Dominant　Resource　Fairness)

５.2 Gang

５.3 Proportion

５.4 其他几个plugin

六. 四个Action

6.1 Allocate

6.2 Backfill

6.3 Reclaim

6.4 Preempt

最新文章

热门文章

巴特西

kube-batch 解析

kube-batch

一. 做什么的？

二. 使用方式

三. 调度的单位

四. 整体结构

五. 几个plugin

５.1 DRF (Dominant Resource Fairness)

５.2 Gang

５.3 Proportion

５.4 其他几个plugin

六. 四个Action

6.1 Allocate

6.2 Backfill

6.3 Reclaim

6.4 Preempt

最新文章

热门文章

kube-batch　解析

５.1 DRF (Dominant　Resource　Fairness)