当前位置:首页 >专题 >GitHub Actions Runner Controller 0.15.0 与 ARC Scale Sets 工程专题

GitHub Actions Runner Controller 0.15.0 与 ARC Scale Sets 工程专题
GitHub Actions Run

GitHub Actions Runner Controller 0.15.0 与 ARC Scale Sets 工程专题

从 Kubernetes 控制器、自托管 Runner 到弹性扩缩容与供应链安全
自托管 Runner 已经是许多团队的构建、测试、镜像和发布基础设施,但单机 Runner 池很难同时满足弹性、隔离、升级和审计要求。本专题以 Actions Runner Controller 0.15.0 与 Runner Scale Sets 为主线,连接 Kubernetes 控制器、Runner 版本治理、CI 运行控制、构建缓存、供应链签名和最小权限实践,帮助平台团队把 Runner 从“能跑任务的机器”升级成可扩缩、可观测、可回退的工程组件。

Runner 池与 CI 生产验收

从版本、调度和重跑到缓存、签名与故障恢复

GitHub Actions 自托管 Runner 强制升级时间线:CI 团队该提前查什么
文章

GitHub Actions 自托管 Runner 强制升级时间线:CI 团队该提前查什么

梳理自托管 Runner 最低版本强制时间线、资产盘点、灰度升级和持续监控。
GitHub Agentic Workflows 进入团队后权限边界怎么设计
文章

GitHub Agentic Workflows 进入团队后权限边界怎么设计

讲清只读 Agent、safe outputs、威胁检测和 Environment 审批的权限边界。
GitHub Actions 手动输入怎么配置或排查
文章

GitHub Actions 手动输入怎么配置或排查

从 workflow_dispatch、输入字段、权限和日志确认手动运行参数。
GitHub Actions 失败步骤怎样只重新运行未完成的任务
文章

GitHub Actions 失败步骤怎样只重新运行未完成的任务

说明失败 Job 重跑、依赖范围、attempt 和旧提交复用边界。
GitHub Actions 缓存依赖并控制失效边界
文章

GitHub Actions 缓存依赖并控制失效边界

用 OS、架构、人工版本和锁文件哈希设计可复用且可失效的依赖缓存。
Docker buildx 缓存导出减少重复构建时间
文章

Docker buildx 缓存导出减少重复构建时间

比较 registry、local、inline 和 gha 缓存后端,并设计跨 Runner 复用边界。
CNCF供应链签名在CI产物验收中的接入方案
文章

CNCF供应链签名在CI产物验收中的接入方案

以 digest、OIDC 和 Cosign 验证 CI 产物身份与签名证据。
GitHub Actions 步骤并行怎么验收:background、wait-all 与日志边界
文章

GitHub Actions 步骤并行怎么验收:background、wait-all 与日志边界

验证并行步骤、等待点、独立日志、取消和失败状态传播。

ARC Scale Sets 常见问题

扩缩容、隔离、权限和恢复的上线答案

ARC Scale Sets 会自动解决 Runner 安全隔离吗?

不会。ARC 负责控制器和 Runner 生命周期;权限、网络策略、容器运行时、密钥暴露和工作区清理仍需平台团队单独设计与验收。

为什么要固定 ARC 和 Runner 版本?

Runner 与 controller 的版本变化会影响注册、标签、扩缩容和 GitHub 平台兼容性;应记录版本矩阵,先灰度再逐步升级并保留回退镜像。

临时 Runner 上应该如何处理缓存和凭据?

缓存放到明确作用域的外部后端,任务结束清理工作区;凭据优先使用短时 OIDC 或最小权限令牌,不把长期密钥写入镜像或日志。

如何判断 Runner 扩缩容真的改善了 CI?

同时观察排队时长、Runner 启动时间、任务执行时间、利用率、失败重试、缓存命中和每次构建成本,不能只看 Runner 数量。

微信登录更方便
  • 密码登录
  • 注册账号
登录即同意 用户协议 和 隐私政策
返回登录
  • 重置密码