开发者学堂课程【云原生实践公开课：资源调度的最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/698/detail/12275
资源调度的最佳实践
内容介绍：
一、 调度器简介
二、 Gang Scheduling
三、 Binpack
四、 Pod Topology Spread
五、 总结
一、调度器简介
1. Scheduling Framework
Scheduling Framework前身是extender的一种扩展机制在我们使用extender进行调度拓展时，因为要在外部维护一个extender的服务所以存在：
1. 性能问题，需要通过app请求去访问 extender，影响了整个调度的性能；
2. 在维护成本的问题，需要单独维护extender，比维护Scheduling Framework要
增加了许多成本；
3. Extender扩展的点有限，只能通过几个有限的点去带动调度策略，所以操作是很有限的。
如图是最新版本1.19 的Scheduling Framework的整体架构，现在相对稳定。
Scheduling Framework几个重要的扩展点：
- Fitter 进行一个过滤操作，进行一个筛选
- Score 进行一个打分插件，将上一部步选出的节点，经行一个打分操作，选择
最优的一个调度节点
2. Multi Scheduling Profiles
- Goals
使得kube-scheduler可以满足不同Workloads对于调度策略差异化的支持
type KubeSchedulerProfile struct {
schedulerName string
Plugins *Plugins
PluginConfig []PluginConfig
}
type PodSpec struct {
SchedulerName string
}
代码示例：
apiVersion:kubescheduler.config.k8s.iolv1beta1kind: KubeSchedulerConfiguration
leaderElection:
leaderElect: false
clientConnection:
kubeconfig:"REPLACE_ME_WITH_KUBE_CONFIG_PATH"
profiles:
- schedulerNlame: my-schedulerplugins:
queueSort:
enabled:
- name: Coscheduling
disabled:
- name: """
preFilter:
enabled:
- name: Coscheduling
permit:
enabled:
- name: Coschedulingreserve:
enabled:
-name:Coscheduling
#optional plugin config
pluginConfig:
- name: Coscheduling
args:
permitWaitingTimeSeconds:10
podGroupGClntervalSeconds: 30
podGroupExpirationTimeSeconds: 600
二、Gang Scheduling
1. Gang Scheduling
- 需求
对于Tensorflow和MP的作业，同一个Job下要求所有Pod同时启动才能运行
对于Spark的作业,需要至少保证启动Driver和Excuter作业满足最小数目才能运行
- 痛点
Kubernetes初始的调度器是以Pod为单位依次调度的，不会在调度过程中考虑Pod之间的关系
当集群资源无法满足Job所有资源请求时，部分Pod无法启动，已经创建的Pod又无法运行，死锁导致资源的浪费
2. Gang Scheduling
- 解决方案
实现QueueSort插件,保证在队列中属于同一个PodGroup的Pod能够排列在一起
Permit的延迟绑定的功能，对于不满足PodGrucpMin限制的Pod进行等待，等待积累的Pod数目满足足够的数目时，再将同一个PodGucp的所有Pod创建
代码示例：
labels:
pod-group.scheduling.sigs.k8s.io/ name: nginx
pod-group.scheduling.sigs.k8s.io/min-available: "2"
- Name标识podGroup的name
- min-available是用来标识该PodGroup的作业能够正式运行时所需要的最小副本
数
3. Batch Scheduling 实践演练
apiversion:"kubeflow.orglv1"
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-smke-gpu
pod-group.scheduling.sigs.k8s.ioymin-available: "5“
spec:
containers:
- args:
- python
- tf_cnn_benchmarks.py
- --batch_size=32
- --model=resnet50
---variable_update=parameter_server
- --flush_stdout=true
- --num_gpus=1
- --local_parameter_device=cpu- --device=cpu
- --data_format=NHWC
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:lopt/tfbenchmarks/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
- --batch_size=32
- --model=resnet50
- --variable_update=parameter_server
- --flush_stdout=true
- --num_gpusm1
- --local_parameter_device=cpu
- --device=gpu
- --data_format=NHwc
image:registry.cn-hangzhou.aliyuncs.comkubeflow-images-public/t-benchmarks-gpu.v20171202-bdab599-dirty-284af3
name: tensorflow
ports:
- containerPort: 2222
name: tfjob-port
resources:
limits:
nvidia.comVgpu: 2
workingDir:lopttfbenchmarks/scripts/tf_cnn_benchmarks
restartPolicy: OnFailure
三、Binpack
1.需求
K8s默认Spreading策略，任务拿到的资源尽量打散，导致资源碎片化，饿死“大任务”，整体资源利用率下降。
Binpack 实现已经抽象成Kubernetes Scheduler Framework的Score插件
RequestedToCapacityRatio，用于优选阶段给节点打
分。将节点根据自己定义的配置进行打分。具体的实现可以分为两个部分，构建打
分函数和打分.
2.打分函数
- 优先调度到资源空闲的节点
- 优先打满一个节点(Binpack)
- 灵活的分配策略
3. 自定义不同资源的权重
代码示例;
resourcetoweightmap :
"cpu" : 1
"nvidia.com/ gpu": 1
4. 完整的配置方式
apiVersion:kubescheduler.config.k8s.io/v1alpha2kind: KubeSchedulerconfiguration
clientconnection:
kubeconfig: letc/ kubernetes/scheduler.confleaderElection:
leaderElect: falseprofiles:
- schedulerName: default-scheduler
plugins :
score:
enabled:
- name: RequestedTocapacityRatio
weight: 100
disabled:
- name: LeastRequestedPriority
pluginconfig:
- name: RequestedToCapacityRatio,
args:
shape:
- utilization: 0
score: 0
- utilization: 10o
score: 10
resource:
#定义具体根据哪种资源类型进行 binpack操作，多种资源时可以设置 weight来进行比重设"nvidia.com/ gpu"": 1
四、Pod Topology Spread
1.需求
- Pod的调度分布提供更精细的控制，以提高服务可用性以及资源利用率
2.已有的功能无法准确控制
- podAffinity可以将无数个Pod调度到特定的某一个拓扑域，这是堆叠的体现
- podAntiAffinity则可以控制一个拓扑域只存在一个Pod，这是打散的体现
- 与NodeSelector / NodeAffinity组合使用
- Multiple TopologySpreadConstraints
五、 总结
Kubernetes ShedulingFramework作为调度器的新架构方向，在可扩展性和定制化
方面进步很大。
通过其强大的可扩展性，更多的数据计算类型的任务也在逐步迁移到Kubermnetes 平台。Kubernetes 可以逐步承载更多类型的应用负载一个平台一套ПT架构和技术
堆栈的愿景向前演进。
