Docker拥抱k8s早有预兆，Docker现何去何从？

时间：2017-10-21 00:24:46 阅读：248 评论：0 收藏：0 [点我收藏+]

导读

本文由Rancher Labs CEO及联合创始人梁胜博士写于前往参加DockerCon之前。从各家容器编排方案均很不成熟的初期，到三足鼎立的编排之战，到如今k8s似已全面胜利，作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，梁胜博士分享了他的一些看法。

Docker宣布支持Kubetnetes，拥抱昔日对手，而这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。

目前Docker技术得到了广泛应用，在大量需求的催生下，我们创造了Rancher，在过去三年的各届DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。

DockerCon有它的特别之处——不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。

Docker的技术革新正处于关键期，因此我对于Docker将在今年DockerCon EU公布的内容非常感兴趣。最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。

容器基础设施

基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过我们遇到了难以逾越的挑战：

我们还没有实现让CNM在Docker的内置网络实现之外工作。比如，我们现在还不能创建一个脱离Swarm Mode的CNM实现。
我们没法让Rancher上的Docker volume插件在Docker守护进程下保持可靠性。我记得有一个极具挑战性的issue，#18504，它导致Docker守护进程会不时地锁住。我们暂时还不能解决它，也还没找到解决方案。

在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。

容器编排

我们为Rancher开发了名为Cattle的容器编排器，来填补在Docker Swarm早期时缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器。我们希望当Swarm更加完善之后，能够最终替代Cattle。

然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。

2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。

可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。

Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。

容器生态系统

DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。

构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。

Docker将何去何从？

早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？

在我从DockerCon回来之后，我会再写一篇文章，分享更多我的一些看法与见解。

Rancher at DockerCon

Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力，这在业界都还是独一无二的特性。