从Kubernetes争霸过程看Google开源套路

一、先说结论

首先、云原生时代到了，大家已经不再仅仅满足于Docker构建镜像，企业用户更需要编排、管理和调度。其次，而Kubernetes作为Google内部秘密从头开发的 Borg2.0 版本，一诞生就具有完整的功能和良好的扩展架构，很多方面都已经吊打其他0.1版本的竞品了。不仅仅如此，Kubernetes的金主爸爸拥有如此核弹头级别的大杀器，为了占领市场居然完全不要钱完全开源免费白送（这和早期微软系统在国内坐视盗版免费占领市场有类似的效果）。不仅不要钱，还拉帮结派找了红帽等很多小弟构建CNCF基金会（是不是很安卓的开放手机联盟很像），生生造出一个基金会标准和生态降维打击竞品。真是占据了天时（云原生时代）地利（Brog2.0）人和（开源+基金会）等要素。

当然，其中也有劣势：就是Docker和Hadoop等开源项目抢了Google内部系统的风头，提前占领了开源屌丝市场（这也正是Google后来在开源疯狂砸钱的原因，当然最近已经控制了云原生平台后就开始砍开源经费了）。Docker通过内置的Swarm来获得前期的竞争优势。正如大家害怕微软IE一家独大的局面再次上演，Google敏锐地抓住了这个机会很好地通过合纵连横策略打败了Docker。

二、Kubernetes争霸简史

Docker是一个开发、交付和运行应用程序的开放平台，开发者可以在此打包他们的应用及依赖到一个可移植的容器中，然而发布到运行平台上。在Docker走红之前LXC已经在一些公司内部得到应用。比如，2008年Google推出的PaaS平台 GAE（Google App Engine）就采用了LXC。在GAE中Google使用了一个能够对LXC进行编排和调度的工具Borg——后来Kubernetes借鉴了它的很多设计。整体而言LXC的应用范围不广，主要是一些有技术实力的大公司在应用。LXC虽然解决了应用的隔离，但并没有解决可移植性问题，而这个问题被Docker完美地解决了。Docker有三个最重要的概念：镜像、仓库、容器，其中镜像是基石，也是Docker最重要的创新。

不过，Docker只是满足了应用软件生命周期中的一部分需求，随着越来越多的企业开始采用Docker技术来开发和部署应用，特别是要规模化部署应用，它们发现自己面临一个现实的问题，就是要对多个容器进行编排、管理和调度。就在这个时候，Google带着Kubernetes下场了。

Google是云计算概念的最早提出者，不仅有PaaS平台GAE，还有Google云GCP，但提到云计算人们首先提到的却是AWS，Google的存在感很弱。多年运行GCP和Borg的经验，使得Google非常认可容器技术，也深知目前Docker在规模化使用场景下的不足。Google从当时大火的容器市场看到了机会，而且这里也存在一些商业机会：如果容器得到广泛应用，那些在AWS运行的应用就有可能自由地移植到GAE和Google云上运行。

2013年夏天，Kubernetes联合创始人Craig McLuckie和Joe Beda、Brendan Burns等开始讨论容器编排系统的开发，并决定采用开源的方式来开发这个系统。经过多次找机会向Google高层游说，最后这个项目终于被Google批准开源。并首次在2014年6月举行的DockerCon 2014大会上正式发布。实际上并不是只有Google看到了容器市场的新需求，就在DockerCon 2014大会上，就有多家公司推出了自己的容器编排系统。其中有影响力的还有Docker、Mesos等，而Google的进场让原本就竞争激烈的容器编排市场火上浇油。

Docker也希望提供更多平台层能力，向PaaS进化，为企业最终要部署的网站、服务、数据库，是云计算业务提供解决方案——这才是Docker的目标。2014年7月，Docker收购OrchardLabs正式开始涉足容器编排领域，Orchard Labs的容器编排工具fig当时很有名，这个fig就是DockerCompose的前身。Docker Compose虽然能编排多个容器，但是只能对单个服务器上的容器进行操作，而不能实现在多个机器上进行容器的创建和管理。

