Coding DevOps 与 Jenkins 迟暮

背景

尊敬的用户您好：

由于产品业务调整，【CODING DevOps】系列产品将计划于以下时间停止相关支持：

标准版产品下线：2025年9月1日；原免费版客户无法使用，订购方案调整

所有产品停止新购：2025年9月30日

所有产品停止续购：2026年3月30日

所有产品停止服务：2028年9月30日

为确保您的使用权益和资产数据安全，请及时关注并处理。

若您仍有类似需求，可选购我们下一代产品【云原生构建】（简称 CNB），能力更强、产品更聚焦于开发者。

随着这则公告，这个季度的 OKR 上自然新增了若干迁移工作，趁刚好完成这份 KR，顺带写篇文档记录一下，Coding 的迟暮。

Jenkins 基座的迟暮

Jenkins 的优点在于其灵活性与生态：几乎任何 CI 流程、任何外部系统都可以通过插件或自定义脚本接入。

但也有以下的一些缺点：

长期驻留的执行单元：Jenkins 的执行模型基于长期在线的 agent（物理机 / VM / 容器），job 被调度到这些已存在的节点上运行。节点的持久性带来缓存和残留状态，也带来不可控的环境漂移。
运维成本和容量规划：agent 的维护、弹性扩容、补丁更新与安全加固需要持续投入。面对突发并发需求时，扩容常常依赖人工配置或额外的 VM 启动，反应滞后且成本较高。
执行语义耦合：Jenkinsfile（Groovy）与插件逻辑常常和 Jenkins 平台高度耦合，流水线难以跨平台复用或以声明式方式版本化管理。

即需要 Jenkins Agent 需要占用一台机器，节点是持续存在的，长期运行会有缓存的残留影响，需要人工进行运维。

云原生 DevOps 势头正盛

云原生 DevOps 是以 Pod 为单位的，具体的差异不在于是否把构建过程放进容器执行，而是直接忽略掉机器这个概念（Node），使用 Pod 来进行任务执行，通过 K8S 实现资源调度

关键点包括：

一次性、镜像驱动的执行环境：每个 job 在独立的容器或 Pod 中启动，执行结束即被销毁。镜像定义环境，保证了环境的一致性与可复现性。
Kubernetes 的调度与弹性：将并发与资源管理交给 K8s，利用节点池、自动扩缩、亲和性调度等能力实现高并发、低延迟的构建执行。
声明式流水线与 GitOps 集成：以 YAML 或 Task/DAG 的声明式方式定义流水线，流水线本身可以版本化、审计并纳入 GitOps 流程，便于审查与回溯。
最小权限与短生命周期安全模型：短生命周期容器 + 集中化秘密管理减少了长期运行节点上凭证泄露及横向越权的风险。

则代表的是一种可复现、一次性的交付体系。

用直觉来对比两者的差异

Jenkins 的模式

[Jenkins Master] 
      |
      ├── Agent 1 (一直活着) 对应某一台活着的具体机器
      ├── Agent 2 (一直活着) 对应某一台活着的具体机器
      ├── Agent 3 (一直活着) 对应某一台活着的具体机器

云原生的 CI/CD 模式

# 构建开始
[Pipeline]
   └── 创建 Pod 1 (新容器) 可能会被调度到某一个 Node 上
   └── 创建 Pod 2 (新容器) 可能会被调度到某一个 Node 上
   └── 创建 Pod 3 (新容器) 可能会被调度到某一个 Node 上
   
# 构建结束
Pod 1 销毁  
Pod 2 销毁  
Pod 3 销毁

K8S 云原生 - GitLab Runner

以 GitLab Runner 的 K8S executor 为例：

CI 触发器（Git push / MR /定时）产生 Job。
Runner 收到 Job 请求后，向 K8s API 发起创建 Pod 的操作。Pod 的 spec 中包含用于执行 Job 的镜像、命令、工作目录、挂载与 sidecar（服务模拟或缓存）等。
K8s 将 Pod 调度到某个 Node 上，容器在该 Node 的运行时中启动，拉取代码并在容器内执行脚本。
Job 完成后，Pod 被销毁，工作目录与运行时中间态不再保留。

注意两点：

Runner 本身并不承担构建负载（它是调度者/启动器），真正的执行发生在每次临时创建的容器中；
Pod 会被调度到集群中的某一台物理机（Node），但这台物理机对用户是透明的——调度、故障转移、资源隔离由 K8s 管理。

云原生的好处 - GitLab Pages

GitLab Pages 有两种部署模式：Omnibus 安装（传统单机部署） 和 K8S原生部署，传统单机部署和直觉理解上用一台服务器上托管静态资源是一样，没有其他优势了，这里主要讲 K8S原生部署 的方式。

Kubernetes 部署（GitLab Helm chart）

GitLab 官方 Helm chart 支持把 GitLab Pages 作为一个 Deployment + Service 部署在 K8s 集群中。
每个 Pages Pod 运行 gitlab-pages 服务进程，处理 HTTP 请求。
构建的静态文件通常存储在共享存储（如 PVC、NFS、对象存储 S3/GCS），Pages Pod 从存储中读取文件提供服务。
可以通过 K8s 实现弹性扩容。

即 GitLab 还能顺带通过 Page Pod 实现静态资源的托管+自动扩容，还能直接使用 S3 来实现共享存储。

结尾

具体的差异如下：

维度	Jenkins	云原生 DevOps（K8s Runner / CNB 等）
执行单元	长期驻留的 Agent，机器级别运行	一次性容器/Pod，按需创建与销毁
环境一致性	环境有缓存，依赖人工维护	以镜像为核心，环境可复现、可审计
扩容模型	手动增加 Agent，扩容成本高、弹性不足	Pod 动态调度，自动扩容、按需分配资源
隔离与安全	多任务在同一 Agent 上运行，可能互相影响	每个任务独立 Pod，天然隔离、安全性更高
流水线表达	Jenkinsfile，与 Jenkins 深度绑定	YAML、Task/DAG 声明式，易与 GitOps、云原生生态集成

这些演变不是简单的技术升级替换，而是一种模式上的演变，真正的驱动来自于云原生生态的繁荣，重点不是团队去适应技术栈升级，而是建立一套可扩容、可持续的交付体系，真正提升交付的效率。