梁晓勇 译 分布式实验室
继OpenStack之后，这些天我被问到的最多的话题是容器及其在企业及原生云应用上的前景。很多人对容器取代类似VMware ESX或Linux KVM（多数OpenStack部署的默认选项）这类Hypervisor的前景尤其有兴趣。然而，还存在一些误区。很多人分不清容器与虚拟机的差异。还有些人为支持虚拟机，喜欢挥动安全性大旗，坚称容器不安全。
这其中缺失的不仅是对基础设施层面上容器是什么的正确理解，还有未来伴随着各类琐碎的更新后的容器可以是什么的正确理解。同时缺失的还有对VMware ESX这类正快速衰退的传统Haypervisor价值的理解。从我的角度来看，虚拟机的时光正在消逝，只是这种变化发生有多快的问题。
在此期间，容器需要运行于虚拟机之上么？或者，运行于裸机上的容器将简单地完全取代Hypervisor？
最后，OpenStack在这其中的位置是什么？与ESX不同，OpenStack不是一个Haypervisor，实际上，它可以与容器、虚拟机或裸机等友好共处。
我们来探讨一下。
也许将来我会更多地讨论这个话题，不过重要的是要理解，与虚拟机不同，容器具有两个视角：它们是基础设施（即“轻量级虚拟机”）？或是应用程序管理与配置系统？事实是，它们两者皆是。如果你是基础设施人员，你可能会将其视为前者，如果是开发人员，则可能会将其视为后者。
这指向了用于扁平化部分云技术栈的一个事实上的途径，并提供了用于简化底层基础设施及其与应用程序交互的能力。我会在未来的文章中对此进行详述。
本文中，我将主要讨论容器作为基础设施工具的一面。
当Intel通过Intel-VTx（https://en.wikipedia.org/wiki/X86_virtualization）指令集在芯片中直接提供Hypervisor所特有的众多功能时，Hypervisor的丧钟就已经敲响。在此之前，VMware和Xen具有两种特有的方法来提供Hypervisor功能：二进制翻译及半虚拟化。关于哪种方法更快的争论不休，但是Intel-VTx一出现，凭借其在芯片中的优势，立即成为了事实上的速度赢家。在之后，VMware ESX及Xen都默认使用了Intel-VTx。100%依赖于Intel-VTx芯片组这些功能的KVM应运而生。最为重要的可能是，它消除了“类型1”和“类型2”Hypervisor之间绝大部分的差异。
当然，现在你会说，Hypervisor依然有价值，不过这种价值已大不如前，并且主要集中在异构环境中为传统应用程序提供支持。实际上，Hypervisor允许你在访客系统（虚拟机）中运行不同的操作系统。
我来解释一下。
Hypervisor中的半虚拟化驱动层
Intel-VTx出现之后，管理现存的传统“宠物”型（译者注：有状态应用，需要关注其每个具体实例的运行状态）工作负载的最大问题在于支持各种各样的操作系统。这是如今企业环境的现状，支持异构系统的关键在于支持这些系统。不幸的是，当你在Intel-VTx上运行未经修改的内核，涉及网络和磁盘的系统调用依然会访问仿真硬件。Intel-VTx主要解决的问题是：分离、隔离并允许高效访问直接的CPU调用及内存访问（通过扩展页表[Extended Page Table，EPT]，https://en.wikipedia.org/wiki/Second_Level_Address_Translation）。Intel-VT未解决网络与磁盘的访问，虽然SR-IOV、VT-d等尝试解决这个问题，但还离实现还很远。
为了维持更高的网络和磁盘性能，主流Hypervisor都采用了半虚拟化驱动。半虚拟化驱动非常类似于Xten的半虚拟化内核。在Hypervisor及其访客操作系统中有一个用于网络或磁盘的特殊的半虚拟化驱动。你可以想像一下，这个驱动被Hypervisor内核与访客内核“劈成两半”，从而允许更高的吞吐量。
取决于不同的工作负载，还是会有5-30%的网络与磁盘性能影响。半虚拟化驱动终究还是无法像裸机那样操作。
除了性能问题之外，半虚拟化（PV）驱动还有其他问题。其中之一：PV驱动由不同的操作系统提供商编写，每个Hypervisor（ESX、Xen、KVM等等）以及每个访问操作系统（Windows 7、Windows 10、RHEL、Ubuntu、FreeBSD等等）都需要不同的PV驱动。这会产生大量代码、更大的可能被***的***面、一个巨大的支持与测试矩阵，以及显著的质量差异。
最重要的是，Hypervisor自身只是用于支持PV驱动的一层，而后者也是用于支持异构操作系统的一层。
我们不得不问道：“在企业数据中心，异构操作系统还需要维持多久？”
在向原生云应用程序及第三方平台迁移时，我们都强烈地意识到需要对底层操作系统进行标准化和规范化。如果你运行着20个不同的操作系统，你无法获得更高的运维效率。如果你想要容器，那么你也将寻求在同质化或近同质化的环境中运行它们。如果你正向任何类型的PaaS平台迁移，你也是在标准化底层操作系统。随处可见，我们正在远离异构性。
在这样的环境中，半虚拟化驱动层（或者说是Hypervisor）价值很小，甚至不存在。
Hypervisor的主要争论是在于支持那些需要高级功能的工作负载，比如用于可用性的VMware DRS和HA、操作系统异构性以及通过隔离获得的“更高的安全性”。
对Hypervisor来说不幸的是，在容器里所有这些功能都以这种或那种方式实现了。异构性可能除外，但这完全不是问题。
容器与安全性
有个流行的论调，认为容器比Hypervisor“不安全”，无视一个事实：对一些人来说，容器的初衷是作为一项应用程序安全机制。它们可以将应用程序打包进一个非常低的***面里，在一个隔离的牢笼中以非特权用户进行运行。这远比典型的基于虚拟机的方式要好得多，在后者你面对的是整个操作系统，不得不对其定期打补丁和维护。
不过很多人会指出Hypervisor用于提供隔离性的魔法，比如扩展页表（EPT）。但是，EPT，以及Hypervisor很多功能已经不再由Hypervisor自身提供，而是由Intel-VTx指令集提供。让Linux内核调用这些指令并没什么特殊之处。实际上，斯坦福的DUNE项目（http://dune.scs.stanford.edu/）释出的代码就能为常规应用程序做到这点。将其整合到容器平台中也是小菜一碟。
可以期待的是，Intel将继续丰富Intel-VTx指令集，且Linux内核和容器将不需要Hypervisor作为中介即可利用这些功能。
在去除了Hypervisor虚拟机中强制包裹着应用程序的绝大部分操作系统，容器可能实际已经比Hypervisor模式要安全。不过，我们可以肯定地说，经过些时日，这必然成真。
容器与弹性
接着，我们必须问这个问题：“DRS和HA呢？”考虑到这些功能很大程度在于支持“宠物”型工作负载这一事实，容器并无此需求，现实的情况就是，在一个弹性的第三方平台中，DRS和HA完全是多余的。PaaS工具如Cloud Foundry、容器管理系统如Kubernetes、Rancher、Mesos，及类似的管理工具已经设计用于扩展工作负载。它们会在运行的应用程序里检测性能和失效问题，并提前应对。
这能让我们明白：Hypervisor唯一的价值在于使用PV驱动支持多种操作系统，下一代数据中心并无此需求。
变化的图景
为帮助你理解变化的可能样子，游戏的结局视图是这样的，它假定Hypervisor在第二代平台“胜出”，并作为支持传统工作负载的关键工具；而容器则在原生云应用程序的第三代平台“胜出”，并成为支持现代数据中心及其工作负载的主要工具。
这个图示有些过于简单，不过我这里想展示的是：如果你无须考虑多个访问操作系统，如果你将斯坦福的DUNE库整合到容器中，如果你依赖于标准的Linux用户权限，如果你只想与物理资源直接通讯，容器是：
性能卓越
只要正确配置，可能就跟任何Hypervisor一样安全
远比Hypervisor简单，额外开销和操作系统占用更少
第三点值得多说几句。要详细说明这一点，可能需要额外一篇博客文章，不过以下是它的基本概念。以容器为中心的模式不仅如你所见极大简化了应用程序架构，消除了Hypervisor层带来的额外层及消耗，还允许进一步“扁平化”基础设施栈。这是什么意思？我是说，当我们变得以容器为中心时，我们自然变得以应用程序为中心。应用无须关心基础设施拓扑。它们有多少块磁盘，是什么类型的，是什么样的网络。全都无所谓。应用及现代原生云应用开发人员只关心基础设施约定：调用一个API，将获得基础设施资源，其性能可能能达到它的SLA也可能不能，如果它不能达到就杀掉并使用其他资源来替代，如果所请求的基础设施的资源即将耗尽，我会请求另外一个（水平扩展）。
我认为有一点是值得考虑的，Hypervisor及“宠物”型思维模式将驱使我们创造过度的、复杂的基础设施拓扑，这是现代应用程序完全不需要的。
OpenStack + 容器，还是OpenStack vs 容器？
对有些人来说，会有一个问题，原生云应用程序和现代数据中心中占主导地位的是OpenStack还是容器生态系统。对其他人来说，这些系统则是协同工作的。双方都有很好的论点。一方面，OpenStack看起来像是用于点燃基础设施即服务（IaaS）的复杂的、过度的尝试。另一方面，没有其他生态系统能像它这样全面，包括了DNS服务器、网络服务、存储、虚拟机、裸机、容器、数据库服务、密钥管理等等。
当你看到OpenStack之上主要的“PaaS”平台（http://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf）都是基于容器（Kubernetes、Cloud Foundry等等）的，你也许会对此更困惑。越来越多的客户选择使用OpenStack和KVM虚拟机作为运行底层。CloudFoundry这类以容器为基础的平台为一般的企业开发人员提供了集结和隐藏OpenStack复杂度的终极工具。
看起来正在发生的一个前进方向是，Hypervisor和容器会在中短期内共存，但随着时间的推移，技术栈趋于扁平，我们将开始直接在裸机系统上运行容器，在提供更好的安全性、可用性和性能的同时，去除Hypervisor、简化技术栈。最终，我们将看到类似这样的图景。
巨轮已经出港
在我看来，Hypervisor的巨轮已经出港。对于下一代原生云应用程序而言，现在是容器的时代，剩下的只是时间的问题。在此期间，在虚拟化底层之上运行容器“只是用于启动”的一种普通方法，而用于直接在裸机上运行容器的底层技术也会越来越好。现代的数据中心将相对同质化，就像为我们带来云计算的Web扩展公司一样。它将主要托管那些使用类似Cloud Foundry这类平台来管理自身弹性的原生云应用程序，同时随着容器及其生态系统的发展，它将比以往更安全、性能更佳、利用率也更高。
我乐见其成，相信你也一样。
本文为翻译文章，原文链接：http://cloudscaling.com/blog/cloud-computing/will-containers-replace-hypervisors-almost-certainly/
