为什么Docker最终接受了Kubernetes？

钟最龙 译

容器编排器的大战似乎快要结束了——Docker宣布在下一个企业版本开始支持Kubernetes。下面是你需要了解的。

Docker的吉祥物可能是鲸鱼，然而在Dockercon Europe 2017之前，Kuberenetes是人们避而不谈的大象。三个主要云提供商都加入了由Kubernetes主持的开源基金会，即云原生基金会（CNCF），这让其势不可挡。

行业的转向似乎让Docker Swarm成了孤家寡人。Docker的竞争者如Redhat的Openshift早已接受Kubernetes，Docker也终于在Dockercon Europe 2017的主题演讲中宣布将Kubernetes整合加入日程，总算登上Kubernetes的列车。

编排器概览

就像Apple推出iPhone让智能手机变成主流，Docker让容器变成了主流。自从项目发布以来，Docker着重于提升开发者的体验。基本理念是可以在整个行业中，在一个标准的框架上，构建、交付并且运行应用。理论上，一个机构能够从一个笔记本上构建出一个持续集成和持续开发的流程，然后将其应用到生产环境。

起初的一个挑战是数据中心编排。与VMware vSphere不同，当时少有能在生产环境中大规模管理负载的工具，而Docker用来在数据中心级别进行容器编排的主要方式是Docker Swarm。

容器编排的解决方案一直不缺。Mesosphere是早期的领头羊，而现在的势头已经今非昔比。Docker Swarm虽然是单个厂商的编排视角，但是它与Docker EE深度整合。Docker正在用Docker EE构建一个能合与成熟的项目如Cloud Foundry匹敌的平台。然而，正如前面提到的，整个行业已经聚集到了Kubernetes的家门前。

按照Docker的说法，Google将它们的超大范围的经验带到了容器编排中。Kubernetes采取的开源策略赢得了生态中的大量用户。

结伴运行

Kubernetes的学习曲线是陡峭的。Docker的实现看起来将Kubernetes的复杂度隐藏到了幕后。编排层就像应用开发者和运维团队的一个契约一样。API是一种用来在这两种团队之间进行沟通的语言。Swarm和Kubernetes不仅使用不同的架构，而且使用的API也不一样。

Docker采用的设计允许在同一个集群中同时运行Kubernetes和Swarm。在部署Swarm的时候，安装器提供了一个安装Kubernetes的选项。如果勾选了该选项，Kubernetes会继承Swarm安装的冗余设计，同时将两种不同的方式整合到子系统如网络中。

为两种编排器设计的生态系统仍然能够独立地运行。例如，利用原生Kubernetes API的应用和进程能直接和用Swarm部署的实例运行。类似的，使用Docker Compose文件部署的应用能原生地在Swarm提供的Kubernetes基础设施上原生地运行。

这就给我们带来了资源管理的挑战。Swarm和Kubernetes能在单个主机上运行，每一个编排器都不知道对方的存在。每一个编排器都假设能使用主机100%的资源，所以，Docker不推荐在同一个主机上同时运行Kubernetes和Swarm的工作负载。

这个特性会在2018的第一个季度GA，据此我有理由认为这是一个容器生态系统的里程碑时刻。通过将Docker EE和Kubernetes整合，Docker不再只是人们口中的开发平台，它也是一个生产级别的能和PaaS提供的解决方案一战的生态系统。