Docker学习笔记3——Docker vs KVM
啥是KVM？
Kernel-based Virtual Machine(KVM) is a virtualization infrastructure for the Linux kernel that turns it into a hypervisor.
可以说KVM（Kernel-based Virtual Machine）http://www.linux-kvm.org/，基于内核的虚拟机，配合QEMU（处理器虚拟软件），需要CPU支持虚拟化技术（并且在BIOS里打开虚拟化选项），效率可达到物理机的80％以上。
下面图片来自Wikipedia：
对比：
Vmware的功能全面，设置全面，速度相对最慢；
VirtualBox的效率比Vmware高一些，中文用户最多；
KVM整体效率最高。
关于kvm：
kvm是开源软件，全称是kernel-based virtual machine（基于内核的虚拟机）。
是x86架构且硬件支持虚拟化技术（如 intel VT 或 AMD-V）的linux全虚拟化解决方案。
它包含一个为处理器提供底层虚拟化可加载的核心模块kvm.ko（kvm-intel.ko 或 kvm-AMD.ko)。
kvm还需要一个经过修改的QEMU软件（qemu-kvm），作为虚拟机上层控制和界面。
kvm能在不改变linux或windows镜像的情况下同时运行多个虚拟机，（ps：它的意思是多个虚拟机使用同一镜像）并为每一个虚拟机配置个性化硬件环境（网卡、磁盘、图形适配器……）。
在主流的linux内核，如2.6.20以上的内核均包含了kvm核心。
Docker会谋杀KVM吗？
关于Docker的想法，以前觉得Docker距离我们很远，突然意识到Docker可能会以比我们想象的更快的速度，进入我们的技术领地。Docker会不会取代KVM，两周之前我的判断是不会，因为在生产环境，性能是一个很大的问题。
从理论上讲，Docker更加的提高了资源利用率，但是Docker的实现机制决定了Docker在网络、存储IO方面有许多瓶颈。现在，一些解决这些瓶颈的方法已经出现，比如OVS（Open vSwitch）和Docker一起结合，可以解决网络问题，比如Ceph和Docker结合，可以解决存储问题。
当然，OVS和Ceph虽然是趋势，但是本身目前也有许多问题要解决，还要不停的实践和总结，但是方向已经非常明确了，只是一个时间问题。
Docker会不会谋杀KVM，我不知道，但是基本可以肯定，2年之后，会有70%的应用场景重合。
还有一个很明显的事件，连Windows也已经开始支持容器技术了，VMWare目前也在积极拥抱容器技术，就知道类似的解决方案影响力有多大。虽然我靠KVM吃饭，但是还是强烈呼吁大家开始拥抱Docker，KVM还会热上好长时间，同时Dcoker也会越来越热。
有人说Docker会和KVM共生，比如Docker目前还不支持热迁移，一个比较巧妙的解决方案就是将Docker容器放到KVM虚拟机里面，通过虚拟机的迁移，完成容器的迁移。
Docker & KVM & Openstack
从最为简单的构成形式出发，Docker实际上旨在提供一套能够在共享式基础设施之上对软件工作负载进行管理的容器环境，但同时又确保不同负载之间彼此隔离且互不影响。以KVM为代表的虚拟机系统所做的工作也差不多：创建一套完整的操作系统堆栈，通过虚拟机管理程序将与该系统相关的设备囊括进来。然而与虚拟机解决方案的区别在于，Docker在很大程度上依赖于Linux操作系统所内置的一项功能——名为LXC（即Linux容器）。LXC利用内置于操作系统当中的各项功能将不同进程的内存进行划分，甚至能够在一定程度上拆分CPU与网络资源。Docker镜像不需要像一套全新操作系统那样进行完整的引导过程，这样一来软件包的体积就能得到大幅压缩、应用程序运行在共享式计算资源之上时也将具备更为显著的轻量化优势。除此之外，Docker还允许工作负载直接访问设备驱动程序、从而带来远超过虚拟机管理程序方案的I/O运行速度。在这种情况下，我们得以直接在裸机设备上使用Docker，而这就带来了前面提到的核心问题：如果已经使用了Docker，我们还有必要同时使用OpenStack等云方案吗？
前面的结论绝非信口开河，Boden Russell最近针对Docker与KVM等虚拟机管理程序在性能表现上的差异进行了基准测试，并在DockerCon大会上公布了测试结果。
本次基准测试提供相当详尽的具体数据，而且如预期一样，测试结果显示引导KVM虚拟机管理程序与引导Docker容器之间存在着显著的时间消耗差异。本次测试同时表明，二者之间在内在与CPU利用率方面同样存在着巨大区别，具体情况如下图所示。
红色线条为KVM，蓝色线条为Docker。
这种在性能表现上的显著区别代表着两套目的相近的解决方案在资源密度与整体利用率方面大相径庭。而这样的差异也将直接体现在运行特定工作负载所需要的资源总量上，并最终反映到实际使用成本当中。
结论整理
·上述结论并不单纯指向OpenStack，但却适用于OpenStack以及其它与之类似的云基础设施解决方案。在我看来，之所以问题的矛头往往最终会被指向OpenStack，是因为OpenStack项目事实上已经在私有云环境领域具备相当高的人气，同时也是目前我们惟一会考虑作为Docker替代方案的技术成果。
·问题的核心不在于OpenStack，而在于虚拟机管理程序！
很多性能基准测试都将Docker与KVM放在了天秤的两端，但却很少将OpenStack牵涉于其中。事实上，前面提到的这次专项基准测试同时将OpenStack运行在KVM镜像与Docker容器环境之下，结果显示这两类技术成果能够带来理想的协作效果。考虑到这样的情况，当我们选择将OpenStack运行在基于Docker的Nova堆栈当中时——正如OpenStack说明文档提供的下图所示——那些资源利用率参数将变得无关紧要。
·在这种情况下，云基础设施能够在容器或者虚拟机管理程序当中提供一套完整的数据中心管理解决方案，而这仅仅属于庞大系统整体当中的组成部分之一。以OpenStack为代表的云基础设施方案当中包含多租户安全性与隔离、管理与监控、存储及网络外加其它多种功能设置。任何云/数据中心管理体系都不能脱离这些服务而独立存在，但对于Docker或者是KVM基础环境却不会做出过多要求。
·就目前来讲，Docker还不算是一套功能全面的虚拟化环境，在安全性方面存在多种严重局限，缺乏对Windows系统的支持能力，而且因此暂时无法作为一套真正可行的KVM备用方案。尽管正在持续进行当中的后续开发工作将逐步弥合这些差距，但抱持着相对保守的心态，这些问题的解决恐怕也同时意味着容器技术将在性能表现方面有所妥协。
·另外需要注意的是，原始虚拟机管理程序与经过容器化的实际应用程序性能同样存在着巨大差异，而且下面这幅来自基准测试的图表清楚地说明了这一点。目前可能合理的解释在于，应用程序通常会利用缓存技术来降低I/O资源开销，而这大大影响了测试结果对真实环境中运行状态的准确反映。
·如果我们将Docker容器打包在KVM镜像当中，那么二者之间的差异将变得可以忽略不计。这套架构通常利用虚拟机管理程序负责对云计算资源的控制，同时利用Heat、Cloudify或者Kubernetes等流程层在虚拟机资源的容纳范围之内进行容器管理。
总结
由此我得出了这样的结论：要想正确地看待OpenStack、KVM以及Docker三者之间的关系，正确的出发点是将其视为一整套辅助堆栈——其中OpenStack扮演整体数据中心管理方案的角色，KVM作为多租户计算资源管理工具，而Docker容器则负责与应用部署包相关的工作。
在这样的情况下，我们可以汇总出一套通用型解决模式，其中Docker分别充当以下几种角色：
·Docker提供经过认证的软件包，并保证其能够与稳定不变的现有基础设施模型顺利协作。
·Docker为微服务POD提供出色的容器化运行环境。
·在OpenStack之上使用Docker，并将其作用与裸机环境等同的运行平台。
前面说了这么多，我确实亲眼见证过不少经过精确定义的工作负载实例，对于它们来说是否使用云基础设施仅仅是种自由选项而非强制要求。举例来说，如果我出于DevOps的目的而考虑建立一套小型自动化开发与测试环境，那么我个人更倾向于在裸机环境上直接使用Docker机制。
而虚拟机与容器这两类环境之间，流程层将成为一套绝佳的抽象对接工具。
将流程框架与Docker共同使用的一大优势在于，我们能够根据实际需求、随时在OpenStack以及裸机环境之间进行切换。通过这种方式，我们将能够选择任意一种解决选项——只要其切实符合我们流程引擎对于目标环境的具体需要。OpenStack Orchestration（即Heat）在最新发布的Icehouse版本当中已经明确表示支持Docker环境。Cloudify作为一款基于TOSCA的开源流程框架，原本适用于OpenStack以及VMware、AWS乃至裸机等云环境，而最近也开始将Docker支持纳入自身。谷歌Kubernetes主要面向的是GCE协作目标，但我们也能够通过自定义来使其适应其它云或者运行环境。
思考：
1、那么问题来了，到底是在裸机上运行Docker，还是在Openstack上运行Docker，还是在KVM创建的虚拟机上使用Docker？
2、“虚拟机与容器这两类环境之间，流程层将成为一套绝佳的抽象对接工具”，这句话啥意思？啥叫流程层？
3、最后一段完全不知道在说什么？！
