GCP帳號註冊服務 GCP Kubernetes集群搭建入門教程：利用 GKE 快速部署容器化應用

第一章：为什么是 GKE，什么是你真正要搭建的东西

GCP帳號註冊服務 很多人第一次接触 Kubernetes，会把它想成“一套很复杂的工具”。其实你要搭建的并不是“工具”，而是一套可以稳定运行容器应用的基础设施：把容器放进集群，让它在故障时自动恢复，在流量来临时自动伸缩，还能用声明式方式持续更新。

在 GCP 上，最省心的选择就是 GKE（Google Kubernetes Engine）。你不需要自己手工管理控制平面，也不必处理底层节点的复杂性。你只要完成几个关键决策：选地区与网络、确定节点规模、准备容器镜像、编写 Kubernetes 资源并部署。

把目标说得更具体一点：你将完成以下结果。

• 在 GCP 创建一个可运行的 GKE 集群
• 部署一个示例容器化应用（例如 Web 服务）
• 通过 Ingress 或 Service 将它对外暴露并验证访问
• 理解日志、伸缩与滚动更新的基本操作

接下来我们一步一步做。你不需要先懂全部 Kubernetes 概念，但你需要愿意在每一步之后确认“发生了什么”。

第二章：准备工作——账号、项目、权限与本地环境

开始前，先确认你有一个有效的 GCP 账号和项目。建议每个练习用一个独立项目，方便管理配额与资源清理。

2.1 开启必要的 API

通常你会用到这些能力：

• Kubernetes Engine API
• Compute Engine API（因为节点在计算层面运行）
• Container Registry 或 Artifact Registry（用于存放镜像）
• Load Balancing 等（取决于你如何对外暴露应用）

GCP帳號註冊服務 在 GCP 控制台的“API 与服务”里开通即可。虽然具体名称可能随时间调整，但大方向一致。

2.2 获取所需权限

最初你可以用较宽松的权限快速跑通流程。等你确认一切稳定后，再收紧权限。

建议至少具备：

• 创建和管理 GKE 集群的权限
• GCP帳號註冊服務 读取/写入镜像仓库的权限（如果你要推送镜像）
• 查看与管理网络相关资源的权限（与负载均衡有关）

2.3 安装本地工具

你至少需要：

• gcloud CLI
• kubectl

GCP帳號註冊服務 安装后，你要做一件事：登录并设置默认项目。

在终端执行类似命令（示意）：

gcloud auth login
gcloud config set project 你的项目ID

然后你要准备好容器镜像。镜像可以来自你本地构建，也可以来自现成示例仓库。本文以你自己构建一个简单 Web 应用为例，便于理解整个链路。

第三章：创建 GKE 集群——把关键选项想明白

在 GKE 的创建过程中，你会遇到很多选项。对新手来说，并不是每个都要追到最细；但以下几个决策必须做清楚：集群模式、网络与节点规模。

3.1 选择区域：Regional 还是 Zonal

Zonal 集群更简单，部署在单个可用区；Regional 集群会跨多个可用区，更抗故障。新手学习阶段可以从 Zonal 开始，但如果你计划对外提供服务，Regional 更稳。

如果你不确定，优先选 Regional（代价是资源与成本略高）。

3.2 网络：默认 VPC 还是自定义

你可以用默认 VPC 快速跑通流程。自定义网络适合你有更严格的隔离或复杂路由需求。

对入门教程来说，使用默认 VPC 更快。关键点在于：你要理解后续对外访问需要负载均衡与 Ingress 配置，网络要能通。

3.3 节点：数量与机器规格

节点数决定可承载的工作负载。你只部署一个示例应用的话，最小配置通常就够。

建议先这样设定：

• GCP帳號註冊服務 节点最小 1，最大 3（如果你用自动伸缩）
• 机器类型选一个通用小规格

当你准备扩展时，再根据 CPU/内存使用率调整。

3.4 工作负载身份与安全性（可先默认，但要知道它在做什么）

GKE 在安全方面支持“工作负载身份”（Workload Identity），可以让 Pod 使用更安全的方式访问 Google 服务，减少对长效密钥的依赖。

