编者按

2015年，整个IT技术领域发生了许多深刻而又复杂的变化，InfoQ策划了“解读2015”年终技术盘点系列文章，希望能够给读者清晰地梳理出技术领域在这一年的发展变化，回顾过去，继续前行。

回顾2015年容器技术的发展历程，我们可以用两个关键词来概括：扩张与进化。

如果说2014年仅仅是Docker为主的容器技术在云计算以及DevOps圈初露锋芒的话，那么2015年则是以Docker为核心的容器生态圈迅猛扩张的一年。这种扩张的态势，一直从2015上半年火爆的DockerCon蔓延到了2015年的最后一天。伴随着容器技术快速发展的过程，国内外的技术人员有幸亲历了OCI、CNCF两大标准组织的确立，第一时间体验了Docker 1.8和1.9两大关键版本的发布，见识到了CoreOS一系列关键技术革新与战略布局，也感受到了国内Docker创业圈的如火如荼。

国外容器技术项目

在2015年，一直以“善意独裁”面孔示人的Docker公司终于迈出了合作的第一步。OCI组织的成立宣告了工业界对Docker提出的容器技术的高度认同，也暗含了后进场玩家试图从这个由startup开创的新领域中分得一杯羹的决心。然而runC项目运作到现在，依然没能够进入Docker Daemon的实现主干，也没有任何巨头发布以runC为基础的新容器实现。Docker而不是runC被用户当作容器技术的事实标准的现状在短期内（1-2年）恐怕还很难发生本质改变。容器技术领域多样化的任务目前还是落在直接竞争对手CoreOS，以及另辟蹊径的虚拟化容器技术比如Hyper和Intel Clear Linux身上。但是无论如何，诞生于startup的Docker容器注定要经历更多的考验才能在巨头林立的云计算领域真正地扎根生长，无论其是否愿意，将容器技术标准化是这条道路上必须面对的选择和进化方向。

另一方面，Docker公司这种独一无二的亲和力和号召力正是2015年Docker为主的容器生态圈版图迅速扩张的主要基石。当然，既然是扩张，这张容器生态圈版图的背后也必然少不了大小领主“封地”的确立和斗争。

2015年，Google和RedHat联盟以Kubernetes 1.0为阵地宣告了大规模容器编排与管理领域的领主地位。号称以Borg等Google多年容器技术实践经验为理论指导、以Google和RedHat PaaS团队为主要工程力量的Kubernetes项目一经宣布生产级别可用，便立刻吸引了的工业界乃至学术界的大量关注和投入。尽管不是第一家，但是我们不得不承认Google的号召力和Kubernetes不凡的背景直接推动了CNCF这一容器编排管理标准组织的诞生。在技术方向上，Kubernetes团队则试图以Kubernetes为依托来对外输出Google的容器技术的思想和经验，或多或少有点要弥补LMCTFY项目中途夭折的意思。无论如何，Kubernetes所体现出的前瞻性的容器技术实践思路，确实值得我们每一个容器技术实践者重点关注和学习。无论是Pod及伙伴容器、单Pod单IP网络模型、volume插件机制、容器生命周期钩子这种对容器技术本身的改造，还是虚拟IP与负载均衡、垂直健康检查、密码数据卷管理、元数据API等平台级别能力的实现，都展现出了Kubernetes与其他编排管理项目与众不同的技术视野和团队实力。在未来发展方向上，Kubernetes已经开始向1000+节点的集群规模进发，毕竟在性能和规模化领域，Kubernetes没有理由落后竞争者太久。另一方面，除了常规的long time running任务，其他类型任务比如短任务和daemon任务的支持都已经引入了项目主干，类似big data业务的支持将是未来的一个重要方向。

