ECS 与 EKS：哪种 AWS 容器服务更适合您？

什么是 ECS？

ECS 是 Amazon 的专有托管容器编排服务。它为运行容器化应用提供一种简单且安全的方式。ECS 以简洁为设计目标，在不牺牲规模与功能的前提下，减少用户在计算、网络与安全配置方面的决策负担。

使用 ECS 需要先熟悉一些术语与组件。

1. 集群（Cluster）
2. 容量提供程序（Capacity provider）
3. 任务定义（Task definition）
4. 任务（Task）
5. 服务（Service）

集群

ECS 集群由服务、任务与容量提供程序组成。它还包含由 AWS 托管且对我们不可见的 ECS 控制平面。

容量提供程序

容器需要在某台服务器上运行，无论是云中的虚拟机还是您的本地计算机。在 ECS 的语境中，您可以选择“启动类型”（Launch Type），将容器运行在 Elastic Compute Cloud（EC2）或 Fargate 上。

AWS ECS 控制台的基础架构选项卡。

任务

任务是根据任务定义配置后正在运行的一组容器。从本质上讲，它代表任务定义的一个实例，类似于容器是镜像的一个实例。

任务定义

我们为应用编写了一个 Dockerfile，并由此创建了镜像。我们把镜像推送到了 DockerHub 或 AWS ECR 等容器镜像仓库。接下来呢？我们会创建一个任务定义，它是我们容器（将在 ECS 集群上部署）的配置蓝图，包含如下信息：

• 镜像。一个任务可以包含多个镜像。
• 用于与应用通信的端口号。
• 卷（Volumes）。
• 为应用预留的资源（CPU 与内存）。

AWS ECS 控制台中的任务定义。

服务

当我们运行一个独立容器且它崩溃时，会发生什么？什么也不会发生。它会保持在崩溃状态。如果我们在 ECS 上创建一个独立任务，行为也相同。我们使用 ECS 服务来确保应用始终可用。服务会确保任意时刻都有期望数量的任务在运行。

如果某个任务崩溃，或承载它（以及容器）的底层服务器宕机，服务会在可用的容量提供程序中创建一个新任务。

ECS 的实现

现在我们已经了解了 ECS 的基础知识，让我们运行一个简单的 Nginx 镜像并访问它。借助上面的 ECS 集群与任务定义，我将创建一个引用该任务定义的服务：

AWS ECS 控制台中的服务。

该服务随后会创建一个任务。

AWS ECS 控制台中的一个任务。

访问该任务的公有 IP 地址：

成功访问运行在 ECS 上的应用。

什么是 EKS？

在深入了解 Elastic Kubernetes Service（EKS）之前，先了解一下 Kubernetes。Kubernetes 是一款开源的容器编排引擎，可自动化容器化应用的部署、扩展与管理。

想进一步学习，建议查看 Introduction to Kubernetes 课程。

然而，从零开始引导并管理一个 Kubernetes 集群既复杂又耗时。搭建 Kubernetes 所需的诸多组件与配置在不同组织与团队之间具有很高的相似性。为抽象这些无差异化的繁重工作并简化 Kubernetes 的采用，AWS 推出了 EKS。

EKS 是 AWS 提供的托管式 Kubernetes 服务，可处理大量运维开销。它代替用户管理控制平面，从而简化 Kubernetes 的部署、扩展与管理。通过抽象对这些组件的管理需求，Amazon EKS 使用户能够专注于运行其容器化工作负载，并管理工作节点，或使用 AWS Fargate 实现无服务器计算。

本节仅对 EKS 作简要介绍。欲了解更多内容，请参阅文章 Fundamentals of Container Orchestration With AWS Elastic Kubernetes Service (EKS)。

在 EKS 中，您需要先熟悉一些术语与组件：

1. 集群（主节点与工作节点）
2. 清单文件（Manifest files）
3. Pod
4. ReplicaSet
5. kubectl 命令行工具

集群

Kubernetes 集群是一组服务器或虚拟机，Kubernetes 工作负载在其上运行。它由主节点（通常称为控制平面）与工作节点组成。

在 EKS 中，主节点由 AWS 在其自有 VPC 中进行托管，对我们而言是抽象出来的。与此同时，我们可以通过 EC2 实例管理工作节点，或使用 Fargate 走向无服务器。

