Fargate 并非 Firecracker (2024)

# Fargate 并非 Firecracker 来源：https://justingarrison.com/blog/2024-02-08-fargate-is-not-firecracker/ ##### 发布于 2024年2月8日 • 阅读约3分钟 • 544字 这是我在 AWS EKS 团队工作时看到的最大误解。几乎每周都会有客户出于各种原因想使用 AWS Fargate，其中一个原因就是因为它采用了 Firecracker。不知为何——也许是 AWS 的营销宣传——人们认为这比传统的 EC2 Xen 虚拟化技术更优越。 而 AWS 内部竟无人纠正这个说法。 公司里存在一条不成文的规定：永远不要指出 Fargate 实际上并未使用 Firecracker 为每个容器创建"微型虚拟机"。就让客户们按照自己的理解来相信吧。当然，所有文档和博客文章都*听起来*像是 Fargate 使用了 Firecracker，但你必须字里行间细细品味，才能看穿公司如何引导人们相信某些并非事实的说法。 让我们看看主要文档页面(https://firecracker-microvm.github.io/)如何描述（重点为我所加）： > Firecracker 被开发...是为了改善像 **AWS Lambda 和 AWS Fargate 这类服务**的客户体验。 或者看看这篇2020年的博客：深入剖析 AWS Fargate 数据平面 (https://aws.amazon.com/blogs/containers/under-the-hood-fargate-data-plane/)。这篇文章肯定会阐明 Fargate 的真实技术构成——它确实这么做了。文章用了80%的篇幅解释 Fargate 已经脱离 Docker，现在使用容器化技术 containerd，但即便没有实际采用 Firecracker，它也不得不提及这项技术。 > Fargate **可以**利用基于虚拟机的容器运行环境，例如 Firecracker 虚拟机管理器，只需将 containerd 的运行时插件从 runC 切换为 firecracker-containerd 即可。 当然它*可以*替换 runC，但在亚马逊这样的规模下，这绝非"简单"操作。这里的"规模"指的是人员规模而非技术规模。其中涉及的组织政治问题比技术挑战要耗费更多精力。 ## 那么 Fargate *究竟*使用了什么？ 令人惊讶的是，Firecracker 文档页面在"为何开发 Firecracker？"章节就提供了相关信息。虽然这段文字描述的是 Lambda，但你可以看出 Fargate 很可能采用了相同架构。 > ...我们使用**每个客户独立的 EC2 实例**来提供强大的安全隔离性。 Fargate 是否保证容器间硬件隔离？并非如此。 Fargate 是否解决了 EC2 的"吵闹邻居"问题？并没有。 Fargate 是否在你和他人之间实现了硬件虚拟化隔离？是的，和 EC2 一样。 Fargate 是否通过免除操作系统管理来降低运维负担？并没有。运维负担只是转移到其他方面，比如"如何获取 EBS 卷或 GPU？"、"如何将所有守护进程迁移到边车容器？"以及"为什么这比 EC2 成本高这么多？"。 你将所有运维时间花在围绕 Fargate 的变通方案上，但至少不用再操心那些烦人的服务器了。🙄 ## 我需要在意这个吗？ 其实没必要。 如果它目前运行良好，那就继续用吧！你正好是他们打造的目标用户。 人们常以为 Fargate 是某种魔法，认为只有亚马逊才能实现这种特殊技术细节。 事实上， AWS 服务大多建立在 AWS 自身基础上，极少有幕后特殊技术实现。 只要别自欺欺人地高估它"移走的重担"有多少，以及这些重担只是被转移到了其他地方就好。 声明：我于2020年4月至2024年1月期间在容器和EKS团队工作。Fargate 的实现方式可能已发生变化，但某些未明言的真相依然如故。