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

写在前面

版本说明：gcloud CLI + GKE 1.30（2026）；命令在 us-central1 验证。

承接 EKS 篇。三家最后一站：GCP GKE——K8s 的"娘家"（K8s 最初是 Google 开源的，GKE 是它的官方实现）。本篇的重点是 GKE 的招牌模式 Autopilot：连节点都不用管，GCP 全托管，按 Pod 计费。

1
2
3
GKE 两种模式：
  Standard   你管节点（像 AKS/EKS），控制平面免费
  Autopilot  GCP 管节点 + 控制平面，按 Pod 计费，零节点运维 ← 本篇主用

1
2
3
4
5
6
7
8
本篇路线（7 步，和前几篇对齐）：
  ① 准备：gcloud + 项目
  ② 建 Artifact Registry + 推镜像
  ③ 创建 GKE 集群（Autopilot 一条命令）
  ④ 身份：Workload Identity 拉私有镜像
  ⑤ 部署 + 暴露（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 自动起的，你看不到具体机型选型

创建速度 ~5-8 分钟，比 EKS 快不少。Autopilot 控制平面免费、节点 GCP 兜底。

四、身份：Workload Identity 拉私有镜像

GKE 的镜像拉取也有两层：

第一层（默认能用）：GKE 节点用 Compute Engine 默认服务账号，它默认有 roles/artifactregistry.reader → 节点上所有 Pod 默认能拉 AR。

1
2
3
Pod 拉镜像 → kubelet 用节点 default SA
           → 默认 SA 有 AR reader 角色
           → 拉取成功（粗粒度）

第二层（生产推荐 Workload Identity）：把 K8s ServiceAccount 映射到 GCP ServiceAccount，Pod 用 GCP SA 的权限（细粒度）。

 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
GSA=web-gcp-sa      # GCP 服务账号
KSA=web-k8s-sa      # K8s 服务账号

# 1. 建 GCP SA，授 AR reader
gcloud iam service-accounts create $GSA
gcloud projects add-iam-policy-binding $PROJ \
  --member="serviceAccount:$GSA@$PROJ.iam.gserviceaccount.com" \
  --role="roles/artifactregistry.reader"

# 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，Pod 就用绑定的 GCP SA 权限。

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
8
Autopilot（按 Pod，us-central1）：
  每个 Pod（如 0.5 vCPU + 1GB）   ~$0.035/小时
  2 个 Pod 跑一小时                 ~$0.07
  无节点空载费、无控制平面费          ✓ 停了就不计费

对比 Standard（按节点，同区域）：
  2 × e2-medium 节点                ~$0.067/小时（即使空载也收）
  控制平面                           免费

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 出口 ~$0.085/GB，跨区流量也收费
  → 用 Cloud CDN / 把依赖放同区

坑 4：Autopilot Pod 被"压缩"
  → GCP 可能给 Pod 分配少于 request 的资源（有上限保护）
  → 关键负载用 Standard

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

九、小结

GKE 的体感一句话：K8s 娘家出品，体验最顺，Autopilot 把"省心"做到极致。

1
2
3
4
5
6
7
GKE 端到端的核心：
  gcloud auth login → artifacts create → docker push
  → gcloud container clusters create-auto（Autopilot，一条命令，无节点）
  → 节点默认 SA 能拉 AR；生产用 Workload Identity 细粒度
  → type=LoadBalancer（内置 Cloud LB，零配置）
  → Cloud Operations（默认启用，不用 addon）
  → gcloud container clusters delete（Autopilot 停 Pod 即停费）

适合谁：追求开箱即用、不想管节点、流量波动大的团队。Autopilot 是三家里唯一让你"只管应用、不管节点"的（AKS/EKS 的 Virtual Nodes/Fargate 也有但不如 Autopilot 主流）。

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

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