解读2015之容器篇:扩张与进化

标签:容器

访客:15160  发表于:2016-01-19 11:03:57

解读 2015 之容器篇:扩张与进化

编者按:2015年 的容器技术圈,是各家施展手脚封疆划土的扩张一年,也是 Docker 以及容器技术生态参与者不断完善自己的进化一年。回顾 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 背后的野心之大,的确配得上目前它在轻量级应用容器界的号召力和绝对地位。在未来的发展方向上,有如下几个方向上的进化是一定会发生的:

Docker Engine 的进一步模块化和解耦,最终用户一定可以选择使用其中的一部分来达成自己的目的

runC 全面取代 execdriver 来执行容器

更丰富的插件能力和以此为基础的数据卷管理能力(类似 Flocker)

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

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

国内容器技术圈

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

重点关注应用生命周期管理

强调应用访问和域名绑定

纳入 Docker 的部分概念比如数据卷和镜像

对用户屏蔽网络、存储和调度细节

将数据库等应用依赖抽象成” 服务”

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

更多地对外暴露 Docker 容器各类概念

强调容器的 IP 而不是域名

不区分应用和它所依赖的 “服务”

强调直接运维容器而不是应用

这种类型的创业组织提供出来的更类似基于容器的 IaaS,意在给用户更大的自由度和发挥空间。当然,无论哪种形态,大家一般都会把 CI/CD 流程的支持纳入到自己的主要产品体系,毕竟这是 Docker 最受大家认同的一个场景;而且各家产品也都在功能上互相渗透,其实并没有一个非常明确的边界。

从这个角度出发,当前的大多数创业组织的产品在大方向上会逐渐趋同,毕竟 Docker 本来的发展路线也是淡化云计算的分层理念,变轻,变薄。然后在小方向上营造差异化,比如有的组织会选择构建各类开发者工具形成产品链,有的会选择在 Infra 层面提供更优质、廉价、可靠的计算和存储资源(比如 SSD,高效的调度策略,最大程度压榨 IaaS 层利用率,甚至提供基于虚拟化技术的容器以彻底解决安全和隔离性问题)。

总之,目前国内容器创业圈子产品能力优秀,相比之下即使是刚刚被 Docker 收购的 Tutum 恐怕在这一领域也没有太多优势;但是创新能力稍显不足,各个技术和产品点都是跟随者,尚没有展现出自己独有的优势。

2015年 国内容器技术圈的另一大事件便是巨头的跟进。各类互联网甚至传统技术企业在自己内部进行容器的规模化应用的案例早已不是新闻,而阿里云,阿里百川 TAE,新浪 SAE,网易等诸多厂商也都在 2015年 开始对外提供或基于容器提供云计算服务,我们相信还有更多的团队还在酝酿中。一般来说国内的 AE 类型的厂商(TAE SAE BAE)会优先选择提供 PaaS 类型的产品,原先的 IaaS 厂商则更愿意提供容器云服务。

不管是哪种形态,国内容器服务的热度值的确做到了另前来布道的 Docker、Google 的老外们都惊叹不已的程度。但是稍微令我担忧的是,这种热度的发展,可能会过早的将国内容器技术提供商拖到价格战的泥潭,届时大家过早停滞技术和产品的打磨而开始拼价格、拼渠道、拼运营,长远来看可能并不利于国内容器圈子的发展。

关于传统 PaaS 和 laaS

国内容器技术热火朝天的背后,或多或少反衬出了传统 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。

来源:36氪

解读 2015 之容器篇:扩张与进化

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");