Google 想要称霸商界的秘密武器——Kubernetes

从某种程度上来说，目前规模较大的公有云服务商都是自给自足的状态，在他们的基础设施云版本上运行他们的应用程序。他们不仅自己使用这个基础设施，也卖给别人用。就这一点而言，这几家大的云提供商跟大型企业、政府机关没什么不一样，而后两者目前则正在努力跟遗留系统做抗争。

Google 的展望

搜索引擎和在线广告巨头 Google 希望自己的云平台业务能够与 AWS 、微软竞争，能够一直走在 IBM SoftLayer 、 Rackspace ，以及一些公有云提供商的前面。 Google 有两个战略性优势，可以让自己最终在云平台领域做得如同 AWS 一样大，甚至做得比剩下的厂商都大。亚马逊坚信， AWS 会做得比自己的电子商务业务（在线零售）要大，虽然现在还远远没有达到。首先， Google 自己设计自己的服务器，存储和网络，以及环绕他们的数据中心。这样的数据中心在全球范围内连接大面积区域网络，范围可以扩充到一百万台机器。第二个优势，不是可以存储数据、分析数据的巨大软件库，而是开源容器编排工具 Kubernetes ，灵感来自于集群管理系统 Borg 以及 Omega 。

Kubernetes 的出生

从 Google 开源 Kubernetes ，并将它放在 CNCF （ Cloud Native Computing Foundation ）旗下，从 2015 年 7 月发布的基础版本 1.0 到今年 9 月底发布的 1.4 ， Kubernetes 已经诞生一年多了。

Google 的 Google Container Engine ——缩写为 GKE ，以避免跟 Google Computing Engine （缩写为 GCE ）混淆，那么为什么不叫它 Google Kubernetes Engine 呢？这个以后再说。由 CNCF 主办的 KubeCon 大会近日在华盛顿西雅图举办—— Kubernetes 现在吸引了足够多的注意力。也包括， Google 内的开发人员，那些没有真正操作使用过 Kubernetes 的人。有趣的地方在于， Google 开发人员正着手在 Kubernetes 上运行应用程序，希望能够运行得更加灵活、便捷，也是出于这个原因， Google 将它作为一个商品宣传，作为裸机或者是公有云上的容器抽象层。

“我们跟 Google 内部的人对话，话题通常关于“我们什么时候将 Kubernetes 的这些性能带入 Google ”，能够在 Kubernetes 上随机运行一个应用程序，这真是一个复杂的问题。” Tim Hockin （ Kubernetes 原始工程师之一） 告诉《 The Next Platform 》道。 Hockin 是 Kubernetes 的发声者之一。而 Craig Mcluckie ，是 Computing Engine 服务的产品经理主管，是 Google 内部 Kubernetes 项目创始人员之一，曾负责过 GKE 容器项目。他现在已经离开 Google ，自己创办了一家公司。 Aparna Sinha ， Google Container Engine 的高级产品经理，之前也跳槽了。 Hockin 回电话给我们，给了我们一些 Kubernetes 在 Google 内部作为项目、工具的更新信息。

“我们已经为人们从 Google 内部得到需求，人们想要在 Kubernetes 上运行，我们跟他们一起在云上使用 Kubernetes （其实就是在 Google GKE 上面）。我们正在这条路上走，阻力很大，因为 Google 带来了很多要求，而我们希望这些需求能够暂时被忽略一下。 Google 是一个很难搞到的客户。”

所以，目前最明显的问题就是，在 Google ， Kubernetes 能否替代 Borg ？（当然也有人问 Hadoop ，这个基于 Google MapReduce 概念的软件，可能会替代 Google 文件系统，成为 Hadoop 分布式文件系统）但是， Google 有它自己的遗留软件问题，这个问题可能会妨碍开源。

“我们现在在关注新应用程序， Google 开发人员正在 Borg 和 Kubernetes 之间做选择，而很多人在这两者之间选择了 Kubernetes ，” Sinha 说道。“但是我觉得将 Gmail 和搜索转移到 Kubernetes 上没什么可行性。”

Kubernetes 和 Borg

但是 Google 不仅仅这两个项目，不管它做出什么让公有云更好的服务，它所做出来的服务不仅 Google 能用，其它任意一家公司也能用。云的真实测试就是当 hyperscaler 内部使用的原始基础设施跟它在公有云上卖的性能和功能没有差异的时候。真正的创新会向上移动堆栈，移动到应用程序软件。

