GitHub Actions 自动扩容需依赖自托管运行器，主流方案包括：① AWS 无服务器扩缩容（Lambda+EC2/Spot）；② Kubernetes 的 Actions Runner Controller（ARC）；③ Docker Compose 轻量级临时运行器；均须启用 ephemeral 模式、标签匹配、健康检查与最小权限。
GitHub Actions 本身不直接提供构建环境的“自动扩容”能力，它依赖自托管运行器（Self-hosted Runners）来扩展执行资源。官方托管运行器（如 ubuntu-latest）由 GitHub 统一管理，无法按需伸缩；真正的自动扩容必须通过自托管 + 自动扩缩容控制平面实现。核心思路是：当 GitHub Jobs 队列出现待处理任务时，动态启动新运行器实例；任务完成后，及时释放闲置资源。
自托管运行器自动扩容的三种主流方式
-
基于 AWS 的无服务器扩缩容（推荐用于云原生团队）
使用terraform-aws-github-runner模块部署：- 控制平面由 Lambda 构成，监听 GitHub Webhook 或轮询 Jobs API
-
scale-up模块根据队列长度触发 EC2 或 Spot 实例启动 -
scale-down模块在运行器空闲超时（如 5 分钟无任务）后自动终止实例 - 支持多架构（x64/ARM64/Windows），且每个架构可独立扩缩
-
基于 Kubernetes 的 Actions Runner Controller（ARC）
适用于已有 K8s 集群的团队：- 安装 ARC Helm Chart 后，创建
AutoScalingRunnerSet资源 - 侦听器 Pod 连接 GitHub Jobs API，收到
Job Available消息即触发扩容 - 底层通过
EphemeralRunnerCRD 动态创建 Pod 级运行器，任务结束自动销毁 - 所有运行器默认为临时模式（ephemeral），天然隔离、安全、轻量
- 安装 ARC Helm Chart 后，创建
-
基于 Docker Compose 的轻量级临时运行器
适合中小项目或测试环境：- 使用
docker-github-actions-runner项目，启用EPHEMERAL=true - 每个任务拉起一个独立容器，执行完自动注销并退出
- 通过
docker-compose scale或简单脚本监控队列数，调用docker-compose up -d --scale runner=N手动/半自动扩缩 - 可结合 cron 或外部调度器（如 Node.js HTTP server）实现简易弹性
- 使用
关键配置要点
标签（Labels）必须对齐
运行器注册时设置的标签（如linux,x64,prod）要与工作流中runs-on: [self-hosted, linux, x64]完全匹配，否则任务无法分发临时模式需显式启用
无论是 AWS、K8s 还是 Docker 方案，都需确保运行器以ephemeral模式注册（即每次任务新建、任务结束自动注销），这是实现“扩容即用、用完即毁”的前提-
健康检查与失败重试不可省略
控制平面应具备：- 运行器启动后验证注册状态
- 任务分配失败时触发重试（最多 5 次）
- 24 小时未被领取的任务由 GitHub 自动取消，避免僵尸等待
权限与凭证最小化
运行器 Token 有效期短、作用域窄；AWS IAM 角色或 K8s ServiceAccount 权限仅限必要操作（如启动 EC2、创建 Pod），不赋予 root 或 admin 权限
不复杂但容易忽略