在与Docker”分手“之后，CoreOS一直在积极地寻求展示自己技术想法的机会，包括加入OCI组织以及在Kubernetes上同Google开展深度的合作。鉴于OCI最开始只关注于container runtime的实现标准，CoreOS的AppC一直在积极推进镜像标准的概念。目前这个标准已经在Kubernetes上初见雏形。最值得关注的是，CoreOS还在0.8.0版本发布时高调宣布了同Intel Clear Linux团队合作在rkt上实现了基于虚拟化技术隔离的容器（这与国内的Hyper团队的做法不谋而合，只不过后者是在Docker上做出的类似实现）。这种hypervisor-based container是目前在公有云上提供容器服务最佳选择，CoreOS在容器安全和隔离性问题上进行本质革新的做法的确很有说服力。而在容器编排管理领域，CoreOS公司将Kubernetes组件内置到CoreOS项目中作为主要的底层依赖之一。Etcd的作者目前也正在Kubernetes社区积极推进项目整体性能提升和调度效率优化的工作，毕竟作为整个项目的核心依赖，Etcd的作者们有足够的理由和能力承担起Kubernetes性能提升的重任。这一点上其他容器管理项目可能要稍微眼红一下了。

而在另一边，Mesosphere公司借助在资源调度管理领域与生俱来的优势，在2015年成功开拓出了一片以DCOS为核心、兼顾大数据和应用托管的服务平台市场。Apache Mesos项目原生的两级调度和多框架支持使得用户在自己的组织内部设施云计算平台终于变得唾手可得。尤其是在传统技术型企业转型互联网架构的过程中，Mesos生态圈能够非常方便的在企业内部迅速实现一套原本在一线互联网公司中都算得上“黑科技”的资源调度管理平台，然后快速搭建起PaaS和BigData服务。尽管Mesos原生并非针对容器设计，Mesosphere所提供的诸如Marathon等上层解决方案也明显在成熟度和技术实现上有着这样那样的不足，但是不得不说Mesos生态体系目前是企业自建私有云最快速、最有利于展示POC的一套技术方案。鉴于Mesos本身较难只针对Docker进行根本性的改造，Mesosphere生态圈目前依赖于Marathon等上层项目来响应Docker容器技术的快速发展，在这种形势下，一组包含了用户生命周期管理、多维度监控、整合大数据业务管理等功能的完善的PaaS很可能是这些上层框架的最终形态。

当然，最后一定要说的就是Docker公司了。在进入2015年之后，雄心勃勃的Docker公司在Docker源码层面开始了大规模的重构，将原先仓促发布的很多模块进行了统一的抽象和整合，使得在1.9版本彻底解耦Volume和Network成为了可能。另一方面，Docker公司加紧了自己在组建生态圈闭环上的战略布局，这一点以年末收购Tutum为2015年画上了圆满的句号。之所以强调这一点，是因为Docker之前的收购对象都是在某一领域具有独创性的公司或团队，比如容器编排上的Fig，容器网络上的SocketPlane，而Tutum虽然在Control Panel以及产品化上做的很早很出色，但是类似的竞争者却不在少数且产品能力也很强，更何况Docker公司自己在这一领域已经有所动作。所以Tutum最终胜出的确是自身技术和产品实力的最有力证明。

在技术路线上，Docker把同runC的集成列到了高优先级任务上，并且已经为之做了大量重构工作，但是奈何daemon同libcontainer的交互过于繁杂，此项工作进展一直缓慢。好消息是Docker在年末发布了Containerd项目来专门负责同runC进行交互，此项目最终会进入Docker Engine主干从而间接实现Docker同libcontainer的解耦。一旦这个目的达成，Docker daemon的复杂度会大大降低，性能也很可能得到大幅提升，更重要的是届时容器开发者将有能力定制自己的daemon，在容器端加入定制化的功能和特性，这才是runC项目的真正意义和玩法，非常值得期待。Docker公司在2015年的另一个大动作便是1.9版本的发布终于完成了存储和网络功能的解耦，使得用户可以以插件的方式提供第三方存储和网络功能来支持远程数据卷和跨主机网络。

