GitLab CI → Docker 镜像 → 部署开发环境 → 接口自动化测试
一、不用 K8s vs 用 K8s
现在简单版（无 K8s）
GitLab CI → 构建 Docker 镜像 → SSH 登录服务器，docker run 手动启动容器问题：
- 机器少还行，多了管不过来
- 挂了不会自动重启
- 不能自动扩容
- 环境（开发 / 测试 / 生产）切换麻烦
用K8s 之后
GitLab CI → 构建 Docker 镜像 → 推镜像仓库 → K8s 自动拉取、部署、调度 SSH 手动操作全部消失，全自动化
二、K8s 在你完整 CI/CD 流程里的位置
完整带 K8s 的流水线，对应你们公司真实部署后做接口自动化：
plaintext
本地git push
↓
【CI阶段】
构建 → 单元测试 → 打包Docker镜像 → 推送镜像仓库
↓
【CD阶段】
K8s部署到 开发环境(Namespace)
↓
接口自动化测试（测开发环境K8s里的服务）
↓
测试通过 → K8s部署到测试/预发/生产环境三、K8s 在流程中具体做什么？5 个核心作用
1. 代替 SSH 手动部署
原来：CI 里写 ssh 命令远程 docker run
现在：CI 只需要发一条指令 kubectl apply，K8s 自动部署
2. 环境隔离（开发 / 测试 / 生产）
用 Namespace 区分：
- dev-ns：开发环境
- test-ns：测试环境
- prod-ns：生产环境一键切换部署到不同环境，不用改服务器 IP
3. 自愈能力
容器挂了、节点宕机 → K8s 自动重启、自动迁移，不用人管
4. 扩缩容、灰度发布
流量大自动多启动几个 Pod；新版本先部署一部分，验证没问题全量发布
5. 统一管理 Nginx（Ingress）
K8s 里用 Ingress-Nginx，统一做反向代理、域名、HTTPS，不用在每台服务器单独装 Nginx
四、Docker、Nginx、K8s 三者分工
- Docker：打包应用成镜像（盒子）
- K8s：调度、运行、管理这些盒子（容器编排）
- Nginx：K8s 里的 Ingress，统一流量入口、反向代理
简单比喻：
- Docker = 集装箱
- K8s = 港口调度中心（管集装箱放哪、坏了换、加箱子）
- Nginx = 港口大门，负责接待访客
五、总结
Docker 用于应用容器化打包；K8s 作为容器编排平台，实现自动化部署、环境隔离、自愈、扩缩容；Nginx 作为反向代理提供统一访问入口。在 CI/CD 流程中，GitLab CI 构建镜像后，通过 K8s 将应用自动部署到开发环境，再执行接口自动化测试，验证通过后发布至生产环境。