从某种程度上来讲,目前规模较大的公有云服务商都是自给自足的状态,在他们的基础设施云版本上运行他们的应用程序。他们不只本身使用这个基础设施,也卖给别人用。就这一点而言,这几家大的云提供商跟大型企业、政府机关没什么不同,然后二者目前则正在努力跟遗留系统作抗争。后端
Google 的展望服务器
搜索引擎和在线广告巨头 Google 但愿本身的云平台业务可以与 AWS、微软竞争,可以一直走在 IBM SoftLayer、Rackspace,以及一些公有云提供商的前面。Google 有两个战略性优点,可让本身最终在云平台领域作得如同 AWS 同样大,甚至作得比剩下的厂商都大。亚马逊坚信,AWS 会作得比本身的电子商务业务(在线零售)要大,虽然如今还远远没有达到。首先,Google 本身设计本身的服务器,存储和网络,以及环绕他们的数据中心。这样的数据中心在全球范围内链接大面积区域网络,范围能够扩充到一百万台机器。第二个优点,不是能够存储数据、分析数据的巨大软件库,而是开源容器编排工具 Kubernetes,灵感来自于集群管理系统 Borg 以及 Omega。网络
Kubernetes 的出生app
从 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 内部做为项目、工具的更新信息。oop
“咱们已经为人们从 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 就像是一个飞行员,在云端操纵着它的用户。
原文连接:
https://www.nextplatform.com/2016/11/08/google-wants-kubernetes-rule-world/?from=groupmessage&isappinstalled=0