利用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%以上时间基本空闲。蔡司对其数字基础设施的要求是：

• 工作集群配置更低，能耗大幅减少，同时降低运营成本
• 行为管理能力，允许自动和手动更改云环境以响应快速变化的网络条件
• 分阶段迭代迁移，使旧订单处理系统按预定计划逐步退役而非一次性更换

“整个行业目前都在讨论心理负荷。我部分工作是确保团队不过载。我们不搞大规模跳跃式实施，希望团队获益而无需重新培训。我们要适应、迭代、改进。”undefined——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的演示系统通过