聊聊 AWS Fargate 在容器世界中的角色定位

Original URL：https://thinkwithwp.com/cn/blogs/containers/the-role-of-aws-fargate-in-the-container-world/

2017年，我们正式推出AWS Fargate，一项以无服务器架构实现大规模容器运行的服务。今天，客户每周都在这项服务之上运行数千万个容器，Fargate也帮助他们摆脱了以往繁重且枯燥的基础设施管理负担。如今，客户再不需要为自己的EC2队列或容器运行时设定大小、调整规模、安装补丁或者执行更新。

但在过去两年当中，我们也意识到Fargate作为一项全新服务仍然有着较高的适应门槛。不少客户发现自己很难将Fargate与其他AWS容器产品组合进行顺畅对接。在AWS，我们专注于为客户打造能够解决实际问题的服务，但同时也坚信只有在客户与合作伙伴当中建立起对AWS服务的深入理解与明确认知，才能真正集合各方之力推动AWS达成预期的发展愿景。

在本文中，我们不会深入探讨Fargate架构，而是以宏观的视角对项目的整体路线图做出阐述。文章的讨论重点，将集中在Fargate“产品性”与Fargate“技术性”之间的差异，以及如何将其与更广泛的容器生态系统匹配起来。其中将涉及AWS Fargate中的一系列关键因素，特别是如何在Fargate产品与其他容器服务（例如Amazon Elastic Container Service，简称ECS；以及Amazon Elastic Kubernetes Service，简称EKS）关联起来。

AWS Fargate项目的来历

如果不回顾项目的起源，我们自然无法准确评估Fargate的未来发展方向。一切要从Docker说起，当这项技术在2013年诞生之时，客户的容器技术使用方式迎来了彻底颠覆。当时，用户的主要生产力平台仍然是笔记本电脑；换句话说，当时大多数开发人员都在笔记本电脑上运行容器技术以提升个人生产力。结合这一背景，本文也将以个人计算机为基础，具体探讨容器的“docker run”议题。

随着时间的推移，人们开始意识到容器技术的强大功能，并开始将其从笔记本电脑（用于个人测试及开发场景）转向云端，借此运行各类生产级应用程序。为了实现这种转型，我们自然需要一种能够超越笔记本电脑加单一容器这种传统组合的全新“docker run”方法。

而这，就是所谓“容器编排工具”的历史使命。Amazon ECS于2015年亮相，成为AWS推出的首批托管云服务之一。约在同一时间，Kubernetes也正式转为开源项目。

与早期的Docker相比，容器编排工具到底有什么新能力？简而言之，编排工具拥有以下两项主要作用：

• 容器编排工具引入多项功能与构造，不仅能够帮助客户更轻松地运行容器（例如实现容器生命周期自动化，并将容器与更高级别的「服务」或「部署」相关联），同时也让容器能够通过特定的网络模型与集群内外保持通信。到这个时候，ECS任务与Kubernetes容器开始成为人们普遍使用的基础部署单元。
• 容器编排工具中的功能与构造还让客户得以将服务与部署同容器运行（以ECS任务及Kubernetes Pod的形式运行）所需要的底层功能彼此解耦。换句话说，编排工具负责执行任务与Pod调度，并将这些具体负载表示为运行在虚拟机上的一组容器。此外，编排工具还能够有效参与甚至全面接管底层功能的扩展任务。

下图所示，即容器编排工具中的两个基本维度：包含「服务」与「部署」（上行）概念的高级定义，以及虚拟机上基于任务及容器调度机制的功能抽象（下行）。

服务抽象与基础设施抽象

从上图中可以看到，编排工具负责管理标准容器部署工作流中的大量活动部分。在ECS场景当中，我们可以将其具体理解成两个映射着不同功能丰富度的API："RunTask" API与"CreateService" API。

大家可以将"RunTask" API理解为在账户内分布式EC2实例fleet上运行任务（可能包含一个或者多个容器）的功能（下行功能）。相较于以往在笔记本电脑上运行容器，这显然是种全新的“docker run”方式，其中任务运行在ECS集群中的某一可用虚拟机之上。

