kubernetes和Swarm，你站哪一队？

前言

前几天阿里云的技术专家来我司介绍云计算相关产品，提到了关于容器编排技术的选择。由于阿里是Docker中国目前唯一代理，所以态度明确的表达大B企业应该使用dockerEE+Swarm。这也引起了我们新一轮的调研和考量（我们前期使用的是k8s）。

背景

当前主流的容器集群管理技术，包括了 Docker 官方的 Docker Swarm、Twitter 背书的 Mesos 和 Google 背书的 Kubernetes。由于Apache Mesos 只是一个分布式内核，目前的发展方向是数据中心操作系统（DCOS），它同时支持 Marathon、Kubernetes 和 Swarm 等多种框架，连 Mesosphere 也是 Kubernetes 生态的一员，从编排的角度，讨论 Mesos 意义不大，故而只对比 Docker Swarm 和 Kubernetes。

我个人的立场

kubernetes是更为成熟的编排工具，有google背书，社区活跃明显超过Swarm，并且考虑到目前Docker公司和整个CaaS生态圈的关系，如果非要站队，我会选择Kubernetes

分析

先上一张对比图（来自网易）

可以看到，起码就目前而言，Swarm在各个方面都明显弱于K8S。
首先，K8S社区活跃度要明显高于Swarm，甚至不在一个量级，社区活跃并不是说当遇到问题是仰仗社区解决问题，而是说明有更多厂商企业使用，有更多的最佳实践经验可以借鉴。

其次，核心功能上Swarm也还缺少很多，虽然swarm肯定会后续不断完善，但那显然需要时间的检验。

而swarm唯一的优势或许是集成在了Docker中，自然有利于开发者获得集群的能力，却也颠覆了系统级程序专注、松耦合的理念，新架构在生产环境中的稳定可靠，可能还需要更多的说服力。

最后，Docker本身的发展和CaaS生态圈也是摩擦重重，出现了很多的槽点，比如：
- Docker向后兼容性问题
- Docker容器在某些生产环境运行不够稳定，在企业级方面还有待提高
- 越过了操作系统的界限（Docker似乎不愿使用systemd，取而代之使用Docker Daemon来提供初始化，服务激活，安全和容器日志的相关功能）

如果甚至都不用Docker呢

我们很容易的想到，以Docker目前的发展态势来说，一旦docker和google等巨头闹翻，那基于k8s+docker来做的系统就没法使用了吗？

我觉得也并不是。

首先，我们最简单的方式，或许是不升级新的docker版本，最多就是后续问题不在有docker官方支持。但我相信这么多企业在用k8s，到时候google或者其他大厂、社区必定会有相应解决方案。

而且google等厂商也已经准备了应对之策，那就是在CaaS中废弃Docker，对容器进行抽象，用谁的容器都可以。
容器运行时不再用Docker，而直接采用RunC，容器扩展功能通过插件来实现，基本就是全抛弃Docker了。
目前RunC是三大容器厂商共同支持的标准：CoreOS Rocket, Cloud Foundry Garden和Docker容器。

目前的形势，就形成了Docker和各个CaaS/PaaS厂商在同一层面竞争，在CaaS/PaaS平台，Docker并没有什么优势，但是Docker想把其容器的广泛使用的优势在CaaS中延续，目前看来并不容易。容器的主要用户还是个人用户、开发者用户、运维用户，而CaaS是企业系统，二者目标客户不同、技术要求不同。

随着这个生态的演进，Docker容器会更多的用于开发、测试环境，而RunC在各个CaaS厂商的推动下会在生产环境得到广泛的应用。

另外其实容器技术壁垒并不高，容器最主要的两个的技术来源：
1、 Namespace—来源于IBM
2、 cGroup—-来源于Google
其他的容器核心技术都是Linux操作系统的功能，容器的核心技术是和Linux操作系统密切相关的，Docker本身在容器核心并没有什么贡。
所以容器生态圈的公司撇开Docker做一个容器标准不是难事。

作为用户或是容器生态圈的创业公司，不能一棵树上吊死，如果在容器层面只考虑Docker，而不考虑RunC，可能会和CaaS/PaaS生态圈的标准越来越远，未来和CaaS/PaaS的标准容器差异越来越大，主流的CaaS/PaaS厂商和技术，如K8s/Mesos/Cloud Foundry均不再支持Docker容器超越RunC之外的功能，而只支持插件对RunC功能的扩展。

业界更普遍的定位是Docker用于开发测试环境，而RunC用于生产环境，所以对于要在生产环境采用容器技术的，一定要研究RunC。

总结

对于企业来说，目前使用Kubernetes+Docker或许是最好的选择，而未来的方向应该是转向Kubenetes+RunC。
而到时候转换的成本其实也不用担心，其实现在已经有Docker镜像转为RunC镜像的方式了（Riddler）

参考

http://tech.china.com/article/20161213/201612139121.html
http://www.weixinnu.com/tag/article/2817098942
https://blog.c.163.com/2016/11/735/