1. 课程导入与平台全景
在 Google Cloud 上构建和运行容器化应用，并不是“选一个产品把镜像跑起来”这么简单。真正决定一个系统能否稳定交付、弹性伸缩、可观测、可治理的，是几个核心组件之间的分工与协作：Cloud Build 负责把源码变成镜像，Artifact Registry 负责存储和分发镜像与制品，GKE 提供完整的 Kubernetes 编排能力，Cloud Run 提供以请求为中心的 Serverless 容器运行方式。理解这四者的定位差异，是后续 29 章设计与部署工作的起点。
一、四个核心组件各自解决什么问题
Cloud Build 是无服务器 CI/CD 执行引擎。它按步骤（step）执行容器化任务，每一步本质上都是一个容器。典型构建流程是：拉取源码 → 执行 docker build 或 gcloud builds submit → 推送镜像到 Artifact Registry。它支持触发器（Trigger），可绑定 GitHub、Cloud Source Repositories 或手动触发，实现“提交即构建”。
Artifact Registry 是容器镜像与语言包（如 Maven、npm、Python）的统一制品仓库。相比已停止新功能迭代的 Container Registry（gcr.io），Artifact Registry 支持区域化存储、细粒度 IAM、VPC Service Controls 和漏洞扫描。镜像地址形如 asia-east1-docker.pkg.dev/项目ID/仓库名/镜像名:标签，区域选择直接影响拉取延迟与跨区流量成本。
GKE 是托管的 Kubernetes 服务，提供集群、节点池、控制平面托管、自动升级、自动修复等能力。它适合需要精细控制调度、网络、存储、Sidecar、Operator 的复杂工作负载。GKE 有 Standard 与 Autopilot 两种模式：Standard 让你管理节点，Autopilot 由 Google 管理节点并只按 Pod 资源计费。
Cloud Run 是托管式 Serverless 容器平台，面向 HTTP 请求或事件驱动场景。你只需提供镜像，Cloud Run 负责伸缩到零、按请求计费、自动分配 HTTPS 域名。它不暴露 Kubernetes API，因此不适合需要 DaemonSet、StatefulSet 或自定义 CRD 的场景。
二、如何选择：GKE 还是 Cloud Run
选择的关键不是“哪个更先进”，而是“工作负载需要多少控制力”。可以用三个问题快速判断：
- 是否需要 Kubernetes API 对象？ 需要 DaemonSet、StatefulSet、CRD、Operator、自定义调度策略，选 GKE。
- 是否以 HTTP 请求或事件为主？ 无状态、请求驱动、希望伸缩到零，选 Cloud Run。
- 是否需要长期运行的后台进程或常驻连接？ Cloud Run 支持常驻实例但按实例计费，若需要精细资源配额与节点亲和性，GKE 更合适。
实际项目中两者常混合使用：核心交易系统跑在 GKE，异步任务、Webhook 接收、内部工具跑在 Cloud Run，共享同一个 Artifact Registry 仓库。
三、一个可运行的最小示例
下面用一段 Cloud Build 配置，把源码构建成镜像并推送到 Artifact Registry，随后部署到 Cloud Run。这是本课程后续所有实操的基础链路。
# cloudbuild.yaml
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t',
'asia-east1-docker.pkg.dev/$PROJECT_ID/demo-repo/hello:v1', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['push',
'asia-east1-docker.pkg.dev/$PROJECT_ID/demo-repo/hello:v1']
images:
- 'asia-east1-docker.pkg.dev/$PROJECT_ID/demo-repo/hello:v1'
执行 gcloud builds submit --config cloudbuild.yaml 后，镜像进入 Artifact Registry。接着部署到 Cloud Run：
gcloud run deploy hello \
--image=asia-east1-docker.pkg.dev/项目ID/demo-repo/hello:v1 \
--region=asia-east1 \
--allow-unauthenticated \
--max-instances=10 \
--concurrency=80
部署完成后，Cloud Run 会返回一个 https://hello-xxxxx.a.run.app 的 URL。用 curl 访问即可验证。观察指标时重点关注：请求延迟 P50/P95、实例数变化、并发数是否接近 --concurrency 上限。若实例数频繁触顶，说明需要调高 --max-instances 或优化单实例处理能力。