新手阶段你可能直接使用默认方案也能成功部署。但你要有意识：如果你后续要读写镜像仓库、访问数据库，最好走更安全的身份机制。

3.5 创建并获取集群凭据

集群创建完成后，使用 gcloud 获取 kubectl 可用的凭据。

gcloud container clusters get-credentials 你的集群名 --region 你的区域

接着验证：

kubectl get nodes

你会看到节点列表。看到节点正常 Ready，说明基础层就绪。

第四章：准备容器镜像——让应用从“能跑”到“能部署”

Kubernetes 不是神秘的魔法，它只是让“容器”在集群上运行。你要先把容器镜像准备好，并确保集群可以拉取它。

4.1 一个最简单的示例应用

你可以用任何语言写一个简单 HTTP 服务，例如输出“Hello”。Dockerfile 的关键是：让容器监听 8080（或你自定义端口），并保持前台运行。

如果你用 Node.js/Express、Python/Flask、Go，都可以。本文不拘泥语言，重点放在后面的 Kubernetes 资源。

4.2 构建并推送镜像到镜像仓库

GCP帳號註冊服務 镜像仓库可以用 Artifact Registry。推送流程大同小异：

• 在仓库创建一个 repo
• 构建本地镜像
• 标记镜像 tag
• 推送到仓库

一个典型流程示意：

docker build -t <镜像名>:v1 .
docker tag <镜像名>:v1 <仓库URL>/<镜像名>:v1
docker push <仓库URL>/<镜像名>:v1

推送成功后，你需要记录镜像完整地址。后续 Kubernetes Deployment 会引用它。

4.3 镜像拉取失败怎么办

新手最常见的坑之一：镜像仓库权限没配好，导致 Pod 一直 Pending 或 ImagePullBackOff。

你可以通过以下思路排查：

• 检查镜像地址是否拼写正确
• 检查镜像仓库是否存在于同一项目/权限范围
• 检查服务账号（ServiceAccount）是否有拉取镜像的权限

如果你启用了 Workload Identity，要确认映射关系正确。

第五章：部署应用到 GKE——从 Deployment 到对外访问

部署应用时，你需要三件套：Deployment（管理副本与滚动更新）、Service（提供稳定网络访问）、Ingress 或 LoadBalancer（对外暴露）。

5.1 编写 Deployment：声明你要跑什么

Deployment 的核心是：指定副本数、容器镜像、容器端口，以及可选的资源请求与探针。

下面给一个示例（你把镜像地址替换成你的即可）。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-demo
  template:
    metadata:
      labels:
        app: web-demo
    spec:
      containers:
      - name: web
        image: <你的镜像地址>
        ports:
        - containerPort: 8080

解释一下它在做什么：

• replicas: 2：确保同时运行两个副本
• selector / matchLabels：让 Deployment 找到它管理的 Pod
• template.labels：Pod 上会打上 app=web-demo，Service 会用这个标签选中它
• containerPort：说明容器监听的端口，便于 Service 转发

5.2 应用探针：让“健康”这件事变得可控

入门时你可以先不加探针，但你很快会遇到一个现实：服务不一定永远在“就绪状态”。探针能让 Kubernetes 知道何时可以接流量。

推荐做两种探针：

• livenessProbe：判断容器是否卡死，需要重启
• readinessProbe：判断容器是否准备好接收请求

示例（你按自己的路径调整）：

        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

记得让应用真的提供 /health 返回 200，否则会一直“未就绪”。

5.3 创建 Service：让 Pod 有“门牌号”

Pod 是短暂的。你不能直接让外部流量随机打到某个 Pod IP 上。Service 提供一个稳定的访问入口，并把流量转发给匹配标签的 Pod。

创建一个 ClusterIP 类型的 Service（内部可访问）：

apiVersion: v1
kind: Service
metadata:
  name: web-demo-svc
spec:
  selector:
    app: web-demo
  ports:
  - name: http
    port: 80
    targetPort: 8080
  type: ClusterIP

说明：

• selector：选择 app=web-demo 的 Pod
• port 80：Service 对外端口
• targetPort 8080：转到容器实际端口

5.4 部署：kubectl apply 与验证

