CircleCI发布机器运行器编排器1.0.0

CircleCI正式发布Machine Runner Orchestrator 1.0.0，可依据持续集成任务的实际需求，自动扩展或释放自托管机器运行器虚拟机。该版本由此前的Runner Provisioner预览版演进而来，通过一次部署即可处理CPU、GPU和ARM工作负载，并支持运行在GKE、AKS、EKS以及KubeVirt集群中的环境。

这项功能主要面向自托管CI基础设施的弹性需求。编排器会持续观察CircleCI任务量，在构建和测试需求突然增加时及时配置运行器，任务减少后再释放资源，帮助企业避免为峰值负载长期预留机器，同时继续掌控底层计算环境。该能力已包含在自托管运行器的全部套餐中，不收取额外费用。

与早期版本主要负责机器运行器配置不同，1.0.0能够在同一套部署中管理多种资源类型。传统CPU构建、GPU密集型任务和ARM构建可以并行存在，无需针对每类工作负载分别安装编排器。其控制平面支持三大托管Kubernetes服务和KubeVirt，但实际执行CI任务的运行器仍以物理机为基础。

该产品与Karpenter、Cluster Autoscaler等Kubernetes节点自动扩缩容工具处于不同层级。后者主要根据无法调度的Pod调整集群容量，而Machine Runner Orchestrator直接管理注册为CircleCI运行器的机器。两者可以协同使用：Kubernetes负责承载编排组件，CircleCI则依据任务需求扩展执行CI工作的机器资源。GitHub Actions Runner Controller同样能够按工作流增减运行器，但其重点是创建和删除由Kubernetes管理的临时运行器；CircleCI方案则针对机器运行器虚拟机，更适合需要虚拟机级隔离或特殊运行能力的任务。

从预览版迁移到1.0.0并非原地升级。产品已从runner-provisioner更名为machine-runner-orchestrator，并同步调整Helm图表、容器镜像仓库和Packagecloud仓库。现有用户需要先卸载旧部署，再安装新版；操作期间，与已配置资源类型相关的运行器会暂时离线，生产环境迁移需提前安排中断窗口。

此外，1.0.0修复了Go gRPC实现中的两个高危漏洞：CVE-2026-84304可能利用HTTP/2帧碎片化耗尽堆内存，CVE-2026-84445则可能在请求缺少":authority"或Host头时导致程序崩溃。此次发布进一步强化了将多类型CI资源与Kubernetes控制平面结合的架构，使CI执行能力成为可独立弹性扩展的基础设施层。