容器和虚拟机 - better together
容器和虚拟机技术的由来和发展
IBM很早就在大型机上实现了虚拟化技术，但是虚拟化技术一直没有得到广泛的应用，直到VMware公司推出了x86平台的商业虚拟化产品，虚拟化技术才开始了爆发式的发展。不同领域的虚拟化技术层出不穷，从vSphere、Xen到KVM，从计算虚拟化、存储虚拟化到网络虚拟化，但是本质上来说虚拟化始终如一的目标就是实现对IT资源的充分利用和高效管理。
容器技术也不是近年来的新鲜发明，Solaris zones、LXC等技术都是早期的容器实现。在公有云PaaS流行的时候，由于有众多的免费用户，为了节省成本，一台服务器上有时会被分配几百甚至上千个应用。运维人员为了提高系统的安全性，使用了容器技术对租户进行隔离。很多的容器技术都是那个时期产生的，比如CloudFoundry使用的warden，dotCloud使用的Docker，Openshift使用的Gear等。
容器技术流行初期，其实很多人是把它当作轻量级的虚拟机来看待的，因为当时看来，容器所能提供的功能虚拟机都可以提供，容器只是比虚拟机更加轻量级一些；由于使用标准的容器镜像格式，容器可以快速的在不同的基础设施、不同的云环境之间迁移，容器只是比虚拟机更方便些。如果没有容器调度管理技术的出现，比如Kubernetes，那么这种说法是有道理的。但是随着Kubernetes的发展，它为容器生态提供了丰富的应用相关的特性，而这些特性是虚拟机所不具备的，比如针对应用抽象出的服务层、负载均衡资源、配置资源等，同时还引入了一些容器和应用更加灵活配置的模式，比如Sidecar、Initializer、istio等。到这个阶段，其实容器已经脱离了基础设施的层面，而成为了应用自身的一部分。
可以看出，容器技术被广泛使用的原因是它可以以标准的方式对应用进行打包、分发和运行，经过多年的发展，它已经是cloud native应用架构不可缺少的组成部分。
Docker是如何推动容器技术被广大技术人员接受的呢？
容器技术的爆发是从Docker的出现开始的。其实，Docker在同时期的容器技术中不是最早出现的，使用规模也不是最大的，那么为什么Docker能够脱颖而出成为最流行的容器技术呢？可能有以下几个原因：
- 容器镜像。同时期的容器技术都提供应用运行隔离的能力，但是只有Docker提出容器镜像的概念，创造了一种新型的应用打包和交付的形式。有了容器镜像，容器技术从原始的资源隔离功能发展出了应用分发的功能，应用可以被方便的分享，也可以在不同的运行环境中迁移。
- 镜像分层。有了分层，镜像在被分享、交付的时候可以共享base layer，从而极大的提高了应用分发的效率。想象一下，如果每个镜像的大小都超过1G，那么镜像的下载、分享和迁移就会非常麻烦，Docker也可能不会被广泛使用。
- Docker Hub。这个可能是Docker流行起来最重要的原因了。众多的Docker镜像在全球范围共享，人们突然发现通过几条命令就可以快速构建出一个高度一致性的环境。通过Docker Hub，Docker构建了一个良性的生态系统，全球的开发人员在同样的格式下分享。
Docker在几个容器技术同时起步的情况下，往前多走了几步，而不仅仅是停留在解决初始问题，提供了几个不算太复杂得功能，没想到这些功能和全球的开发人员起了一些化学反应，从而使Docker成为了最炙手可热的容器技术。
总结一下，容器技术和虚拟化技术是为了解决不同的问题而诞生的，所以它们的使用场景和使用方式都是完全不同的，不能把容器简单的理解为轻量级的虚拟机，也不存在哪个技术会取代另一个的问题，最好的方式就是根据实际情况，选择合适的方案，两种技术互相协同工作，从而更好的实现业务目标。
容器需要运行在虚拟化上吗？
Docker技术出现的初期，很多人将容器理解为轻量级的虚拟机，它比虚拟机启动更快速、计算密度更高、磁盘占用更低，所以有人认为容器技术会取代虚拟化技术。但是经过多年的发展，我们发现虽然容器得到了广泛的使用，但是它和虚拟化环境一直和谐共存。如果容器在短期内不会取代虚拟机，那么容器需要运行在虚拟化的环境中吗，还是直接运行在物理机上呢？
第三方分析机构的数据表明，现阶段企业级容器类型的工作负载大多数仍旧运行在虚拟化的环境中。我们可以从技术和业务两个角度来分析一下原因。
技术角度
- 一致的使用感受。对于企业客户来说虚拟化技术已经非常成熟，经过长期的投资，虚拟化有丰富的工具、经验和人员支持。IT人员对于虚拟化环境已经非常熟悉，在初期采用容器技术的时候不希望重新搭建一个全新的系统，使用不同的管理工具和流程。将新型的容器负载运行在虚拟化的环境中不仅可以获取容器所带来的好处，也可以延续虚拟化的管理感受，包括使用现有的虚拟化管理工具来统一管理容器和虚拟机。如果采用vSphere虚拟化技术，容器还可以利用NSX-T的网络虚拟化以及VSAN的存储虚拟化技术，比如使用NSX-T的分布式防火墙，可以提供容器东西向网络访问的控制能力。
- 管理集群的升级和维护。以Kubernetes为例，如果在物理机上部署Kubernetes集群以后，集群的升级和维护就变的非常困难，几乎都需要手工来完成。在虚拟化环境中，管理人员可以随时按照需求部署出来一个或者多个Kubernetes集群，也可以通过调用IaaS API的方式对Kubernetes集群进行升级、回滚、扩容等操作，还可以对集群中的节点进行健康监控，利用虚拟化的HA、FT、DRS等功能，提高集群整体的可用性。
- 安全和隔离。因为共享内核，所以容器的安全性和隔离型是低于虚拟机的。对于企业用户来说，在某些情况下需要使用虚拟机的安全和隔离性，这种情况下，将容器运行在虚拟化环境是一个更佳的选择，比如VIC的适用场景。从另一个方面来讲，为了提供更好的隔离性，类似GCP这种公有云也是将容器运行在虚拟化之上的，在某些隔离要求高的场景下，不同的租户使用不同的虚拟机组。在物理机上运行容器，如果一个容器出现漏洞会影响到整个物理节点上所有的容器，使用虚拟机可以缩小失败域。同时，在虚拟化环境中还可以使用软件定义网络的安全特性来控制容器的安全。
- 硬件认证和驱动。企业用户对于稳定性的要求很高，所以生产环境的软硬件都需要通过兼容性的测试，虚拟化环境经过长期的发展，对于主流的硬件有丰富的兼容列表。而在物理机上直接运行容器，容器宿主机的操作系统的硬件兼容认证和驱动支持是一个大的问题。使用虚拟化技术，hypervisor帮助屏蔽掉了所有的硬件认证和驱动的问题。
- 资源使用率和灵活性。在企业环境中有时需要多个容器集群，以Kubernetes为例，在物理机环境下，每个集群需要独占的资源，即使工作负载很小的时候，也无法和别的集群共享资源。而在虚拟化环境中，多个容器集群可以共享底层物理资源，也可以快速按需求创建和销毁集群，从而提高资源的利用率。
- 其他技术限制。在早期的Kubernetes版本中，对于每个节点能运行的最大POD数量作出了限制，在物理机的环境中，如果节点的配置非常高，这个上限就限制了物理资源的使用。类似的，在使用某些网络插件的时候，由于IP地址数量的原因，也会限制每个节点上运行的容器数量。
- 多种操作系统支持。因为技术限制，你无法在linux机器上运行windows容器，反之依然。所以在物理机的环境中，宿主机操作系统的选择和比例分配会比虚拟化环境中更困难一些。
当然了，在虚拟化环境中部署容器也有缺点：
- 虚拟化平台的性能损耗。虽然现在虚拟化平台的技术已经发展的非常成熟了，虚拟机对比物理机的性能损失也降到非常低的程度了，但是虚拟化环境中的容器性能在某些方面依然是低于物理机的。
业务角度
用户选择容器的第一诉求应该是满足现代IT环境下的敏捷诉求，不是性能诉求，以性能诉求为第一标准实际上是用户在还在以传统scale up的思路在解读对基础架构的要求，性能影响不应该是我们的选择容器的衡量标准(在当前的IT架构中，性能问题的解决已经转移到应用层面通过分布式架构去解决)，而分布式应用或微服务应用对底层基础架构的诉求更多集中在敏捷性上，也就是效率上(包括时间效率和空间效率)，所以在物理机环境下还是虚拟机环境下那个更能满足我们的的敏捷诉求才是第一标准。显然,如果以敏捷性为第一标准,虚拟机环境有更多的优势和场景。
另外先进技术只是一个方面，在用户方能否转换为真正的生产力还需要最佳实践，所以技术+实践才是比较全面的评估标准，从技术上讲理论上是对，但从实践角度讲运行在物理机环境和用户当前的实践未必相符合，比如很多用户的资源申请流程，如果是物理机采购扩容，整个流程还停留在非常传统的阶段，需要漫长的采购周期，这个无法和现代IT的敏捷诉求相匹配，而大部分企业的虚拟化资源申请流程则敏捷很多。
综上所述，现阶段在企业环境中使用容器技术，最佳的选择还是运行在虚拟化平台之上，即可以同时支持传统的虚拟机应用，也可以支持新型的容器应用，让企业平滑的过度到云原生阶段。
