文：马特·巴彻

在过去的几年中，我们见证了若干新的轻量级 Kubernetes 发行版本的出现。SUSE 的 Rancher Labs k3s 项目 是较早推出的之一。现在 Ubuntu 中包含了 Microk8s。而 k0s 则是一个单文件的 Kubernetes 发行版。

今年早些时候，我们启动了一个名为SpinKube的项目，该项目让在您的Kubernetes集群中运行Spin应用程序变得非常简单。WebAssembly应用程序的一个亮点在于，它们比容器小得多，而Spin应用程序特别需要很少的运行时开销，因为它们采用了无服务器函数设计模式。

所以如果你真的想要从你的低性能硬件或虚拟机中榨取最大性能，结合使用轻量级 Kubernetes 与 SpinKube 可以成为一个强大的组合。在巴黎举行的 KubeCon 大会上，我们展示了如何在一个 k3s 实例上运行 5,000 个 Spin 应用。

运行5000个应用程序很酷……但对我们大多数人来说，实际上并没有那么多应用程序需要运行。那么为什么我会想要使用这个小巧的Kubernetes和高性能的SpinKube的组合呢？我们将深入探讨三个用例，但是在那之前，让我们先来看看这些性能数字背后隐藏的特性是什么：

• 由于 Spin 应用可以在半毫秒内启动，响应速度非常快。这意味着前端的 Web 服务可以从 Spin 的速度中获益。
• 由于 Wasm 沙箱非常轻量（与虚拟机和容器相比），甚至在普通的硬件上也可以启动数万个沙箱实例。
• 由于 Spin 应用仅运行几毫秒、几秒或几分钟，它们占用的资源会很快释放。
• 那么为什么运行密度如此之高很重要？这里有一些可能的场景。

一类“Kubernetes 吸血鬼”就是那些偶尔使用的应用。我们都有这种应用。这些应用提供某种支持服务，比如偶尔用到的仪表盘或几乎没人访问的 API 服务器。每天可能只有几千、几百甚至十几个请求。但是，它们一直在占用 CPU、内存、端口等宝贵的计算资源。

这是最近研究指出容器成本中大约有83%用于运行大多数时间闲置的服务的一部分原因。（注：详见 https://www.datadoghq.com/state-of-cloud-costs/）我的一位在媒体公司的朋友最近告诉我，他们的集群显示资源100%分配（即所有集群资源都被占用），即使CPU空闲率达到80%。所有资源都被分配了，但大部分时间实际上并没有被使用。

解决办法是将这些服务转换成Spin应用服务。这样一来，它们只在处理请求时才会运行和消耗资源。你可以在Kubernetes集群中便宜小巧的节点上部署很多小工具服务，从而为你的其他容器化服务节省大量系统资源。

Spin 在光谱的另一端也表现优异。Spin 应用按请求扩展。这意味着当没有请求进来时，应用没有运行实例。当有 10000 个请求同时出现时，就会启动 10000 个 Spin 应用实例。

这里就是0.5毫秒功能大放异彩的地方，Spin可以扩展三个数量级快，快到你眨眼的瞬间都来不及（眨眼的速度）。

即使是高流量的网站，流量也存在一定的规律，一天中某些时段的访问量远高于其他时段，这表明流量有其规律性。基本的流量模式通常是波浪形的，高峰出现在目标市场的中午，而低谷则出现在深夜时段。对于某些网站，周末流量会显著下降；而对于其他一些网站，周末流量则会显著上升。我们Fermyon团队也亲身经历过，当某个内容在社交媒体上突然走红时，带来的流量激增可能高达平时水平的100倍甚至1000倍。

处理这些模式的传统方式是只为高峰期做准备，而在低谷期接受闲置服务的现实。自动伸缩工具虽然在某些情况下可以用于处理负载，但在大多数时候，它们的响应速度相当慢，通常需要几十分钟才能完成扩容。

因为快速冷启动，Spin 应用可以立即扩展。即便我们在 Twitter 和 Hacker News 上走红，也不曾为了应对这些流量而增加哪怕一个额外的节点。Spin 就是这么高效省事。

如果你有一些少量的前线服务，其中一些是高流量的。在轻量级的 Kubernetes 发行版上运行 SpinKube 通常会减少集群的需求，但仍能处理大量的入站请求。

性能优化不仅仅是靠提升CPU和内存。很多时候，性能优化就是要尽可能减少网络延迟。这通常意味着将计算任务从中心化的数据中心或云服务转移到边缘。然而，边缘设备的计算能力往往有限。运行完整的Kubernetes和容器要么因为计算资源不足而难以实现，要么因为资源稀缺而变得昂贵。

运行轻量级 Kubernetes 和 SpinKube 的组合也能解决这个问题。

我最近在 Akamai 的 Gecko（通用边缘计算环境） 上尝试了一个前沿的 web 服务。我在 Akamai 提供的最小边缘节点上安装了 k3s（以及用于测试的 Microk8s），和 SpinKube。我惊讶地发现从我家办公室到边缘节点的往返请求时间仅需 30 毫秒。请求从我家发出，到达数据中心，在那里启动了一个 Spin 应用，运行完毕后返回结果，整个过程仅需 30 毫秒。相比之下，测试一个运行在亚马逊 us-west 数据中心的 Spin 应用时，仅连接远程主机就需要 60 毫秒。即使是最快速的应用程序，也会在网络性能不佳的情况下显得很慢。

早期的边缘应用仅限于执行简单的任务，例如处理头部信息。但当你可以在边缘运行 Spin 时，你可以将更加复杂的应用逻辑推到边缘，而不会影响性能或增加成本。

轻量级 Kubernetes 发行版通常很容易测试。所以如果你准备好尝试 tiny Kubernetes 上的 SpinKube，你可以在那个安静的周五下午试运行一下。

官方的 SpinKube 文档介绍了如何使用 k3d（一个将 k3s 放在 Docker 中的工具） 以及如何在 Microk8s 中安装。在大多数其他情况下，你可以根据 使用 Helm 安装的说明 即可满足您的需求。

从那之后，你可以开始构建 Spin 应用程序入门指南。如果遇到任何问题，只需在Discord上联系我们。我们随时乐意提供帮助。