CNCF 实现 Arm64 与 x86 平台对等的技术突破

快照

挑战

为 Arm64 架构开发开源软件需要一个强大的 CI/CD 环境。然而，历史上 Arm64 和传统 x86 处理器架构的支持水平存在差距，Arm64 通常处于劣势。为多架构开发基础设施组件的开发者对其工作环境有以下期望：

一致性：跨平台使用的工具和方法保持一致，避免因采用不太流行的平台而不得不采用不同的开发流程
性能：平台和支持机制的性能，确保在选择支持多平台时部署方案不会因速度不足而受影响
测试覆盖率：相同的效率、合规性和安全性测试同时适用于所有平台，且没有显著差异
可维护性：使开发者能够自动化其集成和重新开发流程，以便无需修改即可应用于所有平台

这些组件的产品经理也有相同的要求，另外至少还有两个：

平台覆盖能力：技术客户经理（TAM）具备响应客户需求所需的技能和准备
支持分层能力：使 TAM 和其他 IT 人员能够根据其响应紧急或新兴客户问题的能力对软件支持水平进行分类

解决方案

开源开发者 Alex Ellis 与 Ampere 和基础设施提供商 Equinix 合作，将其 Actuated CI/CD 平台提供给云原生软件生态系统中一些最关键的开源项目。Actuated 将安全工程师证明 inherently vulnerable to malicious attack 的 GitHub 自托管自动化流程，在从公共互联网抽象的微虚拟机中运行。

实施

几个关键的云原生计算基金会（CNCF）项目利用 Actuated 环境运行其所有的 GitHub Actions for Arm64。该环境基于 Ampere® Altra® 处理器，由基础设施提供商 Equinix 提供支持。这一倡议的成功促使 GitHub 实现对 GitHub Actions 的 Arm64 架构全面支持。现在，曾在 x86 架构上的 QEMU 仿真环境中运行 Arm64 构建流程的开发者可以将这些流程迁移到裸机 Arm64 上。

Arm64 上的 GitHub Actions 自托管运行器

GitHub 如今主导着软件项目的托管。GitHub 托管项目为持续集成生成构建和发布的最流行方式是使用平台内置的 CI 工具集 GitHub Actions。GitHub Actions CI/CD 平台最重要的作用是自动化软件开发流水线。

触发任何 GitHub Action 的责任方是运行器。它是一个在服务器上运行的代理，等待任务并在分配任务后 eager to do it。它从工作流中获取作业并负责完成它。

GitHub 是一个完整的软件部署平台。因此，它托管自己的运行器，每个运行器都适应其指定的目标环境和架构。直到最近，GitHub 还没有提供 Arm64 的托管运行器环境。想要生成 Arm64 原生构建的项目确实有一个选项——自托管运行器。

GitHub 用户可以在其他地方托管的物理机或虚拟机上安装代理，并让 GitHub Actions 将作业分派到该主机，由项目用户管理。这要求项目管理员不仅管理项目本身，还要负责项目将使用的构建环境的维护和安全。

在 CNCF 的情况下，开发者利用 Equinix Metal 的积分，使他们能够配置裸机实例，并将其用作项目的自托管运行器。但对于一个必须 24/7/365 向全球其他开发者提供项目的代码实验室来说，自托管运行器的安全性构成了挑战：根据 GitHub 文档，任何人都可以克隆项目仓库，修改 Actions 作业，并访问运行器节点以运行任意作业。

另一个问题是确保 CI 运行之间的一致性。对于自托管运行器，如果 CI 作业有副作用，例如配置更改或事后留下的文件，它们仍会存在于后续作业中。这带来了一个问题——当运行 CI 作业来构建或测试软件时，你应该有一个受控的环境，以便运行之间唯一变化的是软件。对于自托管运行器，环境可能会随时间漂移。在没有清理过程的情况下，同一主机上同一构建作业的运行可能会随时间产生不同的结果。

