从0到企业级私有云｜CI／CD 架构设计解析（不是工具，是体系）

让你的上线，像 git push一样简单

📘 本文阅读时长：约 9 分钟📊 全文字数：约 1800+ 字

📌 阅读本文，你将了解到本实验：

1. 为什么必须做 CI/CD—— 传统部署的痛点与 CI/CD 的本质价值
2. CI/CD 核心架构全景—— 从代码提交到服务上线的完整链路
3. CI 和 CD 的职责区分—— 别再混淆“构建”与“发布”
4. 企业级分层模型—— 开发层、构建层、制品层、部署层、运行层、观测层
5. 两种主流架构模式—— Pipeline 模式 vs GitOps 模式，以及当前该选哪个
6. 推荐落地架构—— Jenkins + Harbor + Kubernetes 的具体方案与必须实现的四个能力
7. CI/CD 与监控打通—— 如何利用 Prometheus + Alertmanager 实现发布后自动告警与健康检查
8. 演进路线—— 从跑通流水线到灰度发布、自动回滚的完整路径

一、为什么必须做 CI/CD？

在前面的实验中，已经完成了：

• ✅ Kubernetes 集群搭建
• ✅ 存储与网络设计
• ✅ 监控系统（Prometheus + Alertmanager）

这些解决了一个问题： 👉 系统能不能稳定运行

但我们还缺一个关键能力： ❗ 系统能不能高效交付

🚨 说出来你可能不信，很多人真实的发布流程是这样的：

开发改代码 → 运维手动构建 → 手动上传 → 手动部署 → 出问题再回滚

这套流程在企业里会带来一堆问题：

• ❌ 人工操作多，极易出错
• ❌ 发布速度慢，无法快速迭代
• ❌ 无法追溯版本（到底部署了哪个 commit？）
• ❌ 标准不统一（每个人部署方式都不一样）

✅ CI/CD 的本质

CI/CD 不是某个工具，而是一套工程体系：

代码提交 → 自动构建 → 自动测试 → 自动部署 → 自动验证

🎯 核心目标

👉 让“交付系统”这件事，像git push一样简单

二、CI/CD 架构全景

🧠 核心链路（必须牢记）

Git（代码） 
   ↓
CI（构建系统）
   ↓
镜像仓库（Registry）
   ↓
CD（部署系统）
   ↓
Kubernetes（运行环境）

🔁 一次发布，背后发生了什么？

开发 git push
   ↓
CI 系统检测到代码变化
   ↓
自动构建 Docker 镜像
   ↓
推送到镜像仓库
   ↓
CD 更新 Kubernetes Deployment
   ↓
Pod 滚动更新
   ↓
服务上线

📌 一句话记住本节CI/CD = 自动化软件交付流水线

三、CI 和 CD 的职责

🔧 CI（持续集成）

解决 “构建问题”。

主要职责：

• 拉取代码
• 编译 / 打包
• 单元测试
• 构建镜像

👉 输出的是：一个可运行的产物（Docker 镜像）

🚀 CD（持续交付 / 持续部署）

解决 “发布问题”。

主要职责：

• 部署到 Kubernetes
• 控制发布策略
• 管理版本与回滚

👉 输出的是：一个正在运行的服务

⚠️ 核心区别（面试常考）

👉 CI 管“打包”，CD 管“上线”，别搞混。

四、企业级 CI/CD 架构分层

🧱 标准分层模型

[开发层]      Git / 分支策略
[构建层]      Jenkins / GitLab CI
[制品层]      Docker Registry（Harbor）
[部署层]      Kubernetes / ArgoCD
[运行层]      应用服务
[观测层]      Prometheus + Alertmanager

📌 各层一句话职责

五、两种主流架构模式

① Pipeline 模式

架构Jenkins → kubectl → Kubernetes

特点

• 简单直接，上手快
• 控制力强

缺点

• 权限耦合（Jenkins 直接操作集群）
• 不够声明式
• 不符合 GitOps 思想

👉 适合阶段：✅ 当前阶段（必须先掌握）

② GitOps 模式（进阶方向）

架构Git → ArgoCD → Kubernetes

核心思想

👉 Git = 最终状态（Single Source of Truth）

特点

• 完全声明式部署
• 自动同步
• 可审计、可回溯

👉 适合阶段：🔥 企业级 / 平台化阶段

🤔 小思考

如果公司要求所有变更必须通过 Git 审批才能上线，你应该选 Pipeline 模式还是 GitOps 模式？ （答案文末揭晓）

六、当前实验的推荐架构（重点）

🎯 推荐落地方案

Git（代码）
   ↓
Jenkins（CI）
   ↓
Docker（构建镜像）
   ↓
Harbor（镜像仓库）
   ↓
kubectl（CD）
   ↓
Kubernetes（运行）
   ↓
Prometheus（监控）
   ↓
Alertmanager（告警）

🔥 必须实现的四个能力

1️⃣ 自动触发

git push→ 自动触发流水线

2️⃣ 禁止手动部署

不再允许 kubectl手工发布

3️⃣ 镜像版本化

demo:v1
demo:v2
demo:commit-hash

4️⃣ 可回滚

kubectl rollout undo deployment/demo

七、CI/CD 与监控系统打通

之前完成了 Prometheus + Alertmanager，这一步非常关键。

🔗 打通后的能力

• 发布失败 → Alertmanager 自动告警
• 发布成功 → Prometheus 监控指标变化

📌 企业级玩法

• 发布失败自动告警
• 发布后自动健康检查
• 异常自动回滚

八、实验演进路线

🚀 第一阶段（现在）

• 跑通 Jenkins Pipeline
• 自动构建镜像
• 自动部署到 K8s

🚀 第二阶段（优化）

• Webhook 自动触发
• 多环境（dev / prod）
• 镜像版本规范

🚀 第三阶段（进阶）

• 引入 ArgoCD（GitOps）
• 灰度发布 / 金丝雀发布
• 自动回滚机制

九、常见误区（必须避开）

❗ 误区1：CI/CD = Jenkins

👉 错。Jenkins 只是工具，CI/CD 是体系。

❗ 误区2：能跑就行

👉 错。企业级关注的是：稳定性、可追溯、自动化。

❗ 误区3：直接上 GitOps

👉 不建议。没有 Pipeline 基础，很难理解 GitOps 的本质。

十、总结（一句话核心）

👉 CI/CD 的本质，是把“软件交付”变成一条可重复、可观测、可回滚的自动化流水线。

🧠 小思考答案

公司要求所有变更必须通过 Git 审批 → 必须选 GitOps 模式（ArgoCD）因为 Pipeline 模式下 Jenkins 直接操作集群，绕过了 Git 审批流程。

文中部分图示来源于互联网，侵删！