Hyper—基于虚拟化的Docker engine

编者按：毋庸置疑，Docker在开源技术圈里是一个现象级的存在。随着Docker的兴起，整个行业都在经历一场从“虚拟化”到“容器化”的变革，而这个变革实际上是一场从“面向机器”到“面向应用”的转变。

机器 vs 应用

传统的虚拟化技术是为了模拟硬件设备而设计的。我们今天所熟知的虚拟机（VM）则是这个思路的一个副产品。一个虚拟机运行了一个完整的操作系统，简称”机器“。虚拟机运行的方式和物理机完全一致，保证了应用程序，操作系统和硬件三者之间的协议不变。因此，在一个虚机的世界里，工作跟过去都差不多，应用也无需调整。

但是 ，这种”完美“的兼容性也带来了几个严重的代价：

• 胖：虚机镜像的体积往往都在几十GB
• 慢：启动一台虚机一般需要几十秒
• 重：一台虚机至少需要百兆内存，而一套物理机上的虚机密度也不会太高
• 易坏：虚机往往都是不间断运行，因此很容易出现各种各样的配置参数错误

而另一方面，容器化的关注点在于”应用“。一个Docker Container只关心如何运行其中的应用，而一个Docker镜像也只包含应用有关的设计。这样做的好处是：

• 薄：一个Docker镜像一般只有200-300MB
• 快: 毫秒级启动Docker容器
• 轻：每个容器只消耗应用所需的内存，因此单台服务器上的密度得以提高
• 不可变：由于能够毫秒级启动，容器的生命周期往往很短，因此容器可以做到运行时状态与镜像一摸一致

下面是Docker官网的一张图，很清晰的解释了虚机和Docker两者之间的区别：

需要指出的是，上面提到的所谓”容器化“实际与各种Container技术(LXC等等)并没有太多关系。而上面列出的容器化带来的所有好处，这些好处来自于摒弃了完整的操作系统，而专注于应用的”容器化“思路。

说到这，自热仍然的问题是： Hyper - a Hypervisor-based Containerization solution

简短的说，

Hyper = Hypervisor + App Container Image Hyper可以使用任何hypervisor(KVM, Xen等等)运行Docker镜像。Hyper与Docker的核心区别在于Hyper没有使用Container技术，而是通过VM直接运行Docker镜像:

Shell

[root@user ~:]# docker pull nginx:latest [root@user ~:]# hyper run nginx:latest [root@user ~:]# docker ps [root@user ~:]# [root@user ~:]# hyper list .......

由于Hyper是一个完全基于虚拟化的解决方案，因此Hyper并不依赖于物理服务器上的Linux内核。每个HyperVM都自带一个HyperKernel。由于HyperKernel是个极简的内核，它可以非常快速的启动。测试表明HyperVM平均的启动时间是500-800毫秒，这个启动性能与Container几乎没有差别。

在启动的时候，Hyper将Docker镜像挂在到虚机里，而HyperKernel通过一个叫HyperStart的Init服务来启动Docker镜像里的应用。在Hyper的场景里，应用被100%的限制在虚机内部，因此也不需要像Container那样访问物理服务器上的操作系统。

Combine the best from both worlds

除去上面提到的隔离性之外，Hyper还融合了虚拟化和容器化两个思路的一些优点：

Introducing the secure multi-tenant CaaS

在Docker之前，IaaS是云计算的标准形式。绝大多数云平台都提供IaaS服务。随着Docker的出现，微服务架构逐渐流行起来，而与之对应的是CaaS的兴起。

虽然CaaS的趋势非常有潜力，但目前制约我们的是Container技术中隔离性的缺乏。毕竟，作为一个公有，多租户的CaaS云平台，安全性是不可或缺的。不同客户的不同应用共享同一Linux内核是不可能的。

现在这个阻碍就不存在了。考虑到VM的攻击面非常小，因此Hyper可以实现非常安全的，基于硬件增强的系统离性。

有了Hyper，我们终于可以打造安全的公有CaaS云了！