GKE Standard：私网、Node pool 与身份

验证：静态检查 · 核验于 2026-09-28

适用版本: 云环境版本未实测；适用条件见正文
验证范围: 已检查文档构建、链接与脚本语法；未执行云端实验。

需要管理 node pool、容量和节点特性时使用 Standard。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
REGION='REPLACE_REGION'
CLUSTER='REPLACE_CLUSTER'

gcloud container clusters describe "$CLUSTER" --project="$PROJECT_ID" --region="$REGION"
gcloud container node-pools list --cluster="$CLUSTER" \
  --project="$PROJECT_ID" --region="$REGION"

容易踩的坑#

节点数参数要按 Zone 计算。 --num-nodes=1 配三个 node locations 通常是初始三台；--min-nodes / --max-nodes 是每 Zone 边界，升级 surge 还会临时增加节点。

node label 不自动隔离业务；需要 nodeSelector/affinity，排斥其他 Pod 则另配 taint。

网络参数 · 升级 · IAP 登录

配置说明与完整示例（按需展开）

前置：网络、IAM、Kubernetes 实践约定；完成企业项目第 1–3 节，保留镜像、私网 SQL、Secret 和网络。本篇新建 Standard 集群及私网管理 VM orders-gke-runner（下称 runner），通过它运行 kubectl。Autopilot 见入门实验。

选择	边界
Autopilot	减少节点运维；先确认特权 Agent、存储、GPU 和硬件要求能否满足
Standard	自管 node pool、容量、节点访问及插件组合；承担节点运维和费用责任

应用外部访问见 GKE Ingress 实验：由 Kubernetes 清单创建公网 ALB、NEG、健康检查和 HTTPS 入口。

先分清管理机、节点和身份#

对象	在本篇中是什么
本机	你的电脑，负责创建云资源和发起远程登录
私网管理机（runner）	同 Region、同 VPC 的独立管理 VM；不是 GKE 节点或 CI Runner
控制面（control plane）	GKE 托管的集群管理服务，包含接收 kubectl 请求的 API Server；不承载本篇业务 Pod
节点（Node）	实际运行 Pod 的工作机器，在 Standard 集群中由 node pool 管理
node pool	一组采用相同配置的节点；system、application 是本例自定义名称
Pod	Kubernetes 调度应用的基本单位，其中可以包含一个或多个容器

本篇的管理路径是：

你的电脑
  → IAP 加密 SSH 隧道
  → 私网管理机 orders-gke-runner（运行 kubectl）
  → 控制面内部 IP 的 HTTPS API

通过 IAP TCP forwarding 与 OS Login 登录 runner 后，在远程 shell 运行 kubectl；SSH tunnel 不为本机提供整个 VPC 的路由。

1. 网络与节点身份#

地址模型见 GKE 网络。本节只列本例规划与创建参数。

**Google Service Account（SA）**是云身份，NODE_SA 用于节点；**Kubernetes ServiceAccount（KSA）**是 Pod 的工作负载身份。KSA 属于 namespace，即 Kubernetes 内的资源分组与授权范围。

IAM 管理云资源权限，RBAC 管理 Kubernetes 操作权限。操作者还需在指定 SA 上具备 actAs（通常由 roles/iam.serviceAccountUser 提供），才能将它附加到节点。详见 IAM。

在企业项目同一 VPC 新建 GKE subnet，避免借另一 VPC 的对等连接间接访问 SQL；VPC Peering 不提供传递路由。先对照所有 subnet、SQL 的私有服务地址段、对等网络及 VPN 网段，确认以下示例无重叠。

primary IP range 分配节点和 runner 地址；同一 subnet 的两个 secondary IP range 分别供 Pod、Service 使用。VPC-native / IP aliases 让 Pod 地址接入 VPC；Service IP 则是集群内的虚拟入口。

surge 是升级时临时新增的节点，需要额外地址和配额；CIDR /32 表示单个 IPv4 地址。

用途	示例范围	容量依据
企业项目原有 subnet	10.62.0.0/24	Cloud Run 与迁移机；保留
GKE 节点与 runner	10.64.0.0/24	节点、runner、升级临时节点；预留扩容
Pod 次要范围	10.68.0.0/18	默认每节点最多 110 Pod 时通常分配 /24，可容纳 64 个节点块；计入全部 node pool 与 surge
Service 次要范围	10.69.0.0/22	集群虚拟服务地址，不用于节点
控制面	172.20.0.0/28	本例私有 endpoint 的专属范围

