容器服务中的节点失效时Docker容器重新调度介绍

    生产环境部署的服务都会考虑单点失效情况下的高可用性。在容器服务中,当节点失效的时候,能否重新调度容器到健康节点上继续提供服务对于生产环境中的服务高可用性尤为重要。下面我们就演示一下容器服务的重新调度功能。


    首先创建一个含有3个节点的集群。


容器服务中的节点失效时Docker容器重新调度介绍

 

容器服务中的节点失效时Docker容器重新调度介绍

    我们使用如下编排模板创建一个含有三个实例的nginx service,注意到添加了一个属性reschedule:on-node-failure意思是在节点失效的时候 会重新调度这个容器。


web:
    image: nginx
    restart: always
    environment:
        - reschedule:on-node-failure
    labels:
        aliyun.scale: "3"


    

     创建成功后容器分布如下:

    容器服务中的节点失效时Docker容器重新调度介绍

    下面我们在 ECS 控制台上将其中一台机器关掉来模拟节点宕机。


容器服务中的节点失效时Docker容器重新调度介绍

 

    我们来看看目前容器情况如何


容器服务中的节点失效时Docker容器重新调度介绍


    可以看到,在失效节点上的容器已经被自动迁移到另外一个机器上,而且这样配合前面的 SLB 负载均衡,可以做到节点宕机不影响线上服务的效果。

    下面我们将宕机的那台机器重新启动起来。因为我们的容器都设置了restart: always, 这样我们原来在这台机器的容器就会重新启动,会导致原service多出一个容器。这里我们会将多余出来的这个容器删除,保证service的容器个数。

容器服务中的节点失效时Docker容器重新调度介绍


     

     Docker Swarm 在overlay 网络下不会重新调度失效节点的容器,而且对于"复活"的节点,它也不会去删除掉多余的容器。 从上面的例子我们可以看到,我们解决了这些问题。

    未来我们会提供更多的调度机制来保证线上服务的稳定可靠。更多内容请看参考 容器服务

上一篇:使用docker compose 测试集群网络连接性


下一篇:那么传统的自顶向下的解析器就能很好地工作