把 Deployment 和 Service 保存为 YAML 文件，然后执行：

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

验证副本是否就绪：

kubectl get pods
kubectl get deploy
kubectl describe pod <pod名>

如果 Pod 一直重启，重点看容器日志：

kubectl logs <pod名>

日志是定位问题最快的方式。

5.5 对外暴露：用 Ingress 走 HTTP 入口

当你要从集群外访问应用时，常见方式是 Ingress（结合负载均衡）。新手阶段你可以把 Ingress 配置当成“告诉集群：哪些域名/路径要转发到哪个 Service”。

Ingress 示例（取决于你是否使用 GCE/GKE Ingress Controller 以及 IngressClass）。先给一个通用思路：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo-ing
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-demo-svc
            port:
              number: 80

部署 Ingress：

kubectl apply -f ingress.yaml

验证是否拿到外部地址：

kubectl get ingress

如果 external IP 或 hostname 还没出现，通常是资源创建/负载均衡还在配置中。你可以持续等待几分钟。

5.6 最小可行路径：从“能部署”到“能访问”

你最终需要确认两件事：

• 浏览器能访问到你的服务（返回预期内容）
• Ingress 转发到 Service，再转发到 Pod（可以通过服务日志或访问日志验证）

如果访问失败，优先查 Ingress、Service 端口映射是否正确，再查 Pod 是否就绪、探针是否导致流量被排除。

第六章：滚动更新与版本管理——把“改代码”变成“改配置”

当你更新应用时，你最不想看到的是：把整个集群推倒重来。Kubernetes 的优势之一就是滚动更新。

6.1 更新镜像并触发滚动更新

假设你把镜像从 v1 推送为 v2，那么 Deployment 的 image tag 更新即可。

GCP帳號註冊服務 两种方式：

• 手动编辑 YAML 后 apply
• 用 kubectl set image 快速替换

示例（把容器名与镜像替换成你的实际值）：

kubectl set image deployment/web-demo web=<你的镜像地址>:v2

然后观察滚动状态：

kubectl rollout status deployment/web-demo
kubectl get pods -w

你会看到 Pod 一批一批更新，旧 Pod 不会立刻消失，直到新 Pod 就绪。

6.2 必须掌握的回滚

更新失败时你要能快速回退。Kubernetes 保留了 rollout 历史。

kubectl rollout history deployment/web-demo
kubectl rollout undo deployment/web-demo

这对生产环境非常关键。即使你现在只是做入门，也要养成习惯。

6.3 版本与不可变镜像（Tag 设计）

GCP帳號註冊服務 建议使用不可变镜像标签策略：v1、v2 或带 git commit 的短 hash。不要只用 latest 这种标签，否则回滚与定位会变得困难。

当你需要可追溯性，镜像名和版本规划比你想象的重要。

第七章：监控与日志——你需要的是“可定位问题”的能力

部署能跑是第一步，真正让你活得轻松的是监控与日志。GKE 与 Cloud Monitoring、Cloud Logging 集成，能把日志和指标统一起来。

7.1 先用 kubectl 定位，再接入控制台看全局

你可以先用：

• kubectl logs 看容器输出
• kubectl describe 看事件与状态
• kubectl get events 查看最近事件

例如：

kubectl describe pod <pod名>
kubectl get events --sort-by=.metadata.creationTimestamp

这些信息能告诉你：是拉镜像失败、探针失败，还是资源调度问题。

GCP帳號註冊服務 7.2 在业务层加入健康检查与可观测性

别把健康检查做成形式主义。/health 应该真实反映依赖是否可用。比如数据库连接失败，就返回非 200，让流量不要打到一个“假活着”的实例。

同时，在应用层输出结构化日志（即使是简单 JSON），将请求路径、状态码、耗时记录下来。后续排障会少掉大量猜测。

GCP帳號註冊服務 第八章：伸缩与资源管理——从“能跑”到“跑得稳、成本可控”

当流量增长，你不希望手工加节点。Kubernetes 提供自动伸缩能力，你要理解它背后的逻辑。

8.1 Horizontal Pod Autoscaler（HPA）基础理解

