DockOne技术分享(七): 基于Hypervisor的Docker引擎——Hyper


【编者的话】从2013年Docker发布,到2014年的全面引爆,Docker给了我们一个明显的感觉——容器正在成为新的“银弹”,而Amazon AWS引爆的虚拟机技术已成了昨日黄花。

审视一下Docker,我们从中学到了什么——Docker的关键点在于它是以App为中心的运行环境的封装,自从有了Docker,开发、测试、生产都可以使用完全相同的环境部署,生产环境需要维护的很多东西都在开发时就固化在镜像内了,维护难度下降,一致性和可确定性提升,持续交付不是梦。

所以,对虚拟机在容器面前的苛责,用一句话说就是——“虚拟机”的问题不在于“虚拟”,而在于“机”。自然地,我们会想可不可以做App为中心的虚拟化呢?

Hyper就是这样一种App-Centric的虚拟化技术,我们完全摒弃了传统虚机上必须和物理机一样,运行一个完整OS这种看似显然的假设,我们让Docker Image直接运行在Hypervisor上。我们让一组容器直接启动在hypervisor上的时间达到350毫秒,并且还在进一步优化。而且所有这些,都是“开箱即得的”。

当然有人会问,有了容器为什么还要虚机。诚然,虚机并不是所有人都需要的,但是,虚机天然具备更好的隔离性;虚拟机也仍然存在于很多企业应用的协议栈中,这样一个依赖更少、开箱即得,而且还带有Pod、persist mode等附加丰富特性的应用,是不少场景中都需要的。而我们最期待的,就是去引爆新的容器服务——CaaS。

从 Docker 到容器服务

Docker 是这两年来,云计算领域最热门的创业项目,带动了整个 Container产业。他们最厉害的一点在于,开发者直接输出 Docker Image 或者 Dockerfile,测试、部署就可以做到高度一致,这里还是贴出对 @杜玉杰@华为开源 杜总的截屏的截屏:
01-app-centric.png

随着Docker的普及,越来越多应用开始倾向于采用Docker的方式部署——操作系统将只用于承载Docker,提供辅助性功能,逐渐同质化,CoreOS,Redhat Atomic,Ubuntu Core 都在走向这个方向。而 IaaS 或者 PaaS 服务商们,必然向 CaaS——容器即服务转型,避免真的沦为自来水一样的基础设施。
02-caas.png

Hyper——用虚机解决隔离问题

但是,Container的隔离性无法得到彻底解决(图片引自黄强的演讲)
03-security.png

于是就有了两个不同的选择——要追求性能,那么就将物理整机机出租给用户,但是这样做弹性有限,回收之后对系统的清理很复杂,而且用户可以接触到物理机、BIOS、网络,会产生一定安全隐患;或者出租虚拟机给用户——AWS ECS(EC2 Container Service)的选择,这样就损失了性能,而且用户其实对维护虚拟机的操作系统没兴趣。

这里我们要说的就是一个其他的选择——直接用虚拟机承载容器: Hyper = hypervisor docker image。

传统虚拟机的问题其实在于过于刻意模仿物理机,刻意要承载完整操作系统,启动一台虚拟机要若干秒,甚至几分钟,Image 有若干GB,加载传播都很慢,但其实根本没有这个必要,Hyper希望兼取两者的强项
07-vm-container.jpg

Hyper 在启动方面开销很低,即使很入门的机器,也可以有很好的性能,比如在一个小盒子上,里面跑的是超低电压的 i3 CPU,启动所用的时延只有不到500ms——
04-box.png

而且 Hyper 的命令行用法和 Docker 很相似,简单到一个 run 命令就可以启动一个 docker image
05-cmdline.png

Hyper 的实现架构是这样的
06-arch.png

在虚机上,引导起 kernel 之后,用 init 进程直接启动 Docker Image,没有完整OS。所有的 image 的处理,在虚拟机外面准备好,插入虚拟机运行。

此外,有时,你需要 link 几个密切关联的 docker,这样的时候,hyper 允许你把它们放在一个虚机里面,通过mount namespace隔离文件系统,这称为 pod,这个概念来自于 kubernetes。

One more thing

Hyper 还有一些额外的好处,对基于虚拟机的私有云架构,利用 hyper, 可以让已经有的针对虚机的软件栈,更平滑地向容器化的方向迁移。而且,虚机可以更好地兼容已有 openstack 软件栈,主流设备厂商的网络和存储设备都提供了针对 OpenStack Neutron 和 Cinder 的驱动,可以快速构建私有云。

我们也提出了 HyperStack ,也欢迎 OpenStack 社区的伙伴一起推动容器化的应用。

下一步即将到来的改进
  • 多 Hypervisor 支持—— Xen 本周发布,Virtualbox 开发中, ESXi 在 Roadmap 上
  • 跨平台——Mac 的支持在开发中


欢迎访问我们的主页: hyper.sh,

QA 环节

问:有木有尝试解决k8s的领域?
答:我们目前支持 k8s 的 pod 格式,服务还需要进一步集成。

问:用现有的openstack docker集成怎样?
答:

这个,其实也是openstack社区在做的方向之一,实际上最终的解决方案基本上还是倾向于 虚机-容器 两层架构,我们倒是致力于变成一层虚机,各有优缺点吧。

问:持续集成怎么玩耍?
答:
  • 我们是直接跑 docker image 的,所以直接用跑Docker 持续集成就没问题
。
  • 也可以在集成测试里用 hyper 做 runtime


问:你们做的是不是把虚拟机和容器进行合理的融合?


