ECS与容量提供商一起扩展到ASG的最小容量



我已经为ECS集群配置了针对服务和容量提供商的目标跟踪策略,该策略管理ASG自动缩放

在我的集群中,服务中的最小任务数和最大任务数以及ASG中的最小容量和最大容量相同。

当在行动中按比例执行时,任务会减少到最小计数。但是ASG仍然有一个或多个未使用的(任务没有放在这个EC2实例上(EC2实例

如何使用容量提供程序配置我的集群以执行扩展到最小计数的ASG容量?


# CLUSTER
resource "aws_ecs_cluster" "default" {
name               = local.name
capacity_providers = [aws_ecs_capacity_provider.asg.name]
tags               = local.tags
default_capacity_provider_strategy {
base = 0
capacity_provider = aws_ecs_capacity_provider.asg.name
weight = 1
}
}
# SERVICE
resource "aws_ecs_service" "ecs_service" {
name            = "${local.name}-service"
cluster         = aws_ecs_cluster.default.id
task_definition = aws_ecs_task_definition.ecs_task.arn
health_check_grace_period_seconds = 60
deployment_maximum_percent         = 50
deployment_minimum_healthy_percent = 100

load_balancer {
target_group_arn = element(module.aws-alb-common-module.target_group_arns, 1)
container_name   = local.name
container_port   = 8080
}
lifecycle {
ignore_changes = [desired_count, task_definition]
}

}
# CAPACITY PROVIDER
resource "aws_ecs_capacity_provider" "asg" {
name = aws_autoscaling_group.ecs_nodes.name
auto_scaling_group_provider {
auto_scaling_group_arn         = aws_autoscaling_group.ecs_nodes.arn
managed_termination_protection = "DISABLED"
managed_scaling {
maximum_scaling_step_size = 10
minimum_scaling_step_size = 1
status                    = "ENABLED"
target_capacity           = 100
}
}
}
# SERVICE AUTOSCALING POLICY
resource "aws_appautoscaling_target" "ecs_target" {
max_capacity       = 20
min_capacity       = 2
resource_id        = "service/${local.name}/${aws_ecs_service.ecs_service.name}"
scalable_dimension = "ecs:service:DesiredCount"
service_namespace  = "ecs"
}
resource "aws_appautoscaling_policy" "ecs_policy" {
name = "${local.name}-scale-policy"
policy_type = "TargetTrackingScaling"
resource_id = aws_appautoscaling_target.ecs_target.resource_id
scalable_dimension = aws_appautoscaling_target.ecs_target.scalable_dimension
service_namespace = aws_appautoscaling_target.ecs_target.service_namespace
target_tracking_scaling_policy_configuration {
predefined_metric_specification {
predefined_metric_type = "ECSServiceAverageCPUUtilization"
}
target_value = 2
}

# ASG
resource "aws_autoscaling_group" "ecs_nodes" {
name_prefix           = "${local.name}-node"
max_size              = 20
min_size              = 2
vpc_zone_identifier   = local.subnets_ids
protect_from_scale_in = false
mixed_instances_policy {
instances_distribution {
on_demand_percentage_above_base_capacity = local.spot
}
launch_template {
launch_template_specification {
launch_template_id = aws_launch_template.node.id
version            = "$Latest"
}
dynamic "override" {
for_each = local.instance_types
content {
instance_type     = override.key
weighted_capacity = override.value
}
}
}
}
lifecycle {
create_before_destroy = true
}
tag {
key                 = "AmazonECSManaged"
propagate_at_launch = true
value               = ""
}
}



原因可能是predefined_metric_specificationtarget_value = 2是cpu使用触发级别(百分比(,而不是最小容量。该实例可能是由使用少量CPU的后台进程保持活动状态的。

顺便说一句,managed_termination_protection设置可能值得重新启用。

针对2009年25日评论的更新:

好吧,我完全有可能错了(尤其是我自己还没有使用过这个功能(,如果是这样的话,我很乐意从中学习。

但这就是我阅读上述与您的配置相关的文档的方式:关键短语是目标容量值用作亚马逊ECS托管目标跟踪扩展策略中使用的CloudWatch度量的目标值。您选择的cloudwatch度量是ECSServiceAverageCPUUtilization,这在"如何计算ECSServiceAverageCPUUUtilization度量?"中进行了讨论?。因此,您配置的目标=2意味着平均CPU利用率为2%。

我承认我错误地认为CPU度量是EC2实例级别的平均值。但在任何一种情况下,将触发值设置为2%CPU都可能导致/维持不需要的扩展。

也有可能你已经找到了对你所看到的行为的简单解释,即,但这种行为并不能始终得到保证语句。然而,我怀疑这一说法更多地适用于目标100%的极端例子,在这个例子中,人们可以预期会看到异常,就像在类似的极端2%中一样。

最新更新