目录
一、四者的定义与定位
1.1 核心定义
DevOps
定义：一种文化、理念和实践的集合
本质：方法论
范围：
- 文化层：协作、责任共担、持续学习
- 流程层：CI/CD、自动化、敏捷
- 工具层：Git、Jenkins、Docker、K8s等
类比：一套完整的生产管理体系CI/CD
定义：持续集成和持续交付/部署的流程和实践
本质：自动化流程
范围：
- CI（持续集成）：代码提交 → 构建 → 测试
- CD（持续交付/部署）：构建制品 → 部署 → 验证
类比：自动化生产线上的核心环节Jenkins
定义：开源的自动化服务器
本质：CI/CD工具
功能：
- 执行CI/CD流水线
- 任务调度
- 插件生态
类比：工厂里的自动化机器人Kubernetes（K8s）
定义：容器编排平台
本质：部署和运维平台
功能：
- 容器部署
- 自动扩缩容
- 服务发现和负载均衡
- 自愈能力
类比：智能仓储管理系统1.2 关系概览图
┌─────────────────────────────────────────────────────────────┐
│ DevOps │
│ （整体方法论和文化理念） │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ CI/CD │ │
│ │ （核心自动化流程） │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Jenkins │ │ K8s │ │ │
│ │ │（CI/CD工具）│ ─────────> │（部署平台） │ │ │
│ │ │ │ 部署到 │ │ │ │
│ │ │ - 构建 │ │ - 容器编排 │ │ │
│ │ │ - 测试 │ │ - 自动扩容 │ │ │
│ │ │ - 打包 │ │ - 故障自愈 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ 其他DevOps工具： │
│ - Git（版本控制） │
│ - Docker（容器化） │
│ - Prometheus（监控） │
│ - ELK（日志） │
└─────────────────────────────────────────────────────────────┘二、层次关系分析
2.1 从大到小的包含关系
第一层：DevOps（最外层 - 理念和文化）
│
├─ 包含CI/CD流程
├─ 包含自动化实践
├─ 包含协作文化
└─ 包含各种工具
第二层：CI/CD（中层 - 具体流程）
│
├─ 需要工具实现（Jenkins等）
├─ 需要部署平台（K8s等）
└─ 是DevOps的核心实践之一
第三层：Jenkins、K8s（底层 - 具体工具）
│
├─ Jenkins：实现CI/CD流程的工具
├─ K8s：应用部署和运行的平台
└─ 都是支撑CI/CD和DevOps的技术工具2.2 类比说明
用建筑工程类比：
DevOps = 现代化建筑施工管理体系
- 理念：快速、高效、高质量建房
- 包含：设计规范、施工流程、质量标准、团队协作
CI/CD = 自动化施工流水线
- 自动化浇筑混凝土
- 自动化搭建框架
- 自动化质量检测
Jenkins = 混凝土搅拌车
- 专门用于自动化搅拌混凝土
- 可以配置不同的配方
- 是流水线上的一台设备
K8s = 智能塔吊系统
- 自动吊装材料到指定位置
- 自动调度多台塔吊
- 确保施工安全和效率用餐厅类比：
DevOps = 现代化餐厅管理体系
- 理念：快速、美味、高性价比
- 包含：菜品设计、后厨流程、服务标准、团队协作
CI/CD = 后厨标准化流程
- 菜品标准化
- 流程自动化
- 质量检查
Jenkins = 智能炒菜机
- 自动完成炒菜过程
- 可以设置不同菜谱
- 保证口味稳定
K8s = 智能送餐系统
- 自动分配餐桌
- 自动调度服务员
- 确保上菜及时三、详细对比
3.1 核心对比表
| 维度 | DevOps | CI/CD | Jenkins | K8s |
|---|---|---|---|---|
| 本质 | 方法论/文化 | 流程/实践 | 工具 | 平台 |
| 层次 | 最高层（理念） | 中间层（流程） | 底层（工具） | 底层（平台） |
| 范围 | 全流程（开发+运维） | 构建+部署 | CI/CD执行 | 容器运行 |
| 目标 | 提升整体效能 | 自动化交付 | 自动化CI/CD | 自动化运维 |
| 可替代性 | 不可替代 | 不可替代 | 可替代（GitLab CI） | 可替代（Docker Swarm） |
| 学习曲线 | 文化理解（易） | 流程理解（中） | 工具使用（中） | 复杂系统（难） |
| 团队角色 | 全员 | 开发+运维 | DevOps工程师 | 运维+SRE |
3.2 功能对比
DevOps的范畴
✅ 文化建设
- 打破部门墙
- 协作文化
- 持续学习
✅ 流程优化
- CI/CD
- 敏捷开发
- 持续改进
✅ 工具链
- 版本控制（Git）
- CI/CD（Jenkins）
- 容器化（Docker）
- 编排（K8s）
- 监控（Prometheus）
- 日志（ELK）
✅ 实践方法
- Infrastructure as Code
- 不可变基础设施
- 微服务架构
- 测试驱动开发CI/CD的范畴
✅ 持续集成（CI）
- 代码提交
- 自动构建
- 自动测试
- 代码检查
✅ 持续交付（CD）
- 自动部署到测试环境
- 集成测试
- 人工审批
- 部署到生产
✅ 持续部署
- 全自动部署到生产
- 无需人工干预
✅ 相关实践
- 自动化测试
- 版本管理
- 环境管理
- 回滚策略Jenkins的范畴
✅ 核心功能
- Pipeline执行引擎
- 任务调度
- 插件管理
- 分布式构建
✅ CI功能
- Git集成
- 构建触发
- 编译打包
- 测试执行
- 代码检查
✅ CD功能
- 部署脚本执行
- 环境管理
- 审批流程
- 通知机制
❌ 不包含
- 容器运行（需要Docker）
- 容器编排（需要K8s）
- 监控告警（需要Prometheus）K8s的范畴
✅ 容器编排
- Pod管理
- Deployment管理
- Service管理
- Ingress管理
✅ 自动化运维
- 自动扩缩容（HPA）
- 故障自愈
- 滚动更新
- 健康检查
✅ 资源管理
- CPU/内存限制
- 资源调度
- 存储管理
- 网络管理
❌ 不包含
- CI构建（需要Jenkins）
- 代码管理（需要Git）
- 监控（需要Prometheus，但K8s提供基础指标）四、协作关系
4.1 完整的DevOps实践中的协作
┌─────────────────────────────────────────────────────────┐
│ 完整的DevOps流程 │
└─────────────────────────────────────────────────────────┘
阶段1：计划和编码（Plan & Code）
工具：Jira + Git
角色：产品经理 + 开发人员
↓
阶段2：持续集成（CI - Jenkins）
┌──────────────────────────────────┐
│ Jenkins Pipeline │
├──────────────────────────────────┤
│ 1. Git Clone │
│ 2. Maven Build │
│ 3. Unit Test │
│ 4. SonarQube Scan │
│ 5. Docker Build │
│ 6. Docker Push to Harbor │
└──────────────────────────────────┘
↓
阶段3：持续部署（CD - Jenkins + K8s）
┌──────────────────────────────────┐
│ Jenkins 触发 K8s 部署 │
├──────────────────────────────────┤
│ kubectl set image ... │
│ kubectl rollout status ... │
└───────────┬──────────────────────┘
↓
┌──────────────────────────────────┐
│ K8s 执行部署 │
├──────────────────────────────────┤
│ 1. 拉取新镜像 │
│ 2. 创建新Pod │
│ 3. 健康检查 │
│ 4. 流量切换 │
│ 5. 删除旧Pod │
└──────────────────────────────────┘
↓
阶段4：监控和反馈（Monitor & Feedback）
工具：Prometheus + Grafana + ELK
角色：SRE + 开发人员
↓
阶段5：持续改进（Continuous Improvement）
基于监控数据和用户反馈，优化系统4.2 具体协作案例
案例：一次代码提交的完整旅程
09:00 - 开发人员提交代码到Git（master分支）
↓
Git Webhook通知Jenkins
09:01 - Jenkins收到通知，开始CI Pipeline
Stage 1: Checkout
- 克隆代码
09:02 - Stage 2: Build
- mvn clean package
- 编译成功，生成jar包
09:05 - Stage 3: Test
- mvn test
- 200个单元测试，全部通过
- 代码覆盖率：85%
09:08 - Stage 4: SonarQube Analysis
- 代码质量：A
- 无严重漏洞
09:10 - Stage 5: Docker Build
- docker build -t my-app:1.0.0
- 构建Docker镜像
09:12 - Stage 6: Docker Push
- docker push harbor.example.com/my-app:1.0.0
- 推送到Harbor镜像仓库
09:13 - Stage 7: Deploy to Dev（Jenkins调用K8s）
- kubectl set image deployment/my-app \
my-app=harbor.example.com/my-app:1.0.0 -n dev
↓
K8s开始工作：
1. 拉取新镜像
2. 创建新Pod
3. 等待Pod Ready（健康检查通过）
4. 流量切换到新Pod
5. 删除旧Pod
09:15 - K8s部署完成
- 3个Pod全部Running
- 服务可访问
09:16 - Stage 8: Integration Test（Jenkins执行）
- 运行自动化测试
- 测试通过
09:18 - Stage 9: Notification
- 发送钉钉通知："部署成功"
- 通知相关人员
全程自动化，无需人工干预
总耗时：18分钟4.3 Jenkins和K8s的深度集成
方式1：Jenkins在K8s外部
┌────────────────┐
│ Jenkins Master│ （运行在独立服务器）
└───────┬────────┘
│
│ kubectl命令
↓
┌───────────────────────────────┐
│ Kubernetes Cluster │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ Pod │ │ Pod │ │ Pod │ │
│ └─────┘ └─────┘ └─────┘ │
└───────────────────────────────┘
Jenkins通过kubectl命令操作K8s方式2：Jenkins动态Agent在K8s中
┌────────────────┐
│ Jenkins Master│
└───────┬────────┘
│
│ 请求创建Agent
↓
┌───────────────────────────────┐
│ Kubernetes Cluster │
│ │
│ ┌─────────────────────┐ │
│ │ Jenkins Agent Pod │ │
│ │ - 执行构建任务 │ │
│ │ - 完成后自动销毁 │ │
│ └─────────────────────┘ │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │App │ │App │ │App │ │
│ │Pod │ │Pod │ │Pod │ │
│ └─────┘ └─────┘ └─────┘ │
└───────────────────────────────┘
优势：
✅ 动态创建Agent，资源利用率高
✅ 构建环境隔离
✅ 易于扩展配置示例：
groovy
// Jenkinsfile
pipeline {
agent {
kubernetes {
yaml """
apiVersion: v1
kind: Pod
metadata:
labels:
jenkins: agent
spec:
containers:
- name: maven
image: maven:3.8-jdk11
command: ['cat']
tty: true
- name: docker
image: docker:latest
command: ['cat']
tty: true
volumeMounts:
- name: docker-sock
mountPath: /var/run/docker.sock
volumes:
- name: docker-sock
hostPath:
path: /var/run/docker.sock
"""
}
}
stages {
stage('Build') {
steps {
container('maven') {
sh 'mvn clean package'
}
}
}
stage('Docker Build') {
steps {
container('docker') {
sh 'docker build -t my-app .'
}
}
}
}
}五、实际应用场景
5.1 场景1：小型创业公司
团队规模：
- 开发：5人
- 运维：1人
方案选择：
DevOps理念：
✅ 开发和运维协作
✅ 自动化优先
CI/CD：
✅ 简化的CI/CD流程
工具选择：
✅ Git（代码管理）
✅ GitLab CE（代码仓库 + 内置CI/CD）
- 优势：集成度高，配置简单
- 缺点：功能不如Jenkins丰富
✅ Docker + Docker Compose（本地开发）
❌ K8s（过于复杂，资源有限）
- 替代：直接Docker部署
架构：
Git → GitLab CI → Docker Build → Docker Deploy为什么不用K8s：
- 应用数量少（<10个）
- 流量不大（不需要自动扩缩容）
- 运维人力有限（K8s学习成本高）
- Docker Compose足够用
5.2 场景2：中型互联网公司
团队规模：
- 开发：50人
- 测试：10人
- 运维：5人
方案选择：
DevOps理念：
✅ 跨职能团队
✅ CI/CD标准化
CI/CD：
✅ 完整的CI/CD流程
✅ 多环境部署
工具选择：
✅ Git + GitLab/GitHub
✅ Jenkins（CI/CD）
- 复杂流程编排
- 丰富的插件
✅ Docker（容器化）
✅ K8s（容器编排）
- 微服务数量多（30+）
- 需要自动扩缩容
- 需要故障自愈
✅ Harbor（镜像仓库）
✅ Prometheus + Grafana（监控）
架构：
Git → Jenkins → Docker Build → Harbor
↓
K8s Deployment
↓
Prometheus监控为什么用K8s：
- 微服务数量多
- 流量波动大（需要弹性扩缩容）
- 高可用要求（需要故障自愈）
- 有专业运维团队
5.3 场景3：大型企业
团队规模：
- 开发：200人
- 测试：50人
- 运维：20人
- DevOps平台团队：10人
方案选择：
DevOps理念：
✅ 企业级DevOps文化
✅ 平台化建设
CI/CD：
✅ 企业级CI/CD平台
✅ 多租户隔离
✅ 权限管理
工具选择：
✅ Git + GitLab企业版
✅ Jenkins集群（高可用）
✅ Docker + 镜像扫描
✅ K8s集群（多集群）
- 开发集群
- 测试集群
- 生产集群（多AZ）
✅ Harbor企业版
✅ Prometheus + Grafana（企业监控）
✅ ELK Stack（日志分析）
✅ SkyWalking（链路追踪）
✅ Nacos/Apollo（配置中心）
架构：
Git
↓
Jenkins集群
(Master + Agents)
↓
Docker Build + 安全扫描
↓
Harbor高可用集群
↓
K8s多集群部署
↓
监控、日志、追踪、告警六、技术选型指南
6.1 选择决策树
是否需要DevOps？
└─ 是 → 所有团队都应该实践DevOps理念
是否需要CI/CD？
├─ 团队>5人 → 是
├─ 发布频率>每周1次 → 是
└─ 质量要求高 → 是
选择CI/CD工具：
├─ 团队规模<10人 → GitLab CI（简单集成）
├─ 团队规模10-50人 → Jenkins或GitLab CI
├─ 团队规模>50人 → Jenkins（灵活强大）
└─ 云原生团队 → Tekton + ArgoCD
是否需要K8s？
├─ 微服务数量>10个 → 是
├─ 需要弹性扩缩容 → 是
├─ 高可用要求 → 是
├─ 有专业运维团队 → 是
└─ 否 → Docker Compose足够6.2 对比矩阵
CI/CD工具对比
| 特性 | Jenkins | GitLab CI | GitHub Actions | Tekton |
|---|---|---|---|---|
| 部署方式 | 自部署 | 自部署/SaaS | SaaS | K8s原生 |
| 学习曲线 | 中等 | 简单 | 简单 | 复杂 |
| 配置方式 | Groovy | YAML | YAML | YAML |
| 插件生态 | 丰富 | 中等 | 丰富 | 少 |
| 适用场景 | 企业级 | 中小型 | 开源项目 | 云原生 |
| 成本 | 免费 | 免费/付费 | 免费（限额） | 免费 |
容器编排对比
| 特性 | K8s | Docker Swarm | Nomad |
|---|---|---|---|
| 复杂度 | 高 | 低 | 中 |
| 生态 | 最丰富 | 少 | 中等 |
| 学习曲线 | 陡峭 | 平缓 | 中等 |
| 适用规模 | 大型 | 小型 | 中型 |
| 社区支持 | 最好 | 一般 | 一般 |
6.3 推荐组合
组合1：轻量级（小团队）
GitLab（代码 + CI/CD一体化）
↓
Docker Compose（本地 + 部署）
↓
简单监控（Uptime Robot）组合2：标准组合（中型团队）
GitHub/GitLab（代码管理）
↓
Jenkins（CI/CD）
↓
Docker + K8s（容器化 + 编排）
↓
Prometheus + Grafana（监控）组合3：企业级（大型团队）
GitLab企业版（代码 + Code Review）
↓
Jenkins集群（CI/CD）
↓
Harbor（镜像仓库 + 安全扫描）
↓
K8s多集群（高可用部署）
↓
Prometheus + Grafana + ELK + SkyWalking
（监控 + 日志 + 追踪）总结
核心关系总结
1. DevOps是理念，CI/CD是实践
DevOps包含CI/CD，但不止于CI/CD
2. CI/CD是流程，Jenkins是工具
Jenkins是实现CI/CD的工具之一
也可以用GitLab CI、GitHub Actions等
3. K8s是平台，是CD阶段的部署目标
Jenkins负责"构建和打包"
K8s负责"运行和管理"
4. 它们不是替代关系，而是协作关系
DevOps理念 → CI/CD流程 → Jenkins工具 → K8s平台选择建议
- 理念层面：所有团队都应该实践DevOps
- 流程层面：根据团队规模选择CI/CD实施程度
- 工具层面：根据需求选择合适的工具
- 平台层面：根据规模和复杂度决定是否使用K8s
关键要点
- ✅ DevOps是方法论，包含但不限于CI/CD
- ✅ CI/CD是核心实践，需要工具支撑
- ✅ Jenkins是CI/CD的实现工具
- ✅ K8s是应用运行和管理平台
- ✅ 四者协同工作，共同支撑现代软件交付
完整的CI/CD系列文档已全部完成！
希望这套文档能帮助您深入理解CI/CD及其与DevOps、Jenkins、K8s的关系！