AWS 中的容器编排：ECS、Fargate 和 EKS 的比较

在深入研究 AWS EKS（AWS 托管的 Kubernetes 产品）这个新宠之前，您可能需要了解它的底层工作原理，并与现有产品进行比较。在本文中，我们将重点介绍不同的 AWS 容器编排解决方案，即 AWS ECS、Fargate 和 EKS，并比较它们的优缺点。

介绍

在深入比较之前，让我们先总结一下每种产品的含义。

ECS是 AWS 提供的首个容器编排工具。它本质上由已安装 Docker 的 EC2 实例组成，并运行一个与 AWS 后端通信的 Docker 容器。通过 ECS 服务，您可以启动任务（通常适用于短期操作的未监控容器）和服务（AWS 监控的容器，如果因任何原因宕机，AWS 保证会重新启动）。与 Kubernetes 相比，ECS 更加简单，这既有优点也有缺点。

Fargate是第二款即将推出的服务，旨在将容器（容器运行所在的 EC2 实例）下的所有组件抽象出来。换句话说，它是一款纯粹的容器即服务 (Container-as-a-Service)，您无需关心容器的运行位置。Fargate 沿袭了 ECS 的两项核心技术进步：能够直接分配专用于容器的 ENI，以及在容器级别集成 IAM。稍后我们将对此进行更详细的介绍。

以下来自AWS 博客的图片说明了 ECS 和 Fargate 服务之间的区别。

EKS是最新推出的产品，目前仍仅在某些区域可用。使用 EKS，您可以简化启动 Kubernetes 集群的部分复杂性，因为 AWS 现在将管理主节点（即控制平面）。Kubernetes 是一个功能更丰富的容器编排器，提供网络覆盖等功能，允许您隔离容器通信和存储配置。毋庸置疑，它的管理也更加复杂，需要 DevOps 方面的投入也更大。

与 Kubernetes 类似，您也可以使用 kubectl 与 EKS 集群通信。您需要在本地配置 AWS IAM 身份验证器才能与 EKS 集群通信。

成本

让我们从成本开始，这是软件开发人员最喜欢忽视的首要因素。

ECS是一项简单的服务，其控制平面被 AWS 抽象化。您只需启动工作节点，这些节点由安装了 Docker 的 EC2 实例和一个正在运行的容器守护进程组成，该守护进程包含最少的元数据，用于了解自身所属的集群，并接收来自 AWS ECS 控制平面的指令。因此，使用 ECS 时，您只需按工作节点（即 EC2 实例）付费。

Fargate将容器托管平台（EC2 实例）从您的服务中抽象出来。这显然意味着，与 ECS 相比，您需要为每个容器支付更高的费用。因此，Fargate 中每个容器的成本自然会更高。另一方面，为了与纯 ECS 进行公平的比较，您还应该考虑与 ECS 相关的维护成本。用于故障排除、升级 ECS 实例代理、更新 EC2 实例包等工作的时间都会转化为工资。因此，这些成本不应被忽略。

EKS是 Kubernetes 的底层组件，需要主节点始终运行以监控集群（即 EKS 控制平面）。此功能并非免费提供，专业集群最低价格为每小时 0.20 美元，相当于专业版每月 144 美元。这仅仅是开始试用，无需任何工作节点。从现在开始，您只需为为工作节点启动的 EC2 实例支付正常价格，就像 ECS 产品一样。

自动缩放

ECS允许您在任务级别进行扩展。请记住：一个任务可能包含一个或多个容器。与 EC2 类似，您可以配置规则来扩展正在运行的任务数量。但是，这些容器运行在 EC2 实例上，而这些实例可能没有可用的 CPU 或 RAM 资源。因此，在实践中，这里的技巧是在 ECS 集群级别定义另一个自动扩展规则，您可以根据集群上的 CPU 或 RAM 预留来定义扩展或缩减。

正如预期的那样， Fargate使自动扩展变得更加容易。在这里，您只需在任务级别进行定义即可。

