Kubernetes相对于Mesos，不同之处在于对资源的调度管理，这篇Proposal展示了Kubernetes对于资源管理方面的思考，也反映了Kubernetes的发展方向。
作为一个集群管理员，希望创建一个环境来运行不同类型的工作负载，例如长时间运行的服务、大数据服务等等。由于这些应用被不同的业务部门所管理，所以我必须保证每个应用都有足够的计算资源。具体来说，如下所示：
长时间运行的服务（应用域）和大数据服务（大数据域）能够共享资源：
定义每个区域的资源使用情况，例如40%的资源属于应用域，60%属于大数据域。
借入/借出协议：如果一个区域里有空闲资源，则可以被其他区借出，并且被抢占。
在大数据域运行多个集群：
定义大数据域内每个集群的资源使用情况，例如Hadoop、Spark等等。
在这些大数据集群之间共享资源，例如通过借入/借出方式。
以大数据为例，需求的具体细节如下：
更进一步，将应用域和大数据域划分成两个“桶”，为每个“桶”分配一小部分的计算资源。与此同时，每个“桶”可以无限制地访问整个集群的资源，但是超过分配值之外的资源随时可以被收回。
根据mesos-style.md（http://suo.im/3NfpQ0）这份文档，我们完全可以通过一个定制的组件来做到这一点；但是这种资源规划、管理和共享的通用需求，最好由Kubernetes来实现。
Arbitrator：根据策略分配资源（resource allocation）的新组件；默认调度器（通常是kube-scheduler）仍通过现有的策略为Pods指定资源（resource assignment）。
Deserved（Resource）：arbitrator分配给namespace的资源总数。
Overused：如果使用的资源超过deserved的资源，命名空间将被认为是overused的。
随着Kubernetes的发展，目前可以通过以下几个功能实现资源Qos控制和共享。
抢占和重调度
一个pod可以被驱逐，因为一些其他pod需要它使用的资源（抢占）。有一个基于优先级的抢占方案（每个Pod都有一个优先级，而具有更高和可能相同优先级的pod可以抢占它；谁做出决定及哪个Pod要抢占还待定，但可以是默认的调度程序，也可以是重调度器，也可能是集成了调度功能的基于应用的控制器，当然也可以是他们配合工作）。抢占总是使用优雅的终止方式。优先权方案通常意味着配额在每个优先级别的基础上分配，以便应用程序可以在最高优先级级别给予有限数量的配额，并且可以给予更大量的配额（甚至是无限的，即集群的整体能力），但是优先级较低。与此同时，重调度器通过驱逐Pod来执行集群级别的策略（目前有一个原始的重调度器来执行这样一个策略：关键的pod，如Heapster，DNS等不会由于集群中的可用资源不足而被阻止运行；但还有很多其他策略可以执行）。它通过驱逐一个或多个pod来允许一些待处理的Pod（s）进行调度。抢占需要在命名空间之间调度资源；arbitrator会是优先级规则的定义者，比如没有满足deserved的namespace的优先级高于overused的namespace。arbitrator将使用驱逐（Eviction）功能进行抢占。重调度器确保关键Pod不会由于资源不足而停止运行，也会重新调度其他Pods使其获得更好的安置（译者注：拥有合理的运行所需资源）。有了arbitrator之后，kube-system命名空间将能够获得无限的资源：即申请多少就能够得到多少，其他命名空间共享剩余的资源；对于“更好的安置（译者注：重新调度以获得更合理的资源）”没有其他影响。
工作负载专用控制器和ThirdPartyResource
ThirdPartyResource对象是使用新的API对象类型扩展Kubernetes API的一种方法。新的API类型将被赋予一个API endpoint并支持相应的增、删、改、查操作。您可以使用此API endpoint创建自定义对象。通过mesos-style.md和ThirdPartyResource，开发人员可以使用自定义对象构建workload customized controller（译者注：工作负载自定义控制器）。
k82cn/kube-arbitrator（https://github.com/k82cn/kube-arbitrator）有一个例子，它通过ThirdPartyResource功能提供资源共享和抢占功能。
水平/垂直缩放和节点级QoS
节点级资源使用率的改进，对集群级资源共享并无贡献。但是关于节点级QoS，还应该考虑Pod的请求和限制。
概要
为了满足上述要求，需要一个新的组件（k8s-arbitrator）和两个ThirdPartyResource（Consumer和Allocation）。
Consummer是arbitrator的ThirdPartyResource，以下yaml文件演示了Consumer的定义：
apiVersion: kuabe-arbitrator.incubator.k8s.io/v1
kind: Consumer
metadata:
name: defaults
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
reserved:
limits.memory: 1Gi
对于每个Consumer对象，它有两个字段，hard和reserved：
reserved：定义了为namespace保留的资源。它使用与”Compute Resource Quota”和”Storage Resource Quota”相同的资源类型。reserved不能超过hard定义的资源。如果启用了ResourceQuota Admission，它还将检查“预留”的总数是否超过了群集中的资源。
hard ：定义了namespace可以使用的最大资源；它不能超过namespace的Quota.hard。
Consumer由arbitrator为每个namespace创建，并且必要时由集群管理员进行更新；arbitrator创建具有无限hard和零reserved的Consumer，因此namespace默认共享集群资源。
arbitrator将创建或更新Allocation中的额外字段：deserved。
apiVersion: kuabe-arbitrator.incubator.k8s.io/v1
kind: Allocation
metadata:
name: defaults
spec:
deserved:
cpu:"1.5"
hard:
requests.cpu:"1"
requests.memory:1Gi
limits.cpu:"2"
limits.memory:2Gi
reserved:
limits.memory:1Gi
下图显示了Consumer/Allocation中的hard，reserved和deserved的关系。
注意：只有”Compute Resource Quota”和”Storage Resource Quota”可用于reserved和deserved 。
-------------
| |
| |
- - - - - - -
| |
| |
| |
-------------
| |
-------------
k8s-arbitrator是一个新的组件，它会创建/更新Consumer和Allocation：
同时，k8s默认调度器仍然根据其策略来分派任务到主机，例如PodAffinity：k8s-arbitrator负责resource allocation，k8s-scheduler负责resource assignment。
Arbitrator将DRF作为默认策略。它将从k8s-apiserver中取得pod/node，并根据DRF算法计算每个namespace的deserved资源；然后更新相应的配置。默认调度间隔为1s（可配置）。arbitrator不会将主机名分配给deserved资源中；它依赖默认的调度器（kube-scheduler）在适当的主机上分派任务。
Arbitrator还符合以下要求：
namespace的总体deserved资源不能超过群集中的资源。
deserved资源不能超过消费者的hard资源。
如果集群中有足够的资源，deserved资源不能少于reserved资源。
抢占
当资源请求/配额发生变化时，每个命名空间的deserved资源也可能会发生变化。“较高”的优先级Pods将可能触发eviction，下图显示了由于deserved资源变化而引发eviction的情况。
T1: T2: T3:
-------------- -------------- -------------- -------------- --------------
| Consumer-1 | | Consumer-1 | | Consumer-2 | | Consumer-1 | | Consumer-2 |
| cpu:2 | ==> | cpu:1 | | cpu:0 | ==> | cpu:1 | | cpu:1 |
| mem:2 | | mem:1 | | mem:0 | | mem:1 | | mem:1 |
-------------- -------------- -------------- -------------- --------------
T1：集群中只有一个namespace：Consumer-1；所有资源（cpu：2，mem：2）都被分配给它。
T2：创建一个新的namespace: Consuemr-2；arbitrator 重新计算每个namespace的资源分配，缩小overused的namespace。
T3：管理overused的namespace的controller必须选择一个Pod来杀死，否则arbitrator将会随机抽取需要杀死的Pods。Evict后，资源会被分配给underused的namespace。
Arbitrator使用pod的“/evict”REST API来回收资源。但是当arbitrator选择需要被杀死的Pods时，至少有两个要求：
Namespace在驱逐后可能会变成underused；arbitrator将尝试从最overused的namespace尝试杀死Pods。对于资源碎片的问题，暂时不在本文的讨论范围内；将在抢占实施文档中讨论设计细节。
调度器
使用调度程序的HTTPExtender访问arbitrator，实现基于Allocation.Deserved的predicates。增强HTTPExtender的接口，为了性能考虑，只发送v1.Pod；arbitrator只指定资源数量，而不指定具体的主机。
工作负载特定的控制器
Arbitrator还将在特定工作负载的控制器中驱逐overused的namespace。基于特定工作负载的控制器不能使用比Allocation.deserved更多的资源。如果Allocation.deserved更新，它会选择Pods驱逐；否则arbitrator将在宽限期（grace period）后驱逐Pod（例如FCFS）。
多调度器
如果启用多调度器；只能启用一个arbitrator以避免竞争条件。
Admission 控制器
如果有计算资源和存储资源的配额，Arbitrator检查Consumer相对于这些Quta的定义。Consumer.hard不能超过Quota.hard。ResourceQuotaAdmission的其他指标将遵循当前行为。
对其他Admission插件没有影响。
节点级QoS
在原型中，仅考虑request；limit会在后续版本考虑。
ReplicaController/ReplicaSet
由于Consumer/Allocation是namespace级别而不是Job/RC级别，k8s-controller-manager不能根据RC的比例创建pod；它需要最终用户在RC之间平衡Pods或在Consumer中请求预留资源。
kubelet
现在还不涉及kubelet，虽然命名空间的Allocation.deserved也是kubelet中evict的一个因素，例如：
目前进展
高级的策略，例如不打破PodDisruptionBudget
使用 “resourceRequest” 来减少 pending pod的使用
加强关于存储策略，例如“PV / PVC”
k8s-arbitrator的HA
层级Consumer
无限Allocation用于kube-system
面向 limit 的策略（节点/资源QoS）
Consumer / Allocation 客户端库，用于开发新的workload customized controller
原文链接：https://github.com/k82cn/community/blob/09092843a05833cc68467b55a015de637478cc3d/contributors/design-proposals/arbitrator.md
