📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在开始学习 Google Cloud 容器平台之前，先建立一个整体判断：容器解决的是“应用及其依赖如何被一致地打包与运行”，而 Google Cloud 上的容器平台解决的是“这些容器镜像如何被安全地存储、调度、扩缩、暴露、观测并持续交付”。这两件事合在一起，才构成从代码到线上服务的完整交付链路。本课程围绕这条链路展开，重点不是记住某个按钮的位置，而是理解每一层在交付过程中承担什么职责、输入输出是什么、出问题时应该先看哪里。

一、核心价值：为什么选择 Google Cloud 做容器交付

Google 内部长期运行大规模容器化工作负载，Kubernetes 正是这一实践的产物。因此 Google Cloud 的容器平台在几个方面具有天然优势：第一，GKE（Google Kubernetes Engine）是托管式 Kubernetes，控制平面由 Google 负责运维，用户聚焦工作负载；第二，Artifact Registry 提供与 GKE、Cloud Build、IAM 深度集成的镜像仓库，支持镜像扫描与区域化存储；第三，Cloud Build 与 Cloud Deploy 把构建、测试、发布串成可审计的流水线；第四，Cloud Operations（原 Stackdriver）提供日志、指标、追踪一体化观测。这些服务不是孤立工具，而是围绕“镜像—集群—流量—观测—发布”形成闭环。

对交付团队而言，核心价值可以概括为三点：一致性（同一镜像在开发、测试、生产环境行为一致）、可重复性（流水线可重跑、可回滚）、可观测性（每次发布都有日志、指标和版本记录可追溯）。

二、技术栈组成：从代码到用户的五层结构

把整条链路拆开，可以分成五个层次，每一层都有明确的输入与输出：

源码与构建层：代码仓库（如 GitHub、Cloud Source Repositories）触发 Cloud Build，执行 docker build 与测试，产出带唯一标签的镜像。
镜像与制品层：镜像推送到 Artifact Registry，按区域和仓库隔离，配合漏洞扫描与 IAM 权限控制。
编排与运行层：GKE 集群接收 Deployment、Service、Ingress 等资源声明，调度 Pod 并维持期望副本数。
流量与接入层：通过 Service、Ingress 或 Gateway API 暴露服务，结合 Cloud Load Balancing 与 Cloud DNS 对外提供访问。
观测与发布层：Cloud Logging、Cloud Monitoring 采集运行数据，Cloud Deploy 管理发布策略（如金丝雀、蓝绿）。

这五层之间的数据流是单向推进的：源码 → 镜像 → 集群 → 流量 → 观测。理解这条主链，后续每一章都能找到自己的位置。

三、学习路径：按交付链路逐层深入

本课程共 30 章，建议按“先跑通、再理解、后优化”的节奏推进。前几章先完成环境准备与第一个容器化应用部署，建立手感；中间章节分别深入镜像管理、GKE 工作负载、网络与存储、配置与密钥、自动扩缩；后段进入 CI/CD 流水线、发布策略、可观测性与安全治理。每一章都会围绕一个可操作的对象展开，例如一个 Deployment、一条 Cloud Build 配置或一次金丝雀发布。

学习时建议始终带着三个问题：这一层的输入是什么？（源码、镜像、YAML 还是流量规则）它做了什么转换？（构建、调度、路由还是采集）输出如何验证？（镜像标签、Pod 状态、HTTP 响应码还是监控图表）。这三个问题能帮助你把零散命令串成完整链路。

四、实验环境准备：最小可用配置

动手之前需要准备一个 Google Cloud 项目，并启用以下 API：container.googleapis.com、artifactregistry.googleapis.com、cloudbuild.googleapis.com。建议使用独立项目，避免与生产资源混用。以下是一组示例参数，可根据实际情况调整：

# 示例：设置项目与区域
gcloud config set project my-container-lab
gcloud config set compute/region asia-east1
gcloud config set compute/zone asia-east1-a

# 启用必要 API
gcloud services enable container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com

# 创建 Artifact Registry 仓库（示例名称 app-repo）
gcloud artifacts repositories create app-repo \
  --repository-format=docker \
  --location=asia-east1 \
  --description="容器镜像仓库"

# 创建 GKE 集群（示例：2 节点，e2-medium）
gcloud container clusters create lab-cluster \
  --num-nodes=2 \
  --machine-type=e2-medium \
  --region=asia-east1

上述命令执行后，可以用 gcloud container clusters list 确认集群状态为 RUNNING，用 gcloud artifacts repositories list 确认仓库已创建。如果集群创建失败，常见原因是配额不足或 API 未启用，可先检查 gcloud services list --enabled 的输出。

环境检查清单：项目已创建并绑定结算账号；三个 API 均为启用状态；Artifact Registry 仓库区域与 GKE 集群区域一致（减少跨区拉取延迟）；本地已安装 gcloud、kubectl 和 docker；gcloud auth login 与 gcloud auth configure-docker asia-east1-docker.pkg.dev 已执行，确保可以推送镜像。

完成以上准备后，你就拥有了一个可以跑通“构建镜像 → 推送仓库 → 部署到 GKE → 暴露服务 → 查看日志”的最小环境。后续每一章都会在这个环境上叠加新的能力。建议在实验过程中为资源打上标签（如 env=lab），便于结束后统一清理，避免产生不必要的费用。

注意：GKE 集群和 Artifact Registry 仓库都会产生费用。实验结束后可执行 gcloud container clusters delete lab-cluster --region=asia-east1 删除集群，并视需要删除仓库。删除前确认没有需要保留的镜像或配置。

整体来看，本课程的主线就是一条从源码到用户的交付链：构建产出镜像，镜像进入仓库，GKE 拉取并运行，流量接入后对外服务，观测数据再反馈到下一轮迭代。掌握这条链上每一层的职责与验证方式，比记住单个命令更重要。接下来将从第一个容器化应用开始，逐步把这条链跑通。