2016年容器技术思考：Docker、Kubernetes、Mesos将何去何从？

2015年，我还只是一个容器用户。 2016年，作为容器和云相关的开发者，我也更加关注容器生态。这篇文章总体从生态系统的角度分析了目前容器相关的产品，作为个人年度总结（本来计划在年前发表，可惜推迟到了年底）。 本文仅代表我个人观点。难免有疏漏。请纠正我。 本文的视角是技术生态系统的视角，而不是使用量和市场份额的视角。换句话说，产品是通过填补技术生态系统的一定空白而生存的，而不是通过市场或其他方式。 码头工人 说到容器，就不能不说到Docker。虽然容器技术已经存在很长时间了，但它的流行却是因为 Docker。长期以来，很多人对Docker的概念基本上就代表了容器。一次一个产品 朋友问我做什么的，我说和容器有关。她说她听不懂，但当我说是Docker时，她就听懂了，可见Docker的热情。今年，Docker发布了几个重要版本。我们先回顾一下Docker是什么，然后再讲讲它的变化。 Docker的镜像机制提供了更高级的通用应用神器包，也就是大家所说的容器能力。事实证明，各种操作系统或者编程语言都有自己的产品机制。 Ubuntu的deb、RedHat的RPM、Java的JAR和WAR都有不同的依赖管理和产品库。应用程序从源代码打包，分发到产品库，然后部署到服务器。很难抽象出一个通用的过程和机制。有了Docker镜像和镜像仓库标准，这个流程终于可以标准化了。于是，很多形象管理仓库如雨后春笋般涌现，这在以前的产品管理领域是很难想象的。过去，Java 领域的联系和人工制品似乎稍微完整一些。 Docker镜像机制和生产工具替代了ansible/puppet的部分功能。至少各种软件栈的定义和维护以及对主机的依赖已经被容器取代了。 Docker 实现了运营商不可变基础设施的梦想。 Docker对cgroups/namespace机制和网络的封装，可以很容易地在本地模拟多节点的运行环境，方便开发者开发和调试复杂的分布式软件系统。Docker的守护进程取代了systemd/supervisor等系统初始化进程管理器的部分角色。通过 Docker 运行的服务不受 systemd 管理，其生命周期由 docker 守护进程维护。 前三点基本上都是与容器相关或者是由容器扩展的。只有第四点受到了其他容器编排和调度厂商的诟病。任何分布式管理系统都会在每个主机上安装自己的代理，该代理将管理该节点上的应用程序进程。从这个功能上来看，它和Docker daemon是冲突的。操作系统的systemd可以忽略，但是如果要使用Docker容器，就离不开Docker守护进程。想象一下，如果你的老板让你管理一个团队，但任何管理指令只能由另一个人发出，你会感到不高兴吗？所以Docker和其他容器编排调度系统之间的冲突从一开始就埋下了伏笔。看来Docker团队一开始并没有考虑到这个问题。他们自己的Swarm也用了独立的agent，但是后来发现有点多余。将 Swarm 代理和调度程序构建到 Docker 守护进程中还不够吗？更重要的是，Docker守护进程本身已经支持远程API，而且这种设计仍然是无中心的点对点节点集群模式，使得部署和操作更加方便。所以Docker 1.12内置了Swarm（准确地说是SwarmKit）。只需几个命令，多个独立版本的 Docker 守护进程就可以变成一个集群。它还支持服务概念（多个容器实例副本的抽象）。 1.13 支持有了Stack（多个服务的组合）和Compose（编排定义文件）的概念，一个比较完整的编排调度体系已经基本形成。 此更改还表明与其他容器编排和调度系统的中断。本来，Docker是一种容器，大家基于容器构建编排调度系统，可以和平共处。容器相当于轮子，编排调度系统就是汽车。结果有一天，轮毂厂家表示，自己的几个轮毂直接拼接在一起，就形成了一辆汽车。奇怪的是，汽车制造商并不着急。这相当于发起了“降维攻击”。 有了编排调度系统，Docker推出Store也就顺理成章了。大多数服务器端应用程序都不是单个节点或进程的应用程序，而是需要多个服务的组装。大家一直在寻找一种方法来实现服务器端应用程序的一键安装和部署。 Docker应用程序打包编排文件和镜像定义，配合编排调度系统提供的标准环境，然后使用Store作为应用程序分发。意图非常明确。不过，我觉得Docker迈出这一步有点仓促了。目前的编排调度系统尚未成熟，急于推出更高级别的应用可能会阻碍后续的演进，但这应该也是商业化压力造成的。 当然，Docker在做出这个决定时面临着巨大的挑战。容器生态系统的碎片化，让Docker能够靠自己重塑自己的生态系统。 Docker推出的容器网络标准（libnetwork）并没有被其他厂商接受，其他厂商也在减少对Docker的依赖（后面详细分析会提到）。 Swarm 还不够成熟，无法在生产环境中使用。其网络目前只支持overlay，尚不能支持自己的网络插件标准，编排文件也不够完整。存储方面，去年Docker收购了Infinit（我关注Infinit很久了，一直号称开源，但是还没等源码出来就听到了被收购的消息）由 Docker 开发），一家分布式存储公司。如果说2017年Docker解决了网络和存储两个分布式系统的痛点，那么Swarm的前景还是被看好的。 作为一名开发者，我其实很喜欢Docker的这种设计，虽然推出的有点晚。这种模式与开发团队逐渐接受容器的趋势相一致。例如，可以先使用Docker作为产品包管理工具，网络使用host模式。这种方法与在主机上维护和部署多个应用程序进程没有什么不同，只不过它接管了依赖项和安装包的维护。那么，当开发流程的打包机制转变，开发者的习惯逐渐改变的时候，就可以引入Docker的网络解决方案了。首先，应用程序可以改造为直接通过容器网络进行通信，但部署和调度将继续使用原来的模型。当所有这些改造完成并且运维成熟后，开启Swarm模式，将应用程序的部署和调度交给Swarm，基本完成应用程序的容器化改造。就像坠入爱河一样。首先，你们约会并牵手，然后（这里省略几句话），然后你们谈论婚姻，考虑是否做出终身承诺。至于其他编排系统，一上来就要求用户回答：你准备好把一切交给我和你的余生了吗？很多人不得不犹豫。综上所述，今年的Docker已经不再是原来的Docker了。它代表了一个容器解决方案、一个系统软件、一个商标、一个公司、一个容器编排调度系统。集装箱大战才刚刚开始，三大支柱相互对立，胜负未知。但无论最终结果如何，Docker这个初创公司都是从开发者工具起家的。短短三年时间，就风靡全球技术圈，搅动了整个服务器端技术栈，进而进军企业应用市场，带领用户对抗巨头。这是前所未有的。在传统企业市场，大部分决策权掌握在不懂技术的领导者手中，因此解决方案是否对开发者友好并不是关键点，但从 Docker 以及最近的一些国外公司的案例来看（例如如slack、twilio等），这种现象正在改变，这说明开发者群体正在成熟，话语权增大。企业应用对开发者的友好程度将成为竞争的关键点。 库伯内斯 当我在2015年底分析Kubernetes架构时，1.2版本还没有发布。目前1.6 beta版本已经发布。去年对于 Kubernetes 来说是爆炸性的一年，这可以从社区文章和聚会中看出。有很多文章迫不及待地宣布 Kubernetes 正在赢得容器之战。 Kubernetes的优势在于很多概念抽象与理想的分布式调度系统非常一致。即使你自己重新设计这样一个系统，经过不断的优化和抽象，你最终会发现它必然更接近 Kubernetes。比如Pod、Service、Cluster IP、ReplicationController（新称为ReplicaSets）、Label，以及通过Label自由选择的选择器机制，以及去年推出的DaemonSets和StatefulSets。 DaemonSet用于定义需要部署在每个主机上且不需要动态迁移的服务，例如监控服务。这个概念在Swarm中还没有被引入，但它也可能使用其他的实现方式，比如插件机制。组件调度系统的代理扩展可以通过DaemonSet定义的服务来理解。StatefulSets（1.5版本之前称为PetSets）主要是为了解决有状态服务部署的问题。它保证了 pod 唯一网络标识符（主要是 pod 的主机名，IP 是否可以保持不变取决于网络实现）的稳定性，不会随机变化。它会因 Pod 迁移和重建而发生变化。它还支持PersistentVolume规范，并封装了现有的分布式存储和IaaS云存储接口。 网络方面，Kubernetes推出了CNI（Container Network Interface）网络标准。这个标准比较简单。它只是同意调用命令的参数。如果想要扩展自己的实现，只需要编写一个命令行工具放到系统路径下，然后根据CNI调用的参数给容器分配一个网络即可。您可以使用任何语言实现。它与 Kubernetes 基本没有耦合，因此可以很容易地被其他调度系统（例如 Mesos）采用。 从Kubernetes的演进可以看出，Google对Kubernetes的期望在于标准制定，而核心点在于描述能力。官方文档什么是 Kubernetes？有这样的描述： Kubernetes 不仅仅是一个“编排系统”；它消除了编排的需要。 “编排”的技术定义是执行已定义的工作流程：先执行 A，然后执行 B，然后执行 C。相比之下，Kubernetes 由一组独立、可组合的控制流程组成，这些流程不断地将当前状态驱动到所提供的所需状态。如何从 A 到达 C 并不重要：就这样吧。 它的目标不仅仅是一个编排系统，而是提供一个规范，允许您描述集群的架构并定义服务的最终状态，这有助于您的系统实现并维护这种状态。这其实和Puppet/Ansible等配置管理工具的目的是一样的。但配置管理工具只能实现某种状态，而无法维护它（没有动态伸缩和故障迁移等调度能力）。同时，配置管理工具还具有较低的抽象级别。之所以选择容器，很简单，因为容器更容易减少主机和应用程序之间的耦合。如果有其他技术可以实现这一目标，如果支持的话，其定位也不会受到影响。因此，Kubernetes去年推出了CRI（Container Runtime Interface）容器标准，进一步将Kubernetes与具体的容器实现解耦。一方面是对Docker内置Swarm的对策，另一方面也是其目标演进的必然。 正因为如此，它已经把很大一部分功能转移到了IaaS云上（比如网络、存储），并不急于推出具体的解决方案或者兼容现有的各种分布式应用。它已经发布两年多了。专注于规范定义和系统优化。 Kubernetes出身于知名家族，所以我们不用担心商业化的问题。我们女人不用为结婚而烦恼，也不需要迎合别人。自然有人会适应我们。 当然，理想是美好的，但现实是，已经有大量的分布式系统重复实现了 Kubernetes 已经实现的很多功能，或者说集群机制并没有被 Kubernetes 目前的抽象概念所涵盖。目前，在 Kubernetes 上运行这些系统仍然是一件困难的事情（比如 redis 集群、hadoop、etcd、zookeeper、支持自动主从切换的 mysql 集群等），因为任何抽象都是以个性化和专业化为代价的。特别是之前分析Kubernetes时有人反驳了我的说法。我并不是说像zookeeper这样的服务不能运行在Kubernetes上，而是说它很难实现一键部署、自动伸缩、自动更改配置。很多情况下还是需要手动访问，比如官方的这个zookeeper例子。 为了解决这个问题，CoreOS引入了Operator的概念，专门针对目前Kubernetes抽象不易描述的服务（有状态服务或特殊集群服务）提供了一个Operator。算子通过调用Kubernetes API来实现伸缩和恢复。 、升级备份等功能。虽然这与 Kubernetes 的声明式理念相冲突，无法直接通过 kubectl 进行操作（kubectl 有提案支持插件机制，这个需求未来可能会通过插件来实现），但目前来说是一种可行的做法。 （注：本文发表后，CoreOS的李翔更正了该算子的描述，该算子是基于Kubernetes的Third Party Resources方法进行扩展的，可以通过kubectl操作，特此更正） 另外，在大数据支持方面，Kubernetes 与 Mesos 还存在差距。去年，Kubernetes 支持了工作概念。作业生成的 pod 执行后会立即退出。原来的service可以理解为一个无限循环的job。这样一来，Kubernetes具备了分发批处理任务的能力，但仍然缺乏上层应用接口。理论上来说，将Hadoop的MapReduce移植到Kubernetes上，用Kubernetes来替代底层的Yarn资源调度功能也是可行的（只是一个想法，没有具体分析）。有一个项目打算整合Yarn和Kubernetes，但已经很久没有更新了。我对两者的融合不是很乐观。两个系统冲突严重，处于替代关系，不像Mesos和Kubernetes的整合（本文后面关于Mesos的段落会分析）。 Kubernetes一直因部署复杂而受到诟病。当我在 2015 年进行测试时，部署 Kubernetes 集是一项非常复杂的任务。去年，Kubernetes推出了kubeadm，大大降低了部署的复杂度。目前，除了 kubelet 需要直接在主机上启动外，其他 Kubernetes 组件都可以由 Kubernetes 自己托管，一定程度上实现了“自举”，但易用性与 Swarm 相比还有差距。 随着 Kubernetes 的成熟，其他供应商开始制作自己的发行版，例如 CoreOS。CoreOS最初的容器思路应该是通过自己定制的容器操作系统和etcd将多个CoreOS主机合并成一个集群，然后使用修改后的systemd充当代理，并在上面添加一个调度器来实现容器的编排和调度。 ，也是一个可行的想法。既然单机的服务进程管理可以通过systemd来完成，那么连接多台机器的systemd不就成了分布式服务进程管理了吗？但后来策略发生了变化。估计采用这个方案的成本太高了。高（用户需要同时改变自己的主机操作系统和应用部署习惯），所以目前的容器策略改为定制Kubernetes，推出tectonic，CoreOS更名为Container Linux（可能是为了避免产品和公司名称重叠）并且还透露出的一个信息是产品重心发生了变化），以主机操作系统为中心（这个会在后面操作系统部分进行分析）。 总结一下，经过一年的快速发展，Kubernetes 基本上已经非常完善了。原始 kube-proxy（1.2 版本之前）的性能问题也已得到解决。建议原本处于观望状态的用户可以加入陷阱。不过，就应用的最终封装定义而言，Kubernetes尚未推出自己的解决方案。目前尚不清楚这是计划正式实施还是留给分销厂商，但可以预计相关解决方案将在2017年推出。 梅索斯 如果说 Kubernetes 是为标准而生，那么 Mesos 就是为资源而生。其理念是： 定义一个最小的接口，以实现跨框架的高效资源共享，并将任务调度和执行的控制权推送给框架 定义一个最小接口来支持跨框架资源共享，将其他调度和执行工作委托给框架本身。 换句话说，它的视角是资源视角，它的目标是资源共享。这和Kubernetes的目标其实是同一件事的两个方面，一个是从定义和描述的角度，另一个是从资源的角度。 Mesos其实是最早进入容器领域的，但其容器封装比较简单，仅用于简单的资源隔离，用户普遍对其没有认知。Docker推出后，也推出了Docker，但正如我之前分析的那样，Docker在Mesos上一直有点尴尬，所以Mesos（准确的说是mesosphere DC/OS）构建了一个Universal容器，提高了原有Mesos容器对Docker镜像格式，使得用户可以在自己的开发环境中使用Docker，而在生产环境中可以直接切换到Mesos自己的容器。虽然可能会存在一些兼容性问题，但图像格式的这种变化并不算太快，问题还在可控范围内。 这也从另一个侧面说明，Docker镜像格式已经基本成为事实上的标准。一个容器解决方案能否渗透整个生态，关键在于是否支持Do​​cker镜像格式。当然，Mesos成员实际上对此有些抵触。在一些分享中，他们强调Mesos还支持其他类型软件包格式的部署，比如gzip等。特别是在大规模服务器场景下，从Docker仓库拉取镜像存在瓶颈。我个人并不同意这一点。在大型服务器场景下，从任意中心节点拉取任意格式的安装包都会出现问题。这就是 Twitter 分发 p2p 安装包的原因，但 Docker 镜像也可以 p2p 分发，只要有需求。 ，一定有人能够弄清楚。 在容器网络方面，Mesos最初的网络解决方案是端口映射。应用程序需要修改以适应Mesos，对应用程序侵入性大，通用性差。因此Mesos支持Kubernetes发起的CNI网络标准，解决了这个问题。 通过框架机制，Mesos接管了现有分布式系统的部分功能，使得多个分布式系统共享同一个资源池成为可能。容器编排只是 Mesos 上的一个应用程序（Marathon）。这种方法的优点是它使得集成复杂的分布式系统成为可能，因为该框架是一个编程接口并且非常灵活。很多在 Kubernetes 上不易运行的复杂应用可以在 Mesos 上运行，比如 Hadoop 等一系列与大数据相关的应用。因为 Mesos 和 Kubernetes 的目标是完全一致的，而且它们的能力也可以互补，所以很早就有人想将 Kubernetes 和 Mesos 集成起来，在 Mesos 之上运行 Kubernetes。这样，Kubernetes就可以接管容器编排和调度，取代Marathon，而Mesos可以解决其他问题。复杂的分布式应用程序实现多个应用程序之间的资源共享。然而，kubernetes-mesos 项目后来就不再活跃了。一方面，Kubernetes 变化太快。另一方面，中层可能发现与 Kubernetes 的竞争大于合作。后来IBM搭建了一个kube-mesos-framework，放到了Kubernetes孵化器中，但是还没有正式投入使用。我个人觉得，如果要真正融合得好，Kubernetes和Mesos都需要进行很大的修改。然而，这个项目对于生态系统来说是一个很大的改变，可能会打破三足鼎立的局面。 Mesosphere的DC/OS开发了基于Mesos的分布式应用程序的封装规范。以前的应用程序版本只能发布独立操作系统的软件包。 Mesosphere通过Marthon、镜像和配置文件定义了一套分布式包规范。用户可以使用一个命令从存储库（repo）部署复杂的分布式包。应用于Mesos。这和Docker的Store思想类似。 总结起来，Mesos的优点就是高度可定制。它诞生于Twitter这样的互联网公司，在互联网公司中也比较流行。互联网企业的基础设施和系统大多是自己开发的，可以通过规范要求其应用程序适应调度系统。因此，对标准化和抽象能力的需求并不像资源共享那么强烈。它的缺点是周边生态比较复杂，接口和标准设计没有Kubernetes那么“优雅”。 牧场主 现在容器之上的编排系统已经成为三足鼎立，各有所长，还有其他的机会吗？兰彻尝试了另一种方法。它自己的定义是IaaS，基于容器的IaaS。首先，它通过容器降低了部署成本。每个节点只需要运行一条命令就可以部署Rancher系统，这与OpenStack等复杂的IaaS相比太简单了。其次，它的定位是专门运行容器编排系统的IaaS，上面可以一键部署Kubernetes、Docker Swarm、Mesos。容器编排系统仍然需要进行一些修改才能直接在物理机上运行，​​并且存在升级和运维问题。于是Rancher就出来了，希望抽象出一层非常薄的IaaS来解决这个问题。 想法是，既然三个公司之间存在争议，很难决定选择哪一方，所以最好选择Rancher。 Rancher一方面允许多个编排系统共存，另一方面降低了未来的切换成本。这个艰难的决定可以稍后做出。 此外，它还推出了自己的应用规范和应用仓库（App Catalogs）。其应用规范也兼容其他容器编排系统的定义文件，相当于容器编排系统应用的超集。这样基础设施相关的应用就可以使用Rancher自己的规范，而业务变化快、需要动态伸缩的应用可以放在容器编排系统中，以后切换也不会麻烦。 但Rancher的产品假设存在的问题是，如果未来容器编排调度系统由一家公司主导的话，它的存在空间会越来越小。 容器平台将走向何方？ CaaS、IaaS、PaaS、SaaS？ 有人将容器服务称为CaaS（Container as a Service），类似于当前IaaS平台上的数据库服务（RDB as a Service）。它是 IaaS 之上的新应用服务。但我个人认为CaaS其实是一个伪需求。用户需要的不是容器。没有人曾将 IaaS 称为 VaaS（VM 即服务）。容器服务提供的是运行环境，而不是具体的服务。 容器编排调度平台首先是为开发者提供的工具平台。它安排应用程序。这是和现在的IaaS最大的区别。现在的IaaS主要是给管理者和调度资源的，所以IaaS的入口主要是控制台。虽然有API，但使用命令式API的复杂度比声明式API大很多，而且API的使用者大多是运维工具，集成到业务系统中的使用场景很少。这是当前IaaS云的历史使命所决定的。上云的第一步是让用户将应用程序从自己的机房迁移到云端。只有提供一个能够完全模拟用户物理机房的环境（虚拟机模拟硬件支持全功能的操作系统、SDN网络、云硬盘存储），应用程序才会无侵入，用户的迁移成本更低。但当这一步完成后，用户会发现，虽然节省了硬件的维护成本，但应用开发和维护的成本并没有降低。他们意识到自己的本质需求不是资源，而是应用程序的运行环境。这个需求有点像PaaS，但是原始PaaS的问题是对应用程序侵入性太大，并且与开发语言绑定。可以直接部署的应用程序是有限的。用户需要的是一个更通用的PaaS，可以称为（Generic Platform as a Service），这个词是我创造的，是一个平台服务，基本上可以部署任何复杂的应用程序，而容器平台可以承担这样的责任。 尽管容器平台有各自的历史背景、侧重点和解决方案，但它们的最终目标是一致的，那就是屏蔽分布式系统的资源管理细节，为分布式应用提供标准的运行环境，并为分布式应用定义一个包，为开发者降低分布式系统的开发成本，为用户降低分布式应用的维护成本，为厂商降低分布式应用的分发成本。总结起来，其实就是DataCenter OS或者Distributed OS。虽然DC/OS这个术语已经被Mesosphere用于自己的产品，但我个人认为这是所有容器平台的最终目标。当然，很难说这波容器是否真的能实现这个目标，但至少现在看来是有希望的。 因此，PaaS 将成为 DCOS 之上的 DevOps 工具堆栈。目前，很多PaaS平台都在朝这个方向发展。 IaaS成为为DCOS提供运行环境的服务，DCOS接管上层应用和基础服务。当然，在IaaS之上还有其他SaaS模式的服务（因为SaaS和PaaS的扩展没有被精确定义，所以在很多场景下，SaaS模式为开发者提供的中间件称为PaaS组件。我的理解是多个组件是通过软件实现，租户和完全按量付费的服务应该都属于SaaS，比如对象存储，这个需要详细解释，可能需要另外一篇文章，所以就不详细分析了这里）。 SaaS模式的资源利用率最高，用户成本最低。 ，用户一般不会用独立部署的服务来替代。这样，模式就变成了用户在IaaS之上部署一套DCOS。需要独立部署的业务以及自己开发的业务都运行在DCOS中。首先使用可以抽象为标准 SaaS 服务的其他中间件。由 IaaS 提供。相当于IaaS将独立部署的基础设施服务和用户自己的服务的部署和调度转移到DCOS上。当然，最终IaaS本身直接变成一个多租户的DCOS也不是没有可能，从调度资源到直接调度应用。但调度层将面临巨大压力，数据中心支持的节点也将受到限制。 ，暂时看来还是两层调度比较可行。 这对整个IaaS影响很大，所以有人说对AWS的威胁可能不是Google Cloud，而是Kubernets（DCOS）。但即使DCOS成熟，最终如何商业化仍存在很大变数。大家理想中的像苹果AppStore这样的服务器端应用市场最终会由DCOS、SaaS或者IaaS服务商提供吗？ DCOS的优势在于掌握了标准，可以定义应用规范，而SaaS服务提供商的优势在于直接面向最终用户。用户可能占据企业应用的入口。 IaaS服务提供商的优势在于他们控制了应用程序的运行环境，这在计费模型和反盗版方面具有很大的优势。但在私有云领域，IaaS产品将面临DCOS更大的冲击。在私有云领域，如果多租户隔离的需求不是那么强烈，部署一套DCOS是一个更简单、更高效的选择。 容器与虚拟机之战 自从Docker技术流行以来，容器与虚拟机之间的争论就从未停止过。但去年，大家的注意力逐渐转移到了上层，容器与虚拟机的争论终于落下帷幕。这主要是因为容器本身的外延正在发生变化。 容器，首先，不是一个技术词，它是一个抽象的概念。顾名思义，它是一个用来存放东西的容器。里面应该填什么？应用。 事实上，J2EE领域很早就使用了容器（Container）的概念。 J2EE 服务器也称为 Web 容器或应用程序容器。其目标是为Java Web应用程序提供标准化的操作环境，以方便开发、部署和分发。这种容器是平台绑定的。 Linux容器自问世以来就是一组进程隔离技术的统称。随着容器领域的竞争和演进，Kubernetes的OCI（Open Container Initiative）标准推出，Docker、Unikernels、CoreOS的Rocket、Mesos的Universal Container、HyperContainer（基于VM的容器解决方案）等百花齐放。容器的概念逐渐清晰起来，我们可以在这里做一个定义： 容器是应用程序流程的标准化封装。无论是使用Linux的cgroup命名空间技术还是虚拟化hypervisor技术来做这种封装，都不是关键。关键是目标。容器是为应用标准化而生的。 也就是说，最早，大家认为容器是和虚拟机一样的一种隔离技术，所以会拿容器和虚拟机做比较，比较二者的隔离成本，隔离安全性，但现在容器的外延变了，和传统虚拟机的本质差异不在于封装技术，而在于封装的目标，传统虚拟机封装的目标是操作系统，为操作系统提供虚拟化硬件环境，而容器封装的目标是应用进程，其中内嵌的操作系统只是应用的依赖而已。 另外一方面，基于虚拟机的调度系统，比如 OpenStack，也可以将容器作为自己的调度系统的 compute_driver，也就是将容器当虚拟机使用，用来降低虚拟机的隔离成本。所以容器与虚拟机之争本质上是调度理念之争，而不是隔离技术之争。 容器对操作系统的影响 Docker 没出现之前，服务器端的操作系统基本是传统 Linux 大厂商的天下，Ubuntu 好不容易通过自己的桌面版的优势赢得一席之地，一个创业公司试图进入这个领域基本是没有机会的，但 Docker 的出现带来了一个契机。这个契机就是一个操作系统需要考虑自己的目标是管理硬件还是管理应用。如果是管理硬件，也就是运行在物理机上的操作系统，目标就是提供内核，管理好硬件(磁盘，网络等)，而应用层的事情交给容器，这样硬件层的操作系统不需要考虑各种应用软件栈的兼容问题，降低了操作系统的维护成本。如果是管理应用，那就可以放弃对硬件层的管理，专心维护软件栈。所以这个领域能冒出几家创业公司的产品试水： CoreOS 的 Container Linux 以及 Rancher 的 RancherOS 这两个 OS 的主要目标都是接管硬件，将主机操作系统从复杂的软件栈中解放出来，专心管理硬件和支持容器。传统的 Linux 操作系统为维护上层软件栈的兼容性付出了巨大的成本，发行版的一个优势在于提供全面软件栈的兼容性测试。而当二者解耦后，这个优势不再，竞争的核心在于能否提供更好的支持容器以及系统和内核的升级。 Alpine Linux 这个精简后的 Linux 发行版则是专注于维护软件栈，给容器内的应用提供运行环境。所以它可以做到非常小，默认只有几M大小，即便是包含 bash 进去，也只十多M。所以 Docker 官方默认以它作为镜像的基础系统。 操作系统的演进和更替是一个长期的工程，基本上得伴随着硬件的淘汰，所以至少五到十年的演进，着急不得，但可以期待。 关于技术类创业的思考 技术类创业，要思考清楚自己的机会是在市场还是在技术生态圈里占领一席之地。当然前者要比后者容易，后者最终也得变为市场的应用才能盈利，而即便是在技术生态圈中取得地位也不一定能找到商业模式，不过后者的潜力要大于前者。国内的创业一般倾向与前者，而国外则多倾向与后者，所以国内同质化的竞争比较激烈，而在差异化的生态构建方面则缺少建树。主要是因为国内的技术积累以及普及度和国外还有差距，还属于追随者，只有追随并赶超之后才会有创新，这个和 2C 领域的类似，2C 领域最近越来越少 C2C(Copy To China) 模式成功的案例了，2B 领域肯定还需要些年，不过感觉应该也不远。 个人认为，2017 年容器编排调度领域的竞争会上升到应用层面，DCOS 之上的多语言应用框架(比如 微服务框架，Actor 模型框架)，各种已有应用和基础设施的容器化，标准化，让已有应用变为云原生(Cloud Native)应用，等等。 当然，理想和现实之间是有鸿沟的。一波一波的技术变革，本质上其实都是在试图将开发和运维人员从琐碎的，重复的，无聊的任务中解放出来，专注于有创意的领域。但变革最难变革的是人的思维方式和做事习惯，以及应对来自组织的阻碍。你说云应该就是按需的，动态的，自服务的，但用户的运维部门就喜欢审批开发人员资源申请，于是云变成了一个虚拟机分配系统。你说资源应该动态调度，应用混合部署有利于提高资源利用率，但用户的安全部门要求应用的业务必须分层，每层必须需要部署到独立的服务器上，跨层调用的端口还需要申请。所以技术变革最后要落地成商业模式，首先要通过技术理念的传播去改变用户的思维方式以及组织体系，当然这肯定不可能是一蹴而就的，是一个长期的，反复过程，其次要等待业务需求的驱动，当业务增长导致软件复杂度到一定规模的时候，自然会寻求新技术来解决复杂性。 结语 写了这么多，有人会问，我还是没能确定到底选择哪一家合适啊?未来是不可预测的，但是可以创造的。当你做出选择的那一刻，你希望的未来就向你靠近了一步。 本文由作者首发[高可用架构] 【本文是51CTO专栏作者“王渊命”的原创文章，转载请联系作者本人获取授权】 戳这里，看该作者更多好文