在企业项目工作目录的本机终端执行；替换项目、区域及可用区，不能直接套用到已有生产网络。

export PROJECT_ID='REPLACE_PROJECT'
export REGION='REPLACE_REGION'
export ZONES='REPLACE_ZONE_A,REPLACE_ZONE_B,REPLACE_ZONE_C'
export NETWORK=orders-enterprise
export SUBNET=orders-gke
export POD_RANGE=orders-pods
export SERVICE_RANGE=orders-services
export MASTER_CIDR=172.20.0.0/28
export CLUSTER='orders-staging'
export NODE_SA="gke-orders-node@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud config set project "$PROJECT_ID"
gcloud services enable container.googleapis.com compute.googleapis.com artifactregistry.googleapis.com
gcloud compute networks subnets list --network="$NETWORK"
gcloud compute addresses list --global --filter='purpose=VPC_PEERING'
gcloud compute networks subnets create "$SUBNET" \
  --network="$NETWORK" \
  --region="$REGION" \
  --range=10.64.0.0/24 \
  --secondary-range="$POD_RANGE=10.68.0.0/18,$SERVICE_RANGE=10.69.0.0/22" \
  --enable-private-ip-google-access
gcloud iam service-accounts create gke-orders-node
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/container.defaultNodeServiceAccount

创建私网管理机及出站路径#

Cloud NAT为没有外部 IP 的 VM 提供访问普通互联网的出站地址转换；Private Google Access 用于访问支持的 Google API 和服务。两者不负责入站 SSH；本例入站登录走 IAP。

企业项目配套 Terraform 没有 Cloud NAT；本篇为新 GKE subnet 补充出网，用于 runner 安装工具及外部依赖。已有 NAT 时先检查范围并复用，不能创建覆盖重叠范围的 NAT。创建无云 Service Account、无公网 IP 的 runner，登录者使用自己的短期身份：

export RUNNER_ZONE=${ZONES%%,*}
gcloud compute routers create orders-gke-router --network="$NETWORK" --region="$REGION"
gcloud compute routers nats create orders-gke-nat \
  --router=orders-gke-router \
  --region="$REGION" \
  --nat-custom-subnet-ip-ranges="$SUBNET:ALL" \
  --auto-allocate-nat-external-ips
gcloud compute firewall-rules create orders-gke-iap \
  --network="$NETWORK" \
  --allow=tcp:22 \
  --source-ranges=35.235.240.0/20 \
  --target-tags=orders-gke-runner
gcloud compute instances create orders-gke-runner \
  --zone="$RUNNER_ZONE" \
  --subnet="$SUBNET" \
  --no-address \
  --no-service-account \
  --no-scopes \
  --machine-type=e2-small \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --metadata=enable-oslogin=TRUE \
  --tags=orders-gke-runner
export ADMIN_CIDR="$(gcloud compute instances describe orders-gke-runner --zone="$RUNNER_ZONE" --format='value(networkInterfaces[0].networkIP)')/32"
gcloud artifacts repositories add-iam-policy-binding "$ARTIFACT_REPO" \
  --location="$REGION" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/artifactregistry.reader
export OPERATOR='user:REPLACE_OPERATOR_EMAIL'
gcloud iam service-accounts add-iam-policy-binding "$NODE_SA" --member="$OPERATOR" --role=roles/iam.serviceAccountUser

操作者另需 GKE 管理、IAP 隧道与 OS Login 权限；不向节点 SA 授予 Editor。ADMIN_CIDR 限定 runner 内网 /32；重建 runner 后需更新 Authorized networks。节点身份负责拉镜像，业务云访问使用独立 KSA。

2. 建区域集群#

先理解控制面的访问 endpoint#

控制面 endpoint 是 kubectl 等客户端访问 Kubernetes API Server 的入口，保存在 kubeconfig 的 server 字段；业务应用的 Ingress / LoadBalancer 是另一条访问路径。

入口	客户端通过什么地址访问	需要考虑什么
DNS-based endpoint	GKE 为集群提供的域名，通过 HTTPS 调用 Kubernetes API	到 Google Cloud API 的网络访问能力，以及 endpoint 的访问配置；通常用 Google IAM 凭据认证
internal IP endpoint	控制面的内部 IP	到这个私有地址的网络路径，以及适用的 Authorized networks、认证和权限
external IP endpoint	控制面的外部 IP	是否启用外部访问、 Authorized networks 及认证和权限

