CircleCI Makes Machine Runner Orchestrator Generally Available

CircleCI 发布 Machine Runner Orchestrator 一般可用版本 - InfoQ

InfoQ 首页 News CircleCI 发布 Machine Runner Orchestrator 一般可用版本

DevOps

从 Token 到功能：为 AI 辅助工程构建成本归属架构（10月29日网络研讨会）

CircleCI 发布 Machine Runner Orchestrator 一般可用版本

2026年10月9日 3分钟阅读

作者：

• Craig Risi

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

CircleCI 已正式发布 Machine Runner Orchestrator 1.0.0 版本，该功能可根据 CI 工作负载需求自动扩展自托管机器运行器虚拟机。此次发布在早期 Runner Provisioner 预览版本基础上进行了扩展，支持从单一部署中处理 CPU、GPU 和 ARM 工作负载，同时支持在 GKE、AKS 和 EKS 上运行的 Kubernetes 环境，以及基于 KubeVirt 的集群。

此次发布旨在解决自托管 CI 基础设施的常见挑战：在不为峰值需求永久分配机器的情况下，为构建和测试活动的突发流量保留足够的运行器容量。编排器会监控 CircleCI 的工作负载需求，并根据需求相应地分配和移除机器运行器，使组织能够在保留底层计算环境控制权的同时，实现运行器容量的动态调整。CircleCI 表示，该功能在其所有计划中均包含在自托管运行器中，无需额外成本。

早期版本主要专注于机器运行器的分配，但新编排器可以从单一部署中管理多种资源类别。这在 CI 工作负载不再同质化的环境中尤为重要：传统的 CPU 构建可以与 GPU 密集型工作负载和基于 ARM 的构建共存，而无需为每种类别分别部署编排系统。

底层架构也反映了 Kubernetes 作为 CI 基础设施控制平面的日益普及。与需要特定 Kubernetes 发行版不同，Machine Runner Orchestrator 现在支持三大主流托管 Kubernetes 平台——Google Kubernetes Engine、Azure Kubernetes Service 和 Amazon Elastic Kubernetes Service，以及 KubeVirt 环境。这使平台团队在选择编排层运行位置时拥有更多灵活性，而实际的 CI 运行器仍保持基于机器的架构。

Machine Runner Orchestrator 与 Kubernetes 节点自动扩展器（如 Karpenter 和 Cluster Autoscaler）处于不同层次。Kubernetes 节点自动扩展主要响应无法调度的 Pod，并调整底层集群容量。例如，Karpenter 会根据待处理的工作负载分配节点，还可以合并或以其他方式管理节点生命周期。

CircleCI 的编排器则在 CI 运行器层级运行。其目标是确保注册为 CircleCI 运行器的机器能够根据 CI 作业的需求进行扩展。在基于 Kubernetes 的架构中，这两种方法可以协同工作：Kubernetes 管理托管编排组件的基础设施，而 CircleCI 管理可用于执行 CI 工作负载的机器容量。

CircleCI 并非唯一一个将自托管 CI 执行转向 Kubernetes 原生自动扩展的平台。GitHub 的 Actions Runner Controller（ARC）提供了一个 Kubernetes 操作符，用于编排和扩展自托管的 GitHub Actions 运行器。其运行器规模设置可根据工作流需求自动增加或减少运行器容量，在处理任务时动态创建和删除临时运行器。

主要差异体现在执行模型上。GitHub ARC 主要通过 Kubernetes 管理的工作负载创建临时运行器环境，而 CircleCI 的 Machine Runner Orchestrator 则专注于机器运行器虚拟机。这使得 CircleCI 的方法特别适用于需要 VM 级别隔离或在标准运行器容器中难以复现的功能的 CI 工作负载，同时仍使用 Kubernetes 作为编排控制平面。

从预览版过渡到 1.0 版本对现有用户并非完全透明。CircleCI 已正式将该产品从 runner-provisioner 重命名为 machine-runner-orchestrator，更改了相关的 Helm 图表、容器镜像仓库和 Packagecloud 仓库。现有安装无法直接就地升级：CircleCI 指导用户卸载旧部署并安装新版本 1.0.0 包。

这会在迁移期间造成短暂的运营中断。CircleCI 警告称，在卸载旧部署和安装新部署之间，与配置的资源类关联的运行器将处于离线状态。因此，组织在升级生产 CI 基础设施时需要考虑这一点，而非将其视为常规的就地软件更新。

1.0.0 版本还修复了 Go gRPC 实现中的两个高严重性漏洞。修复内容涵盖 CVE-2026-84304（通过 HTTP/2 帧碎片化导致堆内存耗尽）和 CVE-2026-84445（当请求缺少 :authority 或 Host 头时可能导致崩溃）。

1.0 版本的发布使 CircleCI 进一步向结合多种资源类、基于 Kubernetes 的编排以及对主流托管 Kubernetes 平台支持的模式靠拢。对于平台工程团队而言，这一转变不仅仅是另一个运行器功能，而是 CI 执行能力作为独立可扩展的基础设施层的出现；这一层能够像现代平台已实现的应用工作负载扩展一样，响应软件交付需求。

作者信息部分主容器

关于作者

部分标题

每个作者信息的主容器

#### Craig Risi

显示更多

显示更少

#### 本内容属于 DevOps 主题

##### 相关主题：

• DevOps

• Kubernetes Operator

• 云

• 持续交付

• 持续集成

• Kubernetes

• 编排

• 相关编辑

• 相关赞助商《实用代理编码实践手册》

• 相关赞助商 大规模自动化代码转换。修复漏洞、迁移框架、现代化所有仓库中的遗留代码。免费试用 Moderne

InfoQ 新闻letter

每周五发送 InfoQ 最新内容摘要。加入超过 250,000 名高级开发者的社区。查看示例

我们保护您的隐私。