在 AWS 中扩展容器
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
这一切都始于对技术的好奇:在 AWS 上扩展容器的最快方法是什么? ECS 比 EKS 快吗?法盖特呢? ECS 上的 Fargate 和 EKS 上的 Fargate 有区别吗?
对于我这个负责财政的人来说,这还有另一个有趣的方面。每个人都必须承受 EKS 的复杂性吗?线路在哪里?假设必须在 1 小时内完成并且平均使用 20.000 个 vCPU 和 50.000 GB 的工作,考虑到启动时间,什么是具有成本效益的选择?
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--l2qjyaca--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws .com/i/nip0lq1nvih2xooqbhae.png)
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
** Tl;博士**:
ECS 上的* Fargate 以每分钟惊人的一致 23 个容器扩展 1 个Service
-
ECS 上的 Fargate 以每分钟 60 个容器扩展多个
Services根据默认 AWS 限制 -
EKS 上的 Fargate 以每分钟 60 个容器的速度扩展,与
Deployments的数量无关 -
Fargate 以相同的方式扩展,无论是在 ECS 还是 EKS 上运行
-
EKS 上的 Fargate 缩小显着加快
-
可以针对相关工作负载增加 Fargate 限制,显着提高性能
-
Fargate 在第一秒内开始扩展 10 个容器
-
EKS 在开始扩展之前确实有 1-2 分钟的延迟。
kube-scheduler必须做一些魔术,cluster-autoscaler必须决定添加哪些节点,等等。 Fargate 立即开始扩大规模 -
X 扩展速度超快
请注意,此基准对 Web 工作负载完全没有用处 — 这里的重点是后台工作或批处理。有关与 Web 服务相关的扩展基准,您可以查看Clare Liguori 在 re:Invent 2019上的精彩演示。
而已!如果您想查看有关我如何测试的详细信息,请继续阅读。
这已经过时了!
有关最新信息,请查看 YouTube 上的my re:Invent 2020 talk:COM401 - Scaling Containers on AWS!
准备
在进行任何测试之前,我们必须做好准备。
设置
我为此创建了一个完全独立的 AWS 账户——我全新的“Container scaling”账户。我计划在未来进行的任何性能测试都将在这里进行。
在这个帐户中,我提交了增加几个限制的请求。
默认情况下,Fargate 最多允许运行 250 个任务。 Fargate Spot Concurrent Tasks 限制已提高到 10.000。
默认情况下,Fargate 允许以每秒 1 个任务的速度扩展(在第一秒初始突发 10 个任务之后)。在与 AWS 讨论并验证了我的工作流程后,这个限制被提高到每秒 3 个任务。
默认情况下,EKS 在扩展 Kubernetes 控制平面组件方面做得很好(真的——我为我的客户进行了广泛的测试)。由于 0 工作会有很多时间,而且我们没有对 EKS 扩展进行基准测试,所以我想去掉这个变量。 AWS 很乐意根据工作负载对集群进行预扩展,并且经过一些讨论和验证,他们确实做到了。
默认情况下,EC2 Spot 最多允许 20 个 Spot 实例。经过多次讨论,EC2 Spot Instances 限制提高到 250c5.4xlarge个 Spot 实例。
测试计划
数字
在最初的期望值 30.000 之后,我多次改变主意,最终决定:我们将测试扩展到大约 3.000 个容器的最快选项是什么!
这其中有多种原因:
-
新 AWS 组织上 EC2 Spot 实例的限制增加带来的乐趣,该组织的持续使用历史约为 5 美元/月
-
我必须在我自己的 AWS 组织中运行这些测试——我真的无法在我的一个客户的账户中执行此操作
-
我真的_真的_ 真的不想等待 6 小时进行一次测试
地区
我们不想只在us-east-1中进行测试,因为它...大小和_特殊性_,所以我们还应该在eu-west-1中运行测试,这是欧洲最大的地区。
作为任何欧洲 AWS 用户,我遇到了us-east-1个问题,这些问题仅发生在我的夜间 - 实际的美国白天时间。我们也必须在美国白天进行测试,以获得完全相关性。
测量
为了衡量容器的创建,我们将使用CloudWatch Container Insights。它具有 Fargate 的RunningTaskCount指标和 Kubernetes 的namespace_number_of_running_pods指标,这正是我们所需要的。
要扩大规模,我们只需将Desired Tasks或Replicas编辑为3.500。
所有测试都将从已经运行的 1 个任务/ pod 开始。
对于 EKS 测试,起点将只是运行 1 个节点; cluster-autoscaler 必须添加所有相关节点。
集装箱
使用的容器映像是poc-hello-world/namer-service——我计划在即将到来的研讨会和帖子中使用的一个简单的应用程序。
容器大小决定为 1 个 vCPU 和 2 GB 内存。不会太小,但也不会太大。
任务和 pod 都可以运行多个容器,但为简单起见,我们将只使用 1 个容器。
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
期望
在开始之前,设定期望是至关重要的。例如,我们不想对 5 位数的账单感到惊讶。
对 ECS 上 Fargate 的期望
ECS 上的 AWS Fargate 必须遵守默认每秒 1 个任务的启动限制,因此从 1 个任务扩展到 3.500 个任务的时间应该在 3.500 秒左右,大约是 1 小时。合理的。
由于我想关注每个人的实际结果,我们将主要使用默认速率限制测试 Fargate。 AWS 确实提高了相关工作负载的速率限制,但这是例外而非规则。
使用默认限制的扩展测试将在大约 2:47 小时内达到 10.000 个任务,这确实不那么相关。第一个小时应该绰绰有余。
对于 Fargate,定价可以通过将任务数量乘以每小时成本来估算。
根据AWS Fargate 定价页面,我们得到以下值:
-
按需:3.500 *($0.40480vCPU / 小时 * 1 vCPU + $0.44450 GB / 小时 * 2 GB * 1 小时)u003d 每次测试约 $180
-
Spot:3.500 *($0.12144vCPU / 小时 * 1 vCPU + $0.13335 GB / 小时 * 2 GB * 1 小时)u003d 每次测试约 $60
是的,北弗吉尼亚州和爱尔兰的 Fargate 定价相同。好的!
这些费用不包括 ECR、NAT 网关和许多其他费用!
为了安全起见,我将 60 美元的费用翻倍。
Fargate 测试的最终预期:150 美元和大约 1 小时。
对 EKS 的期望
AWS AutoScaling Group 负责添加 EC2 实例,cluster-autoscaler负责决定实际需要的 EC2 数量。
有点不清楚 AWS 会给我们一个实例的速度有多快。让我们用60秒。
从我前段时间的测试来看,一个 EC2 实例从真正开始成为 Kubernetes 中的Ready节点大约需要 21 秒。为图像拉取和启动容器添加 30 秒(高估,但让我们疯狂吧)。
现在,所有这些都可以用数学建模,我们可以得到一个时间估计。不幸的是,我没那么聪明,所以我们将跳过时间估计。运行测试比做数学花费的时间更少。
一个c5.4xlargeEC2 实例有 16 个 vCPU 和 32 GB 内存。其中一些是为 Kubernetes 组件、监控、NodeLocal DNS 等保留的。假设每个节点上的集群级 Pod 总共有 2 个 vCPU 和 4 GB。
我们剩下 14 个 vCPU 和 28 GB,我们的任务大小是每个节点 14 个 pod。在 250 个节点上,恰好是 3.500 个 Pod。完美!
根据AWS EC2 定价页面,我们得到以下值:
弗吉尼亚北部的* 按需:c5.4xlarge使用每小时 0.068 美元 * 250 个节点 u003d 每小时 170 美元
弗吉尼亚北部的* Spot:c5.4xlarge使用每小时 0.260 美元 * 250 个节点 u003d 每小时 65 美元
爱尔兰的* 按需:c5.4xlarge使用每小时 0.768 美元 * 250 个节点 u003d 每小时 195 美元
爱尔兰的* Spot:c5.4xlarge使用每小时 0.291 美元 * 250 个节点 u003d 每小时 75 美元
这些费用不包括 ECR、NAT 网关和许多其他费用!
所以为了安全起见,我会把 75 美元的费用翻倍。
EKS 测试的最终期望:每小时 200 美元,运行时间未知。
对 EKS 上 Fargate 的期望
定价与 ECS 上的 Fargate 相同,因此每次测试大约 150 美元。
时间和EKS一样吗? ECS 上的时间比 EKS 更接近 Fargate 吗?
我不知道,我真的很期待看到会发生什么。
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
运行测试
我在 EKS 和 ECS 测试中总共运行了大约 10 个 Fargate — 对于其中一些,我仍在弄清楚一些东西。我总共进行了 4 次 EKS 测试。
我在周末和工作日都进行了测试。我也确保在白天和夜间运行测试。
用于页面顶部图表的数据可以在此链接](///posts/scaling-containers-in-aws/graph-results.csv)(CSV,小于 1MB 文件)处以 CSV[格式下载。
结果
让我们从页面顶部回顾一下结果!
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--l2qjyaca--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws .com/i/nip0lq1nvih2xooqbhae.png)
用于所有测试的 Terraform 代码可在 GitHub 上的Vlaaaaaaad/blog-scaling-containers-in-aws找到。
它根本不是漂亮或正确的代码。另一方面,它是有效的代码!我坚信任何结果的可重复性,并且我相信我有道德责任分享我用来得出这里提出的结论的一切。
不幸的是,成本没有被完全跟踪。
由于 AWS 为我的集群预先扩展了 EKS 控制平面,我不得不让它们在整个持续时间内保持运行。我每天在多个地区进行多次测试,因此没有简单的方法来计算一次测试运行的成本。估算确实有很大帮助,但它们的存在是为了确保我最终不会花费数万美元。
该帐户的总账单略低于 2.000 美元。
Fargate 结果
ECS 上的 Fargate 和 EKS 上的 Fargate 的规模惊人地相似。
我预计结果会出现更多差异,但它们在按比例放大时几乎相同:初始爆发,然后每分钟 60 个容器。
也许一分钟,它是 58,也许再过一分钟,它是 62,但差异很小。
在运行测试时,我确实发现了一个以前未知的 Fargate on ECS 限制: 1Service最多可以运行1.000个任务。为了达到 3.500 个正在运行的任务,我必须创建 4 个单独的服务。这导致了 ECS 上的 Fargate 测试从 4 个容器开始,而不是 1 个。
我没有彻底测试的东西正在缩小。我确实注意到 EKS 上的 Fargate 缩小了的速度明显更快。 ECS 上的 Fargate 缩减速度较慢,从我看到的与扩展速度相似的情况来看。
事实证明我的成本计算很糟糕但正确:我完全忘记了缩小规模!
缩小规模与扩大规模所用的时间大致相同——我计算了扩大规模的成本。另一方面,由于我将成本加倍以应对意外情况,所以我是在正确的范围内!
EKS 结果
不同运行之间的 EKS 结果也非常相似。我在晚上和白天都测试过,我在多个地区测试过,结果几乎相同。
EKS 比 Fargate 快得多有点令人惊讶。虽然 Fargate 将在大约 50 分钟内扩展,但 EKS 始终在不到 10 分钟内完成。
由于我在工作中广泛使用 EKS,因此没有其他惊喜。
从成本的角度来看,我犯了同样的错误:我没有考虑缩小规模。
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
免责声明
首先,我想重申,这对于 Web 工作负载完全没有用——这里的重点是后台工作或批处理。有关相关的 Web 扩展基准,您可以查看Clare Liguori 在 re:Invent 2019上的精彩演示。
顺便说一句,Lambda 将在 1.5 到 7 秒内扩展到 3.500 个容器,具体取决于区域。这是一个完全不同的野兽,但我认为值得一提。
显然,这不是一个非常严格或统计相关的测试过程。
我只做了一些测试,因为我发现差异很小——我没有看到多跑的意义。
我只测试了us-east-1和eu-west-1这两个大区。对于较小的地区或在奇怪的时期(例如黑色星期五、网络星期一、EOY 报告时间),数字可能会或可能不会有所不同。
我使用的容器镜像是poc-hello-world/namer-service的镜像,它很小,可能不太适合。我不想进入整个“让我们优化图像拉动速度”。
对 Dockerhub 上所有镜像的研究可以在这里阅读。
我只用 1 个容器运行 pod 和任务。 pod 和任务都可以运行多个容器。
我根本没有优化测试。我想展示平均体验,而不是对任何人都没有帮助的超级定制解决方案。这里的值可能会得到改进——多个 ECS 集群、多个用于 EKS 的 ASG,等等。
带有 EC2 的 ECS 完全被忽略了。我不能说是有原因的,我只是没有想到这一点。 Fargate 具有成本优势、简单性和一流的 AWS 集成。 EKS 具有复杂性、所有旋钮和所有流行语。在两者之间,我没有考虑 ECS 和 EC2,这取决于我。
总的来说我很高兴。毕竟,我们现在有一个可以在设计系统时使用的大概数字🙂
致谢
首先,非常感谢 Ignacio 和 Michael 帮助我上报我的所有支持票,并将我与 AWS 中的合适人员联系起来!
特别感谢 Mats 和 Massimo 对 Fargate 的所有帮助和评论!您的反馈是无价的!
感谢所有帮助审查、提供反馈或支持我的人!
生成图
这部分花了 forever 来完成,所以我决定将它添加到帖子中。
结果是整个帖子中最令人兴奋的事情。我非常希望有一个漂亮的图形图像来展示结果。
由于测试在统计上不正确,我认为手绘图表会是完美的。它会很好地展示数据,同时暗示体验可能会有所不同。
数字和Excel不能轻易做到这一点。LiveGap 图表有一堆手绘选项,非常出色,但不是我想要的。
Matplotlib来救援!经过大量研究和大约一天的使用,我得到了一个工作脚本。
它不漂亮或优化,也不正确。但它有效!
# Install the required font
# BEWARE: this only works on macOS
# Linuxbrew does not install fonts
brew install homebrew/cask-fonts/font-humor-sans
# Install Python dependencies
pip3 install matplotlib numpy
# Run and generate the image
python3 draw.py
进入全屏模式 退出全屏模式
# File: draw.py
# The actual image-generation script
import matplotlib.pyplot as plt
from matplotlib.lines import Line2D
import numpy as np
# Load data from CSV
data = np.genfromtxt(
'graph-results.csv',
delimiter=',',
names=True,
)
# Start an XKCD graph
plt.xkcd()
# Make the image pretty
figure = plt.figure()
figure.set_dpi(300)
figure.set_size_inches(8, 7.5)
figure.suptitle(
'Scaling containers on AWS\n@iamvlaaaaaaad',
fontsize=16,
)
plt.xlabel('Minutes')
plt.ylabel('Containers')
plt.xticks(np.arange(0, 70, step=10))
# Colors from https://jfly.uni-koeln.de/color/
plt.plot(
data['EKS'],
label="EKS with EC2",
color=(0.8, 0.4, 0.7),
)
plt.plot(
data['TunedFargate'],
label="Tuned Fargate",
color=(0.9, 0.6, 0.0),
)
plt.plot(
data['FargateOnECS'],
label="Fargate on ECS",
color=(0.0, 0.45, 0.70),
)
plt.plot(
data['FargateOnEKS'],
label="Fargate on EKS",
color=(0.35, 0.70, 0.90),
)
# Add a legend to the graph
# using default labels
plt.legend(
loc='lower right',
borderaxespad=1
)
# Export the image
figure.savefig('containers.svg')
figure.savefig('containers.png')
进入全屏模式 退出全屏模式
这已经过时了!
有关最新信息,请查看我在 YouTube 上的 re:Invent 2020 演讲:COM401 - 在 AWS 上扩展容器!
更多推荐

所有评论(0)