GKE Autopilot：工作负载与故障定位

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

节点由 GKE 按工作负载需求管理；先确认 kubectl context。

常用操作#

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

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

gcloud container clusters describe "$CLUSTER" --project="$PROJECT_ID" --region="$REGION"
# describe 不切换 kubectl context；先核对下面的 context 指向该集群。
kubectl config current-context
kubectl get nodes -o wide -L topology.kubernetes.io/zone
kubectl get pods -A -o wide

容易踩的坑#

get-credentials 更新本机配置，不建立私网连接或授予 RBAC。
Pending 先查 Events：等待供应、配额/IP 不足、调度限制分别处理；不要手建 Autopilot node pool。

Pending 检查 · Pod 身份 · 网络 · Ingress

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

前置：保留 VPC 和 Artifact Registry 中的镜像；安装 kubectl 与 GKE auth plugin。Autopilot 管理节点配置，但应用资源、IAM、网络与费用仍由你负责。

Standard/node pool 见 Standard 实验，网络模型见 GKE 网络，应用公网入口见 Ingress。

先认识本篇使用的对象#

对象	含义
控制面 / API Server	管理集群并接收 kubectl 请求的服务，由 GKE 托管
Node / 节点	承载应用 Pod 的工作机器，Autopilot 管理其供应与回收
Pod	Kubernetes 调度容器的基本单位，一个 Pod 可以包含多个容器
Deployment	声明应用副本数和更新方式的控制器，持续创建和维护 Pod
namespace	集群内的资源分组与授权范围，本例使用 `lab`
Google SA / Kubernetes SA（KSA）	分别是 Google Cloud 身份和集群工作负载身份，两者不是同一对象

IAM 管理 Google Cloud 资源权限。下文 NODE_SA 是节点的 Google Service Account；操作者所需的 actAs 权限允许将它附加到集群节点，不代表自动获得该账号的全部权限。节点身份和业务身份要分别管理。

集群与应用#

已有集群的补丁、跨版本升级与恢复操作见 GKE 安全升级 Hands-on。

生产组件选型见企业级 Add-ons，存储见 CSI 与 GKE PD。Autopilot 优先复用托管能力，不直接照搬自建 CNI、节点扩容或特权日志 Agent。

source lab.env
gcloud services enable container.googleapis.com
export NODE_SA="lab-gke-node@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts create lab-gke-node
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/container.defaultNodeServiceAccount
gcloud artifacts repositories add-iam-policy-binding lab-images \
  --location="$REGION" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/artifactregistry.reader
# 操作者还需 NODE_SA 上的 actAs。

创建 Autopilot 集群#

create-auto 创建由 GKE 管理节点的集群：--region 决定集群区域，--network / --subnetwork 指定节点网络，--service-account 配置节点身份。业务 Pod 的云权限另外通过 Workload Identity 授予，不直接复用节点身份。

gcloud container clusters create-auto lab-gke \
  --region="$REGION" \
  --network=lab-vpc \
  --subnetwork=lab-subnet \
  --service-account="$NODE_SA"

让 kubectl 连接集群#

kubeconfig是 kubectl 的本地连接配置；context 是其中组合了集群、认证配置和默认 namespace 的操作目标。认证插件 gke-gcloud-auth-plugin 为 kubectl 获取 Google 身份令牌。

get-credentials 获取集群 endpoint 和认证配置，写入本机 kubeconfig 并切换当前 context；它不创建工作负载，也不授予集群权限。先确认 gke-gcloud-auth-plugin --version 可运行；SDK 安装方式可用 gcloud components install gke-gcloud-auth-plugin 补齐插件，apt 安装方式见官方指南。

gcloud container clusters get-credentials lab-gke \
  --project="$PROJECT_ID" \
  --region="$REGION"
kubectl config current-context

endpoint 是 kubectl 访问 API Server 的入口，DNS-based 使用域名、internal IP 使用私有地址，与 Pod 的 Service DNS 不同。选择与网络前提见控制面 endpoint。

--project / --region 定位集群。启用 IP 访问时默认选 IP endpoint；--dns-endpoint 选择已启用的 DNS 入口，--internal-ip 选择需私网可达的内部入口。工具安装见官方指南。

部署与验证应用#

应用资源里的 requests是调度时要求预留的 CPU / 内存，limits 是运行时资源限制。Autopilot 根据 Pod 需求和调度约束供应节点，未设置的资源请求可能由平台补默认值；节点数不与业务 Pod 数一一对应。工作负载需要扩副本时可使用 HPA（Horizontal Pod Autoscaler，按指标自动调整 Pod 副本数的控制器），节点扩容由平台处理。

下面创建 namespace、Kubernetes ServiceAccount 和应用 Deployment，再等待部署就绪。Autopilot 空集群可以没有可用节点，系统 Pod 保持 Pending；部署业务 Pod 后，平台会按资源需求创建节点。

kubectl create namespace lab
kubectl -n lab create serviceaccount app
kubectl -n lab create deployment hello --image="${REGION}-docker.pkg.dev/${PROJECT_ID}/lab-images/hello:v1"
kubectl -n lab set serviceaccount deployment/hello app
kubectl -n lab rollout status deployment/hello --timeout=600s
kubectl -n lab port-forward deployment/hello 8080:8080

rollout status --timeout=600s 等待 Deployment 就绪，首次供应节点需要时间；持续 Pending 时检查 Pod 事件中的扩容失败原因。port-forward deployment/hello 8080:8080 把本机 8080 转发到选中的应用 Pod 的 8080，命令会占用当前终端。

保持转发进程运行，另一个终端 curl http://127.0.0.1:8080 应返回 hello。端口转发不创建公网 LoadBalancer。

持续 Pending：根据事件决定下一步#

先停止 port-forward 或另开一个已配置 context 的终端，只读检查：

kubectl -n lab get pods -o wide
kubectl -n lab describe pods -l app=hello
kubectl -n lab get events --sort-by=.metadata.creationTimestamp
kubectl get nodes -o wide -L topology.kubernetes.io/zone

事件 / 状态	下一步
TriggeredScaleUp，节点正在供应	等待节点 Ready，再观察 Deployment；不手工添加 Autopilot node pool
FailedScaleUp / 配额或容量不足	按具体 message 查配额、Zone 容量和 Pod IP 余量；反复重建 Pod 不能解决它
FailedScheduling，selector / affinity 不匹配	检查 Pod requests 和调度约束是否能被支持的节点满足
ImagePullBackOff	查镜像路径、节点 SA 的仓库权限及网络；不是没有节点

节点数由 requests、调度约束和系统开销等共同决定，不是“一份 Deployment 对应一台 Node”。Autopilot 排障

Workload Identity Federation for GKE#

Pod 使用 KSA 和短期凭据访问 Google Cloud API，Node SA 继续负责镜像拉取。独立操作参考见 Pod 访问 Bucket 与 Secret Manager，包含资源级授权、Pod/SDK 读取、撤权测试与 impersonation 备选方案。

若曾执行旧版 lab/app 的 Bucket 授权示例，删除集群前先移除该 KSA Principal 在 Bucket 上的 binding；删除集群不会自动清除资源 IAM 授权。

清理#

若继续 Ingress 实验，保留集群；全部完成后先按 Ingress 页回收 LB，再删除集群及身份：

gcloud container clusters delete lab-gke --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 lab-images \
  --location="$REGION" \
  --member="serviceAccount:$NODE_SA" \
  --role=roles/artifactregistry.reader
gcloud iam service-accounts delete "$NODE_SA"

清理前检查 PVC、外部 LB、地址；删除集群不代表所有外围资源都自动清除。