轻量级 Kubernetes 和 Wasm 是完美组合

作者：马特·布彻

近几年，我们见证了多个轻量级 Kubernetes 发行版的出现。SUSE 的 Rancher Labs k3s 项目是最早的项目之一。Canonical 现在已将Microk8s集成到 Ubuntu 中。而k0s则是一个单二进制 Kubernetes 发行版。

今年早些时候，我们推出了一个名为SpinKube的项目，它可以让您轻松地在 Kubernetes 集群中运行 Spin 应用。WebAssembly 应用的一大优势在于它们比容器小得多，而 Spin 应用尤其如此，因为它们采用了Serverless 函数式设计模式，因此运行时开销非常低。

因此，如果您真的想最大限度地利用低功耗硬件或虚拟机，那么将轻量级 Kubernetes 发行版与 SpinKube 结合使用将是一个强大的组合。在 KubeCon Paris 大会上，我们展示了如何在 k3s 实例上运行 5000 个 Spin 应用程序。

用例

运行 5000 个应用固然很酷……但对我们大多数人来说，实际上并没有那么多应用需要运行。那么，我为什么要使用这种小型 Kubernetes 和高性能 SpinKube 的组合呢？我们将深入探讨三个用例，但首先让我们来看看性能数据背后隐藏的特性：

• 由于 Spin 应用可以在半毫秒内启动，因此响应速度非常快。这意味着一线 Web 服务可以受益于 Spin 的速度优势。
• 由于 Wasm 沙箱非常轻量级（与虚拟机和容器相比），即使在配置一般的硬件上也可以启动数万个沙箱实例。
• 由于 Spin 应用的运行时间仅为几毫秒、几秒或几分钟，因此它们的资源会很快被释放。
• 那么，为什么高密度运行如此重要呢？可能有以下几种情况。

1. 将不常用的服务器堆叠在廉价的虚拟机上

Kubernetes 中一大类“资源吸血鬼”就是不常用的应用程序。我们每个人都有这类应用程序。它们提供一些辅助服务，例如偶尔使用的仪表盘或很少访问的 API 服务器。它们每天可能处理几千个、几百个，甚至十几个请求。但它们却始终处于运行状态，这意味着它们会消耗 CPU、内存、端口和其他宝贵的计算资源。

这正是近期研究表明83% 的容器成本都用于运行大部分处于闲置状态的服务的原因之一。我一位在媒体公司工作的朋友最近告诉我，他们的集群显示资源已分配 100%（即所有集群资源都被“占用”），即使 CPU 空闲率高达 80%。所有资源都被认领，尽管它们大部分时间都没有执行任何操作。

解决这个问题的方法是将这类服务打包成 Spin 应用。这样，它们只在处理请求时运行（并消耗资源）。您可以将大量这类实用服务打包到 Kubernetes 集群中一个低成本的小型节点上，从而释放大量系统资源供其他容器化服务使用。

2. 大幅降低高流量网站的运营成本

Spin 在另一个极端情况下也表现出色。Spin 应用按请求扩展。这意味着，当没有请求输入时，应用不会运行任何实例。当并发请求达到 1 万个时，就会启动 1 万个 Spin 应用实例。

这就是0.5毫秒特性大放异彩的地方。Spin的扩展速度可以比你眨眼的速度快三个数量级。

即使是流量很高的网站，其流量也存在规律，一天中某些时段的流量会远高于其他时段。基本的流量模式呈波浪状，高峰出现在目标市场活跃的中午时分，低谷则出现在深夜。有些网站周末流量会大幅下降，而另一些网站则会在周末迎来流量高峰。正如我们 Fermyon 从经验中了解到的，当某个内容在社交媒体上走红时，由此带来的流量峰值可能会比正常流量高出 100 倍甚至 1000 倍。

应对这些模式的传统方法是简单地为高峰期预留资源，并接受在低谷期服务闲置（且需要付费）的事实。虽然在某些情况下可以使用自动扩缩容来处理负载，但大多数情况下，它们需要数十分钟才能完成扩容。

得益于快速冷启动，Spin 应用可以瞬间扩展。即使我们的应用在 Twitter 和 Hacker News 上爆红，我们也从未需要添加任何额外的节点来处理负载。Spin 的效率就是这么高。

如果您只有少量前端服务，其中一些服务流量很高，那么在占用资源较少的 Kubernetes 发行版上运行 SpinKube 通常可以降低集群的资源占用，同时仍然能够处理大量的入站流量。

3. 将应用推送到边缘，降低运行成本

性能并非仅仅取决于 CPU 和内存。很多时候，优化性能意味着将网络延迟降至最低。这意味着将计算工作负载从集中式数据中心或云服务提供商迁移到边缘。然而，边缘计算能力往往有限。运行完整的 Kubernetes 和容器要么根本无法实现（因为计算能力不足），要么成本极其高昂（因为资源稀缺导致价格上涨）。

结合使用轻量级 Kubernetes 和 SpinKube 也可以解决这个问题。

我最近在 Akamai 的Gecko（通用边缘计算）环境中测试了一个前端 Web 服务。我在 Akamai 提供的最小尺寸边缘节点上安装了 k3s（以及用于测试的 Microk8s）和 SpinKube。我惊讶地发现，我的家庭办公室和边缘节点之间的流量速度非常快。每个请求的完整往返行程仅需 30 毫秒。请求从我家发出，到达数据中心，在那里启动一个 Spin 应用，运行完成并返回结果，然后将结果传回我家……整个过程仅用了 30 毫秒。而当我测试运行在亚马逊美国西部数据中心的 Spin 应用时，仅连接到远程主机就需要 60 毫秒。即使是最快的应用程序，在网络性能不佳的情况下也会显得很慢。

早期的边缘应用仅限于一些简单的任务，例如修改请求头或智能地将请求路由到上游。但是，如果能够在边缘运行 Spin，就可以将更复杂的应用逻辑推送到边缘，而不会造成性能损失或产生高昂的成本。

入门

轻量级 Kubernetes 发行版的另一个优点是它们通常很容易在本地进行测试。因此，如果您准备在小型 Kubernetes 上试用 SpinKube，可以在某个安静的周五下午进行测试运行。

SpinKube 官方文档涵盖了使用 k3d（一个基于 Docker 的 k3s 工具）以及如何将其安装到 Microk8s 中。在大多数情况下，使用 Helm 进行安装的说明就能满足您的需求。

接下来，您就可以开始构建 Spin 应用了。如果遇到任何问题，请在 Discord 上联系我们。我们随时乐意为您提供帮助。