关于容器整合open stack实现两级调度（密）

Docker进阶

abs: 初步暂定为将k8s与openstack结合，进行两级调度。

k8s scheduler

k8s官方支持文档
支持用户自定义，同时实现网络代理，可忽略网络负责性。
k8s-github项目地址

新增Pod时

考虑： 考虑容器运行实例之间的关系

• 需集中
  即运行紧耦合服务时，需考虑多个运行相同或不同服务的容器放置在一个pod,该pod包含的容器运行在同一个minon(Host/vm)上，共享相同的volumns和network namespace/IP和Port.

• 过滤掉不符合minon/host/vm

NoDiskConflict：检查在此主机上是否存在卷冲突。如果这个主机已经挂载了卷，其它同样使用这个卷的Pod不能调度到这个主机上。GCE, Amazon EBS, and Ceph RBD使用的规则如下：

GCE允许同时挂载多个卷，只要这些卷都是只读的。
Amazon EBS不允许不同的Pod挂载同一个卷。
Ceph RBD不允许任何两个pods分享相同的monitor，match pool和 image。

docker volumnn concept is different from k8s volumn.

冗余保证

Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行， 即使在节点出错时。
Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等。

整合（即“重调度”）

据说社区已经考虑到了，具体还没有看（待查）
这部分可以自己加

目前已有的产品

Magnum

Openstack Magnum

Magnum现在可以为用户提供Kubernetes as a Service、Swarm as a Service和这几个平台集成的主要目的是能让用户可以很方便的通过OpenStack云平台来管理k8s，swarm，这些已经很成型的Docker 集群管理系统，使用户很方便的使用这些容器管理系统来提供容器服务。

Magnum现在没有调度模块,对Docker的管理通过Swarm Bay来进行管理

总结：openstack magnum 对容器的管理、编排主要依赖上层集成的容器集群管理项目( swarm, k8s, mesos以后)进行。

采用两级调度，除了考虑到安全因素：

• 更好的定制
  可以由用户很据自身使用习惯、惯用的容器编排工具结合vm，进行管理。

• 松耦合胜于紧耦合
  这种松耦合的集成方式，可以最大程度维持openstack项目架构不进行大幅度调整。若将容器的编排直接写进openstack内核架构，那么这个架构将会臃肿，不利于用户自定义剪裁，也不会促进开源社区的激情。

• 插件模块式更利于调度
  采用开放式，独立插件式容器编排方式，可以将vm调度与container调度分开定义，尝试不同调度策略，集传统VM调度经验与现有商用容器调度经验于一体，更利于vm-container整合。