开发者绕过对 Arm64 原生运行器需求的一种方式是在 x86 服务器上使用 QEMU 开源仿真运行虚拟 Arm64 环境。仿真环境为软件编译增加了巨大的性能开销，其运行速度仅为原生非仿真硬件上编译速度的一小部分。

仿真对于开发中小型项目足够好。但如果开发者必须为 ARM64 构建大型重要项目，虚拟环境上的压力会变得如此之大，以至于构建完全失败。

“过去，人们使用 QEMU 进行构建。假设你正在构建一个编译器，其中间步骤需要大量内存并与处理器深度集成。这在仿真环境中根本无法工作。”
Ed Vielmetti，Equinix 开发者合作伙伴经理

差距现象

与典型企业不同，云原生计算基金会有特殊义务为其所有世界主要处理器架构构建云原生组件。诸如 containerd 便携式容器运行时、etcd 键/值数据存储、fluentd 日志数据收集器、Falco 实时威胁检测工具和 OpenTelemetry 可观测性和工具包等数十个项目是云原生生态系统的关键依赖项，因此必须为 x86 和 Arm64 构建。

为了构建支持 Arm64 的低级基础设施组件，CNCF 开发者需要访问原生 Arm64 基础设施。这 ironically 意味着他们需要他们试图创建的同类工具。

最初，Ampere 和 Equinix 与 CNCF 合作克服这些差距，通过捐赠基于 Ampere Altra 的服务器或在 Equinix 设施中设置基于 Altra 的裸机节点。Equinix 可以共享的基于 Arm64 的服务器资源的粒度是裸机节点——160 核双插槽 Ampere Altra 系统。理想情况下，这样的服务器将在多个项目之间共享，但这在当时超出了 CNCF 的能力。这是 Ampere 和 Actuated 提议为 CNCF 解决的问题，通过允许更多项目在更少的主机上运行，从而为更多项目提供轻松访问构建服务，同时消耗更少的硬件。

“OpenTelemetry 是一个全时运行的 CI/CD 系统。我们能够利用 [我们的 Ampere 服务器] 基础设施为我们自己服务，但我们无法与广大开源社区共享。我们不能赠送 GitHub 运行器。一旦我们对下游分发给客户的认证感到满意，我们就向 OpenTelemetry 项目提出了问题，表示我们希望看到 ARM64 支持在最高级别交付——意味着它应该为每次提交运行，为 main 运行，始终运行。反馈是，很好，但 GitHub 中没有 ARM64 运行器。所以我们需要你与我们在这里能做的事情合作。”
Antoine Toulmé，Splunk 区块链和 DLT 高级工程经理，OpenTelemetry 项目维护者

由于这些项目缺乏易于使用的 Arm64 平台，开发者不知道他们提交的更改是否在 Arm64 上引起问题，因为测试套件没有像 x86 那样频繁运行。由于容器编排平台是正在开发以支持 Arm64 的平台之一，这种现象变成了一个恶性循环：发布取决于通过 x86 的集成测试套件，但发布不取决于相同的测试套件在 Arm64 上通过。

CNCF 开发者发现的解决方案远非激进或革命性——实际上，它更像是一个错误修复。实施如此简单，以至于它不仅为 CNCF 而且为任何架构的任何平台级组件的开发者完全补偿了这种差距。

突破：Actuated，加上编辑一行代码

为了在 x86 和 Arm64 之间实现平台对等的第一步，Ampere 寻求了 Alex Ellis 的帮助，他是一项名为 Actuated 的服务的创建者。这是一个在安全隔离的微虚拟机中运行 GitHub Actions 作业的产品，配置为从 GitHub Actions 接收构建作业，并为开发者提供其构建作业性能和共享构建系统负载的可见性。

Actuated 可以在修改其配置文件中的单行代码后运行所有 CNCF 现有的 GitHub Actions 运行器，加上在某些情况下粘贴一些代码片段——这些更改实施时间不到五分钟。这些更改使 GitHub 托管的项目能够将其构建作业指向在 Ampere Altra 处理器上的 Actuated 微虚拟机驱动环境。

