深入理解虚拟机、容器和 Hyper 技术

本文首先介绍了操作系统，然后引出容器技术以及虚拟机技术，最后介绍了 Docker 和 Hyper 技术。通过本文可以清楚地对三者有感性认识。

操作系统概述

我们可以把操作系统简化为：

操作系统 = 内核 + apps

其中内核负责管理底层硬件资源，包括CPU、内存、IO设备等，并向上为 apps 提供系统调用接口，上层 apps 应用必须通过系统调用方式使用硬件资源，通常并不能直接访问资源。这里的 apps 指的是用户接口，比如 shell、gui、services、包管理工具等（Linux 的图形界面也是作为可选应用之一，而不像 Windows 是集成到内核中的），注意与我们手动安装的应用区别开来。同一个内核加上不同的 apps，就构成了不同的操作系统发行版，比如 Ubuntu、Red Hat、Android 等。因此我们可以认为，不同的 Linux 发行版本其实就是由应用 apps 构成的环境的差别，比如默认安装的软件、链接库、软件包管理以及图形界面等。我们把所有这些 apps 环境打成一个包，就可以称之为镜像。

问题来了，假如我们同时有多个 apps 环境，能否在同一个内核上运行呢？因为操作系统只负责提供服务，而并不管为谁服务，因此同一个内核之上可以同时运行多个 apps 环境是没有问题的。比如假设我们现在有 ubuntu 和 fedora 的 apps 环境，即两个发行版镜像，分别位于 /home/int32bit/ubuntu 和 /home/int32bit/fedora，我们最简单的方式，采用 chroot 工具即可快速切换到指定的应用环境中，相当于同时有多个 apps 环境在运行。

容器技术

我们以上通过 chroot 方式，感觉上就已经接近了容器的功能，但其实容器并没有那么简单，工作其实还差得远。首先要作为云资源管理还必须满足：

资源隔离

因为云计算本质就是集中资源再分配（社会主义），再分配过程就是资源的逻辑划分，提供资源抽象的实现方式，我们暂且定义为虚拟实体，虚拟实体可以是虚拟机、容器等。虚拟实体必须满足隔离性，包括用户隔离（或者说权限隔离）、进程隔离、网络隔离、文件系统隔离等，即虚拟实体只能感知其内部的资源，并且自以为是独占整个资源空间，它既不能感知其所在宿主机的真实资源，也不能感知其他虚拟实体的资源。

资源控制

资源控制指为虚拟实体分配一定量的资源，虚拟实体得到所分配的资源，不能超出资源最大使用量。

以上是虚拟实体的两个最基本要求，当然还包括其他很多条件，比如安全、性能等。本文主要基于以上两个基本条件进行研究。

虚拟机技术

显然满足以上两个条件，虚拟机是一种实现方式，这是因为：

隔离毋容置疑，因为不同的虚拟机运行在不同的内核，虚拟机内部是一个独立的隔离环境
资源控制也是毋容置疑的，Hypervisor能够对虚拟机分配指定的资源

目前 OpenStack Nova 和 AWS EC2 都是基于虚拟机提供计算服务，实现 CPU、RAM、Disk 等资源分配。其他比如 Vagrant 也是基于虚拟机快速构建应用环境。

但是虚拟机也带来很多问题，比如：

镜像臃肿庞大，不仅包括 apps，还包括一个庞大的内核
创建和启动时间开销大，不利于应用快速构建重组
额外资源开销大，部署密度小
性能损耗

容器技术

除了虚拟机，有没有其他实现方式能符合以上两个基本条件呢？容器技术便是另一种实现方式。表面上和我们使用 chroot 方式相似，所有的容器实例直接运行在宿主机中，所有实例共享宿主机的内核，而虚拟机实例内部的进程是运行在 GuestOS 中。由以上原理可知，容器相对于虚拟机有以下好处：