2015年初Docker发布Swarm，算是正式向Kubernetes宣战了。在容器规模较小的场景下，许多用户更喜欢使用Docker Swarm，因为它平滑地内置于Docker平台中。如果Docker Swarm能成功，那Docker就将通吃容器市场，这就和CoreOS、Red Hat等一些公司产生了利益冲突，这为Docker后来的败退埋下了伏笔。

在Kubernetes的成长过程中，CoreOS发挥了重要作用。Docker容器发布以后，CoreOS将这一技术集成到自己的操作系统中，2014年发布了自己容器编排框架fleet，这是最早提供云环境自动部署和调度集群资源的容器软件之一。Kubernetes出现后，CoreOS放弃了fleet而转向了Kubernetes，并后来推出了容器运行时rkt来替换Docker的容器运行时RunC。2018 年1月30日，红帽斥资 2.5 亿美元收购了CoreOS。

在Kubernetes项目中，红帽是仅次于Google的重要角色。红帽的OpenShift是最早一批PaaS平台（2011年发布，和Cloud Foundry同一年）之一。2013年9月，Docker大火的时候，红帽将Docker嵌入到红帽Linux企业版RHEL中，并完全重建了OpenShift。作为一个PaaS平台，也需要容器编排功能，红帽需要选一个。红帽在得知Kubernetes项目并最终开源后果断放弃和Mesos合作选择了Kubernetes。2015年6月，OpenShift Enterprise 3在红帽峰会上发布，其中内嵌了Docker和Kubernetes，这给Kubernetes后来的成功打下了坚实的基础。

Mesos是容器编排市场上另一个主要玩家。Mesos最初是加州大学伯克利分校的一个项目，目的是创建下一代集群管理器，一直在努力提高集群的利用效率和性能。作为一个面向资源管理的项目，容器编排其实只是其中的一个功能模块，叫Marathon。Mesos在2014年成为首批支持Docker容器的容器编排框架之一。实际上Mesos不仅仅可以支持Docker，还可以支持Java应用集群。Mesos的最大优势是它在运行关键任务时的成熟度，它比其他许多的容器技术更成熟，2015年Kubernetes 1.0刚出来时也只具有管理100台服务器的能力，而Mesos当时已经有管理上万台机器的案例。Mesos被Twitter、苹果（Siri）、Netflix等公司所采用。相比Docker与Kubernetes，Mesos侧重在传统的资源管理，不如前两者天生是面向多云和集群的，它在应对多云和集群管理时面临很多新的挑战。后来随着外部竞争的恶化逐渐淡出了历史舞台。

Kubernetes脱胎于已经在Google内部运行了多年的Borg项目，但并没有直接延用Borg，属于Borg2.0版本。Kubernetes设计了一套稳定可扩展的API接口、预置服务发现、容器网络、及可扩展等关键特性。其概念抽象非常符合理想的分布式调度系统。Kubernetes的一个成功之处就是提供了一个规范，可以让你描述集群的架构、定义服务的最终状态，由它来帮助你的系统达到和维持在这个状态。同时和Docker、Mesos相比，Kubernetes强大的生态为应用程序开发人员提供了丰富强大的工具，用于编排无状态的Docker容器，让开发人员减少了对基础设施和操作团队的依赖。另外，Kubernetes作为CNCF下的开源项目，使得它与Docker相比更容易得到认可和支持。相比Docker后来将Swarm全部内置到Docker项目，完全是和Kubernetes整个社区竞争。

Docker虽然以创新性的技术通过开源社区取得了巨大的成功，但是在独自对抗Google、红帽巨头乃至整个云计算产业最后以失败收场。不仅仅是Docker，其他云厂商也失去了一家独大的可能，而 Google 则成为了云原生的最大赢家。

三、类似案例

类似的案例还有很多，比如Chrome、Firefox通过免费打败IE，比如安卓联盟通过开放手机联盟打败诺基亚、Windows Phone，WASM通过免费/标准在浏览器领域打败Flash、JVM、ActiveX。而作为一个反面教材，Qt因为缺少真正的盟友而失去了进一步发展壮大的机会。总结而言，首先东西要好，但不能吃独食，所以还需要一个不差钱的金主爸爸。