开发者俱乐部

标题: Amazon VS Google:云容器之争愈演愈烈 [打印本页]

作者: jack    时间: 2016-3-4 19:51
标题: Amazon VS Google:云容器之争愈演愈烈

企业云容器服务将Docker容器管理的组件从用户处抽象出来,使得更为容易地部署以及扩展其上构建的应用。但是,他们所提供的产品之间有着关键的不同之处,包括每个产品选择在哪里实现自动扩展、冗余以及和第三方工具,云平台的交互能力。

自扩展是争论的焦点

Google容器引擎(GKE)包括pod,复制控制器和节点。Pod是容器的逻辑组,建模应用程序特定的逻辑主机。复制控制器确保任意时间都有特定数量的pod在运行。节点是支撑容器化环境的Google计算引擎虚拟机。 

GKE基于Google的Kubernetes容器编排平台。11月24号Kubernetes发布了1.1版本,1.0版本发布于四个月前,是市场里第一个能够使用水平pod自扩展特性来自动扩展pod的产品,该特性非常受用户欢迎,可以用来验证GKE很多用例的特性。

“我们为所有类型的项目大规模使用自扩展,”Tim Kelton说。他是Descartes Labs的联合创始人和云总架构师,这是一家总部位于Los Alamos, N.M.,机器学习领域的创业公司,处理PB级卫星数据。

当运行大批量工作时,自扩展pod非常有用,Kelton解释道。有时,他的公司处理PB级数据,要求扩展到30,000个内核。在Kubernetes的第一个版本里——很快就合并到GKE里,“这并不是核心特性集的一部分,”他说。

GKE不支持垂直容器扩展或者节点自扩展,但是这些特性很快就会发布,David Aronchick,GKE的资深产品经理说,他领导Kubernetes的产品管理。

同时,Amazon的EC2容器服务(ECS)包含服务、任务和实例。服务是一组组成应用的任务,而实例是支持容器的弹性计算云VM -- 更像GKE的节点。

Amazon ECS的自扩展能力和GKE的工作原理相反:服务能够使用Amazon CloudWatch和Amazon Web Services(AWS) Lambda自动扩展,而实例也能够基于CloudWatch矩阵自动扩展,但是任务——逻辑上大致等同于pod,不能自动扩展。

因为所有类型的自动扩展都很重要,Amazon的用户也希望ECS能够添加任务自扩展的功能。

“启动一个额外的实例意味着拥有了运行附加任务的额外能力,但是这并不意味着任何新任务都能够启动。”Chris Moyer,ACI Information Group的技术副总裁说。这是一家总部在纽约的Web内容聚合商,也是TechTarget的赞助商。“如果你仅仅自动扩展实例,其实对于处理额外负载并不会带来什么帮助——你必须确实启动额外任务才能真正实现扩展。”

zone间的冗余

在ECS的开发中,Amazon优先提供了在相同的集群内,原生启动可用zone(AZ)的能力,从而基于客户需求达到任务自扩展上的冗余。当ECS服务调度器启动新任务时,它也尝试自动在集群里跨AZ均衡任务。

"It's really easy -- two or three commands," he said.

“这样做很重要,因为单一的AZ可能出故障,因此如果两个任务都在同一个AZ里,你的服务很可能就会出故障,”Moyer说。

Google能够通过命令行接口(CLI)在GKE里启动多个zone,Google的Aronchick说。

“这其实很容易——两个或者三个命令,”他说。

但是,这也是GKE客户最希望拥有的功能列表:改进Web UI,包括跨zone扩展集群。

“UI还需要大量的优化工作,”Dale Hopkins,Vendasta Technologies的首席架构师说。UI目前只允许创建集群和一点点别的操作,Hopkins说。“并且扩展集群并不直观。”

交互性

ECS构建为一个扩展平台,设计出发点是入侵客户已有的工作流,主要代替用户处理集群状态。和已有工作流集成的一部分工作包括适应客户已经使用的工具,比如Apache Mesos来做高级调度。Amazon声称拥有广大的容器合作伙伴正在向Amazon ECS贡献特性,比如监控、持续集成和安全。

同时,Google已经构建了云容器合作伙伴联合体,允许Kubernetes跨多个云供应商部署——现在还是一个CLI特性,Aronchick说。去年夏天Kubernetes 1.0发布时,Google领导创建了Cloud原生计算基金会。基金会成员包括企业云服务公司,比如IBM和Red Hat,还包括终端用户Box,eBay和Twitter。

“使用Kubernetes,实际上能够部署到Amazon上,也可以部署Azure上,部署到IBM上,还可以部署到自己物理硬件的本地平台上,”Descartes的Kelton说。“这非常有吸引力,因为让用户有多种选择。”

Google还有一个开源项目,有上百个代码提交者,一个月有上千次提交,这使得Kubernetes能够快速添加新特性,比如水平pod自扩展。

“Google催生了Kubernetes,Google也很好地扩展了该社区,”Jay Lyman,451 Research的分析师说。

富人越富有

当然,和已经确定市场地位,大家都很熟悉的第二种Amazon服务的集成,使得Amazon ECS对于新客户而言更具吸引力。

一家总部位于纽约,给大型企业IT项目做咨询的公司计划在两个新项目里使用ECS,其创始人,John D'Esposito说。“驱动我们使用ECS的主要因素是和已有可靠的基础架构服务,比如‘Elastic Load Balancing(弹性负载均衡),Virtual Private Cloud(虚拟私有云),Identity and Access Management(认证和访问管理)和Elastic Block Store(弹性块存储)’的无缝集成。”

GKE和计算引擎的定价对于客户而言也很有吸引力。除了底层VM资源10分钟为单元的计费,GKE免费赠送Kubernetes master——这点对于Vendasta的Hopkins很吸引人。

“直到使用大量机器之前,我都不需要为Kubernetes支付太多——GKE为第一组机器免费提供Kubernetes master,”他说。

在Kubernetes和容器引擎出现之前,Hopkins和Kelton都已经使用过Google的云服务,包括Google App Engine。因此,在选择部署到哪种云容器服务商时,数据重力也是一大要素。

“我们的大部分数据都是PB级别的,因此无法轻松移动或者拷贝,实际上不得不让计算能力去靠近数据,”Kelton说。目前大部分数据都在Google云平台上,虽然Descartes也和AWS的合作伙伴合作。

虽然目前Google和AWS是云容器战场的急先锋,Amazon最大的竞争者仍然是Microsoft Azure,它已经发布了自己的基于Linux的云容器服务的受限预览版,今年还计划发布Windows服务器的新版本来支持基于Windows的容器。

“大部分我们的客户……也同时在使用Azure或者Amazon,”Chris Riley说,他是HKM Consulting公司的合伙人。“Microsoft已经正在开发一些很有意思的工具。如果我们考察第二种方案,很可能是Azure,而不是Google。”

因为很多Microsoft产品,简单化和易用性是设计优先考虑的事情,Kristian Nese说,他是Lumagate的CTO,这是一家位于挪威的Microsoft Azure系统集成商。

“现在,当我们部署Azure容器服务时,可能需要100行代码,”Nese说。“一旦你部署了Azure容器服务,实际上部署了23种资源……如果你想手动完成这些,很可能需要上千行代码。”

Azure容器服务也在开发自扩展功能,由一系列独立的服务组成,正在技术预览中,称为VM Scale Sets。

Azure也会提供成熟并且熟悉的工具来管理容器,比如Azure Resource Manager,Nese补充道








欢迎光临 开发者俱乐部 (http://xodn.com/) Powered by Discuz! X3.2