镜像体积更小，只包括 apps 以及所依赖的环境，没有内核
创建和启动快，不需要启动 GuestOS，应用启动开销基本就是应用本身启动的时间开销
无 GuestOS，无 Hypervisor，无额外资源开销，资源控制粒度更小，部署密度大
使用的是真实物理资源，因此不存在性能损耗
轻量级

目前比较流行的容器实现比如 LXC、LXD 以及 rkt 等，我们需要验证容器是否能够实现资源隔离和控制。

隔离性

主要通过内核提供 Namespace 技术实现隔离性，以下参考酷壳（http://coolshell.cn/articles/17010.html）

Linux Namespace 是 Linux 提供的一种内核级别环境隔离的方法。不知道你是否还记得很早以前的 Unix 有一个叫 chroot 的系统调用（通过修改根目录把用户 jail 到一个特定目录下），chroot 提供了一种简单的隔离模式：chroot 内部的文件系统无法访问外部的内容。Linux Namespace 在此基础上，提供了对 UTS、IPC、mount、PID、network、User 等的隔离机制。

Linux Namespace 有如下种类：

Mount Namespaces
UTS Namespaces
IPC Namespaces
PID Namespaces
Network Namespaces
User Namespaces

官方文档在这里《Namespace in Operation》（http://lwn.net/Articles/531114/）

由上表可知，容器利用内核的 Namespaces 技术可以实现隔离性。比如网络隔离，我们可以通过 sudo ip netns ls 查看 Namespaces，通过 ip netns add NAME 增加 Namespaces，不同的 Namespaces 可以有不同的网卡、Router、iptables 等。

资源控制

内核实现了对进程组的资源控制，即 Linux Control Group，简称 CGroup，它能为系统中运行进程组根据用户自定义组分配资源。简单来说，可以实现把多个进程合成一个组，然后对这个组的资源进行控制，比如CPU，内存大小、网络带宽、磁盘 iops 等，Linux 把 CGroup 抽象成一个虚拟文件系统，可以挂载到指定的目录下，Ubuntu 14.04 默认自动挂载在 /sys/fs/cgroup 下，用户也可以手动挂载，比如挂载 Memory 子系统（子系统可以实现某类资源的控制，比如 CPU、Memory、blkio 等）到 /mnt 下：

sudo mount -t cgroup -o memory /mnt

挂载后就能像查看本地文件一样浏览进程组以及资源控制情况，控制组并不是孤立的，而是组织成树状结构构成进程组树，控制组的子节点会继承父节点。下面以 Memory 子系统为例：

ls /sys/fs/cgroup/memory/

输出：

cgroup.clone_children  memory.kmem.failcnt                 memory.kmem.tcp.usage_in_bytes   memory.memsw.usage_in_bytes      memory.swappiness

cgroup.event_control   memory.kmem.limit_in_bytes          memory.kmem.usage_in_bytes       memory.move_charge_at_immigrate  memory.usage_in_bytes

cgroup.procs           memory.kmem.max_usage_in_bytes      memory.limit_in_bytes            memory.numa_stat                 memory.use_hierarchy

cgroup.sane_behavior   memory.kmem.slabinfo                memory.max_usage_in_bytes        memory.oom_control               notify_on_release

docker                 memory.kmem.tcp.failcnt             memory.memsw.failcnt             memory.pressure_level            release_agent

memory.failcnt         memory.kmem.tcp.limit_in_bytes      memory.memsw.limit_in_bytes      memory.soft_limit_in_bytes       tasks

memory.force_empty     memory.kmem.tcp.max_usage_in_bytes  memory.memsw.max_usage_in_bytes  memory.stat                      user

以上是根控制组的资源限制情况，我们以创建控制内存为 4MB 的 Docker 容器为例：

docker run -m 4MB -d busybox ping localhost

返回 ID 为 0532d4f4af67，自动会创建以 Docker 实例 ID 为名的控制组，位于 /sys/fs/cgroup/memory/docker/0532d4f4af67...，我们查看该目录下的 memory.limit_in_bytes 文件内容为：

