前两篇文章《进击的Kubernetes调度系统 （一）：Scheduling Framework》 和《进击的 Kubernetes 调度系统（二）：支持批任务的 Coscheduling/Gang scheduling 》分别介绍了 Kubernetes Scheduling Framework 和如何通过扩展 Scheduling Framework 实现 Coscheduling/Gang scheduling 调度策略。当我们的批任务作业在集群里边运行起来之后，随后要关注的就是资源的利用率。特别是对于 GPU 卡的价格昂贵，不希望有资源的浪费。本文将介绍在批任务的调度过程中如何通过 Binpack 的方式，减少资源碎片，提升 GPU 的利用率。
为什么需要 Binpack 功能？
Kubernetes 默认开启的资源调度策略是 LeastRequestedPriority，消耗的资源最少的节点会优先被调度，使得整体集群的资源使用在所有节点之间分配地相对均匀。但是这种调度策略往往也会在单个节点上产生较多资源碎片。
下面拿一个简单的例子来说明这种问题。如下图所示，资源在节点之间平均使用，所以每个节点使用 3 个 GPU 卡，则两个节点各剩余 1GPU 的资源。这是有申请 2GPU 的新作业，提交到调度器，则因为无法提供足够的资源，导致调度失败。
如上这种情况情况，每个节点都有 1 个 GPU 卡空闲，可是又无法被利用，导致资源 GPU 这种昂贵的资源被浪费。如果使用的资源调度策略是 Binpack，优先将节点资源填满之后，再调度下一个节点，则上图所出现的资源碎片问题得到解决。申请 2GPU 的作业被正常调度到节点上，提升了集群的资源使用率。
实现方案
Binpack 实现已经抽象成 Kubernetes Scheduler Framework 的 Score 插件 RequestedToCapacityRatio，用于优选阶段给节点打分。将节点根据自己定义的配置进行打分。具体的实现可以分为两个部分，构建打分函数和打分.
构建打分函数
构建打分函数的过程比较容易理解，就是用户可以自己定义不同的利用率所对应的分值大小，以便影响调度的决策过程。
如果用户设定的对应方式如下所示，即如果资源利用率为 0 的时候，得分为 0 分，当资源利用率为 100 时，得分为 10 分，所以得到的资源利用率越高，得分越高，则这个行为是 Binpack 的资源分配方式。
用户也可以设置成利用率为 0 时，得分为 10 分，利用率为 100 时，得分为 0 分。这样意味着资源利用率越低，则得分越高，这种行为是 spreading 的资源分配方式。
用户除了 2 个点之外也可以新增更多的点，对应关系可以不是线性的关系，例如可以标识资源利用率为 50 时，得分为 8，则会将打分分割为两个区间: 0-50 和 50-100。
打分
用户可以自己定义在 Binpack 计算中所要参考的资源以及权重值，例如可以只是设定 GPU 和 CPU 的值和权重。
resourcetoweightmap: "cpu": 1 "nvidia.com/gpu": 1
复制代码
然后在打分过程总，会通过计算(pod.Request + node.Allocated)/node.Total 的结果得到对应资源的利用率，并且将利用率带入上文中所述的打分函数中，得到相应的分数。最后将所有的资源根据 weight 值，加权得到最终的分数。
Score = line(resource1_utilization) * weight1 + line(resource2_utilization) * weight2 ....) / (weight1 + weight2 ....)
复制代码
Binpack 使用
配置方法
1、新建/etc/kubernetes/scheduler-config.yaml, 用户可以自行配置其他的 priorities 策略。
apiVersion: kubescheduler.config.k8s.io/v1alpha1kind: KubeSchedulerConfigurationleaderElection: leaderElect: falseclientConnection: kubeconfig: "REPLACE_ME_WITH_KUBE_CONFIG_PATH"plugins: score: enabled: - name: RequestedToCapacityRatio weight: 100 disabled: - name: LeastRequestedPrioritypluginConfig:- name: RequestedToCapacityRatio args: functionshape: - utilization: 0 score: 0 - utilization: 100 score: 100 resourcetoweightmap: # 定义具体根据哪种资源类型进行binpack操作,多种资源时可以设置weight来进行比重设置 "cpu": 1 "nvidia.com/gpu": 1
复制代码
Demo 演示
接下来我们通过运行 Tensorflow 的分布式作业来进行演示，展示 Binpack 的效果，当前测试集群有 2 台 4 卡的 GPU 机器
1、通过 Kubeflow 的 arena 在已有的 Kubernetes 集群中部署 tf-operator
Arena是基于Kubernetes的机器学习系统开源社区Kubeflow中的子项目之一。Arena用命令行和SDK的形式支持了机器学习任务的主要生命周期管理（包括环境安装，数据准备，到模型开发，模型训练，模型预测等），有效提升了数据科学家工作效率。
git clone https://github.com/kubeflow/arena.gitkubectl create ns arena-systemkubectl create -f arena/kubernetes-artifacts/jobmon/jobmon-role.yamlkubectl create -f arena/kubernetes-artifacts/tf-operator/tf-crd.yamlkubectl create -f arena/kubernetes-artifacts/tf-operator/tf-operator.yaml
复制代码
检查是否部署成功
$ kubectl get pods -n arena-systemNAME READY STATUS RESTARTS AGEtf-job-dashboard-56cf48874f-gwlhv 1/1 Running 0 54stf-job-operator-66494d88fd-snm9m 1/1 Running 0 54s
复制代码
2、用户向集群中提交 Tensorflow 分布式，作业含有 1 个 PS 和 4 个 Worker，每个 Worker 需要 1 个 GPU
apiVersion: "kubeflow.org/v1"kind: "TFJob"metadata: name: "tf-smoke-gpu"spec: tfReplicaSpecs: PS: replicas: 1 template: metadata: creationTimestamp: null labels: pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu pod-group.scheduling.sigs.k8s.io/min-available: "5" spec: containers: - args: - python - tf_cnn_benchmarks.py - - - - - - - - image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3 name: tensorflow ports: - containerPort: 2222 name: tfjob-port resources: limits: cpu: '1' workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks restartPolicy: OnFailure Worker: replicas: 4 template: metadata: creationTimestamp: null labels: pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu pod-group.scheduling.sigs.k8s.io/min-available: "5" spec: containers: - args: - python - tf_cnn_benchmarks.py - - - - - - - - image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-gpu:v20171202-bdab599-dirty-284af3 name: tensorflow ports: - containerPort: 2222 name: tfjob-port resources: limits: nvidia.com/gpu: 1 workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks restartPolicy: OnFailure
复制代码
3、当用户使用 Binpack 功能时，用户提交任务后，4 个 Worker 被调度到同一个 GPU 节点 cn-shanghai.192.168.0.129
$ kubectl get pods -o wideNAME READY STATUS AGE IP NODEtf-smoke-gpu-ps-0 1/1 Running 15s 172.20.0.210 cn-shanghai.192.168.0.129 tf-smoke-gpu-worker-0 1/1 Running 17s 172.20.0.206 cn-shanghai.192.168.0.129 tf-smoke-gpu-worker-1 1/1 Running 17s 172.20.0.207 cn-shanghai.192.168.0.129 tf-smoke-gpu-worker-2 1/1 Running 17s 172.20.0.209 cn-shanghai.192.168.0.129tf-smoke-gpu-worker-3 1/1 Running 17s 172.20.0.208 cn-shanghai.192.168.0.129
复制代码
4、当用户不使用 Binpack 功能时，用户提交任务后，4 个 Worker 被分配到 cn-shanghai.192.168.0.129 和 cn-shanghai.192.168.0.130 两个节点上，产生资源碎片
$ kubectl get pods -o wideNAME READY STATUS AGE IP NODEtf-smoke-gpu-ps-0 1/1 Running 7s 172.20.1.72 cn-shanghai.192.168.0.130tf-smoke-gpu-worker-0 1/1 Running 8s 172.20.0.214 cn-shanghai.192.168.0.129tf-smoke-gpu-worker-1 1/1 Running 8s 172.20.1.70 cn-shanghai.192.168.0.130tf-smoke-gpu-worker-2 1/1 Running 8s 172.20.0.215 cn-shanghai.192.168.0.129tf-smoke-gpu-worker-3 1/1 Running 8s 172.20.1.71 cn-shanghai.192.168.0.130
复制代码
后记
上文中我们介绍了如何利用 Kubernetes 原生的调度策略 RequestedToCapacityRatio 来支持 Binpack Scheduling 的功能，减少资源碎片，提升 GPU 的利用率。使用起来很简单，但是效果很明显。针对 GPU 的资源利用率的提升的课题，我们将在本系列接下来的文章中介绍如何在推理服务下，通过 GPU 共享调度的方法大大的提升 GPU 利用率。
相关阅读：
进击的 Kubernetes 调度系统（一）：Scheduling Framework
进击的 Kubernetes 调度系统（二）：支持批任务的 Coscheduling/Gang scheduling
评论