挑战

维护一个能够处理数万近乎同时请求、但90%以上时间处于空闲状态的系统，其成本难以合理化。容器化承诺了按需扩展工作负载的能力，包括在需求低时缩减规模。但为了不让系统在扩容过程中浪费时间而维护多个集群中的众多Pod，恰恰违背了工作负载容器化的初衷。

解决方案

Fermyon推出了名为SpinKube的平台，该平台利用WebAssembly（WASM）——最初为在不可信的Web浏览器环境中执行字节码小元素而创建——作为在Kubernetes服务器环境中大量执行小型工作负载的手段。由于WASM工作负载更小、更易于维护，Pod可以在网络需求上升时即时启动，而不会在此过程中消耗大量时间。而且，由于WASM由预编译的字节码组成，它可以在由Ampere® Altra®驱动的服务器平台上执行，无需其他CPU通常带来的多线程和微码开销——在诸如这些计算强度较低的情况下，这种开销本来就是不必要的。

实施

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

“当我们查看使用Node.js的运行密集型工作负载时，我们可以在相同时间内处理相同数量的订单，使用Ampere处理器VM环境的成本比替代的x86 VM实例低60%。”

背景：过度配置的难题

过度配置仍然是当今基础设施资源管理中最常见的做法之一。在Linux容器和工作负载编排出现之前，IT经理被告知过度配置虚拟机是确保在需求高峰时资源可用的正确方法。事实上，资源过度订阅曾经被教导为虚拟机管理员的“最佳实践”。当时的意图是帮助管理员维护性能和可用性的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%以上的时间基本上处于空闲状态。蔡司对其数字基础设施的要求是：

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

“整个行业目前都在讨论心理负荷。我工作的一部分……是确保我们不会让团队超负荷。我们在实施东西时不会做大跳跃。我们希望团队获得好处，但无需重新培训。我们希望适应、迭代——逐步改进。”

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

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

一旦运行，Spin应用程序的行为就像无服务器微服务——意味着它不必通过网络地址来服务其核心功能。然而，Spin实现这一点无需向WASM工件添加额外开销——例如，使其监听事件信号。shim组件负责监听角色。Spin使WASM应用程序适应在Kubernetes Pod中运行，因此编排过程完全不需要改变。

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

在实践中，据蔡司集团杰出架构师Kai Walter表示，基于SpinKube的演示系统可以通过在Azure上运行Ampere驱动的Dpds v5实例，以降低约60%的成本处理10,000个订单的测试数据集，适用于Rust和TypeScript示例应用程序。

无需迁移的迁移

与微软和Fermyon合作，蔡司开发了一种迭代迁移方案，使其能够在蔡司已用于现有传统Kubernetes系统的相同Ampere arm64节点池中部署其Spin应用程序。新的Spin应用程序随后可以与旧应用程序并行运行，而无需首先创建新的独立网络路径，然后设计某种方法在这些路径之间A/B分割入口流量。

“我们不会创建新环境。这对微软和Fermyon团队来说是一个挑战。我们期望重用现有的Kubernetes集群，并在我们认为合适的时候，我们将与旧路径并行实施这条新路径。SpinKube提供的原语允许这种共存。然后我们可以重用Arm节点池来运行以前不允许在Arm芯片上运行的逻辑。”

WASM应用程序更保守地使用内存、计算能力和系统资源。（请记住，WASM是为Web浏览器创建的，Web浏览器的环境最小。）因此，整个订单处理系统可以在Azure中两个最小、最便宜的实例类上运行：Standard DS2（x86）和D2pds v5（Ampere Altra 64位），每个实例只有2个vCPU。

然而，蔡司在这个试点项目中发现，通过转向运行在SpinKube上的WASM应用程序，它可以透明地将底层架构从x86实例更改为基于Ampere的D2pds实例，将成本降低约60%。

SpinKube和Ampere Altra使像蔡司这样的全球组织能够在成本大幅降低的云计算平台上部署具有高可扩展性要求的商品工作负载， potentially在不影响性能的情况下将成本削减一半以上。

附加资源

有关蔡司与Ampere、Fermyon和微软合作的深入讨论，请参阅Ampere YouTube频道上的视频：蔡司如何使用SpinKube和Ampere在Azure上降低成本60%。

要查找有关在Ampere CPU上优化代码的更多信息，请查看Ampere开发者中心的调优指南。您还可以通过注册Ampere的每月开发者通讯获取更新和更多有见地内容的链接。

如果您对此案例研究有疑问或评论，请加入Ampere开发者社区，您会在那里找到所有计算领域的专家准备回答它们。此外，请务必订阅Ampere Computing的YouTube频道以获取更多以开发者为中心的内容。