DNS-based endpoint 经 Google Cloud API 网络路径访问，无须先建立到控制面内部 IP 的路由。使用 Google IAM 凭据时需 container.clusters.connect 等权限，Kubernetes 操作仍另行授权。endpoint 配置

集群内部 DNS 用于 Pod 解析 service.namespace.svc.cluster.local，由 kube-dns / Cloud DNS 等实现提供。关闭控制面的 DNS-based endpoint 不影响它。

本例为什么关闭 DNS-based endpoint#

本例只保留 IAP → runner → internal IP endpoint 管理路径，关闭 external IP 和 DNS-based endpoint，并将内部入口的 Authorized networks 限定为 runner /32。

跨网络管理也可选择 DNS-based endpoint 配合 IAM；关闭它是本例的路径选择，并非生产要求。

参数	配置的是哪一层
创建/更新集群的 `--enable-dns-access` / `--no-enable-dns-access`	启用或关闭 DNS 管理入口
创建/更新集群的 `--enable-private-endpoint`	关闭外部 IP 管理入口，使用内部 IP 入口；DNS 入口另行配置
`get-credentials --internal-ip`	在本机 kubeconfig 中选择内部 IP 入口
`get-credentials --dns-endpoint`	在本机 kubeconfig 中选择已启用的 DNS 入口；不会替你启用它

DNS 入口的 Enable Kubernetes tokens via DNS/Enable Kubernetes certificates via DNS 是额外允许 Kubernetes ServiceAccount Token / X.509 客户端证书认证的选项。正常通过 gke-gcloud-auth-plugin 使用 Google 身份访问时，无须为此开启这两个选项。

创建命令#

采用区域控制面，初始节点作为系统池；--num-nodes=1 是每个选定 Zone 一台。按上述选择创建集群：

gcloud container clusters create "$CLUSTER" \
  --region="$REGION" \
  --node-locations="$ZONES" \
  --release-channel=regular \
  --network="$NETWORK" \
  --subnetwork="$SUBNET" \
  --enable-ip-alias \
  --cluster-secondary-range-name="$POD_RANGE" \
  --services-secondary-range-name="$SERVICE_RANGE" \
  --enable-private-nodes \
  --enable-private-endpoint \
  --no-enable-dns-access \
  --master-ipv4-cidr="$MASTER_CIDR" \
  --enable-master-authorized-networks \
  --master-authorized-networks="$ADMIN_CIDR" \
  --enable-authorized-networks-on-private-endpoint \
  --workload-pool="${PROJECT_ID}.svc.id.goog" \
  --service-account="$NODE_SA" \
  --scopes=cloud-platform \
  --enable-dataplane-v2 \
  --enable-shielded-nodes \
  --machine-type=e2-standard-4 \
  --num-nodes=1 \
  --disk-size=100 \
  --node-labels=pool=system \
  --enable-autorepair \
  --enable-autoupgrade \
  --logging=SYSTEM,WORKLOAD \
  --monitoring=SYSTEM \
  --enable-managed-prometheus

参数	作用与本例选择
`--region` / `--node-locations`	前者设置区域型集群位置，后者决定节点部署在哪些 Zone；节点 Zone 必须属于该 Region
`--network` / `--subnetwork`	选择节点接入的 VPC 和区域 subnet
`--enable-ip-alias` 与两个 `--*-secondary-range-name`	使用 VPC-native 网络，分别引用 subnet 中已有的 Pod 和 Service secondary IP range
`--enable-private-nodes`	节点不分配外部 IP；出网路径由 Private Google Access、NAT 等配置决定
`--enable-private-endpoint` / `--no-enable-dns-access`	分别关闭外部 IP 和 DNS 管理入口，保留上文说明的内部 IP 管理路径
`--master-authorized-networks` / `--enable-authorized-networks-on-private-endpoint`	将 Authorized networks 限制应用到私有 endpoint，本例只允许 runner 的内部 `/32` 地址
`--workload-pool`	启用 Workload Identity Federation for GKE，供 Pod 使用独立工作负载身份访问 Google API
`--service-account`	为节点配置 Google Service Account，负责节点职责；不等于业务 Pod 的身份
`--release-channel=regular`	选择版本发布及自动升级频道，维护时间另按升级篇配置
`--enable-dataplane-v2`	使用 GKE 托管的 Dataplane V2 容器网络数据面，负责 Pod 流量转发及网络策略执行
`--enable-shielded-nodes`	使用 Shielded GKE Nodes 的节点身份与完整性保护能力
`--enable-managed-prometheus`	启用 Google 托管 Prometheus 指标采集能力；不是创建另一个 Kubernetes 集群
`--node-labels=pool=system`	为初始节点设置标签，供调度选择；标签本身不会把业务 Pod 自动排除出去

