如何使用Terraform自动化实现GKE节点迁移

完全可以依托Terraform及GKE官方Provider的原生能力实现节点池变更的全流程自动化，不需要手动执行cordon、drain操作，也不会出现一次性全量销毁节点导致的服务中断，具体方案根据要修改的节点池属性类型分两类处理：

场景1：修改可原地滚动更新的属性 #

如果修改的属性不会强制重建整个节点池（比如K8s版本、节点标签、污点、资源预留配置这类，Terraform plan时不会显示forces replacement标记），直接给节点池配置滚动升级策略和自动排空规则即可，变更时GKE会自动逐台替换节点：

resource "google_container_node_pool" "biz" {
  name               = "biz-pool"
  cluster            = google_container_cluster.main.id
  initial_node_count = 3

  # 核心滚动策略配置
  upgrade_settings {
    max_surge       = 1  # 每次最多多启1个新节点
    max_unavailable = 0  # 升级过程中不可用节点数为0
  }

  management {
    auto_repair  = true
    auto_upgrade = true
  }

  node_config {
    machine_type = "n2-standard-2"
    disk_size_gb = 100
    # 其余节点配置...
  }
}

这套配置下，变更触发后GKE的执行逻辑是：每次新建1个符合新配置的节点 → 等节点注册到集群、状态Ready → 自动cordon对应旧节点、排空上面的Pod → 等Pod在其他节点调度就绪后再删除旧节点，循环直到所有节点替换完成，全程不需要人工介入。

场景2：修改会强制重建节点池的属性 #

如果修改的属性必须重建节点池才能生效（比如节点机型、磁盘类型、操作系统镜像类型、专属宿主机配置这类，Terraform plan时会显示forces replacement标记），用Terraform原生生命周期规则搭配GKE删除排空能力实现蓝绿切换：

resource "google_container_node_pool" "biz" {
  # 名称加哈希后缀避免新旧池重名冲突
  name               = "biz-pool-${substr(sha256(join(",", [var.machine_type, var.disk_type])), 0, 6)}"
  cluster            = google_container_cluster.main.id
  initial_node_count = 3

  upgrade_settings {
    max_surge       = 1
    max_unavailable = 0
  }

  node_config {
    machine_type = var.machine_type # 修改这个参数会触发节点池重建
    disk_type    = var.disk_type
    # 其余节点配置...
  }

  # 核心生命周期配置
  lifecycle {
    create_before_destroy = true # 先创建新节点池，再销毁旧池，避免先删资源导致服务雪崩
    ignore_changes = [name] # 忽略名称后缀变化带来的无意义重建
  }

  # 给删除操作留足排空时间，避免大业务量下排空超时
  timeouts {
    delete = "30m"
  }
}

这套配置下，Terraform触发变更的执行逻辑是：

• 先创建符合新配置的节点池，等待所有新节点状态Ready、注册到集群
• 触发旧节点池删除流程，GKE会自动逐台cordon、drain旧节点，遵守Pod配置的terminationGracePeriodSeconds宽限期，不会强杀业务Pod
• 旧节点全部排空、删除完成后，整个变更流程结束

注意事项 #

• 不要用集群创建时自带的默认节点池运行业务，默认节点池不支持上述平滑替换逻辑，所有业务节点池都要单独通过google_container_node_pool资源声明
• 如果业务有特殊的流量切换需求（比如排空节点前需要先从负载均衡摘流、跑自定义健康检查），可以搭配null_resource和kubectl Provider在节点池创建/删除的生命周期钩子上加自定义逻辑，90%以上的常规场景不需要这层额外配置
• 变更前建议先跑terraform plan确认执行计划，避免误操作

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