摘要：微软在2025年1月底宣布，它将关闭其托管Azure Kubernetes服务中对WASI（WebAssembly系统接口）节点池的实验性支持。如果您一直在关注WASI在Kubernetes上的演变，这应该不会令人惊讶。关闭确实要求任何在AKS上使用服务器端W

微软将于5月淘汰自己的Kubernetes WebAssembly节点池功能，并推荐两种不同的选项。

微软在2025年1月底宣布，它将关闭其托管Azure Kubernetes服务中对WASI（WebAssembly系统接口）节点池的实验性支持。如果您一直在关注WASI在Kubernetes上的演变，这应该不会令人惊讶。关闭确实要求任何在AKS上使用服务器端WASI代码的人做一些工作，作为迁移到备用运行时的一部分。

需要注意的是，微软建议的两个选项并不意味着从WASI迁移。WebAssembly和Kubernetes是两种配合良好的技术。因此，几个不同的开源项目填补了空白，允许您为AKS平台添加新层，并确保您可以以最小的中断继续运行。

如果您在AKS中使用WASI节点池，则创建新节点池的最后一天是5月5日。您可以继续使用现有的WASI工作负载，但现在是时候考虑新开发和升级的替代方案了。你不应该等到微软自己的WASI AKS服务停止工作；你现在就可以开始计划你的过渡，官方支持两种替代方法。

从KRustlets到什么？

AKS WASI节点池的最大问题是它依赖于实验性的Krustlet项目，该项目使用Rust构建WebAssembly-ready Kubelets。不幸的是，尽管Krustlet是一个云原生计算基金会沙盒项目，但它不再被维护，因为团队成员已经转到了其他项目。由于没有维护者，随着Kubernetes和WebAssembly的不断发展，该项目将被抛在后面。

由于不再可能依赖关键依赖项，很明显，微软别无选择，只能改变其在AKS中对WebAssembly的方法。对微软来说，幸运的是，AKS提供了一种与Kubernetes合作的托管方式，它仍然通过标准API支持更广泛的Kubernetes生态系统。这允许它提供在其平台上运行WASI的替代方法。

使用SpinKube在AKS上运行WebAssembly函数

一个选项是使用另一个WASI-on-Kubernetes项目的运行时。SpinKube一直在为标准Kubernetes容器主机containerd开发一个垫片，它允许您使用runwasi托管WASI工作负载，而无需更改底层Kubernetes基础设施。Spin由WebAssembly专家Fermyon赞助，是包括Helm和Brigade作者在内的团队长期Kubernetes工具的一部分。

SpinKube是一个无服务器计算平台，它使用WASI工作负载并使用Kubernetes进行管理。它的containerd-shim-spin工具增加了runwasi支持，因此您的节点可以托管WASI代码，将其视为标准Kubernetes资源。节点托管WASI运行时，并进行了标记，以确保您的工作负载被适当安排，允许您同时运行WASI和标准容器，以及KEDA（Kubernetes事件驱动自动缩放）等用于事件驱动操作的工具。

其他Spin工具负责部署和管理垫片的生命周期，确保您始终运行最新版本，并且容器垫片作为应用程序部署的一部分进行部署。这允许您自动使用WASI工作负载，尽管这需要比原始的WASI节点池实现更多的管理，但它离必须通过命令行和kubectl执行所有操作还有用一步。

微软推荐SpinKube作为其工具的替代品，并提供了如何在AKS中使用它的说明。您无法将其与基于Windows的Kubernetes实例一起使用，因此请确保您有一个基于Linux的AKS集群来使用它。有用的是，您不需要从头开始，因为您可以将SpinKube部署到现有的AKS集群中。这种方法确保您可以迁移到基于SpinKube的WASI节点池，并继续使用微软自己的工具运行，直到您完成基础设施的更新。

在AKS上部署SpinKube

虽然它在技术上可以通过Azure Marketplace获得，但大多数使用SpinKube和AKS的说明都是基于您使用Kubernetes工具从平台自己的存储库安装它。这可能是一个更复杂的方法，但它更符合大多数Kubernetes运算符的安装方式，你更有可能获得社区支持。