答:合理不合理这个不好自己评价啊,我们实际上用了虚拟机和 docker image,没用 lxc 或 libcontainer。

问:hypervisor相当于是一个针对docker进行裁剪的虚拟机,不知道理解对不对?
答:

嗯,hyper 基本上是一个剪裁优化过的虚拟机。

问:你们今后会支持Hyper-V吗?
答:暂时没有,这方面经验不够丰富,今后可能会考虑。

问:有规模测试吗,或者性能测试?
答:测试结果比较符合大家对虚拟机性能的估计,CPU/Mem 子系统和物理机接近,IO系统,性能越好的 IO 设备越能看到一定性能差距,和使用方式(串行还是并发等)都有关系,不过如果大家用网络存储,或者套一层虚机的话,就没什么差距了。

问:看了一下安装貌似装docker只是为了去下载镜像,然后hyper去读镜像文件,有没有考虑去除Docker的依赖,这样应该更容易理解hyper的本质。
答:是的,目前是用 docker daemon 来拉 image 的,将来有一个计划去掉这个依赖,这样在 mac 上就也能跑了。

问:想了一下,应该是hypervisor的虚机缺省运行一个docker daemon,里面只有一个container,是不是这样呢?
答:

需要相互耦合的 docker image ,会组成一个 pod,放在同一个虚机上跑,并且放在同一个 network namespace 里,这样比 link 还要方便一些,直接 localhost 访问了。

问: 这么说,hypervisor的下层就是物理机了吧?听起来应该是自建私有云的企业比较需要它,另外就是IAAS本身适合用它构建?
答:

嗯,物理机上可以直接用,公有云做容器服务也可以用的。

问:相关的 image跑在一个虚拟上 那这些的images 的应用之间有隔离什么的吗?
答:这些 image 正常的话,属于同一个租户,相互间共享 ipc namespace 和 network namespace,只是有不同 mount namespace,文件系统是隔离的。

问:虚机的lightkernel是你们定制好的?
答:

缺省是我们定制好的,用户可以用自己的 kernel,不过用户自己的 kernel 可能性能略有差异。

问:coreos也可以装在物理机上,相对于coreos,hyper有哪方面的竞争力呢?
答:

感觉还是不太一样 coreos 更强调了os的维护,重点在 host os,我们强调了在 hypervisor 里运行 image,重点在 vm 和 guest kernel 这边,两者还是有很不错的合作前景的。

问:请问,基于虚拟机的私有云架构,迁移到hyper,会不会有承载不了的场景?
答:会有,容器化,或者说是面向应用的封装,会改变开发、测试、发布的流程,当你选择了演进,我们来帮你演进的平滑,但不是说可以完全不动,安装一下就一劳永逸地演进好了
。

问:即将到来的特性里面,xen、virtualbox支持是什么意思?
答:是让xen通过用hypervisor来降低消耗?

各有所爱吧,有人喜欢 xen,有人习惯 kvm,至于 vbox 的支持,纯粹是为了帮助开发者方便在自己的计算机上跑的。

问:插一句,OpenStack 的 Magnum 算是基于 Hypervisor 的 Docker 引擎吗?
答:

那是个大项目啦,本身不是一个 docker 的执行引擎,但是我们觉得可以集成一下。

问:请问Hyper跟Intel前段时间发布的Clear Linux最大的区别是什么?

答:


  • 作者不一样,嗯

  • clear linux 是比较纯粹地直接替换 container 层,比较纯粹地性能优化,我们有一些 pod 一类的 feature

  • clear linux 对某些内核特性乃至 CPU 特性依赖的比较强烈,做到了很好的效果,我们则强调了多 hypervisor 的可能性,以及 out-of-box 的工作


当然,clear linux 和我们的努力有更多的方面是一样的——大家都乐于去用虚机来承载应用为中心的镜像,这个趋势应该说是得到了认同的。

===========================

以上内容根据2015年6月9日晚微信群分享内容整理。分享人王旭,Hyper 联合创始人、CTO,曾就职于中国移动研究院、盛大云计算,以及担任 VisualOps CTO,从事分布式存储系统和DevOps工具开发等工作。王旭也是一位技术作者与译者,王旭的译文和文章主要涉及了Linux内核、文件系统、虚拟化、Hadoop、NoSQL与分布式存储系统等主题。是O'Reilly的《Cassandra权威指南》的译者。接下来,DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学参与。

3 个评论

你好,针对这个light kernel,我有一些问题:

1 问答里面提到了,light kernel是可以替换为自己的customer kernel的,那么我想问一下,这种替换的范围是怎么样的?是所有的使用hyper起的虚拟机的kernel都会被替换,还是仅仅我指定的虚拟机会被替换?一言以蔽之,就是hyper可不可以同时起不同kernel的虚拟机

2 docker的image是不包含kernel的,但是显然,对于hyper虚拟机来说,docker image+kernel才是完整的环境,hyper提不提供image+kernel的打包格式呢?
1. 目前的版本是全局的,指定的 kernel 会用于所有 hyper 启动的虚拟机,但如果想改为指定每个虚机的内核/initrd也并不困难

2. 目前没有提供这种打包格式,一般的 docker image 都是 kernel 无关的
谢谢你的回答,对于第二个问题,我想container技术除了隔离性的问题之外,还有单一的kernel所带来的对一些依赖kernel的应用的限制性的问题,所以我想hyper既然是做虚拟机,那么这个问题是不是需要考虑呢,这样应用+kernel作为一个完整的环境势必要有一个打包格式来部署和维护的,这是我的一点看法。

要回复文章请先登录注册