cat memory.limit_in_bytes

即最大的可使用的内存为 4MB，正好是我们启动 Docker 所设定的。

由以上可知，容器可以通过 CGroup 实现资源控制。

Docker技术

在 Docker 之前其实容器技术早就有了，Google 的 Borg 以及 Omega 都利用了容器技术。但是之前容器一直没有形成一个标准，也没有一个很好的管理工具。LXC 是 Linux 原生支持的容器，很多工具依赖于具体的发行版，可能会出现移植性差的问题，并且也缺乏一组完善的管理工具集。而 Docker 基于底层的内核特性的基础上，在上层构建了一个更高层次的具备多个强大功能的工具集，它是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，简单说 Docker 提供了一个能够方便管理容器的工具并形成标准。Docker 相当于把应用以及应用所依赖的环境完完整整地打成了一个包，这个包拿到哪里都能原生运行。

其特性包括：

快速构建基于容器的分布式应用
具有容器的所有优点
提供原生的资源监控
自动构建和版本控制
快速构建和重组

Docker 与虚拟机原理对比：

容器技术在很早就有了，因此不能说 Docker 发明了容器技术，而仅仅是发明了一套完整的管理容器的工具集。但其实 Docker 核心的创新在于它的镜像管理，因此有人说：

Docker = LXC + Docker Image

Docker 镜像的创新之处在于使用了类似层次的文件系统 AUFS，简单说就是一个镜像是由多个镜像层层叠加的，从一个 Base 镜像中通过加入一些软件构成一个新层的镜像，依次构成最后的镜像，如图：

知乎：Docker 的几点疑问

Image 的分层，可以想象成 Photoshop 中不同的 layer。每一层中包含特定的文件，当 Container 运行时，这些叠加在一起的层就构成了 Container 的运行环境（包括相应的文件、运行库等，不包括内核）。Image 通过依赖的关系，来确定整个镜像内到底包含那些文件。之后版本的 Docker，会推出 Squash 的功能，把不同的层压缩成为一个，和 Photoshop 中合并层的感觉差不多。
作者：Honglin Feng
链接：https://www.zhihu.com/question/25394149/answer/30671258

这里利用了COW（copy on write）技术，即从一个镜像启动一个容器实例，这个镜像是以只读形式挂载的，即不允许任何修改操作。当在容器实例中修改一个文件时，会首先从镜像里把这个文件拷贝到可写层，然后执行更新操作。当读一个文件时，会首先从可写层里找这个文件，若这个文件存在，直接返回文件内容，如果不存在这个文件，则会从最顶层的镜像开始查找，直到最底层的 Base 镜像。这里存在的一个问题是，当镜像层很多时，查找一个文件可能需要一层一层查找，影响性能。基于 Ceph 构建 OpenStack 创建虚拟机也一样的原理，我们上传一个镜像到 Glance 时，首先对这个镜像创建一个快照并保护起来不允许写操作，当基于这个镜像创建虚拟机时，直接从镜像快照克隆一个新的 rbd image 作为虚拟机的根磁盘，最开始这个根磁盘除了指向其 parent 快照的指针，没有任何内容，不占任何磁盘空间，当虚拟机需要修改一个对象时，首先从 parent 中拷贝这个对象到它所在的空间，再执行更新操作。当读一个文件时，如果存在这个文件，直接读取，否则需要去 parent 所在的 image 中查找。

这样的好处是：

