此文是2017年5月6日Kubernetes Meetup 2017 成都站，嘉宾-IBM中国软件架构师马达的主题演讲《Kubernetes 中基于策略的资源分配》。IT大咖说（id：itdakashuo）作为活动的视频合作方，经主办方和嘉宾授权发布。

编辑：IT大咖说

阅读字数：1322，用时: 5分钟

摘要

无论是传统企业还是如今新兴的互联网行业，对于资源管理和调度的需求都是非常大的。IBM中国系统部软件架构师马达以Kuberntes为例，全方位详细解析它基于策略的资源调度。

嘉宾分享视频回顾及PPT：http://suo.im/4ydQGX

User Cases：Runmultiple type of workloads in DataCenter

Mesos最主要是对资源的管理和分配。Kuberntes进行对微服务的管理和资源调度。因为Spark没有资源管理这一层，所以我们自己做了Spark SessionScheduler，主要是做资源管理和调度。

我们希望在数据中心里面跑的作业是多种多样的，也希望能跑一些bigdate、HPC、MPI这样的作业。所以对这三块领域有不同的workload的需求。

Kuberntes现在有一些features去解决用户的问题。

第一个最常用的就是Quota。Quota现在是一个静态的划分，它有一个上限。我更希望它是一个max，用类似云计算的想法去做。

还有一个是multiple Scheduler，这是之前华为提出的功能。这个功能是希望在一个class里有两个Scheduler。但Scheduler还没有解决资源分配的问题，这中间会存在比较多的问题。

这个最后还是只是Node-level Qos来做，没有全局class的调度。

Kuberntes里面有一个Re- Scheduling。当整个class运行一段时间以后， Re- Scheduling会重新从全局的范围内再去看一下，根据现在的策略调一个更优的解。

Preemption & Eviction是支持杀死一个pod。那个pod其实不会真正的删除，只是把它杀掉了，然后推到Scheduling里重新来做。

现在Kuberntes里有好多object，还有人提不同的需求去添加新的object，所以他们不再添加新的API默认支持的object。而是用ThirdPartyResourcs。

Kuberntes更像是基于元数据，通过修改元数据来驱动彼此间的协作。Kuberntes用自己写的Controller只要修改元数据的值就可以了，不需要修改interface。

BatchJobController会拿到所有的资源，然后根据现在的策略和配置去算一个Queue里应该分得多少资源。

之前在讨论的时候，我们是想建立一个跟space平级的概念也叫Queue，但是后来更倾向于通过namespace来做。所以BatchJobController会基于每一个namespace分配里面区域。

Quota定义了namespace中能利用的最大资源，而BatchJobController算的值则在中间来回浮动。

开始第一步会重新计算namespace的值。这个时候BatchJobController就要把namespace1里面多余的pod杀掉，杀掉了以后再把namespace2起来。所以在整个集群里面，ns1和ns2彼此之间的资源就可以共享分配。

我们不仅做了资源的策略，还做了作业的策略。这块大概分为几种case。

第一种case比较常见。起一个executor，里面不停的跑task。这是最简单的一种资源分配，在创建起来的时候就知道作业有多少个资源的需求，可以调度。

第二个executor是根据当前的这个请求进行动态调整，就是可能executor里一次跑多个task，也可能每次只跑一个task，但这个task能多次跑。这样的话可以做到细力度的调度。

第三种和MPI比较像。MPI有一个比较苛刻的要求，它要求所有资源都满足了以后，它才能起来。这整个class彼此之间是fix的。

大概就是这几种不同的部署方式和结构。对我们来说，我们最主要看到的是这个资源的请求方式到底是什么样，以及它的限制。

具体的讨论可以参考： https://github.com/kubernetes/features/issues/269

谢谢大家！