“这件事情不同人有不同看法，” Hockin 说， Hockin 一开始在 Google 的 Borg 容器管理系统工作，该系统是来管理集群工具的。“我们已经从 Google 内部为那些想要在 Kubernetes 上运行应用的人提了需求，我们正在跟他们一起合作，在云（也就是 Google 的 GKE ）上使用 Kubernetes 。我们正在往这条路上走，这对我们来说十分困难因为 Google 提出的需求是我们想要暂时忽略的。 Google 是一个很难搞到的客户。我们面对的更大的问题是，我们可以在 Google 内部使用 Kubernetes 来替代 Borg ，或者说跟 Borg 一起使用，这是一个更加困难的问题。我们自己起了很多 Borg 集群，并且让他们运行，我们在 Google 内部有很多策略，所以我们仅仅升级一个集群到 Kubernetes 是不行的。 Borg 有很多很多 Kubernetes 没有的功能——不论这些功能是好是坏，这些功能是 Borg 有的，人们在使用的。我们也不想在 Kubernetes 加入这些功能。所以 Kubernetes 要替代 Borg ，这个举动是一个惊人的尝试。这个尝试可能会失败，也可能需要 5-10 年的时候才可走上正轨，又或者是一场博弈，博弈到最后， Borg 会拥有很多的客户，所有人都在我们的云上使用 Kubernetes 。”

所有的大型云供应商都在面对一套同样的选择和难题。某种程度上， Borg 与大型机其实没什么可比性。但是，由公有云创建的服务会有他们自己的成熟曲线，也会“留恋自己的过去”，因为改变的代价大于一成不变。

我们总是在寻找下一个平台，正如我们这个网站的名字一样（ The Next Platform ），显然， Kubernetes 是一个很强的竞争对手，因为这个引人注目的平台的亮点就是，它很大程度上是基于开源技术的。（ Joe Beda ，前谷歌人，曾经和 McLuckie 一起负责 Kubernetes 项目，他帮助过 Urs Hoetzle 。 Urs Hoetzle 是搜索引擎的带头人，也希望创造一个更加全面化的 Borg 和开源项目，指出下一代平台应该是什么样子的，我们也跟他讨论过将 Kubernetes 和 Prometheus 整合到一起。）

“ Kubernetes 的延展性和灵活性造就了这个平台，” Sinha 说道，“你可以在虚拟机上、裸机，或者是任何云上面运行 Kubernetes ，这就是它的奇妙之处。它给了你足够的选择，而不是你为了它特地去找合适的云。你可以自由选择存储，网络和调度程序，同样你也可以在这些里面插入 Kubernetes 。这也是 Kubernetes 更加合适企业的原因之一，因为它更加适合他们的环境。”

微软选择了 Kubernetes 竞争者 Mesos 在 Azure 上管理他们的容器层，当然微软也支持 Docker Swarm （不过这周他们刚宣布自己也是支持 Kubernetes 的）。具体来说， Azure 上，原始虚拟机支持 Kubernetes ，很快， Azure 容器服务上编排层就可以用 Kubernetes 来搭建而不是 Mesos （更加准确来说，在商业层面， Mesos 就是 DC/OS ，以 Mesosphere 的形式售卖）。这样， Azure 跟 Kubernetes 合作更深，整合更亲密，有趣的是，微软现在也开放 ACS 引擎的代码，中间媒介在于 Azure 基础设施和 DC/OS ， Swarm ，或者 Kubernetes 容器编排工具。实际上，这也就是，如同微软说的，是一个开源项目，是 Borg 栈的一部分，而且不是从开源社区那里借用过来的。微软很了解这个选择的意义，但是它支持 Linux ，就是另一个例子了。

但是 Google 和微软是不一样的。微软希望 Azure 可以什么都支持，而 Google 则希望 Kubernetes 什么环境都支持。（在某种意义上来说，微软没有辜负 Borg 的名字，同化了所有的编排工具）准确地说， Kubernetes 就是 Google 迎合裸机云，给它跟 AWS 不一样的云（ AWS 不会卖掉它作为堆栈的基础设施，虽然它说 VMware 才是它的私有云伙伴）。

