标签: aws-auto-scaling

这是我第一次使用亚马逊ecs服务。

我在网上搜索了一段时间以了解 ecs 服务的自动缩放。

我发现有两个选项可以自动扩展我的应用程序。但是，有一些我不明白。

首先是服务自动缩放，它跟踪来自cloudWatch的CPU/内存指标并相应地增加任务数量。

其次是集群弹性伸缩，需要创建弹性伸缩资源、创建容量提供者等。但是，在教程：使用集群自动伸缩中，它可以在没有服务的情况下运行任务定义。但最终似乎也增加了任务数量。

那么它们之间有什么不同和“优缺点”呢？

我正在运行一个带有Autoscaler pod的 Kubernetes 集群（AWS EKS 集群），这样集群将根据集群内的资源请求自动扩展。

此外，当负载减少时，集群将缩小节点数。正如我所观察到的，Autosclaer 可以删除此过程中的任何节点。

我想控制这种行为，例如要求 Autoscaler 停止删除运行特定 pod 的节点。例如，如果一个节点运行 Jenkins pod，Autoscaler 应该跳过该节点并从集群中删除其他匹配的节点。

请问有没有办法达到这个要求。请给出你的想法。

我正在对自动扩展 AWS ECS Fargate 堆栈进行负载测试，其中包括：

• 目标组指向 ECS 的应用程序负载均衡器 (ALB)，
• ECS 集群、服务、任务、ApplicationAutoScaling::ScalableTarget 和 ApplicationAutoScaling::ScalingPolicy、
• 应用程序自动缩放策略定义了目标跟踪策略：
  • 类型：目标跟踪缩放，
  • 预定义指标类型：ALBRequestCountPerTarget，
  • 阈值 = 1000 个请求
  • 当过去 1 分钟评估期内 1 个数据点超出阈值时，将触发警报。

这一切都很好。警报确实被触发，并且我看到正在发生横向扩展操作。但检测“阈值突破”的速度感觉很慢。这是我的负载测试和 AWS 事件的时间安排（从 JMeter 日志和 AWS 控制台的不同位置整理而来）：

10:44:32 start load test (this is the first request timestamp entry in JMeter logs)
10:44:36 4 seconds later (in the the JMeter logs), we see that the load test reaches it's 1000th request to the ALB. At this point in time, we're above the threshold and waiting for …

到目前为止，我所读到的内容：
EC2 ASG 是一个简单的解决方案，可以使用 EC2 实例池前面的负载均衡器扩展服务器的更多副本
ECS 更像是 Kubernetes，当您需要部署多个Docker 容器中的服务在内部相互协作形成一个服务，自动伸缩是 ECS 本身的一个特性。

我在这里遗漏了任何差异吗？因为如果按照我的理解工作，ECS 几乎总是一个更好的选择。

我正在 AWS ECS 集群中运行 Python Celery（分布式任务队列库）工作人员（每个 EC2 实例运行 1 个 Celery 工作人员），但任务需要长时间运行并且不是幂等的。这意味着，当发生自动扩展缩减事件时，即 ECS 由于任务负载过低而终止运行工作线程的容器之一时，该工作线程上当前正在进行的长时间运行的任务将永远丢失。

有人对如何配置 ECS 自动缩放有任何建议，以便在完成之前不会终止任何任务吗？理想情况下，ECS 缩减事件将对要终止的 EC2 实例中的 Celery Worker 启动热关闭，但只有在 Celery Worker 完成热关闭（在其所有任务完成之后才会实际终止 EC2 实例）。完全的。

我还了解有一种称为实例保护的东西，它可以通过编程方式进行设置，并防止实例在缩减自动缩放事件中被终止：https ://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance -termination.html#instance-protection-instance

但是，我不知道在所有任务在热关闭中完成后会触发任何 Celery 信号，因此我不确定如何以编程方式知道何时禁用保护。即使我找到了一种在适当的时候禁用保护的方法，谁来管理首先向哪个工作人员发送关闭信号？EC2 是否可以配置为在缩减事件中对实例执行自定义操作（例如执行热 celery 关闭），而不是仅仅终止 EC2 实例？

