ZEISS通过Ampere Altra和SpinKube展示可扩展工作流的威力

挑战

维护一个能够处理数万近乎同时请求、但90%时间处于空闲状态的系统，成本无法合理化。容器化承诺按需扩展工作负载，包括在需求低时缩减规模。维护多个集群中的许多Pod仅仅为了避免系统在扩展过程中浪费时间，这与工作负载容器化的初衷相矛盾。

解决方案

Fermyon推出名为SpinKube的平台，利用WebAssembly（WASM）——最初为在不受信任的Web浏览器环境中执行字节码小元素而创建——作为在Kubernetes服务器环境中大量执行小型工作负载的手段。

由于WASM工作负载更小、更易于维护，Pod可以在网络需求上升时即时启动，而不会在过程中消耗大量时间。而且，由于WASM由预编译的字节码组成，它可以在由Ampere® Altra®驱动的服务器平台上执行，无需其他CPU通常带来的所有多线程和微码开销——在诸如这些计算强度较低的情况下，这种开销本来就不必要。

实施

作为SpinKube有效性的演示，ZEISS集团的IT工程师与Ampere、Fermyon和Microsoft合作，创建了一个在即时场景中随需求上升启动新WASM Pod的系统。

演示证明，在实践中，运行在SpinKube上的客户订单处理系统，与运行传统Kubernetes Pod的对应系统相比，产生了显著的好处。据ZEISS集团杰出架构师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的庞大数量变得成本过高。

ZEISS实现突破

这正是ZEISS所处的情况。成立于1846年的ZEISS集团是科学光学和光电领域的全球领导者，业务遍布50多个国家。除了服务消费市场，ZEISS的部门还服务于工业质量和研究、医疗技术和半导体制造行业。

消费市场中客户的行为可能高度相关，导致偶尔出现大量订单波，中间有活动间歇。因此，ZEISS的全球订单处理系统在任何给定分钟可能收到少至零个客户订单，而下一分钟则超过10,000个近乎同时的订单。

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

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

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

ZEISS困境的解决方案可能来自一个在三年前会被认为不太可能（如果不是不可能）的来源：WebAssembly（WASM）。它设计用于在客户端Web浏览器上运行二进制、不受信任的字节码——最初是预编译的JavaScript。2024年初，开源开发人员为Kubernetes创建了一个名为Spin的框架。

该框架使事件驱动、无服务器微服务能够用Rust、TypeScript、Python或TinyGo编写，并部署在冷启动时间仅以毫秒计的低开销服务器环境中。

Fermyon和Microsoft是SpinKube平台的主要维护者。该平台包含Spin框架，以及containerd-shim-spin组件，使WASM工作负载能够通过runwasi库在Kubernetes中编排。使用这些组件，WASM字节码应用程序可以作为工件分发，而不是传统的Kubernetes容器镜像。

与容器不同，该工件不是与其所有依赖项打包在一起的自包含系统。它实际上只是编译成字节码的应用程序。在Spin应用程序应用到其指定集群后，Spin操作员为应用程序提供基础、伴随Pod、服务和底层依赖项，使应用程序能够作为容器运行。这样，Spin将WASM工件重新定义为原生Kubernetes资源。

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

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

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

无需迁移的迁移

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

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

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

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

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

附加资源

要深入讨论ZEISS与Ampere、Fermyon和Microsoft的合作，请参阅Ampere YouTube频道上的视频：How ZEISS Uses SpinKube and Ampere on Azure to Reduce Costs by 60%。

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

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