节省存储空间——多个镜像共享 Base Image 存储
节省网络带宽——拉取镜像时，只需要拉取本地没有的镜像层，本地已经存在的可以共享，避免多次传输拷贝
节省内存空间——多个实例可共享 Base Image，多个实例的进程命中缓存内容的几率大大增加。如果基于某个镜像启动一个虚拟机需要资源 k，则启动 n 个同一个镜像的虚拟机需要占用资源 kn，但如果基于某个镜像启动一个 Docker 容器需要资源 k，无论启动多少个实例，资源都是k
维护升级方便——相比于 copy-on-write 类型的 FS，Base Image 也是可以挂载为可 Writeable 的，可以通过更新 Base Image 而一次性更新其之上的 Container
允许在不更改 Base Image 的同时修改其目录中的文件——所有写操作都发生在最上层的 writeable 层中，这样可以大大增加 Base Image 能共享的文件内容

使用容器技术，带来了很多优点，但同时也存在一些问题：

隔离性相对虚拟机弱-由于和宿主机共享内核，带来很大的安全隐患，容易发生逃逸
如果某些应用需要特定的内核特性，使用容器不得不更换宿主机内核

更多关于 AUFS 参考酷壳：Docker 基础技术-AUFS（http://coolshell.cn/articles/17061.html）

Hyper技术

上文提到容器存在的问题，并且 Docker 的核心创新在于镜像管理，即：

Docker = LXC + Docker Image

于是就有人提出把容器替换成最初的 Hypervisor，而又利用 Docker Image 的优势，接下来介绍的 Hyper 技术以及 VMware 最新的 vic 技术大体如此，Hyper 官方（https://hyper.sh/）定义：

Hyper – a Hypervisor-based Containerization solution

即：

Hyper = Hypervisor + Docker Image

简而言之 Hyper 是一种基于虚拟化技术（Hypervisor）的 Docker 引擎。官方（http://mt.sohu.com/20150625/n415640410.shtml）认为：

虽然 Hyper 同样通过 VM 来运行 Docker 应用，但 HyperVM 里并没有 GuestOS，相反的，一个 HyperVM 内部只有一个极简的 HyperKernel，以及要运行的 Docker 镜像。这种 Kernel Image 的”固态”组合使得 HyperVM 和 Docker 容器一样，实现了 Immutable Infrastructure 的效果。借助 VM 天然的隔离性，Hyper 能够完全避免 LXC 共享内核的安全隐患。

创建一个基于 Hyper 的 Ubuntu：

sudo hyper run -t ubuntu:latest bash

创建时间小于1秒，确实达到启动容器的效率。

查看内核版本：

root@ubuntu-latest-:/# uname -a

Linux ubuntu-latest- 4.4.-hyper  # SMP Mon Jan  :: CST  x86_64 x86_64 x86_64 GNU/Linux

宿主机内核版本：

$ uname  -a

Linux lenovo 3.13.--generic #-Ubuntu SMP Wed Jan  :: UTC  x86_64 x86_64 x86_64 GNU/Linux

启动基于 Docker 的 Ubuntu 并查看内核版本：

$ docker run -t -i ubuntu:14.04 uname -a

Linux 73a88ca16d94 3.13.--generic #-Ubuntu SMP Wed Jan  :: UTC  x86_64 x86_64 x86_64 GNU/Linux

我们发现 Docker 和宿主机的内核版本是一样的，即 3.13.0-77-generic，而 Hyper 内核不一样，版本为 4.4.0-hyper。

以下为官方数据（https://github.com/hyperhq/hyper）：

因此 Hyper 是容器和虚拟机的一种很好的折衷技术，未来可能前景广大，但需要进一步观察，我个人主要存在以下疑问：

使用极简的内核，会不会导致某些功能丢失？
是不是需要为每一个应用维护一个微内核？
有些应用需要特定内核，这些应用实际多么？可以通过其他方式避免么？
Hyper 引擎能否提供和 Docker 引擎一样的 API，能否在生态圈中相互替代？
隔离性加强的同时也牺牲了部分性能，如何权衡？

总结

近年来容器技术以及微服务架构非常火热，CaaS 有取代传统 IaaS 的势头，未来云计算市场谁成为主流值得期待。

原文链接：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649690943&idx=1&sn=9f994c4dadcef9b256b8634d563ce795&scene=4#wechat_redirect