美文网首页
微服务笔记27:容器调度与服务编排

微服务笔记27:容器调度与服务编排

作者: 胖琪的升级之路 | 来源:发表于2018-10-23 17:21 被阅读0次

    容器调度

    有一部分带需要发布服务的机器,但是在发布服务的时候应该选择哪些机器部署,这就是调度需要解决的问题。
    机器少量的时候,认为选择还是可以支持,如果数量多大上百台,上千台,那么就不能人肉运维了。
    三个解决方案:Docker原声的Swarm,以及Mesos,和谷歌开源的k8s.

    容器调度解决的问题

    1. 主机过滤
    • 存活过滤:选择的节点必须是可用的。
    • 硬件过滤:Web集群与大数据集群。集群类别不同需要的资源不同,Web属于密集计算类型那么CPU利用率比较高。
      大数据属于数据存储,IO要求比较高。
      新增容器属于大数据类型,那就需要添加到大数据集群中去,而不是Web集群中。
    • 容器层次的过滤:某个主机才会被加入侯选集功能。
    1. 调度策略
      为了解决容器创建时选择哪些主机合适的问题
      Swarm 提供了两种策略spread和binpack.提供的策略是根据配置进行打分。
      spread 选择一个资源使用最少的节点,让容器尽可能的分布在不同的主机上。负载比较均衡。
      binpack 选择资源使用最多的节点,让容器运行在少数机器上。
      根据业务选择策略。

    服务编排

    服务编排需要考虑到三个方面 1. 服务依赖。 2. 服务发现 3. 自动扩缩容。

    1. 服务依赖
      官方提供的方式是通过Docker-compose yaml文件编程进行依赖挂靠。先启动哪个容器,再启动后面的容器。
    2. 服务发现
      调度完成后,需要将启动的节点服务加入到线上的服务中去。
      服务发现机制大概有两种:
    • 基于Nginx的服务发现:针对HTTP服务的,通过节点列表配置利用reload机制加载配置文件。
    • 注册中心的服务发现:针对RPC服务的,通过注册中心的服务发现机制。
    1. 自动扩缩容
      容器完成调度后,需要做到姿容的扩缩容。
      时间规律性的产品,白天人数多,那么需要的机器容器就多,需要自动的扩容。晚上机器少,可以做到缩容。

    相关文章

      网友评论

          本文标题:微服务笔记27:容器调度与服务编排

          本文链接:https://www.haomeiwen.com/subject/vorazftx.html