ZEISS展示Ampere Altra与SpinKube在可扩展工作流中的强大能力
挑战
维护一个能够处理数万近乎并发请求的系统成本高昂，而该系统90%以上的时间处于闲置状态。容器化承诺了按需扩展工作负载的能力，包括在需求低时缩减规模。但维护多个集群中的众多pod以避免扩容过程耗时，这与工作负载容器化的初衷相矛盾。
解决方案
Fermyon开发的SpinKube平台利用WebAssembly(WASM)技术，在Kubernetes服务器环境中执行大量小型工作负载。WASM工作负载更小且更易于维护，pod可以在网络需求上升时即时启动，而不会消耗大量时间。由于WASM是预编译的字节码，它可以在Ampere® Altra®服务器平台上执行，无需其他CPU通常带来的多线程和微码开销。
实施
作为SpinKube有效性的演示，ZEISS集团的IT工程师与Ampere、Fermyon和微软合作，构建了一个在即时场景中随需求上升而启动新WASM pod的系统。演示证明，在实际应用中，运行在SpinKube上的客户订单处理系统相比传统Kubernetes pod带来了显著优势。
ZEISS集团杰出架构师Kai Walter表示：“当我们查看Node.js的重运行时工作负载时，使用Ampere处理器VM环境可以在相同时间内处理相同数量的订单，比x86 VM实例便宜60%。”
背景：过度配置难题
过度配置至今仍是基础设施资源管理中最常见的做法之一。在Linux容器和工作负载编排出现之前，IT经理被告知过度配置虚拟机是确保峰值需求时资源可用的正确方法。Kubernetes曾承诺通过使工作负载更细粒度、更灵活和更易于扩展来完全消除过度配置的需求。但平台工程师很快发现，使用Kubernetes的自动扩展插件在需要时创建新pod会消耗宝贵的分钟级时间。
ZEISS取得突破
ZEISS发现自己在处理消费者市场中高度相关的客户行为，导致偶尔出现大量订单波峰，中间则是平静期。过度配置对ZEISS不切实际，因为订单处理系统的逻辑远比生成式AI研究项目平凡得多，而且只是偶尔需要。
ZEISS对其数字基础设施的要求是：
- 配置更低的worker集群，消耗更少能源同时降低运营成本
- 行为管理能力，允许根据快速变化的网络条件自动和手动更改云环境
- 分阶段计划迁移，使早期订单处理系统能够按预定时间表逐步退役
解决方案来自三年前被认为不太可能的WebAssembly(WASM)。2024年初，开源开发者创建了名为Spin的Kubernetes框架，使事件驱动的无服务器微服务可以用Rust、TypeScript、Python或TinyGo编写，并部署在冷启动时间仅以毫秒计的低开销服务器环境中。
Fermyon和微软是SpinKube平台的主要维护者。该平台包含Spin框架和containerd-shim-spin组件，使WASM工作负载能够通过runwasi库在Kubernetes中进行编排。
在演示中，ZEISS开发了三个WASM Spin应用：一个分发器和两个接收器。分发器应用从入口队列接收订单消息，然后两个接收器应用处理订单，第一个处理耗时较少的简单订单，第二个处理更复杂的订单。
在实践中，基于SpinKube的演示系统通过在Azure上的Ampere-powered Dpds v5实例上运行Rust和TypeScript示例应用，可以以约低60%的成本处理10,000个订单的测试数据集。
无需迁移的重新部署
ZEISS与微软和Fermyon合作开发了迭代迁移方案，使其能够在用于现有传统Kubernetes系统的相同Ampere arm64节点池中部署Spin应用。新的Spin应用将与旧应用并行运行，无需首先创建新的独立网络路径。
WASM应用更保守地使用内存、计算能力和系统资源。因此，整个订单处理系统可以在Azure中最小的、最便宜的实例类上运行：Standard DS2(x86)和D2pds v5(Ampere Altra 64位)，每个实例只有2个vCPU。然而，ZEISS在这个试点项目中发现，通过转向在SpinKube上运行的WASM应用，它可以透明地将底层架构从x86实例更改为基于Ampere的D2pds实例，成本降低约60%。
SpinKube和Ampere Altra使像ZEISS这样的全球组织能够在成本大幅降低的云计算平台上部署具有高可扩展性要求的商品工作负载，在不影响性能的情况下可能将成本削减一半以上。