我们有一个简单的示例，为基于 CPU 和内存的 ecs 容器化应用程序配置了目标跟踪自动缩放。我们通过下面的代码自动配置了 4 个警报（2 个 CPU - 1 个向上扩展、1 个向下扩展和 2 个内存、1 个向上扩展和 1 个向下扩展）

我们看到，当 cloudwatch 警报触发自动扩展时，我们的 ecs 服务任务会立即自动扩展（在 ecs 方面，存在立即设置所需计数的事件）。然而，当 cloudwatch 警报触发自动缩减时，我们观察到不同的行为：

1. 有时，ecs 服务任务会立即缩小（缩小警报会立即响起，并设置所需的向下计数事件立即出现在 ecs 端）
2. 有时，ecs 服务任务会延迟缩减，例如 7-15 分钟后，甚至几个小时后（缩减警报会立即响起，但在 ecs 端设置所需的向下计数事件延迟 7-15 分钟，或几个小时）几个小时以后）
3. 有时 ecs 服务任务根本不会缩减（我们在周末看到触发了缩减警报，但 ecs 服务任务从未在 48 小时内缩减，并且设置所需的递减计数事件从未到达 ecs 端）

在cloudwatch警报方面，我们观察到警报总是在预期的扩展和缩减时响起，我们认为问题出在ecs方面。

自动缩放代码如下：

resource aws_appautoscaling_target this {
  max_capacity = 5
  min_capacity = 1
  resource_id = "service/dev/service1"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace = "ecs"
}

resource aws_appautoscaling_policy memory {
  name               = "memory"
  policy_type        = "TargetTrackingScaling" …

我正在尝试从从 ec2 AMI 创建的启动配置创建自动缩放组。但是，在第二步“配置设置”中，当我单击“下一步”时收到错误消息。我尝试检查第一步，但在 CpuOptions 上找不到任何内容，也无法在我指定为自动缩放组一部分的启动配置中找到有关 CpuOptions 的任何内容。

自动伸缩组

启动模板

挑战

现货节点组的扩展失败并出现 AsgInstanceLaunchFailures，因为它“无法启动 Spot 实例。UnfulfillableCapacity - 由于您的请求配置而无法满足容量。请调整您的请求并重试。启动 EC2 实例失败。”

发生该错误后，节点组将降级并且不再调度新实例。

我该如何解决这个问题，以便在实例再次可用时节点组可以正常工作？

设置

我利用terraform-aws-eks-blueprints-repo并为自己构建了一个 EKS 集群。集群具有以下受管节点组。

• 现货 - eu-central-1 - a
• 现货 - eu-central-1 - b
• 现货 - eu-central-1 - c
• 点播 - eu-central-1 - a
• 点播 - eu-central-1 - b
• 点播-eu-central-1-c

最重要的是，我将其配置cluster-autoscaler-priority-expander为首先使用点，然后按需使用。

2022-05-13 更新：我刚刚使用过m5.large，现在添加了更多类型来解决该问题。有了这个扩展集，到目前为止似乎没有问题。我仍然非常想知道如何解决这个问题，好像 SPOT 根本不可用，我的集群就会失败......这不是一个好的前景。

2022-05-19 更新：我与 AWS 进行了交谈，他们声称这是一个到目前为止还没有解决方案的问题。由于自动缩放组没有“降级”，集群自动缩放器只是认为它是“降级”。对我来说，这听起来像是想要进入的障碍......所以，如果有人有解决方案，我会持开放态度。

在AWS ECS中创建容量提供程序时。我们正在填充的目标容量％值，在超过该值后，我们的集群缩小，但我很好奇当前集群的这个值是如何计算的，如果我想检查集群的当前值是多少，我可以在哪里检查这个。我在cludwatch方面没有找到任何数据。

我有一个 AWS Sagemaker 推理终端节点，该终端节点启用了 SageMakerVariantInitationsPerInstance 目标指标的自动扩展功能。当我向端点发送大量请求时，实例数量会正确扩展到最大实例计数。但在我停止发送请求后，实例数不会缩减为 1（最小实例数）。我等了好几个小时。这种行为有原因吗？

谢谢