常见容器技术(下)—KubeCon + CloudNativeCon总结
——lvyilong316
——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