2、流水线架构基础：CI/CD流水线核心组件及其在容器场景下的角色
容器化应用的发布流水线并非凭空构建，而是由一系列成熟的核心组件串联而成。在容器场景下，每个组件的职责都发生了显著变化——从传统的“编译-打包-部署”转变为“构建镜像-推送镜像-调度容器”。理解这四大核心组件（代码仓库、构建系统、镜像仓库、编排平台）及其在容器生态中的新角色，是掌握故障排查与恢复设计的前提。
2.1 核心组件全景图
下图展示了容器场景下 CI/CD 流水线的标准拓扑结构，以及各组件之间的数据流与触发关系。
2.2 代码仓库：流水线的触发源
代码仓库是流水线的起点。在容器场景下，它不仅存储源代码，还存储 Dockerfile、Helm Chart 以及 Kubernetes 清单文件。任何变更（代码提交、PR 合并、Tag 推送）都可能触发一次完整的容器化发布。
| 角色 | 传统场景 | 容器场景 |
|---|---|---|
| 触发方式 | 定时轮询或手动触发 | Webhook 事件驱动（push / pull_request / tag） |
| 存储内容 | 源代码 + 配置文件 | 源代码 + Dockerfile + .dockerignore + Helm Chart + K8s YAML |
| 分支策略 | master / develop | feature → develop → release → main + 版本 Tag（v1.2.3） |
| 故障点 | 代码冲突、权限错误 | Webhook 失联、Dockerfile 路径错误、.dockerignore 遗漏大文件 |
2.3 构建系统：镜像生产的核心引擎
构建系统负责将源代码编译、打包并生成容器镜像。在容器场景下，构建系统的核心产出不再是传统的二进制包或 WAR 包，而是 OCI 标准容器镜像。常见的构建系统包括 Jenkins、GitLab CI、GitHub Actions、Tekton 等。
2.3.1 构建阶段的关键步骤
- 代码检出：从代码仓库拉取指定分支或 Tag 的代码。
- 依赖安装与编译：执行
npm install、mvn package等传统构建步骤。 - 镜像构建：执行
docker build -t app:v1.2.3 .，依赖 Dockerfile 中的指令。 - 镜像标签与推送：为镜像打上多个标签（如
v1.2.3、latest），并推送至镜像仓库。 - 镜像安全扫描（可选）：使用 Trivy、Clair 等工具扫描镜像中的漏洞。
2.3.2 构建系统在容器场景下的特殊角色
| 能力 | 说明 | 故障场景示例 |
|---|---|---|
| Docker-in-Docker (DinD) | 构建节点内部运行 Docker 守护进程，执行 docker build | DinD 容器重启导致构建中断；/var/run/docker.sock 权限不足 |
| Kaniko / BuildKit | 无特权模式构建镜像，适用于安全受限的 Kubernetes 构建节点 | 缓存层失效导致构建时间暴增；基础镜像拉取超时 |
| 多阶段构建 | 通过多个 FROM 指令分离构建环境与运行环境，减小镜像体积 | 阶段间文件未正确 COPY；中间层缓存污染 |
| 构建缓存 | 利用 Docker 层缓存加速后续构建 | 缓存未命中；缓存层过大导致磁盘空间不足 |
docker build 时因磁盘空间不足而失败。排查时使用 docker system df 查看镜像/容器/卷的磁盘占用，并设置构建节点的自动清理策略（如 docker system prune -f）。
2.4 镜像仓库：不可变制品的存储与分发中心
镜像仓库是容器化发布流水线的“制品库”。所有构建系统产出的容器镜像都集中存储在镜像仓库中，供后续的部署、回滚、审计使用。常见的镜像仓库包括 Harbor、Docker Registry、Amazon ECR、Google Container Registry 等。
2.4.1 镜像仓库的核心功能
- 镜像存储与版本管理：支持多 Tag、多仓库、多项目隔离。
- 访问控制：基于角色的权限管理（RBAC），区分推送、拉取、删除权限。
- 镜像复制与同步：跨地域、跨集群的镜像同步，支持 Pull-Through 缓存。
- 安全扫描与签名：集成漏洞扫描、内容信任（Notary）、镜像签名验证。
- 垃圾回收：清理未被引用的镜像层，释放存储空间。
2.4.2 镜像仓库在流水线中的角色对比
| 角色 | 传统制品库（Nexus / Artifactory） | 容器镜像仓库（Harbor / ECR） |
|---|---|---|
| 制品格式 | JAR / WAR / ZIP / RPM | OCI 镜像（多层 + manifest + config） |
| 拉取方式 | HTTP GET 下载 | docker pull / containerd pull（基于 manifest 的层式拉取） |
| 版本不可变性 | 可覆盖（相同版本号可重新上传） | 推荐不可变 Tag（禁止覆盖已有 Tag） |
| 故障排查重点 | 磁盘空间、索引损坏 | 镜像层损坏、GC 未执行导致存储爆炸、认证凭证过期 |
v1.2.3-build.20250321.01），禁止覆盖 latest 标签。这能显著降低因镜像覆盖导致的部署回滚困难。
2.5 编排平台：容器化应用的最终运行环境
编排平台是流水线的终点。它负责从镜像仓库拉取容器镜像，并根据声明式配置（Deployment、StatefulSet、DaemonSet）调度容器到集群节点上运行。Kubernetes 是目前容器编排的事实标准。
2.5.1 编排平台在流水线中的关键交互
- 镜像拉取策略：
imagePullPolicy: Always确保每次部署都拉取最新镜像；IfNotPresent优先使用本地缓存。 - 滚动更新：通过
kubectl set image或 Helm Upgrade 触发 Pod 的渐进式替换。 - 就绪与存活探针：确保新版本 Pod 在流量接入前已正常启动。
- 回滚机制：利用 Kubernetes 的
rollout undo快速恢复到上一个稳定版本。
2.5.2 编排平台故障排查要点
| 故障现象 | 可能原因 | 排查命令 |
|---|---|---|
| Pod 一直处于 ImagePullBackOff | 镜像仓库认证失败、镜像 Tag 不存在、镜像仓库不可达 | kubectl describe pod <pod-name> 查看 Events |
| 滚动更新卡住 | 新版本 Pod 就绪探针失败、资源配额不足、PDB 阻止驱逐 | kubectl rollout status deployment <deploy> |
| 回滚后仍异常 | 镜像 Tag 被覆盖、数据库 schema 不兼容、ConfigMap 未回滚 | kubectl rollout history deployment <deploy> |
2.6 四大组件的故障依赖链
在容器化流水线中，四个组件形成一条完整的依赖链：代码仓库 → 构建系统 → 镜像仓库 → 编排平台。任何一个环节的故障都会导致下游无法正常执行。下表总结了各组件之间的典型故障传播路径：
| 上游组件 | 下游组件 | 故障传播示例 |
|---|---|---|
| 代码仓库 | 构建系统 | Webhook 未触发 → 构建系统未收到事件 → 流水线静默失败 |
| 构建系统 | 镜像仓库 | docker push 认证失败 → 镜像未上传 → 编排平台拉取不到新镜像 |
| 镜像仓库 | 编排平台 | 镜像仓库 GC 导致层丢失 → 编排平台拉取镜像时 manifest 损坏 → 部署失败 |
| 编排平台 | （反馈至构建系统） | 部署失败 → 构建系统需要重新触发回滚流水线 → 依赖镜像仓库中的历史镜像 |