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