下面第一条 gcloud compute ssh 在本机执行；登录后的安装和认证在 runner 执行。远程 shell 不继承本机变量，需重新设置 PROJECT_ID、REGION、CLUSTER；安装命令适用于 Debian 12。

gcloud compute ssh orders-gke-runner --zone="$RUNNER_ZONE" --tunnel-through-iap
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg git
curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo 'deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main' | sudo tee /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update
sudo apt-get install -y google-cloud-cli google-cloud-cli-gke-gcloud-auth-plugin kubectl
gcloud auth login --no-launch-browser
export PROJECT_ID='REPLACE_PROJECT'
export REGION='REPLACE_REGION'
export CLUSTER=orders-staging
gcloud config set project "$PROJECT_ID"

配置 kubectl 的集群入口#

kubeconfig是 kubectl 的本地连接配置，保存集群地址、证书校验信息和认证方式；context 把集群、调用者认证配置及默认 namespace 组合成一个可切换的目标。gke-gcloud-auth-plugin 是 kubectl 调用的认证插件，用于获取 Google 身份令牌。

get-credentials 更新当前机器的 kubeconfig 并切换 context；默认写入 ~/.kube/config，可由 KUBECONFIG 指定位置。它不授予 Kubernetes 权限。

在刚登录并完成认证的 runner 中执行：

gcloud container clusters get-credentials "$CLUSTER" \
  --project="$PROJECT_ID" \
  --region="$REGION" \
  --internal-ip

参数	含义
`--project`	明确集群所属项目，避免操作当前 gcloud 配置中的其他项目
`--region`	区域型集群的位置；zonal 集群应使用 `--zone`，或统一使用 `--location`
`--internal-ip`	将 kubeconfig 的 API Server 地址设置为控制面的内部 IP；不负责建立 VPN、隧道或路由

runner 满足同 Region 私网路径及 Authorized networks 要求。get-credentials 成功只说明取得了配置，后续 kubectl 仍需网络可达、认证插件和 IAM/RBAC。DNS 入口参数见上表。命令说明

检查当前 context、API 就绪状态和节点：

kubectl config current-context
kubectl get --raw=/readyz
kubectl get nodes -L pool,topology.kubernetes.io/zone

预期 readyz 返回 ok，节点没有公网 IP。超时先检查 runner 路由、/32 授权与出站 443；Forbidden 则检查 IAM/RBAC，不扩大网络白名单。工具安装

release channel 决定可用版本；变更前查询 gcloud container get-server-config --region="$REGION"，将实际控制面/节点版本记录到变更单。需要精确首发版本时使用频道支持的 --cluster-version。生产维护窗口/排除按升级篇配置，不能无限期停止安全升级。

3. 添加业务 node pool#

nodeSelector / affinity 按标签等条件选择节点；taint / toleration 控制 Pod 能否被某类节点接纳。HPA 调整 Pod 副本数，节点自动扩缩容调整承载它们的机器数量。

node-pools create 为 Standard 集群添加名为 application 的业务池；Autopilot 由平台管理节点，无须此步骤。

回到保留前述环境变量的本机终端创建 node pool。下面先执行 gcloud 创建命令，完成后再到 runner 执行 kubectl 验收。

gcloud container node-pools create application \
  --cluster="$CLUSTER" \
  --region="$REGION" \
  --node-locations="$ZONES" \
  --machine-type=e2-standard-4 \
  --num-nodes=1 \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=3 \
  --node-labels=pool=application \
  --service-account="$NODE_SA" \
  --scopes=cloud-platform \
  --workload-metadata=GKE_METADATA \
  --enable-autorepair \
  --enable-autoupgrade \
  --max-surge-upgrade=1 \
  --max-unavailable-upgrade=0

