kubernetes和Swarm,你站哪一队?
前言前几天阿里云的同事来我司介绍云计算相关产品,提到了关于容器编排技术的选择。由于阿里是Docker中国目前唯一代理,所以态度明确的表达大B企业应该使用dockerEE+Swarm。这也引起了我们新一轮的调研和考量(我们前期使用的是k8s)。背景当前主流的容器集群管理技术,包括了 Docker 官方的 Docker Swarm、Twitter 背书的 Mesos 和 Google 背书的 Kube
前言
前几天阿里云的技术专家来我司介绍云计算相关产品,提到了关于容器编排技术的选择。由于阿里是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/
更多推荐
所有评论(0)