“这才是正确的思考方式，才是正确的意图，以及那些公司是如何使用 Kubernetes 的，以及集群联盟也就是意味着在那上面创建，” Sinha 说，“我们的策略就是， Kubernetes 总是提供开源设施，这样公司就可以在裸机上使用你选择的云。所以它也不仅仅只是混合云，或者公有云，它是多种云，真的有用户在使用这一点。他们可以在任意的地方部署工作：在 AWS 上，在 GCP 上，或者裸机上，又或者允许他们创建控制面板的联盟上。”

Kubernetes 引入集群联盟

今年发布的 Kubernetes1.3 版本中引入了集群联盟，允许多个 Kubernetes 集群被扩展到多个云上面，公有云或者私有云，或者是跨云提供商的不同领域，有统一的控制面板，允许集群或者是他们的 replica set ，就如同他们是在一个巨大的基础设施上面。显然，这个联盟层可以帮助弹性和灾难恢复，同时也被打算用来允许设置策略，这样就可以推送特定的工作和数量种类到特定区域的集群，如果有依从性或者其它限制的话。你可以放东西在云上的任意地方，但是并不意味着开发人员就要这么做。

抽象层和控制中心两者是种强大的联合，是一项 Google 在它自己的基础设施上收益不菲的技术。

“有件事在 Kubernetes 社区绝对狂热，来自云提供商和他们的实践的抽象层，” Hockin 解释道，“我们并没有想用 Kubernetes 系统的任意部分来复制我们自身，成为 Google 云平台，或者亚马逊的 AWS ，或者是任意的裸机基础设施。对于在实现过程中引起的疼痛，这件事真的十分重要。这会反映在我们的 API 和存储中。 Kubernetes 系统使用抽象存储，但是它被绑定在后端，使存储具体化。所以作为一个开发人员，我只想提 100GB 的快速磁盘的需求，这个快速取决于集群管理人员设置了什么。在我的裸机上， Kubernetes 集群可能就意味着 NetApp 装置；在 GCP 上，它可能就意味着持久性磁盘；在 AWS 上，它可能就意味着 Elastic Block Storage ；但是作为开发人员，其实我不是很了解，也不是很在意。”

在 《 Next Platform 》，我们度过一段艰难的时期，因为那会儿人们不知道，也不在意，但是 Hockin 的观点是对的。他们总是想要更快的速度，更多的性能，更少的延迟性。哦，还有扩容，扩容得更大。这也就是 Google 一直在为 Kubernetes 扩大规模的原因。因为它很清楚要如何处理跨 50000 多个服务节点的 Borg 集群，以及跨 10000 个节点的集群。

“我们有相当强烈的 API 遗留需求，以及我们怎么定义扩容限制，尤其是对于 Google 云平台来说，” Sinha 解释道，“在 Kubernetes1.3 的时候，我们宣布可以支持 2000 个节点，我们计划最高可以扩大规模到 5000 个节点。在外部，用户 push 这个到他们的极限，所以像这样设置限制根本没有困难。但是我们看到的就是全球范围内的消费者正在用 1000 或者 2000 个节点进行工作，然后他们想要拥有分开的集群，但是还是运行在一起的——于是集群联盟诞生了。”

Hockin 说， Google 内部测试 Kubernetes 运行在很多联合集群上面，以及这个联合集群的功能就是，它是分别被创建的，这样消费者就可以将集群胶合在一起，从管理和工作分享角度来看，在每个 Google 云平台区域，在允许情况下，要充分利用所有的地理分布。

“如果一个联盟里有不少于 100 个的集群，那么我们的目标就是几十个。每个集群可以有 2000-5000 不等的节点，最高拥有 60000 个 pod ，” Hockin 说，“如果将 12 个云区域乘以每个云区域里的 12 个集群，再乘以 5000 个节点，那么你就拥有了一堆机器。”（如果准确来说的话，就是 720000 个节点，即使一个节点算作一个虚拟机，那也是很大数目的一堆机器...…目前，大概每个双路服务器有 40 台虚拟机，不过这样算下来也是 18000 台物理机。）

Google 的秘密武器—— Kubernetes

Google 想要开启一场战争，想要在商界称霸。而 Kubernetes 就像是一个飞行员，在云端操纵着它的用户。

转载请联系我们 -3-