停止为闲置的 CI 付费：在 Kubernetes 上运行 GitLab Runners
在周一高峰期扩展 CI 规模，然后在夜间和周末缩减容量——附带操作演示视频的五分钟指南。
Balinder Walia2026年9月29日1 min read
大多数团队为持续集成付费的方式，仿佛每个夜晚和周末仍然是周一早晨。GitLab Runners 在 Kubernetes 上颠覆了这一模式：当流水线到来时扩展容量，当办公室安静下来时再缩减。阅读技术深度解析以了解 Helm 价值、执行器设置及成本模型。
底线。为峰值预留资源，为低谷释放资源。临时作业容器在需求下降时（尤其是夜晚和周末）回收 CPU、内存和存储空间，因此周一的资源池不会为周六的账单买单。
观看视频
1. Runners & pipelines— 在 Kubernetes 上自动扩展 GitLab Runner 工作负载。
2. GitLab Server on HA Kubernetes— 几分钟内通过 Operator 部署。
youtu.be/fu82hENYNEs· 文档：GitLab Operator
昂贵的习惯
- 白天：合并请求和测试使需求激增。
- 夜晚：活动减少；固定虚拟机仍在消耗 CPU 和内存。
- 周末：通常接近空闲——但磁盘和节点可能仍在计费。
您不是在为已完成的构建付费，而是在为无论是否有人使用都存在的容量付费。
更简洁的架构图
GitLab 的Runner执行流水线任务。Kubernetes可以将这些工作节点创建为短生命周期的 Pod，并在任务完成后将其删除。在超大规模场景下，同样的思路适用于节点：队列积压时增加节点；夜间和周末则减少——理想情况下几乎为零。
巨大成本节省的来源
- 在工作时间（人类或机器人活跃时）弹性扩容——并行启动任务 Pod，直至达到并发和集群限制。
- 需求消失时强力缩容——Pod 自动消失；借助集群自动伸缩，空闲节点离开集群。
- 停止在安静时段浪费 CPU、内存和存储来维持始终在线的 Runner 集群。
- 为成果付费，而非为基础设施付费——保留 GitLab 和轻量级 Runner 管理器；让空闲时的资源池自然蒸发。
巨大的节省体现在：周一的峰值不再决定周二凌晨的账单——而周六的寂静终于在发票上显得安静了。
官方文档
下一篇：超大规模技术文章涵盖 Operator 与 Helm 轨道、并发、DinD、可观测性以及 FinOps 检查清单。课程构建提示：gitlab-runners-k3s-hyperscale-course.prompt.md在 Workstation 网站仓库中（替换已退役的 devops.git 链接）。
由Workstation发布。