BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

提供Kubernetes原生支持 AWS将成更积极的开源玩家?

| 作者 杨赛 关注 3 他的粉丝 发布于 2017年12月1日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

2016年10月,Adrian Cockcroft以云架构师VP的身份加入了AWS。早在Adrian加入AWS之前,他在Netflix就已经与AWS打交道多年——当时,他作为Netflix的架构师主导了Netflix往AWS迁移的工作,这一项工作前前后后一共花费了七年的时间。

加入AWS一年的时间里,Adrian代表AWS大量参与开源社区的活动,几乎成了AWS的开源界头号代言人。他到九个国家的AWS Summit上演讲,在OSCon演讲,积极参与了Linux基金会下的Cloud Native Computing Foundation(CNCF),并作为AWS在基金会的列席董事积极参与Kubernetes项目,同时也密切关注并参与MXNet、FreeRTOS等多个开源社区。

“AWS团队在MXNet项目的贡献占比达到30%-40%。我们在TensorFlow项目也有代码提交,确保TensorFlow可以在AWS平台上很好的扩展。”

Adrian对InfoQ编辑介绍道。

“其实AWS从以前开始就对开源社区在做贡献了,只不过没人把这个故事讲出来。现在我就是这个讲故事的人。”

“我们确保绝不会把Kubernetes做成AWS自己的分支,我们一定会保证AWS平台上的Kubernetes与上游的兼容,并且将我们的工作全面反馈给上游社区。”

AWS CEO Andy Jassy在大会的主题演讲上正式发布了Elastic Container Service for Kubernetes(简称EKS)的预览版本。AWS的容器服务最早是在2014年公开发布的,那时的容器领域还没有形成今天这样的格局,Kubernetes是在之后的两三年内开始流行起来的。按照Andy Jassy提供的信息,早在EKS发布之前,AWS上面就已经跑了很多的Kubernetes部署(按照CNCF的数据,有63%的Kubernetes负载是运行在AWS上面的)。于是这里面就有很多用户表示:这个东西让我们自己部署其实还是有点麻烦的,如果AWS能提供原生的Kubernetes支持,那我们用起来就更省事了。

所以就有了EKS。

AWS在其官方博客上这样介绍EKS

  1. Amazon EKS与上游的Kubernetes完全兼容,任何你原来跑的应用、原来用的插件都不会受到任何影响。
  2. 使用Amazon EKS做部署,可以自动跨三个可用区域(AZ)部署三份Master,可用性很高。
  3. Amazon EKS能够自动检测可能有问题的master并将其替换,同时提供自动升级和补丁服务。
  4. Amazon EKS与其他AWS服务做了深度集成,比如ELB、IAM、VPC、PrivateLink、CloudTrail。

Kubernetes社区对此并不感到意外。开源社区老玩家、目前就职于红帽的资深软件工程师Gerard Braad表示:“大家都在等着这个东西发布呢。”作为Kubernetes的资深玩家,Gerard认为有了EKS之后的AWS“应该”会逐步丢弃自家原来的ECS,因为原来那套系统自成体系,有了EKS之后应该不会再有人想要去用ECS了。而且,Andy Jassy同时还宣布了Fargate(针对ECS的Fargate现在已经可用。针对EKS的Fargate将在2018年正式发布),Gerard认为这就更加没有ECS存在的必要了。

AWS技术布道师Randall Hunt在博客上这样介绍Fargate服务

以前,如果你部署了一个Kubernetes集群来管理你的容器们,那么你不仅要管理这些容器们,还要管理容器们用到的底层资源——比如EC2实例们的可用性、资源调度与维护。但是其实吧,你要一套Kubernetes集群是因为你需要容器,EC2并不是你需要的东西,这些底层资源的管理其实不是你的业务需求,而是你的额外负担。

所以AWS说:你别去管那些EC2啦,我们来帮你管理底层。这就是Fargate——从Kubernetes集群的层面来看,你现在直接找Fargate要资源,而不用去判断要去哪一台EC2实例要资源:

Fargate同时集成了VPC,这就意味着在Amazon的私有云里也可以使用。Fargate还集成了IAM、CloudWatch、LB服务,并且提供了命令行(CLI)的控制工具。

以上,可能是关注Kubernetes的读者们在本次AWS re:Invent上最关心的消息。

从另一个角度来看,在开源技术的世界里(尤其是底层技术栈的开源项目们),我们会看到更多来自AWS的贡献吗?

Andy Jassy今年的主题演讲上说过一句话,这几乎是一句他每年都会说的话,大意是:我们不是因为某个技术很酷而去做一个功能,我们做功能是为了解决问题的。

对于Kubernetes的情况而言,它比ECS更流行,更受到开发者们的拥护,所以AWS去主动拥抱、迎合Kubernetes是完全合理的。作为迎合的一方,你只有做到跟那个大家都想用的东西完全没差别,别人才敢来用你,所以AWS必须打包票说“我绝对不fork”,这是一个合理的决策。

对于MXNet的情况而言,它在当下的影响力与Tensorflow相比是这样的:

AWS在MXNet项目上大力投入,因为AWS想要让MXNet项目更多能够按照自己想要的方式去发展——这是他们在Tensorflow项目上做不到的事情。至于这个目的的动机,你可以往竞争、占地盘的方向理解,也可以往好的方向理解——比如,说不定AWS是真心觉得MXNet可以在某些场景成为一个更合适的框架,而他们在MXNet上的努力可以为数据科学领域/AI领域带来更大的价值。无论是哪种动机,AWS在MXNet项目上的大力投入也是一个合理的决策。

AWS在IoT操作系统FreeRTOS项目上的大力投入也很容易理解,因为在当前的IoT领域,未来形势仍然很不明朗,此时一个优秀的开源OS项目如果能发展出可观的开发者生态,这个价值无法估量。对于任何一个有志于成为主流IoT平台服务商的企业来说,花大力气做开源OS和工具链是必然,不做才是难以理解。

所以,上面覆盖了两种情况:

  1. 一个大家都想用的非AWS主导的开源项目,迎合上游更有利于发展用户
  2. 一个AWS迫切希望大家都来用的开源项目,快速完善功能与工具链更有利于发展用户

而传统上,大家觉得说AWS在开源领域贡献不大,主要是Linux内核、Xen或者KVM这些项目。说他们贡献不大也不算冤枉他们,因为当我们罗列这些开源项目的贡献者名单时,amazon.com的邮箱后缀实在是太少出现了。这几个开源项目对AWS而言,并不属于上述两种情况的任何一种,而是第三种情况:

3. AWS自己是这些开源项目的深度用户。

深度用户去给开源项目反馈、贡献代码的诉求一般是这样的:因为我是深度用户,我因为自己的业务需求把你这个项目的代码给改了。同时,我这个业务是要长期运行、要长期与时俱进的,所以你这个项目未来的更新我还希望能够及时跟进。所以,我希望你这个更新的时候,能把我之前做的变更带上,这样我会省很多事。否则的话,当时间过得越长,这一坨代码的维护成本就日积月累,对我来说太恐怖了。

或者说,对于缺乏自动化代码维护系统的用户而言,这种维护工作太恐怖了。

而AWS这套体系的代码维护能力,放眼全球,如果它说自己第二,谁敢说自己是第一呢?所以以InfoQ编辑看来,如果我们未来没有看到AWS在Linux内核、KVM这些项目上的大量贡献,这也不奇怪。而如果我们看到哪天,Linux内核的贡献者忽然出现了很多来自Amazon的工程师们,那么这也将是一个很好的经验:跟随上游走才是正确的选择。

以上是来自InfoQ中文站记者的前线报道。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT