机器 vs 应用
传统的虚拟化技术是为了模拟硬件设备而设计的。我们今天所熟知的虚拟机(VM)则是这个思路的一个副产品。一个虚拟机运行了一个完整的操作系统,简称”机器“。虚拟机运行的方式和物理机完全一致,保证了应用程序,操作系统和硬件三者之间的协议不变。因此,在一个虚机的世界里,工作跟过去都差不多,应用也无需调整。
但是 ,这种”完美“的兼容性也带来了几个严重的代价:
- 胖:虚机镜像的体积往往都在几十GB
- 慢:启动一台虚机一般需要几十秒
- 重:一台虚机至少需要百兆内存,而一套物理机上的虚机密度也不会太高
- 易坏:虚机往往都是不间断运行,因此很容易出现各种各样的配置参数错误
而另一方面,容器化的关注点在于”应用“。一个Docker Container只关心如何运行其中的应用,而一个Docker镜像也只包含应用有关的设计。这样做的好处是:
- 薄:一个Docker镜像一般只有200-300MB
- 快: 毫秒级启动Docker容器
- 轻:每个容器只消耗应用所需的内存,因此单台服务器上的密度得以提高
- 不可变:由于能够毫秒级启动,容器的生命周期往往很短,因此容器可以做到运行时状态与镜像一摸一致
下面是Docker官网的一张图,很清晰的解释了虚机和Docker两者之间的区别:
需要指出的是,上面提到的所谓”容器化“实际与各种Container技术(LXC等等)并没有太多关系。而上面列出的容器化带来的所有好处,这些好处来自于摒弃了完整的操作系统,而专注于应用的”容器化“思路。
说到这,自热仍然的问题是:
能不能实现一个面向应用的VM,使得VM也可以容器化?
Hyper - a Hypervisor-based Containerization solution
简短的说,
Hyper = Hypervisor + App Container Image
Hyper可以使用任何hypervisor(KVM, Xen等等)运行Docker镜像。Hyper与Docker的核心区别在于Hyper没有使用Container技术,而是通过VM直接运行Docker镜像:
由于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云了!