Docker近日宣布支持Kubetnetes，拥抱昔日对手，让业界大为震惊。其实，这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的驱动下，我们创造了Rancher，在过去三年DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon的特别之处不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，最近我们发布了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插件方面做努力，不过还是遇到了难以逾越的挑战：
1、我们还没有实现让CNM在Docker的内置网络实现之外工作。比如，现在还不能创建一个脱离Swarm Mode的CNM实现。
2、我们没法让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 EU上，我遇见的DockerCon的用户、供应商以及Dokcer公司的员工都给我留下了非常友好和亲切的印象，与他们的交流也让我收获了很多。毫无疑问，这是一次组织充分的大会，对我而言也是一段有趣的经历。
在启程参加大会之前，我曾对Docker公司的未来计划与发展走向提出了一些疑问。而这次大会上，Docker之父、Docker公司CTO Solomon Hykes在他在keynote中的分享正好解答了我上面说的这些问题，这也毋庸置疑成为了演讲中引起业界震动的焦点——Docker决定拥抱Kubernetes，而这也是此次DockerCon上最重磅的新闻。
押宝“现代化传统应用”项目MTA
然而，除此之外，如果说Docker公司还有一个动态就是他们非常希望参会者及业界知晓的，那一定是“现代化传统应用”项目（MTA，Modernize Traditional Applications）。MTA的想法很简单，将传统的Windows或Linux应用程序打包成Docker容器，然后将应用部署到现代云基础架构上并且实现一些资源节约。大会花了三场keynote（整整一天半的时间）来介绍MTA，Docker似乎把整个业务都押在这单一价值主张上了。
然而令我惊讶的是，MTA居然是DockerCon中唯一聚焦的业务案例。DockerCon的参会者和我说，他们期望Docker能够描绘出一个更加完整的Docker商业机会的愿景和版图。然而MTA并没有吸引到大多数参会者，即使是我遇到的一些企业嘉宾也有比MTA更大的计划。其实我更希望Docker能够花更多的时间来加强容器在改变应用程序开发方面上传递的价值，因为在我看来这是一个更大的商业机遇，不过有点可惜，Docker似乎并没有这么做。
Docker技术是一种应用打包的方式，它也是Docker公司从创立之初便开始的实践，MTA便是建立在Docker这一最基础的功能之上。但是Docker EE究竟有哪些具体的功能，能够使得MTA工作得比以前更好？为什么Docker要专门为MTA提供解决方案？客户还需要哪些工具来完成他们的MTA之旅？关于MTA的keynote并没有解答以上这些疑问。（事实上，我相信大家还有更多未得到解答的疑问。）
几点遗憾的地方
另外让我感到遗憾的一点是，除了宣布支持Kubernetes外，Docker再没发布什么和Swarm相关的动态和信息了。Rancher Labs作为Docker生态系统的合作伙伴，在这一情境下，我个人深感在基于Docker技术组件上实现创新愈发困难。我至今记得曾经Docker发布一个又一个杰出的、创新的技术与产品的日子，像Docker Machine、Docker Swarm、Docker Compose、Docker network以及volume插件等等。那时的我们，在Docker发布这些新的创新之后，便会马不停蹄地开始投入相应的工作。时至今日，在容器技术领域依然有许多创新，只不过这些创新大多发生在Kubernetes以及CNCF生态系统中了。
我真心地希望，在整合Kubernetes之后，Docker能够回到过去的状态，为业界带来更多的技术创新。我依然认为很少有公司像Docker这样，既具有出色的创新能力，又专注于产品的可用性。我很期待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集群的能力。
热门专题
