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

jack

企业云容器服务将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补充道