云托管 K8s 实战（四）：GCP GKE 端到端

写在前面

版本说明：当前版 gcloud CLI 与 GKE GA 能力（2026）；可用版本和默认设置会随区域、发布渠道及集群模式变化，创建前以官方版本表为准。

承接 EKS 篇。三家最后一站是 GCP GKE。Kubernetes 源于 Google 并由 CNCF 社区治理，GKE 是 Google Cloud 的托管 Kubernetes 产品。本篇重点介绍 Autopilot：节点基础设施由 GCP 管理，用户主要围绕工作负载声明资源需求。

1
2
3
GKE 两种模式：
  Standard   你管理节点池与更多基础设施选项
  Autopilot  GCP 管理节点基础设施，按其资源计费模型收费 ← 本篇主用

1
2
3
4
5
6
7
8
本篇路线（7 步，和前几篇对齐）：
  ① 准备：gcloud + 项目
  ② 建 Artifact Registry + 推镜像
  ③ 创建 GKE 集群（Autopilot 一条命令）
  ④ 身份：节点身份拉镜像 + Workload Identity 访问云 API
  ⑤ 部署 + 暴露（Cloud LB，零配置）
  ⑥ 接监控（Cloud Operations，开箱即用）
  ⑦ 清理 + 算账（Autopilot 按 Pod）

一、准备：gcloud + 项目

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 装 gcloud CLI（略，见官方）
# 登录（开浏览器）
gcloud auth login

# 选项目（GCP 一切资源归"项目"，类似 Azure 订阅）
gcloud projects list
gcloud config set project <你的项目 ID>

# 设默认区域
gcloud config set compute/region us-central1

启用 GKE API（新项目首次）： gcloud services enable container.googleapis.com artifactregistry.googleapis.com

二、建 Artifact Registry + 推镜像

Artifact Registry（AR）——GCP 镜像仓库，取代老的 GCR（Container Registry）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
PROJ=$(gcloud config get-value project)
REGION=us-central1
REPO=$REGION-docker.pkg.dev/$PROJ/demo-repo

# 建 AR 仓库
gcloud artifacts repositories create demo-repo \
  --repository-format=docker --location=$REGION

# 配 docker 认证
gcloud auth configure-docker $REGION-docker.pkg.dev

构建并推：

1
2
3
4
5
6
7
cat > Dockerfile <<'EOF'
FROM nginx:alpine
RUN echo "<h1>Hello from GKE</h1>" > /usr/share/nginx/html/index.html
EOF

docker build -t $REPO/web:v1 .
docker push $REPO/web:v1

三、创建 GKE 集群（Autopilot 一条命令）

1
2
3
CLUSTER=myGKE
gcloud container clusters create-auto $CLUSTER \
  --region $REGION

就这一行。Autopilot 没有 --num-nodes（你不管节点），GCP 自动调度 Pod、自动扩缩、自动补节点。

Standard 模式对比（你自己管节点）：

1
2
gcloud container clusters create $CLUSTER \
  --region $REGION --num-nodes 2 --machine-type e2-medium

接入集群：

1
2
3
gcloud container clusters get-credentials $CLUSTER --region $REGION
kubectl get nodes
# Autopilot 的节点是 GCP 自动起的，你看不到具体机型选型

创建耗时会随区域、容量和网络配置变化。Autopilot 由 GCP 管理节点基础设施，但集群仍产生 $0.10/h 的管理费；每个结算账户的月度免费额度可抵扣一个符合条件的 Autopilot 或 zonal Standard 集群。

四、身份：节点身份拉镜像，Workload Identity 授权应用

私有镜像由节点上的 kubelet 在 Pod 启动前拉取，因此要确保节点服务账号对目标 Artifact Registry 仓库具有读取权限。不要假设任意项目的默认服务账号必然已有该角色；使用自定义节点服务账号和最小权限更稳妥。

1
2
3
Pod 拉镜像 → kubelet 用节点 default SA
           → 该节点 SA 必须有目标仓库的 AR reader 权限
           → 拉取成功（粗粒度）

Workload Identity Federation for GKE 用于给已经启动的应用授予访问 Cloud Storage、Pub/Sub 等 Google Cloud API 的权限，不参与 kubelet 拉取镜像。下面展示兼容的 KSA→IAM 服务账号关联方式；新项目也可按官方建议直接授权给 Kubernetes ServiceAccount principal。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
GSA=web-gcp-sa      # GCP 服务账号
KSA=web-k8s-sa      # K8s 服务账号

# 1. 建 IAM 服务账号，并按应用实际需要授予最小权限（此处仅作占位示例）
gcloud iam service-accounts create $GSA

# 演示：允许读取项目内 Cloud Storage 对象；生产应缩小到实际资源和权限
gcloud projects add-iam-policy-binding $PROJ \
  --member="serviceAccount:$GSA@$PROJ.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# 2. 允许 K8s SA 模拟这个 GCP SA（Workload Identity 绑定）
gcloud iam service-accounts add-iam-policy-binding \
  $GSA@$PROJ.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:$PROJ.svc.id.goog[default/$KSA]"

# 3. 在集群里建带注解的 K8s SA
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: $KSA
  namespace: default
  annotations:
    iam.gke.io/gcp-service-account: $GSA@$PROJ.iam.gserviceaccount.com
EOF

Deployment 指定 serviceAccountName: web-k8s-sa 后，应用用绑定身份调用获准的 Google Cloud API；镜像仍由 kubelet 使用节点服务账号拉取。

1
2
3
4
三家身份机制本质同构（OIDC 联邦 + SA 注解）：
  AKS  Managed Identity + Workload Identity（OIDC）
  EKS  IRSA（IAM Roles for ServiceAccounts，OIDC）
  GKE  Workload Identity（K8s SA ↔ GCP SA 映射）

