从 Amazon ECS 迁移到 EKS 可能是您最不想花时间做的事情。

然而,你来了。因此,ECS 很可能没有完全为您服务。或者您可能好奇是否应该开始计划迁移以及需要多长时间。

我将尝试回答您的大部分问题,从您是否应该查看 EKS 到您做出决定时的一些实际迁移和 EKS 管理技巧。

为什么要从ECS迁移到EKS?

想要在 Kubernetes 中取得进步的公司最好使用 EKS。亚马逊、汇丰银行、摩根大通和 Delivery Hero 等巨头都使用 EKS,因为它提供了控制力和灵活性。

1.可移植性

虽然 ECS 是 AWS 专有技术,但 EKS 基本上是由 AWS 开发和维护的 Kubernetes 即平台服务。 EKS 集群实际上是可移植的,您可以使用 vanilla K8s 在本地环境、开发环境等上重新创建类似的体验。因此,您大概可以判断在哪种情况下您将面临云供应商锁定的风险。

如果您在 ECS 中构建和运行应用程序,从长远来看,您可能会遇到供应商锁定问题。如果您决定使用其他提供商,则必须定义整个架构以匹配它。

这就是为什么将您的应用程序设计为在 EKS 上运行会给您带来更大的灵活性。 EKS 的抽象层可帮助您打包容器并将它们快速移动到另一个平台。这样一来,您就可以在任何其他 Kubernetes 集群上运行工作负载——无论是本地还是为您提供最优惠价格的云提供商。

最重要的是,您可以在市场上找到允许您在不同托管 Kubernetes 服务之间无缝切换的解决方案。

开源和社区是与此相关的两个重点。

使用 EKS,您可以在其上构建大量工具,并且社区本身正在迅速发展。你知道这意味着什么——你会得到很多支持,因为许多问题已经有了解决方案。

开源还允许您选择您的工具,而在 ECS 中,一切都非常固执己见,最终没有多少灵活性。

2.网络限制

Amazon ECS 允许用户仅使用一种网络模式为任务分配弹性网络接口 (ENI):awsvpc。通常,每个 EC2 实例只能获得 8-15 个网络接口,但 ECS 也支持具有更高限制的容器(只要您满足特定的先决条件)。总的来说,每个 EC2 实例最多可以运行 120 个任务。

在 EKS 中,您可以享受更大的网络灵活性。您可以在多个 Pod 之间共享一个 ENI,并为每个实例放置更多 Pod。

3.命名空间

命名空间很方便,因为它们隔离了在同一个 Kubernetes 集群中运行的工作负载。例如,您可以在一个集群中拥有开发、登台和生产环境。它们都可以共享集群的资源。

问题是,您不能在 ECS 中使用命名空间。解决方案只是不将它们作为一个概念包括在内。与此相反,EKS 允许您像在自我管理的 Kubernetes 中一样使用它们。

4.没有配置灵活性

很多人选择ECS是因为它很简单。但要为此付出代价 - 即有限的配置选项。例如,您无法访问集群节点,这限制了您的故障排除能力。

如果您将 ECS 与 Fargate 一起使用,请为更多限制做好准备。例如,您无法像在 EKS 中那样轻松地将特定于环境的配置与容器映像分离以实现可移植性。

ECS 到 EKS 词汇表

在从 ECS 迁移到 EKS 之前,您需要熟悉一些 Kubernetes 常用的术语:

• ECS 与 K8s 构建块 - 这是最好的入门位置,回顾ECS和Kubernetes的构建块将帮助您了解这两者之间的区别。

• EKS 工作节点 - 这是运行您的工作负载 (Pod) 的 EC2 实例。

• IaC - 基础设施即代码 - 这些工具允许您在通常提交到 Git 存储库的代码中定义基础设施。除此之外,只要您的代码与云中的基础设施不匹配,您就会获得类似 Git 的差异输出。示例包括Pulumi、Terraform和AWS CloudFormation

• Helm- Kubernetes 世界中最流行的打包解决方案。

• ALB - 应用程序负载均衡器。

• NLB - 网络负载平衡器。

• 互联网网关- 互联网网关是一个水平扩展、冗余且高度可用的 VPC 组件,允许您的 VPC 和互联网之间进行通信。

• VPC- Amazon Virtual Private Cloud (Amazon VPC) 使您能够将 AWS 资源启动到您定义的虚拟网络中。该虚拟网络与您在自己的数据中心中运行的传统网络非常相似,具有使用 AWS 的可扩展基础设施的优势。

