docker 编排工具 2017最佳选择是 swarm/kubernetes/Mesos ？

叁叁肆提问于 2018-11-28 16:43

• 勿忘初心2018-11-28 17:04

  这个问题并没有一个明确的答案，只能从技术角度分析具体的场景，例如公司的规模，将部署小集群还是大集群，倾向于私有云还是公有云，已经采购了IaaS还是没有IaaS，IT运维能力强还是弱，是否需要物理机、虚拟机、容器的混合部署，是一般的并发系统还是高并发，这里面所应该做的技术选型都不一样。

  例如，如果你是一个初创型的主营业务非IT的小公司，自然不应该花大力气在数据中心里面自己搭建一套大规模、高并发、高性能的容器平台。以下将从几种模式分析不同的业务场景下容器的使用方式：

  模式一：公有云虚拟机

  适合场景：初创公司，无信息安全担忧
  如果您是一家初创公司，人员少，IT运维能力不足，要部署的系统很少，能够花在IT系统上的资金有限，当然应该选择公有云的虚拟机部署，它能够解决您的如下问题：
  基层IT资源的管理交给公有云平台，公司自身运维人员仅需要基本的Linux能力；
  少量的部署系统，例如10台以下的虚拟机，往往替换一个war，重启Tomcat就能解决，如果稍微虚拟机多一点10到20台，Ansible脚本可以很好的解决这个问题；
  公有云按量按时收费，可以在花费很少的情况下启动，并且在业务飞速扩展的时候，迅速申请大量虚拟机。网易云的云服务器可以免费体验。

  模式二：无IaaS，裸用容器

  适用场景：初创公司无IaaS，有信息安全担忧
  还是有初创公司或者初创项目，也许因为心理方面，也许因为合规方面，非常担心信息安全问题，还是希望采取部署在自己机房的方式。

  但由于是初创公司，在机房里面一般是不能部署IaaS，因为IaaS平台的运维难度，优化难度更大，没有一个50人的团队根本玩不起来，所以一般在使用容器之前，采用的是物理机部署的方式，当物理机数目非常小，比如部署5到10个应用的时候手动部署或者简单脚本部署就可以，但是一旦到了20个应用，手动部署和简单脚本就非常麻烦了。

  这个时候，可以试一下裸用容器，即在原来的脚本，或者Ansible里面，将启动进程，改为使用Docker run。

  在这个阶段，最简单的方式就是把容器当做虚拟机来使用，也即先启动容器，然后在里面下载war包等，当然也可以更进一步，将war包和配置直接打在容器镜像里面，这样需要一个持续集成的流程了，不仅仅是运维的事情，开发也要参与其中。

  网易云提供容器服务专属云版，是企业级的容器平台，部署在用户的专属云资源上。基于 Kubernetes 技术，提供用户独享的容器集群。

  模式三：有IaaS，裸用容器

  适用场景：创新项目，引入DevOps流程
  有一些公司规模大一些，已经采购了IaaS，只不过有一些创新的项目需要部署，这种状态下，基本虚拟机已经能够满足需求，而且由于能够运维IaaS，IT能力比较强，一般也采用了Ansible等部署工具。

  这种情况下，使用容器的动力相对比较少，然而容器也是能够带来一定好处的，就是DevOps。

  创新项目迭代速度比较快，如果有比较多的创新项目，对运维的压力也是非常大的，这里的裸用容器和模式二的裸用容器不同的是，不是拿容器当做虚拟机来用，而是将容器当做交付物来用。虽然容器化对于运维的整个过程来讲改进有限，但是关键就是要开发写一个Dockerfile，这一点非常重要，意味着运行环境的配置提前到开发，而非直接交到运维，也即上面说的，开发5%的工作量增加减少大量运维工作，容器环境原子性升级回滚使得停服时间变短，可以保持开发、测试、运维环境的一致性。

  模式四：使用Docker Swarm Mode

  适用场景：发展中公司，中等规模集群
  当集群规模超过50台时，裸用容器已经非常难受了，因为网络、存储、编排、服务发现等全部要靠自己的脚本或Ansible来搞定，是时候引入容器平台了。当容器平台规模不是很大时，Docker Swarm Mode还是比较好用的：
  集群的维护不需要Zookeeper，不需要etcd，自己内置
  命令行和Docker一样的，用起来顺手
  Docker Overlay网络是内置的

  总之Docker帮你料理好了一切，你不用太关心细节，很容易就能够将集群运行起来。

  而且可以通过Docker命令，像在一台机器上使用容器一样使用集群上的容器，可以随时将容器当虚拟机来使用，这样对于中等规模集群，以及运维人员还是比较友好的。

  模式五：使用Marathon和Mesos

  适用场景：万节点集群，多定制
  当集群规模大一些，几百个节点时，很多人就不愿意使用Docker Swarm Mode了，很多的选择是既没有用DC/OS，也没有用Kubernetes，而是仅仅用了Marathon和Mesos。

  因为Mesos是一个非常优秀的调度器，它的双层调度机制可以使得集群规模大很多。其它框架的调度器是直接面对整个集群，Mesos的优势在于，第一层调度先将整个Node分配给一个Framework，然后Framework的调度器面对的集群规模小很多，然后在里面进行二次调度，而且如果有多个Framework，例如有多个Marathon，则可以并行调度不冲突。

  而且Mesos的架构相对松耦合，有很多可以定制化的地方，从而运维人员可以根据自己的需要开发自己的模块。这也是很多优秀的公司使用Marathon和Mesos的原因。

  例如爱奇艺、去哪儿、携程、当当等都选择了使用Mesos，需要提一下的是，大家如果参加社区，能发现裸用Marathon和Mesos的很多，但是整个DC/OS都用得比较少，而用Marathon和Mesos往往不能解决一些问题，因而这些IT能力非常强的互联网公司做了大量的自己的定制化，增加了Marathon和Mesos的外围模块。

  模式六：使用开源Kubernetes

  适用场景：千节点集群，少定制
  Kubernetes模块划分得更细，模块比较多，比起裸Marathon和Mesos来讲功能丰富，而且模块之间完全的松耦合，可以非常方便地进行定制化。

  而且Kubernetes的数据结构的设计层次比较细，非常符合微服务的设计思想。例如从容器->Pods->Deployment->Service，本来简单运行一个容器，被封装为这么多的层次，每次层有自己的作用，每一层都可以拆分和组合，这样带来一个很大的缺点，就是学习门槛高，为了简单运行一个容器，需要先学习一大堆的概念和编排规则。

  但是当需要部署的业务越来越复杂时，场景越来越多时，你会发现Kubernetes这种细粒度设计的优雅，使得你能够根据自己的需要灵活的组合，而不会因为某个组件被封装好了，从而导致很难定制。例如对于Service来讲，除了提供内部服务之间的发现和相互访问外，还灵活设计了headless service，这使得很多游戏需要有状态的保持长连接有了很好的方式，另外访问外部服务时，例如数据库、缓存、headless service相当于一个DNS，使得配置外部服务简单很多。很多配置复杂的大型应用，更复杂的不在于服务之间的相互配置，可以有Spring Cloud或者Dubbo去解决，复杂的反而是外部服务的配置，不同的环境依赖不同的外部应用，External Name这个提供和很好的机制。
  包括统一的监控cadvisor，统一的配置confgMap，都是构建一个微服务所必须的。

  然而Kubernetes当前也有一个瓶颈——集群规模还不是多么大，官方说法是几千个节点，所以超大规模的集群，还是需要有很强的IT能力进行定制化，这个在模式七中会说一下我们在网易云上做的事情。但是对于中等规模的集群也足够了。

  而且Kubernetes社区的热度，可以使得使用开源Kubernetes的公司能够很快地找到帮助，等待到新功能的开发和Bug的解决。

  模式七：深入掌握使用Kubernetes

  适用场景：万节点集群，IT能力强
  随着Kubernetes使用规模的越来越大，大型的公司可以对Kubernetes进行一定的定制化，从而可以实现万节点甚至更大规模的支撑，当然需要IT能力比较强，网易云在这方面有很多的实践，这里不再赘述，感兴趣的可以点击原文查看。

  模式八：深入掌握使用DC/OS

  适用场景：万节点集群，IT能力强
  前面说过Mesos由于本身独特的调度机制，从而支撑的集群规模比较大，但是大多数使用Mesos的公司都没有使用DC/OS，而是裸使用Marathon和Mesos外加自己定制开发的一些组件。

  后来DC/OS在最基础的Marathon和Mesos之上添加了很多的组件，和Kubernetes已经非常像了。很多公司裸用Marathon和Mesos而没有进一步使用DC/OS，可能是因为和核心组件Mesos已经经过大规模生产性支撑不同，这些外围的组件也是新的，对其稳定性也是有一定的顾虑，所以需要比较长的学习曲线，并且对于这些新的组件有非常好的把控，才敢上生产。

  所以从这个角度来讲，虽然Mesos的稳定性和大规模无容置疑，但就整个DC/OS来讲，和Kubernetes从功能和稳定性来讲，在伯仲之间，都需要使用者有强大的IT能力，对于开源软件的各个模块非常熟悉，甚至能够做一定的代码修改和Bug fix，才敢在大规模集群中使用。

  模式九：部署大数据，Kubernetes vs. Mesos

  Mesos还有一个优势，就是Mesos可以通过开发Framework，构建大数据平台，例如Spark就有基于Mesos的部署方式。

  如果使用kubernetes部署大数据，其实和部署一个普通的应用思路差不多，和Mesos不同，kubernetes不会干预到大数据运行的上下文中，Kubernetes启动的容器仅仅作为资源预留方式存在，容器内的资源分配则大数据平台自己解决。这样的利用率就降低了，相当于粗粒度模式。

  基于容器部署大数据平台，也是建议部署计算部分，例如Map-Reduce，或者Spark，对于数据部分HDFS，应当另行部署。

  模式十：容器和虚拟化混合部署

  适用场景：大型公司，逐步容器化
  对于很多大公司但是非互联网公司，使用容器还是需要小心对待的，因而需要逐步容器化，所以存在有IaaS平台，并且虚拟机和容器混合使用的状态，这种状态可能会持续相当长的时间。在这种情况下，建议容器套在虚拟机里面使用。网易云在这个过程中也积累了很多丰富经验，有兴趣可以看《网易云容器服务研发实践分享》。

  以上回复摘自于网易云首席解决方案架构师刘超的文章《容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？》，欢迎到原文深入阅读。

  
  

  网易云提供容器服务，为用户提供了无服务器容器，让企业能够快速部署业务，轻松运维服务。容器服务支持弹性伸缩、垂直扩容、灰度升级、服务发现、服务编排、错误恢复及性能监测等功能。可以点击这里立即体验。