另一方面，我们可以将"CreateService" API视为上行功能的表示形式，这部分功能与多种任务组合起来，共同通过负载均衡器为公开应用服务提供支持。Docker当中没有能够与之直接映射的原语，这是因为"CreateService" API本身属于编排工具引入的高级抽象。"CreateService" API还作为"RunTask"API的消费方，借此保证应用程序拥有与预期相符的运行状态。

当然，ECS还提供其他多种功能与API。但为了易于理解，我们在本文中只使用"CreateService"API与"RunTask" API来表示这些编排工具层：前者更接近高级应用抽象，而后者更接近低级基础设施抽象。

例如，当我们谈到"CreateService" API时，指的是包括原子任务编排在内的所有相关机制。其中可能包括用于支持各项服务运行的对应任务指令、在集群内各虚拟机上运行单一任务的对应指令，或者负责在服务内实现任务规模伸缩的配置等。

而在谈到"RunTask" API时，我们指的则是通过各类复杂调度算法将特定任务运行在集群内某一虚拟机之上，同时对集群内虚拟机数量进行规模伸缩调整的所有相关机制。虽然说起来简单，但其中相当一部分集群规模伸缩算法，在以往需要大量人力配合繁重的配置操作才能实现。

走进AWS Fargate

在推出新的AWS服务时，我们一般会选择以新的API以及控制台（如果可以）来实现。但在推出Fargate服务时，我们并没有提供任何新的控制台或API。这可能令不少用户感到困惑，并花了大量时间进行消化整理。也正是这一点，让用户们真正开始思考和理解“产品”与“技术”之间的区别。

Fargate是一套用于运行容器的无服务器环境，能够帮助用户彻底摆脱计算基础设施在整个生命周期内带来的采购、运行与管理需求。我们可以将Fargate视为一种具有云规模的纯弹性计算资源，无需考虑边界因素，即可在弹性算力之上运行各类任务与Pod。

换句话说，Fargate能够直接消除以往只能由容器编排工具解决的大多数（甚至是全部）下行功能需求：如何将离散的虚拟机转化为可根据具体情况进行规模伸缩的简单资源池，以及如何对不同任务及Pod进行调度等等。

到这里，我们迎来了项目的发展十字路口。“技术”已经开发到位，而且看起来颇具潜力；但我们该如何以技术为基础真正构建起“产品”？我们要如何让Fargate完成落地，帮助客户轻松使用由其带来的下行功能？

当然，我们可以引入新的专用Fargate API（例如RunFargateContainerGroup），并在运作方式及使用效果等方面全面与ECS RunTack API看齐。

或者，我们也可以将Fargate直接纳入RunTask API之内，让它转化为“Fargate API”。

我们最终选择了后者。实际上，大家现在也可以将RUnTask API与"--launch-type"配合使用，借此区分您的任务到底是运行在账户中的EC2实例上、还是运行在由AWS托管的Fargate fleet当中。下面来看Fargate服务的简单架构示意图：

如果大家希望了解关于Fargate底层工作原理的更多详细信息，我们强烈建议您观看re:Invent 2019上的相关内容，其中对Fargate做出了深入阐述。

使用RunTask API构建Fargate“产品”的优势之一，在于Fargate能够借此直接使用ECS提供的各类高级（上行）功能。

我们虽然高度关注如何帮助客户解决问题，但同时也意识到将Fargate“技术性”与Fargate“产品性”做出如此明确的区分，确实有可能在使用者群体中引发误解与争议。

很多用户提出“我们选择的是Fargate，而非ECS”或者“我们需要思考到底是选择Fargate还是ECS”这类问题。答案到底是什么？很难讲。

有些人倾向于将Fargate“产品”及其解决的上行问题进行过度解读，并把高级上行应用程序抽象认定为Fargate产品的自然扩展方向。通过这样的理解，他们人为把Fargate与专门负责处理集群内各离散EC2容器实例的ECS对立了起来，强调“上行用Fargate，下行用ECS。”