关键参数	作用与本例结果
`--cluster` / `--region`	指定已有集群及其区域， node pool 在这个集群中创建
`--node-locations="$ZONES"`	节点分布在指定 Zone；不是给每个 Zone 创建不同 subnet
`--machine-type=e2-standard-4`	每台节点 VM 的机型为 4 vCPU、16 GiB 内存，Pod 可分配量会扣除系统预留
`--num-nodes=1`	初始每个选定 Zone 一台节点；若选三区，初始总数为三台
`--enable-autoscaling` / `--min-nodes=1` / `--max-nodes=3`	启用 node pool 自动扩缩容，每区范围为 1–3 台；三区合计 3–9 台，不是全池 1–3 台
`--node-labels=pool=application`	为节点添加标签；Pod 需配置对应 nodeSelector 或 affinity 才会定向调度到该池
`--service-account` / `--scopes=cloud-platform`	前者选择节点身份，后者设置 VM OAuth scope；实际 Google API 权限仍由 IAM 控制，并非自动授予全部权限
`--workload-metadata=GKE_METADATA`	使用 GKE metadata server，配合集群 Workload Identity，让 Pod 按工作负载身份访问 Google API
`--enable-autorepair` / `--enable-autoupgrade`	启用节点自动修复和自动升级；升级节奏还受频道及维护策略影响
`--max-surge-upgrade=1` / `--max-unavailable-upgrade=0`	滚动升级每区最多临时多建一台，不主动留出不可用节点额度；仍需额外配额、地址容量和可驱逐的业务 Pod

参数完整说明见 node-pools create。

回到 runner 验收：

kubectl get nodes -L pool,topology.kubernetes.io/zone

本例用 selector 将业务调度到 application 池；system 池没有 taint，不会排斥其他业务。复用 GKE 托管 CNI、CSI 和节点扩容能力，不另装第二套网络插件或 Cluster Autoscaler。

4. 身份、入口与验收#

后文涉及的应用与存储对象先按用途区分：

术语	在验收中检查什么
Mesh / 服务网格	管理服务间通信、身份和流量策略的层；本例具体安装与应用步骤在 ServiceMesh 文档
overlay	Kustomize 基础清单之上的环境定制配置，生成本环境实际部署对象
PDB（PodDisruptionBudget）	限制自愿驱逐时可中断的副本数
PVC（PersistentVolumeClaim）	Pod 对持久存储的申请；不是容器内部的临时目录
CNI / CSI	分别是容器网络、容器存储的接口体系；本篇复用 GKE 实现
PD（Persistent Disk）	Google 持久磁盘，可由 CSI 驱动挂载到 Pod
Ingress / Gateway / LB	入口路由对象、Gateway API 入口模型、云负载均衡器；与控制面管理 endpoint 分开
RoleBinding	在 Kubernetes 中把角色授予 Principal 的对象，常用于 namespace 范围授权

具体应用落地及数据库凭据导入使用 Mesh 第 3 节的配套清单；它复用本集群与企业项目 SQL，包含三副本、 PodDisruptionBudget 和网络策略。只练集群时可停在 node pool 验收，但不能据此标记“业务生产验收通过”。Mesh/业务完成后再做以下验收。

本配套应用通过独立数据库角色访问 SQL，不需要给 KSA 额外 Google API 权限。若新增 Storage 等访问，按 GKE Pod 身份配置资源级授权，并验证错误 KSA 被拒绝；节点 SA 仅负责节点职责。
配套 overlay 已包含业务 namespace 内的资源配额与网络策略。人员按 RBAC限定 namespace，并核对项目 IAM 继承授权；不能只查 RoleBinding 就认定人员无集群管理权限。
本业务数据持久化到 Cloud SQL，入口仅为网格内部 Service；不需要再部署一套订单基线。需要公开入口或持久卷时，另做 Gateway和托管 PD CSI 实验，使用 GKE 实现支持的类与策略。
Cloud Logging 验证控制面/工作负载日志；涉及 Data Access 的审计类别在项目审计配置中显式启用并核对费用/保留。
外网 endpoint 不可达，私网授权 runner 可达；Mesh 正反向身份测试通过；按下一节排空业务节点并对账。

gcloud container clusters describe "$CLUSTER" \
  --region="$REGION" \
  --format='yaml(currentMasterVersion,privateClusterConfig,controlPlaneEndpointsConfig,masterAuthorizedNetworksConfig,workloadIdentityConfig,nodePools)'
