GCP托管实例组自动扩缩容未触发问题排查求助

问题描述 #

我按照官方指南完成了GCP托管实例组（Managed Instance Group）和负载均衡器的搭建，但在持续5分钟的CPU压测过程中，自动扩缩容并未触发。明明负载已经明显上升，系统却没有按预期扩容。附上我的Terraform配置脚本，请求帮忙排查原因。

Terraform配置脚本 #

resource "google_compute_network" "vpc_network" {
  name = "${var.gcp_env}-${var.gcp_project}-vpc"
  auto_create_subnetworks  = false
}

resource "google_compute_subnetwork" "subnet1" {
  name = "${var.gcp_env}-${var.gcp_project}-subnet-1"
  region = "${var.gcp_region}"
  network = google_compute_network.vpc_network.self_link
  ip_cidr_range = "11.0.0.0/24"
}

resource "google_compute_global_address" "lb-ip" {
  name = "${var.gcp_env}-${var.gcp_project}-load-balancer-ip"
  lifecycle {
    prevent_destroy = false
  }
}

resource "google_compute_address" "mig-ip" {
  name = "${var.gcp_env}-${var.gcp_project}-mig-ip-1"
  lifecycle {
    prevent_destroy = false
  }
}

resource "google_compute_instance_template" "debian12-template" {
  name = "${var.gcp_env}-${var.gcp_project}-debian12-template"
  region = var.gcp_region
  machine_type = "e2-standard-2"
  disk {
    auto_delete = true
    boot = true
    device_name = "${var.gcp_env}-${var.gcp_project}-boot-disk"
    disk_size_gb = 30
    source_image = "projects/uat-aarogyadoot/global/images/uat-aarogyadoot-instance-image"
  }
  network_interface {
    network = google_compute_network.vpc_network.name
    subnetwork = google_compute_subnetwork.subnet1.name
    access_config {
      nat_ip = google_compute_address.mig-ip.address
    }
  }
  depends_on = [google_compute_address.mig-ip]
  tags = ["firewall-for-mig"]
}

resource "google_compute_region_instance_group_manager" "mig" {
  name = "${var.gcp_env}-${var.gcp_project}-managed-instance-group"
  version {
    instance_template = google_compute_instance_template.debian12-template.self_link
  }
  distribution_policy_zones = ["${var.gcp_region}-a", "${var.gcp_region}-b", "${var.gcp_region}-c"]
  base_instance_name = "${var.gcp_env}-${var.gcp_project}-instance"
  # target_size = 1
  region = var.gcp_region  
  named_port {
    name = "${var.gcp_env}-${var.gcp_project}-named-port"
    port = 80
  }
  ### This makes it stateful, I want stateless so I commented it.
  # stateful_internal_ip {
  #   interface_name = "nic0"
  #   delete_rule    = "ON_PERMANENT_INSTANCE_DELETION"
  # }
  update_policy {
    type                         = "PROACTIVE"
    minimal_action               = "REFRESH"
    instance_redistribution_type = "NONE"
    max_unavailable_fixed        = 3
    replacement_method= "RECREATE"
  }
}

resource "google_compute_region_autoscaler" "autoscaler" {
  name = "${var.gcp_env}-${var.gcp_project}-autoscaler"
  region = var.gcp_region
  # zone = "${var.gcp_region}-a"
  target = google_compute_region_instance_group_manager.mig.id
  depends_on = [google_compute_region_instance_group_manager.mig]
  autoscaling_policy {
    mode = "ON"
    cooldown_period = 60
    cpu_utilization {
      target = 0.75
    }
    max_replicas = 2
    min_replicas = 1
    scaling_schedules {
      name = "every-weekday-morning"
      min_required_replicas = 2
      schedule = "0 9 * * MON-SAT"
      time_zone = "Asia/Kolkata"
      duration_sec = 32400
      }
    scale_in_control {
      max_scaled_in_replicas {
        fixed = 1
      }
      time_window_sec = 1800
    }
  }
}
resource "google_compute_firewall" "firewall-for-mig" {
  name          = "${var.gcp_env}-${var.gcp_project}-firewall-for-mig"
  direction     = "INGRESS"
  network       = google_compute_network.vpc_network.self_link
  priority      = 1000
  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["firewall-for-mig"]
  allow {
    ports    = ["80", "22"]
    protocol = "tcp"
  }
}

resource "google_compute_health_check" "health-check" {
  name               = "${var.gcp_env}-${var.gcp_project}-http-basic-check"
  check_interval_sec = 5
  healthy_threshold  = 2
  http_health_check {
    port               = 80
    port_specification = "USE_FIXED_PORT"
    proxy_header       = "NONE"
    request_path       = "/"
  }
  timeout_sec         = 5
  unhealthy_threshold = 2
}

resource "google_compute_backend_service" "backend-service" {
  name                            = "${var.gcp_env}-${var.gcp_project}-backend-service"
  connection_draining_timeout_sec = 0
  health_checks                   = [google_compute_health_check.health-check.id]
  load_balancing_scheme           = "EXTERNAL_MANAGED"
  port_name                       = "http"
  protocol                        = "HTTP"
  session_affinity                = "NONE"
  timeout_sec                     = 30
  enable_cdn = true
  backend {
    group           = google_compute_region_instance_group_manager.mig.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

resource "google_compute_url_map" "url-map-backend" {
  name            = "${var.gcp_env}-${var.gcp_project}-alb"
  default_service = google_compute_backend_service.backend-service.id
}

resource "google_compute_target_http_proxy" "http-lb-proxy" {
  name    = "${var.gcp_env}-${var.gcp_project}-http-lb-proxy"
  url_map = google_compute_url_map.url-map-backend.id
}

排查关键点 #

• 命名端口不匹配：MIG配置的命名端口是自定义名称（${var.gcp_env}-${var.gcp_project}-named-port），但后端服务的port_name设置为http。GCP自动扩缩容依赖两者命名端口一致才能正确收集实例利用率数据，需将后端服务的port_name修改为与MIG一致，或统一使用http作为命名端口。
• 静态公网IP冲突：实例模板绑定了固定的mig-ip，但MIG跨3个可用区部署，多个实例会争抢同一个IP，导致扩容时新实例无法启动。建议使用Cloud NAT或让实例自动获取临时公网IP，而非指定固定IP。
• 指标与健康状态验证：
  • 查看GCP控制台的Autoscaler页面，检查指标历史记录确认CPU利用率是否真的达到75%阈值，排查压测流量是否正确到达实例。
  • 确认实例是否通过健康检查：不健康实例不会被计入可用容量，需确保实例的80端口服务正常运行。
• 扩缩容规则冲突：检查缩放调度every-weekday-morning是否处于生效时间，若生效则最小副本为2，可能掩盖扩容问题；冷却时间60秒正常，但需确认压测期间是否有足够时间触发扩容。
• 负载来源验证：登录实例使用top命令确认CPU占用是否来自负载均衡的流量，而非实例内部进程，确保压测确实给实例带来了有效负载。

内容的提问来源于stack exchange，提问作者DarkDead