创建AKS集群后，您将需要Azure CLI来部署SpinKube。这是您使用AKS凭据运行Kubernetes kubectl工具的地方。您的集群需要运行证书管理器，可以使用Helm进行部署。一旦到位，通过安装SpinKube的运行时类管理器及其相关运算符来跟进。这可以在其原始名称KWasm下在自己的存储库中找到。

您现在可以使用注释节点命令通过kubectl将containerd shim部署到您的集群中。这通知运行时类管理器部署垫片，标记已准备好使用的节点。您现在可以将SpinKube自定义资源定义和运行时类添加到集群中，使用kubectl从GitHub复制旋转组件并将其应用于您的集群。一旦这些到位，您将在添加SpinAppExecutor之前使用Helm部署spin-operator。

启动和运行是一组相对复杂的步骤，但是，您确实可以选择将整个部署过程包裹在Azure CLI脚本中。这将允许您实现流程自动化，并在应用程序实例和Azure区域之间重复。

一旦SpinKube节点到位，您可以将您的WASI应用程序带到新环境中。Spin旨在从符合OCI的注册表中加载WASI代码，因此您需要在Azure基础设施中设置一个。您还可以选择使用CI/CD集成注册表，就像GitHub软件包服务的一部分一样。如果您走这条路，您应该使用GitHub企业帐户来保持注册表的私密性。

使用此方法，您可以将代码编译为WASI，作为GitHub操作的一部分，使用相同的操作将其保存在存储库中。您的AKS应用程序将始终可以访问您的WASI模块的最新版本。像所有Kubernetes应用程序一样，您需要为您的代码定义YAML描述，并使用containerd shim作为代码的执行器。

在AKS上通过wasmCloud使用WASI微服务

作为SpinKube的替代品，您可以使用另一个CNCF项目wasmCloud。在这里，您需要一个Helm图表来同时安装各种wasmCloud组件。这需要Azure CLI和kubectl管理AKS，因为没有与Azure门户集成。与此同时，由于有完全不同的架构方法，您需要从头开始，重新架构您的集群和应用程序，以便与wasmCloud一起使用。

首先为wasmCloud创建一个Kubernetes命名空间，然后再使用Helm安装wasmCloud平台组件。一旦pod重新启动，请使用kubectl启动wasmCloud实例，然后部署构成应用程序的组件。WasmCloud有自己的命令行管理工具，您需要将流量转发到管理窗格才能使用它。

再次，您必须使用YAML来描述您的应用程序；但是，现在您正在使用wasmCloud自己的编排工具，因此您将使用其对应用程序组件的描述。完成后，您可以使用命令行工具来部署和运行应用程序。WasmCloud旨在支持构建和运行应用程序的组件模型，目的是在Cosmonic的支持下提供一种描述和调用WASI组件的标准方式。

哲学上的差异

微软的WASI节点池有两个替代方案，很明显，AKS上的WebAssembly仍然有未来。但为什么使用和运行WASI有两种截然不同的方式呢？

wasmCloud和SpinKube的基本理念非常不同；wasmCloud旨在托管基于WASI的全尺寸应用程序，组装和编排微服务组件，而SpinKube则非常注重快速启动基于WASI的功能，在极少的时间内从零扩展，作为AWS Lambdas或Azure Functions等服务的替代品。在AKS中支持两者是有意义的，因此您可以根据自己的需求选择合适的WASI平台。

我们仍在探索WebAssembly能为我们做什么，所以很好，我们没有被锁定在AKS中使用它的唯一一种方式。拥有许多不同的选项在很大程度上是Kubernetes的做事方式，因为它是构建和管理分布式应用程序的一种方式。像我们的PC和服务器一样，它是一个灵活而强大的平台，可以为您的应用程序做好准备，无论是无服务器功能还是大型企业服务，用任何语言编写，并托管在您想要的任何符合容器的环境中。

来源：AI中国