EKS 控制平面网络连通性。 图片来源： AWS

Pod

Pod 是一种 Kubernetes API 资源，是 Kubernetes 中最小的可部署单元。它是一组一个或多个容器，并包含所用镜像、端口、命令等规范。

AWS EKS 控制台中的资源选项卡。

ReplicaSet

与 Pod 类似，ReplicaSet 也是一种 Kubernetes API 资源。它确保始终有期望数量的 Pod 在运行。

清单文件

Kubernetes 清单文件用于以声明式方式定义 Kubernetes 资源的期望状态。这些文件描述了集群中应存在哪些资源、它们的配置，以及彼此如何交互。

清单文件通常使用 YAML 编写：

# pod.yml - Pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.27
    ports:
    - containerPort: 80技术支持

# service.yml - Kubernetes Service manifest
apiVersion: v1
kind: Service
metadata:
  name: nginx-node-port-service
spec:
  type: NodePort 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 80
      nodePort: 31000技术支持

kubectl

用于与 Kubernetes 集群通信的命令行工具。我们可以使用 kubectl 命令以命令式方式创建、管理与删除 Kubernetes 资源，或配合清单文件以声明式方式进行管理。

# Create a pod that runs a container with the nginx:1.27 image
kubectl run nginx-pod --image nginx:1.27 
# Create a replicaset with 2 pods
kubectl create replicaset --replicas=2 --image nginx:1.27技术支持

EKS 的实现

下面我们通过运行并访问同一个 Nginx 镜像来演示 EKS 的工作方式。

为保持简洁，我将在公有子网中创建一个 EC2 实例/工作节点，在其上部署应用，通过类型为 NodePort 的 Kubernetes Service 资源对外暴露，并通过该实例的公有 IP 访问。

我将使用上面的 Pod 与 Service 清单，并通过 kubectl 命令来创建 Pod：

# Update local .kube/config file
aws eks update-kubeconfig --region ap-southeast-1 --name i-love-datacamp-eks-cluster
# Create the pod
kubectl create -f pod.yml
# Create the service
kubectl create -f service.yml技术支持

该 EKS 集群有一个 EC2 实例：

EC2 实例/工作节点。

找到该实例的公有 IPv4 地址。

EC2 实例/工作节点的公有 IP 地址。

通过该实例的公有 IP 与端口 31000 进行访问：

成功访问运行在 EKS 上的应用。

 

ECS 与 EKS：相似之处

了解了 ECS 与 EKS 的基础后，我们可以看到它们之间的一些相似点。这并不意外，因为二者都是容器编排工具。

计算容量

两项服务都允许应用运行在 EC2 上，在这种模式下，用户需负责维护、打补丁与升级 EC2 实例；也可以运行在 AWS Fargate（无服务器计算选项）上，由 AWS 管理底层服务器，从而免去基础设施管理。

工作负载管理模型

两项服务在管理与维护应用资源的结构与方法上有相似之处。

在 AWS ECS 中，定义容器运行方式的配置称为任务定义；在 AWS EKS 中，则通过 Pod 清单文件来实现。部署完成后，容器化应用在 ECS 中运行于任务（Task）内，而在 EKS 中运行于 Pod 内。为确保始终有指定数量的任务或 Pod 在运行，ECS 使用服务（Service），而 EKS 则依赖 ReplicaSet 来实现这一功能。

与其他 AWS 服务的深度集成

作为 AWS 上的容器服务，Amazon 致力于确保 ECS 与 EKS 能很好地与其他 AWS 服务集成。

在网络方面，有 Amazon VPC，可让容器在隔离环境中运行，并对网络配置、安全组与子网进行完全控制。还可使用负载均衡器将流量路由至容器。

针对持久化存储需求，可使用 EBS、EFS 与 S3 等方案为容器化应用提供支持。

两项服务均使用 AWS IAM 对访问与权限进行细粒度控制。这决定了容器化应用可访问哪些 AWS 资源，如 S3、DynamoDB 或 RDS。

关键相似点概览

ECS 与 EKS：差异

在二者之间做出选择时，了解 Amazon ECS 与 Amazon EKS 的差异至关重要。

本节将从易用性、可扩展性、定制化与成本等核心方面进行拆解，帮助您判定哪个服务更契合您的技术需求与业务目标。