HPA 根据指标（如 CPU 利用率或自定义指标）调整 Deployment 的副本数。

它解决的问题是：实例数量跟随负载变化。

当你设置 HPA 时，你至少需要：

• 目标 Deployment
• 最小副本数与最大副本数
• 指标与目标阈值

8.2 Cluster Autoscaler：节点也会跟着变

Pod 数量增加不等于节点自动可用。Cluster Autoscaler 负责在需要时增加节点，在空闲时减少节点（在配置允许的情况下）。

如果你只开了 HPA，但节点数固定，副本再怎么扩也可能调度失败。

8.3 资源请求与限制：别让系统靠运气

建议你给容器设置 requests 和 limits：

• requests：调度所依据的“最低保证”
• limits：容器能用的“上限”

否则系统可能无法正确分配资源，导致某些 Pod 被频繁重启或性能抖动。

第九章：常见坑与排查思路——把时间花在正确的地方

你在入门阶段很可能遇到这些问题。别慌，按优先级排查。

9.1 Pod 一直 Pending

常见原因：

• 资源配额不足（CPU/内存额度耗尽）
• 节点资源类型不匹配
• 调度约束（亲和/污点）导致无法落到节点

排查方式：

kubectl describe pod <pod名>

看 Events 里给出的提示。

9.2 ImagePullBackOff

常见原因：

• 镜像地址错
• 镜像仓库权限不足
• 网络访问限制

排查方式：

kubectl describe pod <pod名>
kubectl logs <pod名> --previous

9.3 探针导致一直不就绪

表现通常是：Pod Running 但 Service 不转发，或者 Ingress 返回 502/503。

原因常见：

• health 路径与应用不一致
• 端口不一致
• 初始延迟太短，服务还没启动就被判定失败

9.4 Ingress 外部访问失败

通常是端口映射或 Ingress 控制器配置问题。你可以按顺序检查：

• Ingress 是否已分配外部地址
• Service 是否正确选择到了 Pod（selector 标签是否匹配）
• Pod 是否就绪（readiness 是否通过）

必要时使用：

kubectl get endpoints web-demo-svc -o wide

看 Service 的 endpoints 是否有地址。

第十章：清理资源与后续学习路线——让每次练习都不浪费

GCP帳號註冊服務 你在学习过程中会创建很多资源。为了避免账单持续增长，最后一定要清理。

10.1 删除不需要的 Kubernetes 资源

如果你只是在实验，可以删除 Deployment、Service、Ingress：

kubectl delete ingress web-demo-ing
kubectl delete service web-demo-svc
deloyment/web-demo

（注意大小写与资源名，建议直接按你实际 YAML 文件删除。）

10.2 删除集群或降低节点数量

集群本身是成本大头。如果确定不需要，直接删除集群最干净。

如果你希望保留环境用于后续练习，可以把节点数降到最小或按自动伸缩策略运行。

10.3 下一步你应该学什么

当你完成本教程，你已经掌握了一个可用系统的基本闭环。下一步可以按目标继续：

• 把应用拆成多个微服务，用 NetworkPolicy 做隔离
• 引入 ConfigMap/Secret 管理配置与敏感信息
• 使用 Helm 或 Kustomize 管理复杂资源
• 学习 CI/CD（例如用 Cloud Build 或 GitHub Actions 推送镜像并自动更新）
• 深入监控告警：CPU、延迟、错误率、HPA 指标

GCP帳號註冊服務 不要急着学“所有 Kubernetes”。先把一个应用稳定跑起来，你会更快理解它为何存在，也更能把知识用在真实项目里。

结语：把入门做成可复用的方法

搭建 GKE Kubernetes 集群并部署容器化应用，本质上是把一条链路串起来：集群与网络提供运行环境，镜像提供可部署内容，Deployment 与 Service 定义应用如何被调度与访问，Ingress 让外部流量进入，监控与日志让你能快速定位问题。你只要每一步都“验证”，就不会在复杂度里迷路。

当你再次遇到新应用时，流程会越来越顺：换镜像、改端口、补探针、加资源限制、接入 Ingress，剩下的就是迭代与优化。你真正建立的是一套可复用的工程方法。