标签：容器 取代 Kubernetes WASM Linux Docker 运行
云计算、微服务计算、无服务器计算、可扩展计算、可负担计算等等，这一切主要靠一项杰出的技术——Linux容器（LXC）来实现。
Linux容器（LXC）提供了操作系统级的虚拟化沙箱。简而言之，容器允许在一台主机上运行多个隔离的Linux系统。 利用Linux内核的某些特征，将共享资源（内存、CPU、文件系统）划分为称为“命名空间”的隔离级别。容器直接在物理硬件上运行，没有仿真，并且资源消耗低（除了设置命名空间的一点初始化之外）。目前使用Linux容器最流行的工具是Docker。Linux容器与虚拟机不同，在虚拟机中，虚拟机管理软件（VirtualBox、VMware ESXi等）模拟物理硬件，虚拟机在该模拟环境中运行。
LXC一直是云计算开发的关键，但是一个新的玩家（我之前在本周刊谈到过）已经进入这个游戏。是的，我指的就是WebAssembly（WASM）。我想我已经多次复制粘贴过WASM的定义，但为了清楚起见，我觉得值得再次阐述一下：“WebAssembly是一种新的二进制格式的开放标准。从设计上看，它是内存安全的、可移植的，并以接近原生的性能运行。 其他语言的代码可以交叉编译成WebAssembly。目前，对Rust、C/C++和AssemblyScript（一种为WebAssembly构建的新语言，针对TypeScript的子集进行编译）提供了一流的支持。许多其他编译器已经在开发中。”
众所周知，WASM最初是为浏览器设计的，它是一种在浏览器中取代Javascript来进行计算密集型应用的方式，但是想象一下，有一种交叉编译的二进制格式，其可以提供一种快速、可扩展且安全的方式在所有机器上运行相同的代码，这个想法是相当吸引人的。这就是WASI（WebAssembly系统接口）诞生的原因（可参见2019年的公告）。WASI是一项新的标准，它将WebAssembly的执行扩展到操作系统。它引入了新的抽象层次，使WASM二进制文件可以“编译一次，就能在任何地方运行”，而与底层平台无关。这就是去年让我对WASM感到兴奋的原因，也是引发我在本周刊中发表这篇文章的原因。
开端
然而，前几天我在开发一个小型的Rust微服务，在部署的那一刻，我开始怀疑：“等一下，在这里用WASM也许会很方便”。具体来说，我正在开发的是一个简单的服务器，该服务器可以监听一组webhooks，并根据所触发的webhook及其具体内容触发数据库和其他服务中的动作。它是一个无状态的微服务，我希望它尽可能的轻量级（因此，选用了Rust）。当我在对服务进行Docker化时，我意识到：“为什么不能将我的Rust微服务编译成WASM，并像无服务器功能一样在我的基础架构上按原样运行它？” 就在那时，我开始研究WASM在无服务器环境中的使用。显然，很多人之前已经尝试过使用AWS Lambdas和Azure Functions，但我讨厌供应商锁定。我已经使用Kubernetes来管理我的部署（因此，对微服务进行Docker化），为什么我不能在没有附加虚拟化的情况下运行原始WASM二进制文件，就像在Kubernetes上运行Docker容器一样。 这将允许LXC和WASM负载共存于我的Kubernetes集群中，使我能够在Kubernetes上部署轻量级WASM（由于WASM二进制文件小，唤醒速度快）功能和应用，并在我的基础架构中融合容器化和无服务器的方法。
在云中使用WASM不仅意味着频繁睡眠和唤醒的轻量级进程的快速启动时间、接近原生代码的性能以及更轻量的二进制文件（这也是其开发的一些初衷），而且还意味着通过设计具有一种沙箱式运行环境。WASM安全模型具有两个重要目标：“（1）保护用户免受错误或恶意模块的影响；（2）在（1）的约束下，为开发者提供开发安全应用的有用原语和缓解措施。” 这是云安全工程师多年来一直试图在Docker中实现的目标。
Docker与WASM的比较
深入研究后，我发现并不是只有我一个人看到了WASM在云计算中的潜力，就连Docker的创始人所罗门·海克斯（Solomon Hykes）也已经意识到WASM和WASI的结合对云环境的影响：
（tweet）“如果在2008年已经有了 WASM + WASI，我们根本不需要创建 Docker。WASM 就是这么重要。服务器端的 Webassembly 是计算的未来。标准化的系统接口是缺失的环节。让我们希望WASI能够胜任这项任务!”
我强烈推荐大家关注上述推特的回复，可以找到亮点，比如：
（tweet）“那么WASM会取代Docker吗？不会，但是可以想象一下未来Docker并排运行linux容器、windows容器和WASM容器的情景。随着时间的推移，WASM可能会成为最流行的容器类型。Docker会对它们一视同仁，能够全部运行。”
然后我看到了Microsoft的这篇博文和Krustelet的公告，对我的答复的进一步回答。
“重要的是，WASM在很高的层面上具备两个主要特征，Kubernetes生态系统或许能够利用它的优势：
- 与容器相比，WASM及其运行时可以快速执行并且体积非常小
- WASM在默认情况下不能做任何事情；只有在明确的权限下才能执行。
上述两个特征恰好是我们需要的，这暗示了我们或许可以在受限且对安全性要求很高的环境中（在这些环境中，对于容器而言比较困难）有利地结合使用WASM与Kubernetes。”
仅通过LXC，容器的执行还是会受限于底层的体系结构，比如，你试过在Windows在运行Docker嘛？我懂你的困难。但是通过WASM我们有了一个全新的通路，使得我们可以在任何体系上运行虚拟的WASM环境，甚至在虚拟化或容器技术都不支持的架构上（其实浏览器就是这种体系）。我不知道你如何看待这个问题，但是随着我越来越深入的阅读和学习WASM，我就愈发对这个技术感到兴奋。当然我可能也有自己的偏见，无所谓啦。
原文作者：Alfonso de la Rocha，原文链接。
标签：容器,取代,Kubernetes,WASM,Linux,Docker,运行 来源： https://blog.csdn.net/weixin_52466383/article/details/110056194
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。