易用性与学习曲线

EKS 构建于 Kubernetes 之上，因此需要熟悉 Kubernetes 的概念与工具。相较于 ECS，EKS 的学习曲线更陡。这涉及理解 kubectl 命令的工作方式，以及一些其他基础的 Kubernetes API 资源，如 Service（注意不要与 ECS 语境中的“Service”混淆）、ConfigMap、Ingress 等。上文“什么是 EKS”一节仅是对 EKS 功能的浅尝辄止。

ECS 与 EKS 都需要了解 AWS 的相关服务，如 CloudWatch、IAM、ASG 等。幸运的是，掌握这些基本知识对使用 ECS 已足够，但对 EKS 则不然。因此，就易用性而言，ECS 更占优势。

可扩展性

两项服务在正确配置后都具备同等出色的扩展能力。但它们的扩展方式不同。ECS 通过 ECS Service Auto Scaling（针对任务）与 ECS Cluster Auto Scaling（针对实例）实现自动扩展，且仅使用 AWS 原生服务，如 CloudWatch 指标与 ASG 扩展策略。

而 EKS 使用 Kubernetes 原生的扩展特性，如用于 Pod 的 Horizontal Pod Autoscaler（HPA）与用于实例的 Cluster Autoscaler。Cluster Autoscaler 并不会在 EKS 集群中默认安装，因此需要用户自行安装。这会增加复杂度，因为为使其工作，需要在 AWS 资源（如 IAM 角色）与 Kubernetes API 资源（如 ServiceAccount）两侧进行正确配置，以便其通过调用 AWS API 实现扩缩容。

EKS 最近推出的 AutoMode 新功能可缓解这部分复杂性。它将 EKS 工作节点的管理与扩缩容交由 AWS 处理，但会带来额外成本。

灵活性与定制化

如前所述，ECS 是 Amazon 的专有托管容器编排服务，旨在提供简洁体验。AWS 负责大部分集群管理任务，并提供适用于常见容器工作负载的预定义配置，但可能无法满足小众需求。虽然这降低了复杂度，但与 Kubernetes 相比，定制化选项更有限。

EKS 提供了 Kubernetes 的全部能力，用户可根据需要定制部署、Pod 调度、存储类与网络策略。通过自定义资源定义（CRD）与 Operators 等高级编排特性，EKS 在应用设计上实现了无与伦比的灵活性。

EKS 还可与 Kubernetes 生态的各类开源工具与插件集成，如 Prometheus、Grafana 与 Istio，使开发者能够构建高度定制化的解决方案。因此，在灵活性与定制化方面，EKS 胜出。

成本

除了两者共同适用的网络资源（如公有 IPv4 地址、NAT 网关）以及计算与存储资源（如 EC2 实例、Fargate 与 EBS 卷）的标准费用之外，ECS 成本更低，且成本结构更为直观。

ECS 控制平面不收费。换言之，如果您仅创建了一个没有任何运行任务的 ECS 集群，将不会产生费用。相较之下，EKS 的 AWS 托管控制平面即便在 Kubernetes 集群内没有运行任何应用，也会产生费用。

EKS 控制平面的费用取决于所用 Kubernetes 版本。处于标准支持期的版本费用为每个集群每小时 0.10 美元，处于延长支持期的版本费用为每个集群每小时 0.60 美元。

关键差异概览

何时选择 ECS？

选择取决于您应用的需求、业务目标、团队专长、运维预算与整体优先级。

ECS 更简洁、性价比更高，适合预算更紧、上市周期更短、偏好精简运维的团队。对于不需要在多云或混合环境中实现可移植性、且专为在 AWS 上运行而设计的应用，ECS 尤其契合。作为 AWS 专用服务，ECS 能与限定在 AWS 生态内的工作负载无缝对接。

尽管 ECS 与 EKS 都支持使用 Fargate 进行无服务器容器部署，但 ECS 的集成更为直接。在 ECS 中，您可以直接选择在 Fargate 上运行任务，无需额外配置。相比之下，在 EKS 中使用 Fargate 需要通过指定 Pod 标签来确定哪些工作负载运行在 Fargate 上，这会增加一定复杂度。对于追求更简单无服务器体验的团队而言，ECS 具备吸引力。

何时选择 EKS？

