本章目标：学习完本章内容，你将对整套方案有全局认识，知道每一台服务器干什么用，理解整个CI/CD流程。
【本章说明】
本章介绍整本书的架构设计，帮助您理解：为什么需要7台服务器、各组件之间的数据流向、以及CI/CD流程的完整链路。读完本章，您将对后续部署有清晰认知，明白每一步操作的用途。
本章时长 ：约 35 分钟 本章难度 ：★☆☆☆☆ 部署节点：无（概念讲解）
1.1 为什么要做这套方案？
在实际工作中，一个微服务项目从代码编写到上线发布，需要经过以下步骤：
-
开发人员编写代码
-
提交到 Git 仓库
-
编译打包（Maven）
-
运行单元测试
-
构建 Docker 镜像
-
推送到镜像仓库
-
部署到 K8s 集群
-
健康检查验证
如果这些步骤全部手工操作，每次发布都需要花费大量时间，还容易出错。CI/CD 流水线的目的就是自动化这些步骤，让开发人员只需关注代码，后续所有事情自动完成。
手工发布 vs 自动化发布对比：
| 对比项 | 手工发布 | CI/CD自动化 |
|---|---|---|
| 编译打包 | 5-10分钟 | 自动触发，1-2分钟 |
| 单元测试 | 10-20分钟（常被省略） | 自动执行，2-3分钟 |
| 构建镜像 | 3-5分钟 | 自动构建，1分钟 |
| 推送镜像 | 1-2分钟 | 自动推送，30秒 |
| 部署到K8s | 5-10分钟 | 自动滚动更新，30秒 |
| 总耗时 | 约30-50分钟 | 约5-8分钟 |
| 出错率 | 高（漏步骤、打错命令） | 低（脚本化执行） |
核心价值：开发人员提交代码后，系统自动完成后续所有工作，无需人工干预。
1.2 整体架构图
bash
┌─────────────────────────────────────────────────────────────────────────────────────┐
│ 完整 CI/CD 架构图 │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ 开发人员日常工作 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 1.写代码 │───▶│ 2.git │───▶│ 3.打Tag │───▶│ 4.推送 │ │ │
│ │ │ 本地 │ │ commit │ │ 版本 │ │ 远程 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └────┬─────┘ │ │
│ └────────────────────────────────────────────────────────┼──────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ Git 代码仓库（Gitee/GitLab） │ │
│ │ • 存储项目源代码 │ │
│ │ • Webhook 触发 Jenkins 构建 │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────┐ │
│ │ Jenkins CI 服务器 │ │
│ │ 1. 拉取代码 ──▶ 2. Maven 编译 ──▶ 3. 单元测试 ──▶ 4. Docker 构建镜像 │ │
│ │ 5. 推送到 Harbor ──▶ 6. 更新 GitOps 仓库 ──▶ 7. 触发 ArgoCD 同步 │ │
│ └─────────────────────────────────────────────────────────────────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌──────────────────────────────┐ │
│ │ │ GitOps 配置仓库 │ │
│ │ │ • 存储 K8s 部署 YAML │ │
│ ▼ │ • 存储 Helm Chart │ │
│ ┌──────────────────────────────┐ └──────────────────────────────┘ │
│ │ Harbor 镜像仓库 │ │ │
│ │ • 存储所有镜像版本 │ │ ArgoCD 监听 │
│ │ • 镜像版本管理 │ ▼ │
│ └──────────────────────────────┘ ┌──────────────────────────────┐ │
│ │ │ ArgoCD CD 服务器 │ │
│ │ │ • 监听 GitOps 仓库变更 │ │
│ └─────────────────────▶│ • 自动同步到 K8s 集群 │ │
│ └──────────────────────────────┘ │
│ │ kubectl apply │
│ ▼ │
│ ┌──────────────────────────────┐ │
│ │ K8s 高可用集群（3主2从） │ │
│ │ • 拉取 Harbor 镜像 │ │
│ │ • 运行微服务 Pod │ │
│ │ • 提供服务访问 │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────────┘1.2.1 架构图分层说明
上图按"从上往下"的顺序理解，分为四个层次：
| 层级 | 名称 | 包含组件 | 职责 |
|---|---|---|---|
| 第一层 | 代码管理层 | Git仓库（Gitee） | 存储源代码，触发CI流程 |
| 第二层 | 持续集成层 | Jenkins + Harbor | 编译代码、构建镜像、推送到仓库 |
| 第三层 | 持续部署层 | ArgoCD + GitOps仓库 | 监听配置变更，同步到K8s集群 |
| 第四层 | 业务运行层 | K8s集群（3主2从） | 最终运行业务Pod |
数据流向（从上往下看）：
-
开发人员将代码推送到Git仓库（第一层）
-
Webhook触发Jenkins开始构建（第二层）
-
Jenkins编译代码、构建镜像后推送到Harbor（第二层）
-
Jenkins更新GitOps仓库中的镜像Tag（第三层）
-
ArgoCD 检测到配置变更，同步到K8s集群（第四层）
-
K8s集群从Harbor拉取新镜像，滚动更新Pod
新手理解口诀：
代码进Git，Jenkins建，Harbor存，ArgoCD推，K8s跑。
1.2.2 各组件连线含义
| 连线 | 含义 | 协议/方式 |
|---|---|---|
| 开发电脑 → Git仓库 | 推送代码 | HTTPS/SSH |
| Git仓库 → Jenkins | 触发构建 | HTTP Webhook |
| Jenkins → Git仓库 | 拉取代码 | HTTPS/SSH |
| Jenkins → Harbor | 推送镜像 | Docker Registry API |
| Jenkins → GitOps仓库 | 更新配置 | Git push |
| GitOps仓库 → ArgoCD | 触发同步 | HTTP Webhook |
| ArgoCD → K8s集群 | 应用配置 | Kubernetes API |
| K8s集群 → Harbor | 拉取镜像 | Docker Registry API |
1.3 核心组件说明
| 组件 | 作用 | 部署位置 | 访问方式 | 依赖关系 |
|---|---|---|---|---|
| Git（Gitee） | 存储代码，触发CI构建 | 云服务/自建 | https://gitee.com | 无 |
| Jenkins | CI工具，负责构建镜像 | 192.168.3.80 | http://192.168.3.80:8080 | 依赖Git、Harbor |
| Harbor | 镜像仓库，存储Docker镜像 | 192.168.3.81 | http://192.168.3.81 | 无 |
| ArgoCD | CD工具，自动部署到K8s | K8s集群内 | https://192.168.3.60:32001 | 依赖Git、K8s |
| K8s集群 | 容器编排，运行业务Pod | 3主2从 | API: https://192.168.3.59:6444 | 依赖Harbor |
组件依赖关系图：
bash
Git ──依赖──▶ Jenkins ──依赖──▶ Harbor
│
│ 触发
▼
ArgoCD ──依赖──▶ K8s集群 ──拉取镜像──▶ Harbor1.4 服务器清单
本方案需要 7 台服务器，规划如下：
| 序号 | 服务器名称 | IP地址 | 配置要求 | 安装软件 | 用途 |
|---|---|---|---|---|---|
| 1 | master01 | 192.168.3.60 | 4C8G+ | containerd, kubelet, kubeadm | K8s控制平面 |
| 2 | master02 | 192.168.3.61 | 4C8G+ | containerd, kubelet, kubeadm | K8s控制平面 |
| 3 | master03 | 192.168.3.62 | 4C8G+ | containerd, kubelet, kubeadm | K8s控制平面 |
| 4 | worker01 | 192.168.3.70 | 4C16G+ | containerd, kubelet | 运行业务Pod |
| 5 | worker02 | 192.168.3.71 | 4C16G+ | containerd, kubelet | 运行业务Pod |
| 6 | jenkins | 192.168.3.80 | 4C8G+ | Jenkins, Docker, Maven, JDK, Git | CI构建 |
| 7 | harbor | 192.168.3.81 | 4C8G+ | Docker, Harbor | 镜像仓库 |
| - | VIP | 192.168.3.59 | - | Keepalived虚拟IP | K8s API入口 |
服务器角色分类：
| 角色 | 包含节点 | 数量 | 职责 |
|---|---|---|---|
| 控制平面 | master01, master02, master03 | 3 | API Server、调度器、控制器、etcd存储 |
| 工作节点 | worker01, worker02 | 2 | 运行实际业务Pod |
| 工具节点 | jenkins, harbor | 2 | CI/CD工具链 |
💡 资源不足怎么办？ 如果您只有3台服务器，可以搭建单Master集群（去掉master02、master03、worker01、worker02），后续部署配置不变。
各服务器职责详解：
| 服务器 | 核心职责 | 为什么需要 |
|---|---|---|
| master01-03 | 管理集群状态、调度Pod | 高可用，任一Master故障不影响集群 |
| worker01-02 | 运行实际业务容器 | 业务负载隔离，与管控分离 |
| jenkins | 编译代码、构建镜像 | CI核心，承担构建任务 |
| harbor | 存储Docker镜像 | 私有镜像仓库，存储构建产物 |
1.5 网络端口规划
| 端口 | 组件 | 服务器 | 说明 | 方向 |
|---|---|---|---|---|
| 6443 | kube-apiserver | K8s Master | API Server（通过VIP访问） | 入站 |
| 6444 | HAProxy | K8s Master | VIP负载均衡端口 | 入站 |
| 2379-2380 | etcd | K8s Master | etcd通信 | 集群内部 |
| 10250 | kubelet | K8s所有节点 | kubelet API | 入站 |
| 80/443 | Ingress | K8s Worker | 业务入口 | 入站 |
| 8080 | Jenkins | Jenkins节点 | Jenkins Web界面 | 入站 |
| 50000 | Jenkins Agent | Jenkins节点 | Jenkins Agent通信 | 入站 |
| 80/443 | Harbor | Harbor节点 | Harbor Web界面 | 入站 |
| 30000-32767 | NodePort | K8s所有节点 | 服务临时暴露端口 | 入站 |
端口开放建议：
| 场景 | 开放端口 | 说明 |
|---|---|---|
| 集群内部通信 | 2379-2380, 6443, 10250 | Master与Worker之间 |
| 运维访问 | 6443, 8080, 80/443 | kubectl、Jenkins、Harbor、业务 |
| 外部用户 | 80/443 | 业务访问入口 |
1.6 软件版本清单
| 软件 | 版本 | 用途 | 版本选择理由 |
|---|---|---|---|
| CentOS / Rocky Linux | 7.9+ / 9.x | 操作系统 | 稳定、社区活跃 |
| containerd | 1.6.28+ | 容器运行时 | K8s官方推荐 |
| Kubernetes | 1.32.0 | 容器编排 | 当前稳定版本 |
| Docker | 24.0+ | 镜像构建 | Jenkins需要 |
| Jenkins | 2.440+ | CI工具 | LTS稳定版 |
| Harbor | 2.10+ | 镜像仓库 | 功能完善 |
| Maven | 3.9+ | Java构建 | 主流版本 |
| JDK | 17/21 | Java运行 | LTS版本 |
| Helm | 3.13+ | K8s包管理 | 与K8s兼容 |
| ArgoCD | 2.10+ | CD工具 | 稳定版本 |
| Prometheus | 2.50+ | 监控 | 主流选择 |
| Grafana | 10.0+ | 可视化 | 功能丰富 |
版本兼容性说明：本文所有软件版本经过兼容性测试，请勿随意升级，以免出现不兼容问题。
1.7 硬件资源估算
| 部署模式 | 控制平面 | 工作节点 | 工具节点 | 合计CPU | 合计内存 | 适用场景 |
|---|---|---|---|---|---|---|
| 高可用生产 | 3台4C8G | 2台4C16G | 2台4C8G | 28核 | 64GB | 生产环境 |
| 标准测试 | 1台4C8G | 2台2C4G | 2台2C4G | 10核 | 20GB | 测试验证 |
| 个人学习 | 1台2C4G | 无 | 2台2C4G | 6核 | 12GB | 单机学习 |
个人学习环境配置建议：
如果您的电脑配置有限（如16GB内存），可以采用以下分配方案：
| 虚拟机 | CPU | 内存 | 硬盘 |
|---|---|---|---|
| master01 | 2核 | 3GB | 40GB |
| worker01 | 2核 | 4GB | 50GB |
| jenkins | 2核 | 4GB | 40GB |
| harbor | 2核 | 3GB | 50GB |
| 合计 | 8核 | 14GB | 180GB |
1.8 时间规划参考
| 阶段 | 章节 | 预计时长 | 累计 |
|---|---|---|---|
| 基础环境 | 第1-2章 | 1.5小时 | 1.5小时 |
| K8s集群部署 | 第3-11章 | 3小时 | 4.5小时 |
| DevOps工具 | 第12-15章 | 1.5小时 | 6小时 |
| Git与代码 | 第16-18章 | 1.5小时 | 7.5小时 |
| 镜像构建 | 第19-21章 | 1.5小时 | 9小时 |
| CI流水线 | 第22-24章 | 1.5小时 | 10.5小时 |
| K8s配置 | 第25-27章 | 1.5小时 | 12小时 |
| CD部署 | 第28-30章 | 1.5小时 | 13.5小时 |
| 运维监控 | 第31-34章 | 2小时 | 15.5小时 |
| 实战案例 | 第35-37章 | 2小时 | 17.5小时 |
学习节奏建议：
| 节奏 | 每天学习 | 完成周期 |
|---|---|---|
| 快速 | 2-3章（2-3小时） | 2周 |
| 标准 | 1-2章（1-2小时） | 3-4周 |
| 宽松 | 每周5-6章 | 6-8周 |
1.9 常见问题与解答
Q1：服务器数量不够怎么办？
A：最少可以用3台服务器学习：1台Master、1台Worker、1台同时部署Jenkins和Harbor。后续部署配置不变。
Q2：Windows/Mac电脑可以跟着做吗？
A：可以。本书使用VMware虚拟机，Windows和Mac都有对应版本。
Q3：CentOS 7已经停止维护了，还能用吗？
A：可以。CentOS 7虽然停止维护，但现有镜像源仍可正常使用。推荐使用Rocky Linux 9.x作为替代。
Q4：K8s版本为什么选择1.32.0？
A：本书编写时K8s的最新稳定版本。建议使用书中指定版本，避免版本差异导致的问题。
Q5：一定要用Gitee吗？GitHub可以吗？
A：可以。GitHub、GitLab等均可，只需修改相应的仓库地址即可。
Q6：什么是VIP？为什么需要VIP？
A：VIP是虚拟IP地址，由Keepalived管理。当客户端访问VIP时，请求会被转发到当前健康的Master节点。如果当前Master宕机，VIP会自动漂移到其他Master，实现高可用。
Q7：Jenkins和Harbor为什么要独立部署？
A：Jenkins和Harbor是CI/CD的核心工具，需要较多的CPU和内存资源。独立部署可以避免与K8s集群争抢资源，也便于独立维护和升级。
Q8：生产环境和学习环境的区别是什么？
A：生产环境要求高可用（3个Master、2个Worker），学习环境可以用单Master降低成本。两者在部署流程上没有区别，只是节点数量不同。
Q9：Master节点后期如何扩充？
A：K8s控制平面推荐使用奇数个Master节点（1、3、5、7），这是基于etcd的分布式共识算法（Raft）要求。奇数节点可以在保证多数派（超过N/2）存活的前提下，容忍相同数量的节点故障。例如3节点可容忍1个故障，5节点可容忍2个故障。4节点与3节点容忍故障数相同（都是1个），但增加了网络开销，不推荐。
Q10：Worker节点后期如何扩充？
A：Worker节点没有奇偶限制，可根据业务负载随时扩充。步骤如下：
# 1. 在新节点上安装 containerd、kubelet、kubeadm
# 2. 在 master01 上生成加入命令
kubeadm token create --print-join-command
# 3. 在新节点上执行加入命令
kubeadm join <vip>:6443 --token <token> --discovery-token-ca-cert-hash <hash>扩充后，新Worker会自动加入集群并承担业务负载。
1.10 本章小结
| 要点 | 说明 |
|---|---|
| CI/CD流程 | 代码提交 → 自动构建 → 自动部署 |
| 7台服务器 | 3 Master + 2 Worker + Jenkins + Harbor |
| 核心组件 | Git + Jenkins + Harbor + ArgoCD + K8s |
| 学习目标 | 理解整体架构，知道每台服务器的用途 |
| 硬件需求 | 个人学习最低6核12GB，生产28核64GB |
| 学习周期 | 标准节奏3-4周，快速2周 |
| 四层架构 | 代码管理层 → 持续集成层 → 持续部署层 → 业务运行层 |
学完本章后，您应该能够：
-
说出CI/CD自动化的核心价值
-
画出整体架构图并解释数据流向
-
明确每台服务器的角色和职责
-
根据自己的硬件条件规划部署方案
-
估算完成整套方案需要的时间
-
理解四层架构的划分逻辑
下一章预告：搭建7台虚拟机，完成系统初始化配置（主机名、静态IP、防火墙、时间同步）。