有关 ECS/Fargate 自动扩展的更多信息，请参见此处。

最近， AWS 为 EKS 引入了与 Kubernetes 水平 Pod 自动扩缩器 (HPA) 的集成。与 ECS 类似，这允许您在 Pod 级别进行扩展，这意味着您还需要在 EC2 级别进行扩展以支持 Pod 的增长。更多关于HPA 入门的信息，请点击此处。

此外，如果您已运行 EKS 集群，请确保您的EKS 版本支持 HPA。所有新的 EKS 集群都将搭载平台版本 eks.2+，这意味着在撰写本文时，它们已经支持 HPA。

现在让我们从技术上更深入地探讨区分这三种服务的三个主要网络方面。

网络：流量负载均衡

在 AWS 将 EKS 与其更复杂的负载均衡器（即应用程序负载均衡器和网络负载均衡器）集成之前，从网络角度来看，流量流动仍然非常低效。由于 EKS 仅支持经典的 AWS ELB，流量在 EC2 实例之间随机且盲目地分配，并且容易出现多跳传输。

ECS 和 Fargate 均可与 AWS ALB 和 Network LB 无缝集成，让您能够直接指向目标容器。Cloudnout 在其博客文章中就此主题提供了非常精彩的说明。

网络：ENI

能够直接将网卡分配给容器乍一看似乎没什么大不了的。然而，这实际上意味着更高级别的安全性。这样，您就可以为该容器分配专用的安全组，而不是简单地为整个集群开放所有端口。

使用ECS，您可以选择以“awsvpc”模式启动任务，将 ENI 直接与容器关联。然而——总有一个“但是”，不是吗？——每个 EC2 实例可分配的 ENI（虚拟网卡）的最大数量因 EC2 类型而异；有人可能会说，目前 ENI 的数量相当有限，在 2 到 15 之间。因此，如果您运行大量小型容器，这种情况实际上意味着创建一个由小型 EC2 实例组成的非常大的 EC2 集群。以下列表佐证了这一说法。

另一方面，使用 EKS，您可以选择为容器组（Kubernetes 中称为 Pod）分配专用网络接口。这意味着该 Pod 内的所有容器将共享同一个内部网络。不过，好消息是，每个实例最多可以放置 750 个 Pod。这对 EKS 来说是一个更大的优势。

网络：服务发现

AWS最近推出了 ECS/Fargate 的服务发现功能。这是 ECS 与 Kubernetes 相比的一个关键区别，后者使用网络覆盖来实现本质上的容器级 DNS。

但需要注意的是，只有在“awsvpc”网络模式下启动的容器才支持此功能。

安全策略控制（AWS IAM 集成）

回到安全话题，ECS/Fargate 的另一个优点是可以分配专用于容器的 IAM 实例配置文件。这些策略具体指什么呢？基本上可以访问所有其他 AWS 资源，例如 S3 存储桶、数据库/数据仓库（例如 DynamoDB、Aurora、Redshift）、队列系统（例如 SQS 和 Kinesis）等等。你懂的。

同样，这里的论点类似于 ENI：在容器级别分配专用 IAM 角色比在 EC2 实例级别安全几个数量级。

ECS 和 Fargate 允许您在容器级别指定权限。目前，EKS 不允许您这样做。这意味着您只能在 Workers/EC2 级别限制权限。

容器注册表 - AWS ECR

这里没有什么特别的：正如预期的那样，所有服务都与 AWS 容器注册表集成，允许您从内部 AWS 注册表中提取。

概括

总而言之，ECS 和 Fargate 与 AWS 生态系统的集成更加紧密。另一方面，Kubernetes 与通用开源生态系统的集成更加紧密，也让你能够更加不受云供应商的限制。

与往常一样，这里汇编了一些用于撰写这篇文章的有用资源，希望对您有所帮助：

鏂囩珷鏉ユ簮锛�https://dev.to/diogoaurelio/container-orchestration-in-aws-comparing-ecs-fargate-and-eks-56d1