首页 > 云计算 > 正文

Amazon VS Google:云容器之争愈演愈烈

2016-03-03 15:44:33  来源:TechTarget中国

摘要:企业云容器服务将Docker容器管理的组件从用户处抽象出来,使得更为容易地部署以及扩展其上构建的应用。
关键词: Amazon Google
  自扩展是争论的焦点
 
  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补充道。

第三十五届CIO班招生
国际CIO认证培训
首席数据官(CDO)认证培训
责编:pingxiaoli

免责声明:本网站(http://www.ciotimes.com/)内容主要来自原创、合作媒体供稿和第三方投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。