GKE 的 Workload Identity 三步绑定比 IRSA 略繁（多一步"允许模拟"），但思路一致。会一个就会另两个。

五、部署 + 暴露：Cloud Load Balancer（零配置）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# web.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      serviceAccountName: web-k8s-sa
      containers:
      - name: web
        image: <REGION>-docker.pkg.dev/<PROJ>/demo-repo/web:v1
        ports: [{ containerPort: 80 }]

1
2
3
4
5
6
7
8
9
# 填镜像
sed -i "s|<REGION>|$REGION|;s|<PROJ>|$PROJ|" web.yaml
kubectl apply -f web.yaml

# 暴露（type=LoadBalancer → GCP 自动建 Cloud LB）
kubectl expose deployment web --port=80 --target-port=80 --type=LoadBalancer
kubectl get svc web -w
# NAME   TYPE           EXTERNAL-IP     ...
# web    LoadBalancer   34.x.x.x        # GCP 分配的公网 IP

1
2
3
4
GKE 的暴露对比：
  GKE  type=LoadBalancer → 内置 cloud controller 自动建 Cloud LB（像 AKS，零配置）
       不用装额外 controller（EKS 要装 AWS LB Controller）
       七层用 GCE Ingress Controller（内置）

GKE 在"暴露服务"这一步的开箱即用程度和 AKS 持平，比 EKS 省事。

六、接监控：Cloud Operations（开箱即用）

GKE 集群创建时默认启用 Cloud Monitoring 和 Cloud Logging（除非显式关）。不用装 addon。

Cloud Logging：所有容器 stdout/stderr 自动进 Cloud Logging。
Cloud Monitoring：集群/Pod/节点指标进 Cloud Monitoring，有现成的 GKE Dashboard。

查日志（Cloud Logging 里）：

1
2
3
resource.type="k8s_container"
resource.labels.cluster_name="myGKE"
severity>=ERROR

要更细的可观测性（PromQL、分布式追踪）：

1
2
3
# 启用 managed Prometheus
gcloud container clusters update $CLUSTER --region $REGION \
  --enable-managed-prometheus

GKE 监控是三家最省心的——默认全开，控制台一站式看，不用配 IRSA/addon（EKS 要 addon，AKS 要 enable-addons）。

七、清理 + 算账（Autopilot 按 Pod）

1
2
3
4
5
# 删集群（Autopilot 删了集群，Pod 计费即停，无残留节点）
gcloud container clusters delete $CLUSTER --region $REGION

# 删 AR 仓库（可选）
gcloud artifacts repositories delete demo-repo --location=$REGION

Autopilot 成本（按 Pod，粗算）：

1
2
3
4
5
6
7
Autopilot（按 Pod，us-central1）：
  Pod 资源费                          随计算类、request、区域及承诺折扣变化
  另有集群管理费                       $0.10/集群小时，可受月度额度抵扣

对比 Standard（按节点，同区域）：
  节点计算费                         按所选机型、磁盘、区域和折扣计算
  集群管理费                         $0.10/集群小时；zonal 集群可受月度额度抵扣

Autopilot 适合：流量波动大、不想管节点、Pod 数量不多（<几十）。Standard 适合：节点多、要自定义机型/守护进程、长期稳定负载（按节点更省）。

Autopilot 单价高于 Standard 单节点均摊——规模化后 Standard 反而便宜。选型看 Pod 数和负载曲线。

八、踩坑速记

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
坑 1：Autopilot 不能自定义节点
  → 不能跑 hostNetwork、特权容器受限、某些 DaemonSet 不能用
  → 需要这些选 Standard

坑 2：Workload Identity 绑定不生效
  → 检查集群是否启用 WI（Standard 模式建集群要加 --workload-pool=<PROJ>.svc.id.goog）
  → Autopilot 默认开

坑 3：出口与跨区域流量会增加成本
  → 单价取决于来源、目的地、层级和区域，按 GCP 当前网络价格表计算
  → 用 Cloud CDN / 把依赖放同区

坑 4：Autopilot 修改或拒绝资源请求
  → 当请求低于最小值、缺失或不符合规则时，GKE 可能补默认值、向上调整或拒绝调度；不会承诺按少于 request 的资源运行
  → 部署前核对 Autopilot 的最小值、上限和突发规则

坑 5：删集群漏镜像库
  → 集群删了，AR 还在（按存储收费）
  → 单独删 AR

九、小结

GKE 的体感一句话：与 Google Cloud 集成紧密，Autopilot 能显著减少节点基础设施运维，但要接受其资源与安全约束。

1
2
3
4
5
6
7
GKE 端到端的核心：
  gcloud auth login → artifacts create → docker push
  → gcloud container clusters create-auto（Autopilot，一条命令，节点基础设施由 GCP 管理）
  → 节点服务账号拉 AR；应用访问 Google Cloud API 时用 Workload Identity 细粒度授权
  → type=LoadBalancer（内置 Cloud LB，零配置）
  → Cloud Operations（默认启用，不用 addon）
  → gcloud container clusters delete（删除后停止该集群的管理费和工作负载资源费）

适合谁：追求开箱即用、希望减少节点运维、负载形态符合 Autopilot 约束的团队。它与 AKS Automatic、EKS Auto Mode、Fargate/Virtual Nodes 的抽象层次和限制不同，应按工作负载而不是一句“谁更省心”选型。

不适合谁：要深度定制节点（特权/DaemonSet）、超大稳定负载（Standard 更省）、强 AD/企业合规（GCP 这块弱于 Azure）。

下一篇：横向对比 + 选型——把三家的创建/网络/身份/监控/成本/Serverless 摆一起，给一张"什么场景选哪个"的决策表。