容器调度

Agenda
1. Architecture of Scheduler
2. Kubernetes Default Scheduler
3. Multiple Schedulers
4. Schedule Policy
5. Schedule RateLimiter

1. Architecture of Scheduler
集群调度工具要求/原则：使得集群的资源(如:cpu,memory,disk)被高效利用,支持用户提供的配置约束（placement constraints）,能够迅速调度应用以此保证它们不会处于待定状态（pending state）,有一定程度的”公平”(fairness),具有一定的健壮性和可用性。在关于Omega(Omega flexible, scalable schedulers for large compute clusters)的白皮书中，提到了三个主要的调度架构

1.1 Monolithic scheduling
单体式调度结构由单一的调度器(scheduler)组成，它负责处理所有的请求，
这种结构通常应用于高性能计算。其通常实现了一个单一的算法来处理所有的作业(job)
因此根据作业的类型来运行不同的调度逻辑是困难的

Apache Hadoop YARN 就是单体式调度架构的典型代表，
所有的资源(slot)请求都会被发送到一个单一的全局调度模块

1.2 Two-level scheduling

两级调度框架会利用一个中央协调器（central coordinator）来动态地决定各个调度
模块可以调用多少资源. Apache Mesos既是该架构的典型代表

Mesos由四个组件组成,分别是Mesos-master,mesos-slave,framework和executor
Mesos-master是系统的核心,负责管理接入mesos的各个framework
(由frameworks_manager管理）和slave（由slaves_manager管理），并将slave上的
资源按照某种策略分配给framework（由独立插拔模块Allocator管理）。
Mesos中的调度机制被称为”Resource Offer”,采用了基于资源量的调度机制，这不同
于Hadoop中的基于slot的机制。在mesos中,slave直接将资源量（CPU和内存）汇报
给master，由master将资源量按照某种机制分配给framework，其中,”某种机制”即是
”Dominant Resource Fairness（DRF）”

Mesos-slave负责接收并执行来自mesos-master的命令、管理节点上的mesos-task，
并为各个task分配资源。mesos-slave将自己的资源量发送给mesos-master，
由mesos-master中的Allocator模块决定将资源分配给哪个framework，当前考虑的资源
有CPU和内存两种,也就是说，mesos-slave会将CPU个数和内存量发送给mesos-master
而用户提交作业时，需要指定每个任务需要的CPU个数和内存量
DRF是一种支持多资源的max-min fair 资源分配机制，其中max表示max{CPU,mem}
而min表示min{user1,user2,…}=min{max{CPU1,mem1}, max{CPU2,mem2}, …}，
其中user代表mesos中的framework，算法伪代码如下图所示:

1.3 Shared-state scheduling
赋予每一个调度器（scheduler）对整个集群的全部访问权限,也就是说调度器们可以
自由地竞争。因为所有的资源分配都发生在各个调度器中，所以也就没有了
中央资源分配器。也就是说，没有了中央策略引擎，每一个调度器能够自己做决定。通过支持独立的调度器实现和公布整个资源分配的状况，不仅支持扩展多个调度器，
还能够支持它们自己的调度策略,共享状态调度的典型代表是Borg,Omega和Kubernetes
Borg,Omega共享状态使用的是Chubby(Paxos算法的实现)
Kubernetes共享状态使用的是Etcd(Raft算法的实现)

2. Kubernetes Default Scheduler

Kubernetes scheduler 的任务就是寻找那些PodSpec.NodeName为空的pods，
然后通过对它们赋值来调度对应集群中的容器。相比于Swarm和Mesos，
Kubernetes允许开发者通过定义PodSpec.NodeName来绕过调度器。schedulder使用
谓词(predicates)和优先级(priorities)来决定一个pod应该运行在哪一个节点上。
通过指定一个新的调度策略可以覆盖掉这些参数的默认值
http://geek.csdn.net/news/detail/58974

–scheduler-name=”default-scheduler”
Name of the scheduler, used to select which pods will be processed by this scheduler,
based on pod’s annotation with key ‘scheduler.alpha.kubernetes.io/name‘

–policy-config-file=”/etc/kubernetes/scheduler-policy.json”
File with scheduler policy configuration

–port=10251 The port that the scheduler’s http service runs on

–algorithm-provider=”DefaultProvider”
The scheduling algorithm provider to use, one of: DefaultProvider

3. Multiple Schedulers

https://github.com/kubernetes/kubernetes/pull/17865

This PR partially implements multi-scheduler, including:1. Name default scheduler with name default-scheduler2. The default scheduler only schedules the pods meeting the following condition:- the pod has no annotation scheduler.alpha.kubernetes.io/name: scheduler-name- the pod has annotation scheduler.alpha.kubernetes.io/name: default-scheduler

4. Scheduler Policy

4.1 Scheduler Policy

4.2 Scheduler Policy Priorities

LeastRequestedPriority:
LeastRequestedPriority is a priority function that favors nodes with fewer requested resources. It calculates the percentage of memory and CPU requested by pods scheduled on the node, and prioritizes based on the minimum of the average of the fraction of requested to capacity.
BalancedResourceAllocation:
BalancedResourceAllocation favors nodes with balanced resource usage rate.
It should NOT be used alone, and MUST be used together with LeastRequestedPriority. It calculates the difference between the cpu and memory fracion of capacity, and prioritizes the host based on how close the two metrics are to each other.
ServiceSpreadingPriority:
spreads pods across hosts and zones, considering pods belonging to the same service or replication controller. When a pod is scheduled, it looks for services or RCs that match the pod, then finds existing pods that match those selectors. It favors nodes that have fewer existing matching pods

EqualPriority:

4.2.1 Scheduler Policy Least Requested Priority
该算法的原则是->剩余资源越多的节点优先级越高

show me the code:

4.2.2 Scheduler Policy Balanced Resource Allocation

该算法的原则是->cpu和memory使用率的差异越小优先级越高
The algorithm is partly inspired by: “Wei Huang et al. An Energy Efficient Virtual Machine Placement Algorithm with Balanced Resource Utilization”
http://www.tralon.com/2015/05/VMP/

show me the code:

4.2.3 Scheduler Policy Service Spreading Priority

该算法的原则是->把属于相同service,rc的pod调度到不同的节点(or zone)上

该算法比较复杂,尚需要深入研究(随后补充)

4.3 Scheduler Policy extender
Multiple extenders can be configured in the scheduler policy
https://github.com/kubernetes/kubernetes/blob/master/docs/
design/scheduler_extender.md

5. Schedule RateLimiter

–kube-api-burst=100 Burst to use while talking with kubernetes apiserver
–kube-api-qps=50 QPS to use while talking with kubernetes apiserver

随着时间流逝,系统会按恒定1/qps时间间隔(如果qps=50,则间隔是20ms)往桶里加入Token
(想象有个水龙头在不断的加水),如果桶已经满了就溢出.新请求来临时,会拿走一个Token,
如果没有Token可拿了就阻塞或者拒绝服务.
刚刚我们描述的情形，就属于用户洪峰。对于这种洪峰，我们需要考虑的因素是:
允许访问的速率(qps), 系统承受的最大洪峰(burst), 洪峰爆发的间隔时间
https://github.com/juju/ratelimit