ECS 附带您可能熟悉的自己的术语。以下是不同的 ECS 概念如何转化为 EKS 世界。

• ECS 任务定义 <> EKS Kubernetes 部署 YAML

• ECS 任务 <> EKS Kubernetes Pod

• ECS 集群 <> EKS 集群

如果您在此处需要更多指导,可以查看ECS Workshop和EKS Workshop的一些很好的资源。

使用 EKS 可以获得什么

对于正在运行的每个工作负载,您可能不需要 pod。但你不能否认它们提供了对 pod 放置和资源共享的无与伦比的控制。当您处理大多数基于服务的架构时,这非常有价值。

EKS 为管理底层资源提供了更大的灵活性。您可以在 EC2 实例、Fargate 甚至本地(通过 EKS Anywhere)上运行集群。

如果您熟悉 Kubernetes 并希望亲身体验它提供的灵活性和功能,请选择 EKS。

如何从ECS迁移到EKS

AWS 有一些关于迁移到 EKS的好技巧。

但我们发现在您的 ECS 到 EKS 迁移之前您需要注意一些其他事项。

1.将 ECS 任务定义文件重写为 K8s 部署 YAML

首先,您需要将 ECS任务定义文件重写为 Kubernetes部署 YAML。这部分是不可避免的,并且与 ECS 和 EKS(或 vanilla Kubernetes)之间的最大区别之一有关。

2.启动你的环境

您还需要启动 EKS 上的相应环境版本。人们通常选择使用基础设施即代码 (IaC) - 使用 Terraform、CloudFormation 或 Pulumi。好消息:最流行的 IaC 工具支持 EKS。

假设您已经熟悉 Docker 并已打包应用程序映像并可供使用:

• 您可以使用 Terraform(或替代 IaC 工具)的功能,例如kubernetes 提供程序将您的部署 YAML 作为 IaC 流程的一部分发送。

• 如果您的应用程序包使用 Helm,您也可以使用Helm Provider。

• 或者,您可以使用 CloudFormation,它允许将工作负载部署到 EKS 集群,假设您的应用程序是使用 Helm 打包的。

您可以通过更多方式获得上述工作 - 每种方式都有其优点和缺点。但是这个简单的解决方案现在就足够了。

3.配置 CI/CD 管道

您需要执行此操作才能将您的应用程序部署到 EKS 集群中。

4.联网

ECS 和 EKS 都支持类似的网络功能:ALB 和 NLB。您可以在 ECS 中使用您当前熟悉的基本网络结构。如果您正在寻找有关 ALB 入口的更多详细信息,这篇文章可能会派上用场。

5.运行一些测试

针对新配置运行测试套件以确保一切正常。

6.将您的流量切换到 EKS 集群

这可能因您的配置而异,但为了让您了解需要做什么:

• 您可以切换您的域指向的 IP,使其指向您的 EKS 集群使用的负载均衡器。这是您确保您的应用程序流量现在指向 EKS 集群的方式。

• 对于有状态的应用程序,你还需要考虑其他的事情,比如确保基于K8s的应用程序转换为数据库的主用户(从使用数据库的ECS平滑切换到使用数据库的EKS应用程序)用于写作)。

通过自动化让您的 EKS 之旅更轻松

配置和运行 EKS 并不难。这就是所有托管 Kubernetes 工具的用途。

例如,CAST AI 带有固执己见的 Kubernetes 实施,可帮助您管理所有基础设施的复杂性:

• 专注于你最感兴趣的高水平工作。

• 创建和管理 CAST Al 组件很容易 - 您可以通过 API 和 Terraform 来实现基础设施生命周期管理的自动化。

• 您可以使用余量策略简化自动缩放,以适应突然的需求高峰。

• 并自动化现场实例使用以进一步降低成本。如果现货可用性减少,您的工作负载会自动转移到按需实例,并且永远不会停止。

• 总而言之,您将从自动化的云成本优化中受益——该平台选择最具成本效益的 AWS 实例类型和大小,并提供详细的成本报告。

如果您想了解这在现实生活中是如何运作的,以下是电子商务机构 Snow Commerce 如何迁移到 EKS,现在通过完全自动化的环境无缝推出应用程序。

了解 CAST AI 在现实生活中的工作原理