但是需要提醒读者的是，无论是网络还是存储，这些插件方式的工作原理与非插件方式并没有本质区别，Docker并没有能力也没有理由提供任何优化。所以在这一点上，普通用户在前期阶段需要寄希望于社区里的插件开发者的能力和技术水平不要太低。因为笔者前面的经验表明即使是Docker官方比如SocketPlane提供的网络方案，在稳定性、可用性上也没有特别值得表扬的地方，建议用户保守上线该功能，必要时自己按需开发插件。“Docker之心，路人皆知”。这家已经在云计算领域掀起革命的startup背后的野心之大，的确配得上目前它在轻量级应用容器界的号召力和绝对地位。在未来的发展方向上，有如下几个方向上的进化是一定会发生的：

1. Docker Engine的进一步模块化和解耦，最终用户一定可以选择使用其中的一部分来达成自己的目的
2. runC全面取代execdriver来执行容器
3. 更丰富的插件能力和以此为基础的数据卷管理能力（类似Flocker）

在容器编排与管理领域，Docker已经构建出了Compose+Swarm+Machine的技术闭环，这套技术栈的最大亮点是全面兼容Docker API。当然，这个优势的前提是目前Docker而不是runC仍然是业界公认的容器标准。在这个领域，Docker目前选择了重点照顾用户友好度而适当放弃性能和规模能力的路线，毕竟在兼容Docker API的前提下引入更复杂的编排、调度和管理能力是比较困难的。这也是为什么Swarm现在正在推进同Mesos集成以提高调度方面的性能和可扩展能力，虽然笔者认为这个路线可能并不太友好(想象一下宿主机上同时运行着Docker dameon，Swarm agent和Mesos Slave的场景）。

总之，Docker目前在容器界的领导地位已经毋庸置疑。一系列产品和技术布局的完成也确立了Docker公司在这一由它自己开拓的疆土上的霸主地位。接下来，如何在不甘心的巨头们设置的规则丛林里生存、壮大并且健康发展下去，甚至达成Linux项目的创举，则是考验这家已经创造了一个不小的奇迹的初创团队真正实力和水平的难题。

国内容器技术圈

与国外相比，以Docker为主的容器技术在国内的发展势头甚至要更猛烈一些，其中部分原因是因为2014年以前的PaaS风潮没能够在国内掀起本质上的变革，使得国内云计算圈子在除了IaaS之外的领域颇有点一筹莫展的感觉。在这层意义上，Docker容器技术的诞生和普及绝对起到了久旱逢甘霖的效果。容器创业组织雨后春笋般萌发，不少团队的背景也跟经典PaaS领域息息相关；另一方面原先经典PaaS从业者的转型到容器创业领域的也不在少数。所以目前国内Docker创业项目的产品形态，有一部分延续了原先PaaS项目的产品路线（尤其是Cloud Foundry），比如：

1. 重点关注应用生命周期管理
2. 强调应用访问和域名绑定
3. 纳入Docker的部分概念比如数据卷和镜像
4. 对用户屏蔽网络、存储和调度细节
5. 将数据库等应用依赖抽象成”服务”

而另外一部分则选择了稍微偏向通用化的产品形态，这类项目一般会强调自己为CaaS（Container as a Service），例如:

1. 更多地对外暴露Docker容器各类概念
2. 强调容器的IP而不是域名
3. 不区分应用和它所依赖的“服务”
4. 强调直接运维容器而不是应用

这种类型的创业组织提供出来的更类似基于容器的IaaS，意在给用户更大的自由度和发挥空间。当然，无论哪种形态，大家一般都会把CI/CD流程的支持纳入到自己的主要产品体系，毕竟这是Docker最受大家认同的一个场景；而且各家产品也都在功能上互相渗透，其实并没有一个非常明确的边界。从这个角度出发，当前的大多数创业组织的产品在大方向上会逐渐趋同，毕竟Docker本来的发展路线也是淡化云计算的分层理念，变轻，变薄。然后在小方向上营造差异化，比如有的组织会选择构建各类开发者工具形成产品链，有的会选择在Infra层面提供更优质、廉价、可靠的计算和存储资源（比如SSD，高效的调度策略，最大程度压榨IaaS层利用率，甚至提供基于虚拟化技术的容器以彻底解决安全和隔离性问题）。总之，目前国内容器创业圈子产品能力优秀，相比之下即使是刚刚被Docker收购的Tutum恐怕在这一领域也没有太多优势；但是创新能力稍显不足，各个技术和产品点都是跟随者，尚没有展现出自己独有的优势。

2015年国内容器技术圈的另一大事件便是巨头的跟进。各类互联网甚至传统技术企业在自己内部进行容器的规模化应用的案例早已不是新闻，而阿里云，阿里百川TAE，新浪SAE，网易等诸多厂商也都在2015年开始对外提供或基于容器提供云计算服务，我们相信还有更多的团队还在酝酿中。一般来说国内的AE类型的厂商（TAE SAE BAE）会优先选择提供PaaS类型的产品，原先的IaaS厂商则更愿意提供容器云服务。不管是哪种形态，国内容器服务的热度值的确做到了另前来布道的Docker、Google的老外们都惊叹不已的程度。但是稍微另笔者担忧的是，这种热度的发展，可能会过早的将国内容器技术提供商拖到价格战的泥潭，届时大家过早停滞技术和产品的打磨而开始拼价格、拼渠道、拼运营，长远来看可能并不利于国内容器圈子的发展。

关于传统PaaS和IaaS

国内容器技术热火朝天的背后，或多或少反衬出了传统PaaS和IaaS提供商的些许落寞。而事实上，传统PaaS和IaaS厂商在2015年依旧取得了不菲的成绩，仅以Pivotal Cloud Foundry为例，其商业产品已打入了大量国际一线制造业和金融业巨头，仅其中某一个大客户的日均运行容器数量恐怕目前尚没有哪家互联网公司能望其项背。就这一点而言，目前的Docker容器服务商恐怕在很长一段时间之后都很难出现这种规模和高质量的客户案例。但是商业归商业，开发者归开发者，Docker为主的容器技术掀起的风潮起始于一线技术人员，也风靡于一线技术人员，这与商业产品的成功路线本质上就是不同的。这也正是为什么很多PaaS和IaaS厂商2015年甚至更早开始宣布支持Docker的最主要原因，OpenShift甚至完全转型基于Kubernetes进行彻底重构。但是无论如何，在关系更密切的开发者服务场景下，目前startup做的更好。

另一方面，OpenStack社区也在积极的寻求同Docker等容器技术的结合点来试图扩展一线技术人员这一不能忽视客户群，但是稍显遗憾的是哪怕是2015年被反复提及的Magnum项目都没有针对容器而对OpenStack本身做本质的改进和集成，项目依然是停留在调用OpenStack API然后把容器运行在VM里的程度。笔者认为，考虑到当前情况下虚拟机的不可替代性，OpenStack如果能够提供虚拟机和物理机上容器的统一调度，或者引入类似Hyper或者Clear Linux这样的虚拟化技术容器，进而提供任务优先级、抢占、混部等一系列数据中心级别的高级特性，也不失为一种进取的手段。仅就OpenStack社区目前的应对方案来看，仍然不足以解决开发者的目光被Docker吸引并且采用容器作为OpenStack替代方案的情况。当然，OpenStack无论是社区质量、规模还是产品、生态圈都不是现在的Docker所能挑战的，只是在社区层面对Docker以及容器技术的支持上做的还不够好。

总结

综上所述，2015年的容器技术圈，是各家施展手脚封疆划土的扩张一年，也是Docker以及容器技术生态参与者不断完善自己的进化一年。总的来说，尽管有不少亮点涌现，这一年的容器技术仍然处于厚积阶段，标准尚未达成，社区缺乏平衡，跟进者多创新者少。但是，我们也不得不考虑到很可能这才是容器技术发展的一种常态，而不是重复其他开源项目的发展模式。或许在未来，容器技术生态圈的参与者始终会保持着这种不断进化的姿态以应对瞬息万变的应用场景和捉摸不定的开发者意图，很难达成一种平衡或者稳定的状态。毕竟在容器技术这种无限贴近于每一个一线技术人员的特殊领域里，“唯有适者，才能生存”。

作者简介

张磊，浙江大学VLIS/SEL实验室云计算团队负责人，Kubernetes项目Collaborator。