利用 Ampere Altra 与 SpinKube 实现可扩展工作流的突破性实践

挑战

维护一个能够处理数万近乎并发请求、但 90%时间处于空闲状态的系统成本难以合理化。容器化技术承诺按需扩展工作负载（包括在需求低迷时缩减规模），但为了避免系统在扩容过程中浪费时间而维护多集群中的大量 Pod，这与工作负载容器化的初衷相悖。

解决方案

Fermyon 推出的 SpinKube 平台利用 WebAssembly（WASM）技术——最初为在不可信的 Web 浏览器环境中执行字节码片段而设计——实现在 Kubernetes 服务器环境中大规模执行小型工作负载。由于 WASM 工作负载更小、更易维护，Pod 可在网络需求上升时即时启动，而无需消耗大量时间。且 WASM 由预编译字节码构成，可在 Ampere® Altra®驱动的服务器平台上执行，无需其他 CPU 通常带来的多线程和微码开销——在诸如此类计算强度较低的场景中，这些开销本就多余。

实施

为展示 SpinKube 的有效性，蔡司集团的 IT 工程师与 Ampere、Fermyon 和微软合作，构建了一个在即时场景中随需求上升而启动新 WASM Pod 的系统。实践表明，运行在 SpinKube 上的客户订单处理系统相较于传统 Kubernetes Pod 系统具有显著优势。蔡司集团杰出架构师 Kai Walter 表示：

“当我们处理 Node.js 的高运行时工作负载时，在相同时间内处理相同订单量，Ampere 处理器 VM 环境的成本比 x86 VM 实例低 60%。”

背景：过度配置困境

过度配置仍是当今基础设施资源管理中最常见的做法之一。在 Linux 容器和工作负载编排出现之前，IT 经理被告知过度配置虚拟机是确保峰值需求时资源可用的正确方式。资源过度订阅甚至曾被作为 VM 管理员的“最佳实践”教授，旨在帮助管理员在限制计算、内存和存储过度消耗风险的同时维持性能与可用性 KPI。

Kubernetes 曾承诺通过使工作负载更细化、更灵活、更易扩展来完全消除过度配置需求。但平台工程师很快发现，使用 Kubernetes 自动缩放器插件在需要时创建新 Pod 会消耗数分钟宝贵时间。从最终用户角度看，数分钟犹如数小时。

当前 Kubernetes 有一种称为“暂停 Pod”的常见配置实践：唤醒休眠 Pod 比动态创建新 Pod 更快。该实践指示集群自动缩放器提前启动工作 Pod，这些 Pod 最初被分配到其他 Pod 活跃的工作节点上。虽然与活跃 Pod 一同维护，但它们优先级较低。当需求增加需要扩展工作负载时，暂停 Pod 的状态更改为“挂起”，触发自动缩放器将其重新定位到新工作节点，并将其优先级提升至其他活跃 Pod 水平。尽管启动暂停 Pod 与标准 Pod 耗时相同，但该时间被提前消耗，因此启动 Pod 的延迟被转移到不被注意的时间点。

Pod 暂停是使活跃工作负载启动更快的聪明方法，但当峰值需求水平比标称水平高几个数量级时，过度配置的暂停 Pod 数量变得成本高昂。

蔡司实现突破

蔡司集团（成立于 1846 年）是全球科学光学和光电子学领导者，业务遍及 50 多个国家。除消费市场外，其部门还服务工业质量与研究、医疗技术和半导体制造行业。消费市场客户行为高度相关，导致偶尔出现大量订单波峰，中间伴随活动间歇。因此，蔡司全球订单处理系统可能在任何给定分钟收到零客户订单，而下一分钟收到超过 10,000 个近乎并发的订单。

过度配置对蔡司不实用。订单处理系统的逻辑远比生成式 AI 研究项目平凡，且仅偶尔需要。在此类情况下，过度配置涉及分配大量 Pod 集群，所有这些都消耗宝贵资源，而其存在 90%以上时间基本空闲。蔡司对其数字基础设施的要求是：

• 工作集群配置更低，能耗大幅减少，同时降低运营成本

• 行为管理能力，允许自动和手动更改云环境以响应快速变化的网络条件

• 分阶段迭代迁移，使旧订单处理系统按预定计划逐步退役而非一次性更换

“整个行业目前都在讨论心理负荷。我部分工作是确保团队不过载。我们不搞大规模跳跃式实施，希望团队获益而无需重新培训。我们要适应、迭代、改进。”

——Kai Walter, 蔡司集团杰出架构师

蔡司困境的解决方案可能来自三年前被认为不太可能（若非不可能）的来源：WebAssembly（WASM）。它设计用于在客户端 Web 浏览器中运行二进制、不可信的字节码——最初是预编译 JavaScript。2024 年初，开源开发者创建了名为 Spin 的 Kubernetes 框架，该框架支持使用 Rust、TypeScript、Python 或 TinyGo 编写事件驱动、无服务器微服务，并部署在冷启动时间仅需毫秒的低开销服务器环境中。

Fermyon 和微软是 SpinKube 平台的主要维护者。该平台整合了 Spin 框架和 containerd-shim-spin 组件，通过 runwasi 库实现 WASM 工作负载在 Kubernetes 中的编排。使用这些组件，WASM 字节码应用可作为工件分发，而非传统 Kubernetes 容器镜像。与容器不同，该工件并非包含所有依赖项的自包含系统，而仅是编译成字节码的应用程序。Spin 应用应用到指定集群后，Spin 操作员为应用配置基础、伴随 Pod、服务和底层依赖项，使其作为容器运行。这样，Spin 将 WASM 工件重新定义为原生 Kubernetes 资源。

运行后，Spin 应用行为类似无服务器微服务——意味着无需通过网络地址访问即可服务核心功能。但 Spin 实现此功能无需向 WASM 工件添加额外开销（例如监听事件信号），shim 组件负责监听角色。Spin 使 WASM 应用适应 Kubernetes Pod 内运行，因此编排过程完全无需改变。

在演示中，蔡司开发了三个 WASM Spin 应用：一个分发器和两个接收器。分发器应用从入口队列接收订单消息，两个接收器应用处理订单，第一个处理耗时较短的简单订单，第二个处理更复杂订单。Kubernetes 的 Fermyon 平台使用 Spin 框架管理 WASM 工件部署，系统极其简单。

实践中，基于 SpinKube 的演示系统通过更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）公众号二维码

办公AI智能小助手