如何触发EKS Pod自动扩缩容？仅调ASG最大实例数是否可行？

安全阿岳

2026-5-11

问得好！仅调大ASG的asg_max_size确实不足以实现自动扩缩容——你还需要配置触发扩缩容的规则，以及对应的组件来监控集群资源状态、执行扩缩操作。结合你用Fargate跑Airflow Worker的场景，我给你梳理一个简单易上手的方案：

先理清你的部署场景

你的Fargate Profile指定了fargate命名空间，所以Airflow Worker Pod应该是由Fargate托管的——Fargate会自动为每个Pod分配所需的CPU/内存资源，不需要你手动管理EC2节点的生命周期。这时候你要解决的是Worker Pod数量的自动调整，而不是EC2节点的扩缩容；如果你的Airflow其他组件（比如Scheduler、Webserver）跑在EC2节点上，那才需要配置EC2节点的自动扩缩容。

方案一：给Fargate上的Airflow Worker配置Pod自动扩缩（HPA）

Horizontal Pod Autoscaler（HPA）是Kubernetes原生的组件，能根据Pod的CPU/内存使用率自动增减Pod副本数，完美适配你Airflow Worker按需生成的场景。

步骤1：确保Worker Deployment配置了资源请求/限制

HPA需要基于Pod的资源使用率计算，所以你得先给Airflow Worker的Deployment加上resources.requests和resources.limits（比如CPU 0.5核、内存1Gi），示例YAML（你可以转换成Terraform的kubernetes_deployment资源）：

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1000m"
    memory: "2Gi"

步骤2：用Terraform部署HPA

直接用Terraform创建HPA资源，设置基于CPU/内存使用率的触发规则：

resource "kubernetes_horizontal_pod_autoscaler_v2" "airflow_worker_hpa" {
  metadata {
    name      = "airflow-worker-hpa"
    namespace = "fargate"
  }

  spec {
    scale_target_ref {
      api_version = "apps/v1"
      kind        = "Deployment"
      name        = "airflow-worker" # 替换成你的Worker Deployment名称
    }

    min_replicas = 1 # 最小保留1个Worker
    max_replicas = 10 # 最多扩容到10个，根据你的需求调整

    # CPU使用率超过70%时扩容
    metrics {
      resource {
        name = "cpu"
        target {
          type               = "Utilization"
          average_utilization = 70
        }
      }
    }

    # 内存使用率超过75%时扩容
    metrics {
      resource {
        name = "memory"
        target {
          type               = "Utilization"
          average_utilization = 75
        }
      }
    }
  }
}

步骤3：部署Metrics Server

HPA依赖Metrics Server来收集Pod的资源使用率指标，用Helm快速部署：

resource "helm_release" "metrics_server" {
  name       = "metrics-server"
  repository = "https://kubernetes-sigs.github.io/metrics-server/"
  chart      = "metrics-server"
  namespace  = "kube-system"

  # 测试环境可以加这个参数跳过证书验证，生产环境建议配置合法证书
  set {
    name  = "args[0]"
    value = "--kubelet-insecure-tls"
  }
}

方案二：给EC2 Worker节点配置自动扩缩容（如果你的组件跑在EC2上）

如果你的Airflow Scheduler、Webserver等组件跑在EC2节点上，或者后续打算把Worker移到EC2，那需要配置Cluster Autoscaler来自动调整EC2节点的数量：

步骤1：给EC2节点角色附加扩缩容权限

你已经创建了node_autoscaling_pol策略，现在需要把它附加到EC2 Worker节点的IAM角色上：

resource "aws_iam_role_policy_attachment" "node_autoscaling_attach" {
  role       = module.eks_cluster.worker_iam_role_name
  policy_arn = aws_iam_policy.node_autoscaling_pol.arn
}

步骤2：部署Cluster Autoscaler

Cluster Autoscaler会监控集群中待调度的Pod（因为资源不足无法分配的Pod），自动调整ASG的期望节点数；节点空闲时也会自动缩容：

resource "helm_release" "cluster_autoscaler" {
  name       = "cluster-autoscaler"
  repository = "https://kubernetes.github.io/autoscaler"
  chart      = "cluster-autoscaler"
  namespace  = "kube-system"

  set {
    name  = "autoDiscovery.clusterName"
    value = module.eks_cluster.cluster_id
  }

  set {
    name  = "awsRegion"
    value = var.aws_region # 替换成你的AWS区域
  }

  set {
    name  = "rbac.create"
    value = true
  }
}

步骤3：调整ASG的上下限

修改你现有Worker Group的配置，设置合理的最小/最大节点数：

worker_groups = [
  {
    instance_type = var.nodes_instance_type_1
    asg_min_size  = 1 # 最少保留1个节点
    asg_max_size  = 5 # 最多扩容到5个，根据你的需求调整
    name          = "${var.project_name}-${var.env_name}"
  }
]

核心总结

仅调大asg_max_size没用：ASG需要触发条件（比如资源使用率、待调度Pod数）才会自动扩缩容，光有上限等于摆设。
Fargate场景重点在HPA：Fargate自动管Pod的资源分配，你只需要用HPA控制Worker Pod的数量。
EC2场景要配合Cluster Autoscaler：既要用HPA管Pod数，也要用Cluster Autoscaler管EC2节点数，两者配合才能实现端到端的自动扩缩容。

内容的提问来源于stack exchange，提问作者alt-f4