但也有些用户过度强调上行ECS服务定义层所能解决的具体问题，认为自己使用的这类栈仍然属于“ECS”的范畴。以此为基础，Fargate的“技术”实际上属于EC2的一种替代方案，或者说是立足于所运行任务之上的额外数据平面。顺带一提，我们一直在努力降低EC2集群的管理难度。ECS最近刚刚引入了ECS Capacity Providers，帮助客户在提升EC2实例管理效率的同时将其与ECS集成起来。如果大家希望了解关于这些功能的更多详细信息，请参阅re:Invent 2019深度分析。

集成Amazon EKS与Fargate

在re: Invent 2019大会上，我们宣布对Amazon Elastic Kubernetes Service（EKS）与AWS Fargate进行集成。这在业界引起了有趣的讨论，以往热衷于比较“要Fargate还是要ECS”的用户们纷纷表示摸不着头脑。

我们原本以为可以使用虚拟kubelet项目轻松实现这种集成，但却很快意识到如果沿着这个方向推进，将无法兑现坚持在上游使用Kubernetes的承诺。为此，我们决定按部就班建立集成机制，并继续使用Kubernetes中的现成标准扩展机制，包括webhook突变并提供自定义调度程序等。

在这种情况下，由于Kubernetes中不存在无服务器概念，而且始终假定存在一个节点，因此Fargate将充当由AWS拥有并托管的算力自动售货机。Fargate负责以虚拟机的形式将基础设施资源交付给EKS集群。这些虚拟机配备有所需的各类Kubernetes代理，可即时接入集群，可用于调度运行在Fargate上的各K8s Pod。正因为如此，当大家在Fargate上启动K8s Pod时，会看到Fargate会向EKS集群提供专用的“工作节点”。

经过此次集成，客户们很少会强调自己在使用“Fargate”了；相反，他们开始提到自己在使用“带有Fargate数据平面的EKS”。下面来看新架构的高级简单表示：

运行在EKS上的Kubernetes自定义调度程序负责将上游Kubernetes集群同容器无服务器数据平面（即Fatgate）的特定AWS实现剥离开来。通过上图可以看到，我们在EKS上部署的自定义Fargate调度程序会通过调用"RunTask" API以调度Pod。

下图为re:Invent 2019深度分析当中使用的演示文稿之一，可以看到这一解耦过程的更多详细信息。除此之外，我们可以看到当一项标准Pod定义被发送至Kubernetes API端点时，Fargate之上的定义突变、发送至自定义调度程序以及实例化等具体过程。

图中的第4步，为调用外部“RunTask” API时的情况：

总体而言，“RunTask” API仍然能够与Fargate直接集成，并以即服务形式消费核心无服务器容器运行时提供的各项功能。举例来说，EKS团队可以通过这样的方式将Fargate作为EC2上的额外Kubernetes数据平面使用。

认知即现实

我们在开头已经提到，今天的文章希望向大家分享我们在EKS、ECS以及Fargate定位方面的一些思考，借此消除用户当中普遍存在的一些技术性误解。但必须承认，这本身更多属于认知问题，而认知与态度有时候也会反过来影响技术成果的具体定位甚至是发展方向。

不少客户将Fargate当成对业务问题的直接解决方案，而且高度赞赏Fargate以多语言形式支持多种应用程序定义语义（ECS与Kubernetes）的特性。这部分用户，更多将Fargate视为自己能够直接使用的实际产品：

但也有一部分用户认为Fargate这款容器编排工具提供的上行功能，才是其核心能力的关键所在。在他们看来，Fargate更像是一种替代性的数据平面技术：

认知即是现实。以上两种方式，其实就是从不同的角度审视完全相同的技术能力，其中没有对错之分。

总结

在本文中，我们从宏观层面介绍了AWS Fargate的技术背景与开发权衡，特别是其与AWS容器产品组合（即ECS与EKS）内其他技术的关系。之前我们曾反复强调，虽然AWS一直以解决客户的实际问题为己任，但也同样重视对技术栈内各个环节与元素的剖析与定位。只有以不同方式重新整合这些环节与元素，技术成果才能真正发挥其全部潜能。如果您身为AWS技术合作伙伴，那么只有明确理解Fargate项目的本质，才能够与其顺利集成。面对莫衷一是的争论，希望本篇文章能够给大家一点启发。当然，如果您还不熟悉AWS Fargate，请点击此处阅读入门教程。

本篇作者