常见容器技术总结（下）—KubeCon + CloudNativeCon总结

常见容器技术（下）—KubeCon + CloudNativeCon总结
                                         ——lvyilong316

    前面介绍了gVisor和Kata的实现，下面我们看下另外三种常见容器的实现。

Unikernel

目前的 Unikernel 项目。介绍完 Unikernel，接下来将介绍下目前比较成气候的 Unikernel 项目，Unikernel 的实现大部分都是语言特定的。因为涉及到具体语言的运行时，所以很难有一个项目可以适配所有的技术栈。

应该是名气最大的一个 Unikernel 项目，它是使用 OCaml 进行开发的，也是要求开发者懂 OCaml 才行。与其他 Unikernel 相比，它非常成熟，而且有一些，对钟爱论文的同学非常友好。

也是一个比较早的 Unikernel 项目，它可以帮助 Haskell 程序员们把自己的 Haskell 程序构建成 Unikernel。如果你不会 Haskell，那就算了 =。=

是一个比较独特的项目，他也非常古老了，但是原本 Click 并不是以 ClickOS 的形式出现的，原本它只是一个支持定制的 router，后来就变成了 ClickOS，一个基于 Unikernel 的 router。它也有很多，大部分都是关于 Click 本身，而不是 Unikernel 实现的。

也是一个非常独特的项目，其利用了 ，理论上 POSIX 兼容的程序，都可以用 Rumprun 来构建成 Unikernel。

如果这些还不能满足你的好奇心，上列出了众多的 Unikernel 项目，如有需要还请自行浏览。

Unikernel与容器

    Unikernel，在我看来是另一种形式上的容器。在一个 Unikernel 中，只能运行一个应用，这与容器的哲学不谋而合。但现在容器最吸引人的特性并不是它的便捷，而是在它的分发。Docker 让我们看到了，原来应用的分发可以这么无痛。而 Unikernel 与容器相比，虽然可以做的更小更安全，而且也不需要有 Docker Daemon 这样的后台程序存在，甚至不需要 Host OS，或者 Hypervisor，但是它一是与传统的软件过程有较大的出入，二是在分发等等方面不能做到像容器那样方便。所以它目前肯定不会成为主流的应用分发方式，还需要进一步探索。

为了能够让 Unikernel 尽快进入生产环境，有一项工作很值得关注。

在 Unikernel 里运行一个 Docker Container，想法很美好，但是同样也有很多问题。这样其实并没有利用到容器便于分发的优势，也没有完全发挥 Unikernel 的优势，我觉得这不是未来。不过作为一种折中方案值得一看，可惜从 DockerCon 15 之后就没听见什么动静了。

Firecracker

    

Pouch