Kubernetes在微软的Krustlet中遇到WebAssembly

微软的Deis Labs最近宣布了Kubernetes的一个有趣方向，它为我们的代码提供了一个新的沙盒环境。 在日益流行的WebAssembly的基础上， Krustlet是一个用于将Kubernetes管理的工作负载交付给WebAssembly运行时的工具 ， 现已在GitHub上发布了v0.1.0 。

这个名字Krustlet来源于他们是如何建造和他们打算做什么 。 Krustlets是“ Kubernetes RUST kubeLETs”。 他们采用了基本的Kubernetes组件kubelet，并以新的编程语言和新的平台实现了它。 像大多数Kubernetes一样，Kubelets用Go编写。 Krustlet是在Mozilla的类型安全和内存安全Rust中开发的。

[ 同样在InfoWorld上：使Kubernetes更好的11种工具 ]

注意到Rust的选择很有趣。 微软一直在研究Rust，以此来减少对系统进行基于内存的攻击的风险， 并将它用作系统编程语言 ，而在过去，您曾经使用过C或类似语言。 Rust是WebAssembly支持的主要语言之一，两种语言都来自Mozilla托管的研究，这使其成为在WebAssembly虚拟机上运行的应用程序的不错选择。

从kubelet到Krustlet

kubelet 是 Kubernetes 的基本元素 ，位于节点的基础上。 运行后，kubelet将在Kubernetes控制器中注册为节点，然后接收PodSpec。 这描述了在节点上运行的容器，并且kubelet管理这些容器，以确保它们保持健康。 没有kubelets，Kubernetes将无法运行。 微软的虚拟Kubelets是其Azure Kubernetes实施的重要组成部分，在设计和实施默认Kubernetes kubelet的替代方案方面，Azure和Deis拥有丰富的经验。

最好将Krustlet视为替代的kubelet实现，但是Krustlet可以管理WebAssembly工作负载，而不是使用容器托管的工作负载。 它使用与kubelet相同的机制从控制器获取工作负载详细信息，并使用这些相同的工具将运行状况和其他管理指标发送回去。 您可以在同一Kubernetes基础结构中同时拥有kubelet和Krustlets，同时容器和WebAssembly工作负载都可以运行并一起工作。

使用Krustlets不需要新技能 ; 它们使用YAML进行配置，并使用kubectl或您选择的图形前端进行管理。 您需要做的就是构建一个适当的配置文件，该文件描述和部署WebAssembly应用程序，就像它们是标准的Kubernetes容器一样。

在Kubernetes中运行Krustlet

通过在Rust中构建Krustlet，您可以快速将Kubernetes功能交付给WebAssembly和开发中的独立WebAssembly系统接口（WASI）。 使WebAssembly成为Rust编译器中Krustlet的构建目标，并且可以在您的浏览器中运行它。 应用程序代码将需要WASM编译器，并支持Microsoft自己的Blazor中使用clang和.NET语言编写的 C 语言 。

部署到Krustlet的代码的YAML与其他Pod YAML一样。 关键区别在于体系结构描述符 “ wasm32-wasi”。 Krustlet将使用此字符串部署和管理Pod。 除了编写应用程序YAML之外，您只需要将WebAssembly代码部署到容器注册表即可，供Krustlet下载和运行。

Krustlet在明天的边缘

当我们开始考虑将Kubernetes用作应用程序的管理层时，也许有趣的观点来了，Kubernetes可以支持大规模扩展它们，远远超出了在Azure或GCP或AWS上运行的分布式代码的范围。 我们需要开始考虑边缘，其众多的小型服务器将作为我们工作负载的新主机，该边缘已通过Azure Edge Zones等技术引入到超大规模云中。

然后，我们需要考虑较小的设备，直到我最近编写的Azure RTOS硬件 。 我们如何管理在它们上运行的代码？ Krustlet概念中隐藏着一个答案，这个答案超出了当前的WebAssembly实现。

WebAssembly仅仅是开始。 拿走浏览器并添加一组标准接口，您就会得到WASI：一种新的通用虚拟机，可以使用您的WebAssembly编译的二进制文件并运行它们，而无需浏览器的开销。 定义WASI的许多Mozilla团队现在都在云和边缘提供商中工作，这并不是巧合，他们正在研究如何发布可在超融合和低功耗边缘硬件中运行的代码。

与Krustlet和WASI合作

如果我们可以使用WASI缩小尺寸并在Azure Sphere之类的设备上运行，甚至在Azure RTOS上运行该怎么办？ 现在我们有了Krustlet的运行时，可以使用Kubernetes作为应用程序的控制器，根据需要将代码推送到其中，而无需增加容器的开销。 无需手动更新微控制器。 他们的固件将是网络堆栈顶部的WASI，并且可以根据需要提供应用程序代码。

与传统的Kubernetes操作相比，消除对容器的依赖性是一个很大的变化，但是我们可以通过构建受信任的沙箱运行时（例如WebAssembly和WASI），将这些变化降至最低。 有必要将新的安全扫描功能添加到我们的存储库并构建管道，以确保我们推送到设备的代码没有受到破坏，这也许是建立在添加到GitHub的安全工具的基础上的。 使用WebAssembly扫描代码和依赖项将变得更加容易，因为WebAssembly编译器中的代码旨在在具有相对较少指令集的相对简单的基于堆栈的系统上工作。

最小的指令集在这里是一个优势，因为构建管道中的代码扫描程序将能够在WebAssembly代码大规模交付给Krustlet之前对其进行测试和验证。 希望任何扫描程序都将是一个开源项目，就像Kubernetes和WebAssembly一样，使任何人都可以构建和交付Krustlet实施，而不会被任何大型云提供商所束缚，并且不受其知识产权的束缚。

重要的是要记住，Krustlet和WASI都是实验性项目，但是将这两种技术结合在一起有很多希望。 使Kubernetes能够访问第二个代码沙箱是在交付可以在受限的边缘运行在数据中心之外的分布式应用程序方面的一大进步。 看看Microsoft和Deis接下来将Kubernetes带到何处以及社区将如何发展将会很有趣。

From: https://www.infoworld.com/article/3537535/kubernetes-meets-webassembly-in-microsofts-krustlet.html