容器调度
有一部分带需要发布服务的机器，但是在发布服务的时候应该选择哪些机器部署，这就是调度需要解决的问题。
机器少量的时候，认为选择还是可以支持，如果数量多大上百台，上千台，那么就不能人肉运维了。
三个解决方案：Docker原声的Swarm，以及Mesos,和谷歌开源的k8s.
容器调度解决的问题
- 主机过滤
- 存活过滤：选择的节点必须是可用的。
- 硬件过滤：Web集群与大数据集群。集群类别不同需要的资源不同，Web属于密集计算类型那么CPU利用率比较高。
大数据属于数据存储，IO要求比较高。
新增容器属于大数据类型，那就需要添加到大数据集群中去，而不是Web集群中。 - 容器层次的过滤：某个主机才会被加入侯选集功能。
- 调度策略
为了解决容器创建时选择哪些主机合适的问题。
Swarm 提供了两种策略spread和binpack.提供的策略是根据配置进行打分。
spread 选择一个资源使用最少的节点，让容器尽可能的分布在不同的主机上。负载比较均衡。
binpack 选择资源使用最多的节点，让容器运行在少数机器上。
根据业务选择策略。
服务编排
服务编排需要考虑到三个方面 1. 服务依赖。 2. 服务发现 3. 自动扩缩容。
- 服务依赖
官方提供的方式是通过Docker-compose yaml文件编程进行依赖挂靠。先启动哪个容器，再启动后面的容器。 - 服务发现
调度完成后，需要将启动的节点服务加入到线上的服务中去。
服务发现机制大概有两种：
- 基于Nginx的服务发现：针对HTTP服务的，通过节点列表配置利用reload机制加载配置文件。
- 注册中心的服务发现：针对RPC服务的，通过注册中心的服务发现机制。
- 自动扩缩容
容器完成调度后，需要做到姿容的扩缩容。
时间规律性的产品，白天人数多，那么需要的机器容器就多，需要自动的扩容。晚上机器少，可以做到缩容。