“Falco 确实需要 Arm64 GitHub 运行器来提升其对架构的支持并扩大其用户群。[Actuated] 对我们来说是完美的解决方案，因为它易于利用并减轻了维护者的任何负担。这样，我们作为维护者可以专注于对项目真正重要的事情，而不是与维护和部署自托管基础设施作斗争。现在我们正在为 ARM64 构建、测试和发布工件，利用 Actuated 处理许多项目，并且它运行完美。”
Federico Di Pierro，Sysdig 高级开源工程师，Falco 项目维护者

看到近年来对 Arm 原生构建环境需求的增加，GitHub 于去年 6 月宣布在公共测试版中提供基于 Arm64 的 GitHub Actions 托管运行器，由 Microsoft Azure 上的 Ampere 计算实例提供支持，随后于 2025 年 1 月发布用于公共仓库的免费托管运行器的公共预览版。

对于 OpenTelemetry 来说，这意味着网络负载高达其分配带宽上限 10 倍的日子结束了，因为 OpenTelemetry 构建不断从 Docker Hub 仓库下载依赖项。

“是的，我们确实在破坏东西。我们很幸运，因为 GitHub 的 Arm 运行器发布了。我们已经迁移到 ARM 运行器，我们非常高兴，再也没有东西坏了。”
Antoine Toulmé，Splunk 区块链和 DLT 高级工程经理，OpenTelemetry 项目维护者

现在，项目维护者首次可以像关注 x86 构建的安全性和安全性一样密切关注 Arm64 构建的安全性和安全性，知道他们不再可能遇到性能下降或惩罚。

“[Actuated] 使我们对 ARM64 上的 CI 构建充满信心。如果 Arm CI 现在中断，我们绝不会合并那个 [拉取请求]，直到我们找出原因……我们现在完全有信心 [构建失败] 不是硬件不稳定问题 [像以前有时那样]。”
Phil Estes，AWS 首席软件工程师，containerd 项目维护者

就 Oracle 而言，它继续其政策，每年向 CNCF 项目捐赠 300 万美元的 OCI 积分，用于由 Ampere 提供支持的 Arm64 实例。这种慷慨，加上由 Ampere 和 Equinix 催化并由 Actuated 带来的 Arm64 平台的新发现稳定性，使包括 Red Hat、SUSE、Canonical 和 Mirantis 在内的知名云基础设施供应商能够为其选择 ARM64 基础设施的企业客户提供全面支持。

对等使企业能够就其计算基础设施和平台做出明智选择，而不会因选择替代架构而受到惩罚。大型云客户正在证明 Arm64 可以为组织提供所需的性能，并降低工作负载的费用——所有这些都具有行业领先的能源效率。但组织只有在能够在一个公平的竞争环境中将所有工作负载部署到所有基础设施选项上，并自己衡量结果时，才能体验这些好处。

公平竞争环境

2023 年初，对于希望将 Arm64 完全集成到其持续集成流程中的 GitHub 托管项目来说，选择很少。通过这一倡议，利用 Actuated 的创新软件解决方案与 Equinix 托管的 Ampere CPU，降低了 CNCF 项目开始实现对 ARM64 和 x86 支持对等的门槛。

包括 etcd、containerd、Open Telemetry、Falco 等在内的关键云原生项目能够推进其对 ARM64 的支持，加速其在原生 Arm64 基础设施上的 CI 运行，并支持越来越多用户利用云中的 Arm64 计算。

到这个试点项目结束时，开发者的选择数量大大增加。CNCF 现在为其项目提供了在 OCI 上的托管 Kubernetes 集群上运行 GitHub Actions 作业的能力，使用 Ampere 驱动的实例和 GitHub 项目 Actions Runner Controller，并且随着 GitHub 添加托管 Arm64 运行器，项目轻松支持这种快速增长的令人兴奋的云原生应用架构从未如此容易。