在 Google Cloud 上搭建 GKE 集群，核心思路是利用谷歌托管的 Kubernetes 控制平面，把节点资源与网络边界交给用户自定义。GKE 全称 Google Kubernetes Engine，它屏蔽了 etcd、API Server 的高可用运维细节，但使用者依然要理解项目层级配额、服务账号授权以及 VPC 原生网络的工作方式。只有把这些前置依赖理顺，后续创建集群才不会频繁报错。
一、准备工作与项目环境初始化
在真正创建 GKE 集群之前，必须先拥有一个 Google Cloud 项目并完成账单账号绑定。GKE 本身不单独收费，但节点虚拟机、负载均衡器和出站流量都会产生费用。你需要安装 gcloud 命令行工具，并通过 gcloud auth login 完成 OAuth 身份认证，再用 gcloud config set project [PROJECT_ID] 锁定默认项目。很多操作失败的原因其实是当前账号缺少 container.clusters.create 权限，或者项目未开通 Container API。
启用 Container API 是强制步骤，可以通过命令 gcloud services enable container.googleapis.com 完成。与此同时，建议单独创建一个服务账号专门用于 CI/CD 流水线，而不是一直使用个人账号。这样在集群出问题时可以精确回收权限。下面的代码展示了如何新建服务账号并赋予 Kubernetes Engine Admin 角色：
# 创建专用服务账号
gcloud iam service-accounts create gke-admin
--display-name="GKE Admin Account"
# 绑定角色
gcloud projects add-iam-policy-binding my-gcp-project
--member="serviceAccount:gke-admin@my-gcp-project.iam.gserviceaccount.com"
--role="roles/container.admin"
网络方面，GKE 推荐使用 VPC 原生集群，也就是每个 Pod 直接从子网分配 IP。这要求在创建子网时规划好 Pod 地址范围，避免与节点 IP 冲突。如果随意使用默认网络，后期做集群扩容时会遇到 IP 耗尽问题。因此初始化阶段就要用 gcloud compute networks subnets create 明确划分节点段与 Pod 段。
二、使用命令行创建标准 GKE 集群
当环境与网络就绪后，就可以用 gcloud container clusters create 命令拉起集群。标准模式（Standard）允许用户完全控制节点池和版本，适合需要精细调优的场景。命令中必须指定区域、节点机型以及节点数量。如果不写 --machine-type，默认会拉起较贵的通用机型，导致成本失控。下面的示例创建了一个位于 asia-east1 的三节点集群，并开启自动升级：
gcloud container clusters create my-first-gke
--region=asia-east1
--machine-type=e2-medium
--num-nodes=3
--enable-autoupgrade
--enable-autorepair
--subnetwork=my-gke-subnet
集群创建过程通常耗时三到五分钟，期间 GKE 会在后台部署控制平面并注册节点。完成后，使用 gcloud container clusters get-credentials my-first-gke --region=asia-east1 把 kubeconfig 拉到本地，之后 kubectl get nodes 就能看到就绪的节点。需要注意，如果本地没有安装 kubectl，gcloud 也提供了 gcloud beta kubectl 的托管版本。
和标准模式相对的是 Autopilot 模式，后者由谷歌自动管理节点池和扩缩容。Autopilot 降低了运维负担，但灵活性受限，比如不能自定义节点操作系统。对于学习或中小型业务，Autopilot 能省去很多麻烦；但对于有 GPU 调度、特殊内核参数需求的企业，标准模式仍是唯一选择。两者在控制台和命令行里只需一个参数区别，但背后资源模型完全不同。
三、集群联通验证与基础应用部署
集群跑起来只是第一步，还必须验证网络联通和控制平面可用。最简单的方式是部署一个 nginx 测试负载，并通过 Cloud 负载均衡暴露服务。在 GKE 中，使用 type: LoadBalancer 的 Service 会自动触发谷歌云负载均衡器创建，但前提是节点子网能访问谷歌 API，且防火墙允许健康检查。下面是一段最基础的部署定义：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-test
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx-lb
spec:
type: LoadBalancer
selector:
app: nginx
ports:
- port: 80
targetPort: 80
应用上述文件后，用 kubectl get svc nginx-lb 观察外部 IP 分配状态。如果长时间处于 pending，往往是子网没有配置 Cloud NAT，导致节点无法回连控制平面去上报负载均衡器状态。此时应回到 VPC 页面补一个 Cloud NAT 网关。验证联通后，就可以把业务容器逐步迁移进来，并利用 GKE 的节点池功能分离在线和离线负载。
最后要强调的是，GKE 集群的安全基线不能忽视。创建时建议开启 Workload Identity，让 Pod 以 Kubernetes 服务账号映射谷歌服务账号，避免把密钥写进镜像。同时打开二叉授权（Binary Authorization）可以防止未签名镜像部署。这些设置在命令行里只是几个开关，却能在后续防住大部分供应链攻击。搭建指南到这里就覆盖了从零到可用的核心路径，剩下的就是结合业务做节点伸缩与监控告警的细化。
GKEGoogle_Cloudkubernetes修改时间：2026-08-15 16:34:32