提供Kubernetes原生支持 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的工程师们，那么这也将是一个很好的经验：跟随上游走才是正确的选择。