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

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 中文站记者的前线报道。