我想知道gVisor 和Weave Ignite 在用例方面是否有区别（如果有的话）。对我来说，他们俩似乎都在尝试类似的事情：让代码在虚拟化环境中的执行更加安全。
gVisor 通过引入 runsc 来实现这一点，这是一个启用沙盒容器的运行时，而 Ignite 是通过使用 Firecracker 来实现的，在他们的上下文中似乎也被用作沙盒。
【问题讨论】：
标签： sandbox virtualization firecracker gvisor weave-ignite
Firecracker 和 gVisor 都是提供沙盒/隔离的技术，但方式不同。
Weave Ignite 是一个工具，它可以帮助您使用 Firecracker 在轻量级虚拟机中运行容器，并通过良好的用户体验来实现这一点，类似于使用 Docker。
github.com/weaveworks/ignite的Scope部分也提到了这一点
范围
Ignite 不同于 Kata Containers 或 gVisor。它们不允许你运行真正的虚拟机，而只是在新层中封装一个容器，提供某种安全边界（或沙盒）。
另一方面，Ignite 可让您轻松且超快速地运行成熟的虚拟机，同时使用熟悉的容器 UX。这意味着您可以“向下移动一层”并开始管理您的 VM 机群，例如一个 Kubernetes 集群，但仍然像容器一样打包你的虚拟机。
关于您问题的 用例 部分，我的感觉是，由于 VM 提供了更强的隔离性，Ignite 可以为生产做好准备。此外，gVisor 的方法似乎有很大的性能成本，正如The True Cost of Containing: A gVisor Case Study 中提到的那样：
结论
- gVisor 可以说比
runc更安全- 不幸的是，我们的分析表明，有效遏制的真正成本很高：系统调用慢 2.2 倍，内存分配慢 2.5 倍，大型下载慢 2.8 倍，文件打开慢 216 倍
当前的沙盒方法
使用 gVisor 进行沙盒化
我需要 gVisor 吗？
没有。如果您正在运行生产工作负载，请不要考虑它！现在，这是一个隐喻的科学实验。这并不是说您可能不想在它成熟时使用它。我对它试图解决进程隔离的方式没有任何问题，我认为这是个好主意。在未来采用这项技术之前，您还应该花时间探索其他替代方案。
我想在哪里使用它？
作为操作员，您会希望使用 gVisor 隔离不完全受信任的应用程序容器。这可能是您的组织过去信任的开源项目的新版本。这可能是您的团队尚未完全审查的新项目，或者您不确定是否可以在集群中信任的任何其他项目。毕竟，如果您正在运行一个不是您（我们所有人）编写的开源项目，那么您的团队肯定没有编写它，因此正确隔离和保护您的环境将是良好的安全性和良好的工程设计，以防万一可能是一个未知的漏洞。
我的回答包含来自以下来源的信息，这些信息在“按原样”获取时位于引用部分中，我建议您进一步阅读：
【讨论】：