作为 EKS 的底层平台，Kubernetes 与云无关，可使工作负载在 AWS、其他云服务商以及本地环境中保持一致运行。对于采用多云或本地混合架构的组织而言，这种可移植性尤为有利。Azure 与 Google Cloud 也提供托管式 Kubernetes 服务——分别是 Azure Kubernetes Service（AKS）与 Google Kubernetes Engine（GKE），这凸显了 Kubernetes 在现代云环境中的普及性。

如果您的应用或用例需要高级定制与可扩展性，EKS 是理想之选。比如，Kubernetes 支持创建自定义资源定义（CRD），允许您定义自定义资源以管理特定应用配置或与外部系统集成。这种灵活性是 EKS 的关键差异点。

尽管 EKS 对控制平面进行了抽象并由 AWS 进行管理，但在 EKS 环境中高效运行仍需要熟悉 Kubernetes 的 API 资源与相关概念。因此，团队是否具备 Kubernetes 专业能力是有效利用该平台的关键。

EKS 还提供了种类丰富的可定制附加组件，可安装以扩展集群功能。这些附加组件使得为集群配置必要的运维工具更加容易，从而简化搭建并提升生产力。

EKS 附加组件选择。

总之，EKS 非常适合微服务架构，或由众多相互关联组件组成、需要高度控制与细粒度管理的应用。对于需要高级定制选项，或在工作负载可移植性至关重要的环境中运行的团队，EKS 尤为有利。

ECS 与 EKS 决策流程图。作者供图。

工具与集成

无论是容器化应用，还是直接运行在虚拟机上的应用，监控与可观测性都至关重要。身处 AWS 生态，ECS 与 EKS 都可利用 AWS 工具与第三方服务，来增强容器化应用的整个软件开发生命周期（SDLC）。

监控与日志

监控与日志是了解应用与基础设施可见性的关键。AWS 为 ECS 与 EKS 都提供原生工具并支持第三方集成，例如用于指标、日志与告警的 Amazon CloudWatch。

AWS X-Ray 可对跨微服务的请求进行追踪，便于分析与调试 ECS 任务或 EKS Pod 的性能问题。Datadog、Prometheus、Grafana 与 New Relic 等第三方工具可提供面向容器的增强可视化与告警能力。

CI/CD 流水线

CI/CD 流水线可自动化测试、扫描与部署，加速迭代、减少手工操作。常见的 CI/CD 工具，如 GitLab Pipelines 与 GitHub Actions，可与 ECS 和 EKS 集成以完成容器构建、测试与部署。这些工具在 ECS 中可与 Docker 容器配合，在 EKS 中可与 Helm Chart 配合使用。

基础设施即代码（IaC）

IaC 对于创建一致、可复用的基础设施至关重要，可最大限度地缩短交付时间，并降低通过 AWS 管理控制台进行手工配置所带来的人为错误风险。

常见的 IaC 工具包括 Terraform 与 AWS CloudFormation。二者均被广泛使用，但 Terraform 因其与云无关的能力而常被偏好，团队可使用同一工具跨多个云服务商管理基础设施。

网络与安全

AWS 为 ECS 与 EKS 提供了强大的网络与安全功能，以确保安全的通信与访问控制，例如使用 AWS VPC 网络将资源隔离在私有子网中。AWS WAF 与 Shield：保护部署在 ECS 与 EKS 上的应用免受常见 Web 漏洞与 DDoS 攻击。AWS KMS 用于加密 EBS 卷与存储于 etcd 中的 Kubernetes Secret。

结论

ECS 与 EKS 都是 AWS 提供的强大容器编排服务，但它们分别面向不同的应用需求与团队优先级。

ECS 更易上手、供应与部署更简单、维护更轻松，且运维成本更低。相比之下，EKS 学习曲线更陡、初始复杂度更高，但提供了无可比拟的灵活性与高级定制选项，适合具有专业或复杂需求的团队。

在 ECS 与 EKS 之间做出选择，取决于您应用的需求、团队的专业能力，以及您在简洁性与可控性之间所期望的平衡。

如果您希望强化 AWS 知识，可以从 AWS Concepts 课程开始。想更深入了解 AWS 工具与技术，请查看 AWS Cloud Technology and Services 课程。此外，如您希望精通容器化， Containerization and Virtualization Track 将为您提供管理与部署容器的宝贵见解。