kubectl -n orders-mesh get pods -o wide

失败先修 Authorized networks /路由，不能直接开放 0.0.0.0/0 排障。删除前按序迁流、备份并验证恢复、清理 LB/PVC/静态地址；保留审计与制品。不要把删除集群当 node pool 回滚。

5. 节点排空期间的业务验收#

**节点排空（drain）**是先禁止向目标节点调度新 Pod，再通过驱逐让现有应用 Pod 迁走，用来模拟节点维护。uncordon恢复节点接受新 Pod 的能力。emptyDir 是随 Pod 生命周期存在的临时卷；本例 --delete-emptydir-data 允许驱逐使用它的 Pod，会丢弃这些临时数据。

完成 Mesh 身份验收后，在 runner 执行；数据库在 Cloud SQL，下面删除的 emptyDir 只是应用临时目录。保留正确身份客户端，移除两个负向测试 Pod，避免无控制器 Pod 阻断 drain。选另一台承载 API 的节点，不排空客户端所在节点。

kubectl -n orders-mesh delete pod mesh-wrong mesh-plain
export CLIENT_NODE=$(kubectl -n orders-mesh get pod mesh-good -o jsonpath='{.spec.nodeName}')
export NODE=$(kubectl -n orders-mesh get pods -l app.kubernetes.io/name=orders-api -o json | python3 -c 'import json,os,sys; print(next(p["spec"]["nodeName"] for p in json.load(sys.stdin)["items"] if p["spec"].get("nodeName") != os.environ["CLIENT_NODE"]))')
test -n "$NODE"
# 另一个 runner 终端运行，覆盖排空前、排空中和恢复后；IMAGE 为已批准摘要。
for i in $(seq 1 60); do python3 ~/check.py business --image="$IMAGE" || break; sleep 2; done > drain-business.log 2>&1

上述循环运行期间，在原 runner 终端排空；不会跳过 PDB，不使用 --force。即使失败也执行 uncordon，避免把实验故障遗留给后续章节：

kubectl drain "$NODE" --ignore-daemonsets --delete-emptydir-data --timeout=10m
kubectl uncordon "$NODE"
kubectl -n orders-mesh rollout status deployment/orders-api --timeout=10m
kubectl -n orders-mesh rollout status deployment/orders-worker --timeout=10m
kubectl -n orders-mesh get pods,pdb -o wide

验收日志需持续产生订单成功与金额一致结果；若循环提前结束，按失败处理并保留最后错误，不能只看 drain 成功。确认三副本恢复、PDB 重新有可驱逐额度。驱逐超时先查 PDB、节点配额/Pod IP、拓扑约束和未结束请求，再决定修复，不能直接强杀。

6. 收尾顺序#

完成 Mesh、升级和恢复演练后，从本机执行。先删除本篇业务 namespace/外部 LB 等，再清理集群及 runner；以下只针对本篇专属资源，不删除企业项目数据库或 VPC：

gcloud container clusters delete "$CLUSTER" --region="$REGION"
gcloud compute instances delete orders-gke-runner --zone="$RUNNER_ZONE"
gcloud compute firewall-rules delete orders-gke-iap
gcloud compute routers nats delete orders-gke-nat --router=orders-gke-router --region="$REGION"
gcloud compute routers delete orders-gke-router --region="$REGION"
gcloud compute networks subnets delete "$SUBNET" --region="$REGION"
gcloud projects remove-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/container.defaultNodeServiceAccount
gcloud artifacts repositories remove-iam-policy-binding "$ARTIFACT_REPO" \
  --location="$REGION" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/artifactregistry.reader
gcloud iam service-accounts delete "$NODE_SA"
gcloud container fleet memberships list --project="$PROJECT_ID"

Fleet membership 是集群加入 GKE Fleet（统一管理多个集群的逻辑分组）后的登记对象，不是节点或 Pod。

核对是否残留本集群的 fleet membership、磁盘和 LB 地址；不要删除其他集群的 membership 或项目共享 Mesh feature。若在现有 NAT 上复用，本节不删除该共享 NAT/router。最后才能按企业项目的清理流程处理 SQL 和 VPC，避免 IaC 删除网络时被本篇 subnet 占用。

参考：创建参数、网络隔离、node pool。