开源和商业的结合，或许是容器生态更光明的未来

 

作者｜木环、易立

编辑｜小智

时至今日，IT 圈已经进化到开源与商业不再剑拔弩张的时代。

1 时至今日，没有人质疑容器技术的未来

现在，没有人会否认容器技术的作用与地位。2013 年 Docker 问世，热度迅速蹿升并被大范围使用，如此势头在开源界当属少见。

DataDog 连续三年发布 Docker 问卷调查，2017 年报告显示 Docker 的采用率上升 40%。



调查数据显示 2015 年起就有不少大型公司已经开始尝试使用 Docker，并且近 60% 的企业宣称使用 Docker 的机器规模超过 500 台，不过 100-499 台规模的使用比率也获得了显著上升。有分析认为 Docker 的出现在早期解决的是大公司痛点问题，而现在 Docker 正在寻求成为各类公司的通用平台技术。



Sysdig 调查了 4.5 万个企业，统计显示平均每台机器上会运行 10 个容器实例，甚至有企业在一台机器上启用 95 个容器实例。当 Docker 逐渐生产环境中不可或缺的部分之后，势必要寻求工具更高效地管理和编排这些容器。目前市面上被广为熟知的编排方案是 Kubernetes、Mesos、Amazon ECS、Google Engine 等，而 Docker 也推出了自己的原生系统编排方案。

2 Kubernetes  vs Docker Swarm 两股流派

Kubernetes 出身于谷歌，是其多年大规模容器管理技术的开源版本，在容器浪潮中完成了短时间内的迅速发展，是目前容器生态中最受欢迎的开源项目。项目于 2014 年 6 月首次亮相 GitHub，即 Docker 项目开源的一年多之后；项目已经被捐赠给 CNCF（Cloud Native Computing Foundation）组织，其目标是成为“跨集群的应用级别容器部署、扩展和运维自动化平台”，它会支持包括 Docker 在内的一系列容器工具。

而 Docker Swarm 则是 Docker 主推的原生的集群工具，意图让用户像使用单机 Docker API 一样来驱动整个集群。2016 年 7 月发布的 Docker1.12 把 Swarm 内置到 Docker 中，这种内置的做法引来了一些争议，有人认为这对 Kubernetes 和 Mesos 造成了一定的威胁。

在很多人眼里，Kubernetes 更开源、汇聚了更多的力量，而 Docker Swarm 则是 Docker 处于商业化的本心。这里，先抛开 Kubernetes 和 Docker 的历史背景，也不提两者社区背后曾经有过的争论；我们单纯从技术设计的角度来看看两者技术层面的差异。

1. 遵循的两种网络标准

在不同的用户环境中，如公共云、专有云、混合云中，容器的网络模型都有不同之处，为此容器平台提供了插件机制，来支持不同的网络实现。目前关于容器网络接口的配置主要有两种标准：容器网络模型（Container Network Model， CNM）和容器网络接口（Container Network Interface，CNI）。

CNM 由 Docker 主导，吸引了 Cisco、VMware 等公司的应用；而 CNI 更归属社区，被运用于 Mesos、Cloud Foundry、K8S 之中。

CNM 是 Docker 主导的网络方案，而且 libnetwork 和 Docker 原生编排等能力紧密集成在一起，内置的服务发现和负载均衡等能力对于开发者而言非常友好。但是正因如此，也对网络驱动的实现带来了一定挑战，在 Docker 17.06 中 Swarmkit 开始支持 node scope 网络，会简化一部分网络模型支持的复杂性。

CNI 是社区主导的网络方案，整个方案很简洁，只提供基本的网络管理和 IPAM 管理接口，同时和其他网络能力（如 DNS，负载均衡等）保持正交。好处是网络驱动容易实现，三方编排可以方便地控制网络接口和容器对象的生命周期。不足之处则是，编排系统需要集成多个方案才能完整解决用户的诉求，比如在 Kubernetes 中，DNS 和 Ingress 都是通过 addon 的方式实现的，这也为部署和维护引入和复杂性。

2. 两种设计的对比

CNM 是 Docker 提出的规范。Docker 引擎中的 libnetwork 是 CNM 的缺省实现，现在 CNM 已经被 Cisco Contiv, Project Calico,Weave 等项目所采纳。阿里云也提供了基于 CNM 的 VPC，MacVLAN 等网络驱动。CNM 提供了 Docker daemon 与网络驱动实现之间的控制接口。Docker 提供了原生网络驱动包括 none, bridge, overlay 以及 Macvlan/Ipvlan 等。除了 Linux 容器支持，Libnetwork 也推出了对 Windows 的支持。通过 CNM，Docker 也可以由第三方插件获得更多的网络驱动支持。

CNI 最早是由 CoreOS 提出的一个容器网络规范。已采纳该规范的包括 Apache Mesos, Cloud Foundry, Kubernetes 等。Flannel, Project Calico 和 Weave 等项目为 CNI 提供插件实现，阿里云也为 Flannel 项目贡献了支持阿里云 VPC 的实现。CNI 最近加入 CNCF 的官方项目。Docker/Moby 社区也会在 Containerd/Swarmkit 中提供 CNI 支持。

CNM 和 CNI 都提供了插件化的机制来提供网络支持的扩展性，也都支持多个网络驱动被同时使用，这些大大扩展了容器的灵活性和适用范围。

然而在设计细节上还是有很多不同，比如 CNI 目前只提供了基本网络管理和 IP 地址管理接口。

Docker libnetwork 是一套完整的容器网络方案实现，不仅提供 CNM 支持 network 驱动和 IPAM plugin，还包含了 DNS、负载均衡、IP Masq 等功能。下面会深入谈到其中的一些实现差异。libnetwork 和 CNM 可以让容器方便地支持多个网络接口，实现更加灵活和安全的网络拓扑。比如，在部署一个典型的三层应用架构（web 层、应用服务层、数据库层）时。web 层容器和数据库容器可以分属于两个隔离的网络，应用服务层容器则可以同时加入这两个网络。这样的网络模型会比把所有容器放置到一个网络更加安全，可以防止由于 Web 层漏洞导致数据库遭到直接攻击。libnetwork 代理了网络 plugin 的部分行为，避免 plugin 直接操作容器的 network namespace，其优点是可以仲裁解决不同驱动可能引起的配置冲突，如路由规则等。

Kubernetes 中的网络模型相对简单，并不需要 libnetwork 类似的冲突解决能力。比如，Pod 中容器共享相同的网络名空间，Pod 只支持一个网络接口等等。

同时这两种方案也在不断相互影响和互相融合，不少开源的网络方案同时支持 CNM/CNI 接口。

3 阿里云的容器服务打开方式

容器技术使用概况

去年阿里已经实现了电商平台核心业务（买家链路）全部容器化；今年则会实现全部业务应用的容器化，除了一些核心的数据库系统之外，主要应用和部分数据库将都完成容器化。由于买家链路交易流量大，需要具备弹性，这也是电商最痛的业务部分，所以容器化的改造是先从买家链路开始的。

选择 Docker 是因为它具备开源技术标准化、高效率、工具链丰富等优势。在拥抱 Docker 之前，阿里已经使用了五年多自研容器技术 T4，去年开始基于 Docker 容器技术来进行应用的交付和运维，为了适配阿里内部 IT 系统架构和运维方式做了大量的优化和定制。

时下 AI 的发展备受关注，阿里云展示了其容器服务对机器学习的支持，该解决方案可以持续观测用户机器学习的过程，在发生故障时进行快速修复。



除了对外提供容器服务支撑，阿里云容器服务团队还支撑阿里集团容器内部镜像仓库服务，提供集团内部的 Docker 镜像分发的基础设施。利用 Docker 容器技术，可以实现 IT 架构快速水平扩展和灾备恢复。比如双 11 时，即使有一个数据中心发生故障（比如地震或火灾等不可预知的灾难），要确保有能力在一两个小时内在创建一个的虚拟数据中心，这意味着需要迅速在云上创建数千台虚拟机，并部署完成对应的电商全部业务。

一方面，是 Docker 战略伙伴

2015 年 12 月开始阿里云在公共云上推出了容器服务：支持 Docker 原生编排技术，用户可以在云端复用已有的 Docker 镜像和编排模板；将容器技术和阿里云的存储、网络、日志、监控等能力整合；预置了容器化 DevOps 解决方案，简化持续集成和持续交付等。



去年容器技术公司 Docker 与阿里云宣布达成战略合作，当时宣布的合作包括三方面内容：阿里云平台提供 Docker Hub 在中国运营的基础服务；阿里云获得 Docker 企业版的销售权，为客户提供企业级支持和咨询服务；阿里云 成为 Docker 官方支持的云服务提供商。

其中 Docker Hub 国内服务已经在阿里云上海云栖大会发布。基于阿里云的数据存储和 CDN 能力， 加速从国内下载 Docker Hub 容器镜像的速度，并且会基于此陆续推出本地化服务，可以访问 www.docker-cn.comDocker 中国网站了解更多详情。



Docker 近来面向企业市场推出的 Docker Enterprise Edition（Docker EE）有几个不同版本 ；Docker EE Basic 对应原来的 Docker Engine CS， Docker EE Advanced 则对应为之前的 Docker Datacenter。其中 Docker 企业版也已经在阿里云市场发布。目前阿里云与 Docker 的合作可以总结为下面三方面：Docker 云服务对于国内开发者开服；对企业化产品的整合，包括技术和业务流程上的协同；对 Docker 技术在阿里云能力的集成。

在谈及前一段时间在圈内引起轩然大波的 Moby 项目事件时，阿里云容器负责人易立和阿里云容器服务产品经理汤志敏均此表达了赞同的观点。Docker 和 Moby 主要是为了区分产品服务和开源项目的名字。Docker 公司的逻辑是把 Moby 项目交给社区，模块化拆分则提供更多的灵活性，方便应用于不同的特定领域。其实容器领域适用范围很广，但是 Docker Engine 并不适合所有场景，对于嵌入式设备上、网络设备上等所谓的 IoT 等场景，现有 Docker Engine 会比较重，而基于 Moby 可以剪裁和定制自己的容器引擎。然而此次的改变没有与社区沟通好，引起了一些误解，但是未来应该带给容器生态带来更多的活力。

而另一方面，支持 Kubernetes，成为 CNCF 金牌会员

上个月， CNCF(Cloud Native Computing Foundation) 基金会宣布阿里云正式成为金牌会员，当前 CNCF 最具人气的项目非 Kubernetes 莫属；阿里云同时宣布除了 Docker 最新版 Swarm mode，其容器云服务亦将支持 Kubernetes。

阿里云支持 Kubernetes 的研发工作从 2016 年就已经开始，主要是从与阿里云能力的整合和简化 Kubernetes 部署等方面入手，先后陆续支持了若干个国内外的客户，帮助将其 Kubernetes 环境迁移到阿里云上。

CNCF（Cloud Native Computing Foundation）是 Linux 基金会下属定义云计算模型未来的重要标准化组织，从最早的容器集群调度技术 Kubernetes，到现在覆盖了从容器引擎、容器编排、微服务应用编程和运维模型等众多内容。2017 年 2 月，阿里云加入 Linux 基金会，并开始与 CNCF 讨论合适的加入时机。由于双方在技术方向，社区发展等方面都有合作基础，并且阿里云也一直致力于开源社区和 Cloud Native 的标准推动，比如阿里云是 containerd 项目的初始成员；所以双方的合作是水到渠成的事情。

4 一山二虎，容器编排的未来何去何从？

那么，阿里云怎样看待 Docker 和 Kubernetes 背后的两种编排体系的未来？两者是会更加有特色的分化？还是更加趋同的直面竞争？

一方面，Docker 和 Kubernetes 将在容器编排领域有更多直接的竞争，因为对于多数应用，Docker 和 Kubernetes 的编排方案都能够提供类似的能力，社区将在易用性、稳定性、规模、能力等多方面展开竞争，而厂商们也会努力差异化自己的产品，比如阿里云和 Docker 合作在推动容器在企业混合云场景的应用。良性竞争终将让用户收益，就像 iOS/Andriod 的竞争让移动互联网变得如此富有创造力一样。

但在更高的层面，Docker 和 Kubernetes 并不是竞争对手。容器领域有足够的想象空间可以发展；商业的成功也不仅决定于技术，生态的建设更加重要： 只有更多的厂商围绕容器技术进行的创新，更多的应用开发商支持容器化应用交付，更多企业开始拥抱容器技术，才能让容器商业蓬勃发展。除了编排技术本身，Docker 也在不断完善生态建设，比如 Docker 企业版提供的认证的基础设施、插件和企业应用，可以为企业客户提供安全可信的容器环境；其推出的传统应用现代化（Modernize Traditional Applications）项目，将帮助企业用户改造遗留系统，更好地利用容器技术。在去年底 Docker 推出 containerd 项目时得到了 Google、阿里云、AWS 等厂商支持，因为它不但提供了一个标准化、稳定的容器运行时，也将更加便于 Kubernetes 这样的编排方案来进行集成。在这一方面上，Docker 和 Kubernetes 更像是合作伙伴。

业界更希望看到的是各派系编排系统在良性竞争中逐渐成熟，如此整个容器生态、包括企业级用户将会更加方便轻松受益于此。根据 451 Research 调查显示，以 Docker 为首的容器技术在 2016 年创收 7.62 亿美元，预计该数字将于 2020 年上升至 27 亿美元。

5 写在最后

编排系统各自着力布局发展， Kubernetes 得到了不同厂商的支持，发行版包含 Openshift、Tectonic 等，其最新 1.6 版本在集群规模、调度能力上都有提升；而 Docker Swarm 作为原生编排机制，提供了简化用户体验，Docker 亦在 DockerCon2017 上为大家展示了其内置安全特性；Mesos 内含 Mesosphere DC/OS，最新版 Mesos 1.1 添加了如嵌套容器、任务组等关键性功能 。在众多提供容器服务的厂商中，阿里云、Azure、灵雀云等提供了对 Kubernetes 和 Docker Swarm 的双支持。当然，目前还有一些容器云服务坚定地选择只支持一种编排系统。

在 Kubernetes 和 Docker Swarm 之争成为焦点之前，其实 Mesos 在早期是被广泛使用。有些遗憾的是，目前 Mesos 的社区热度似乎在递减，而另一方面，业界明显感受到 Kubernetes 的崛起；Sysdig 调查显示 43% 的用户使用 Kubernetes，而只有 9% 的用户使用 Mesos。那为什么比 Mesos 晚五年亮相的 Kubernetes 会实现这样的逆转呢？不过，两者的 star 数量相差 7.5 倍（Kubernetes ：23965 颗 star，Mesos：3158 颗 star），不能否认的是社区贡献的力量，这是对于技术生态的发展至关重要。

同样，各个 IT 企业也不再偏居一偶地“闭门造车”，在提供或者使用商业软件同时，大家越来越多地关注开源项目甚至深度参与源代码的贡献。Docker 虽为商业公司，也是如此：Docker 已经向 Linux 基金会的 Open Container Initiative 项目捐献了容器镜像和运行时相关规范，和参考实现（runC）；并在今年 3 月份，将其容器引擎核心 containerd 捐献给了 CNCF；并且还会继续开展其他标准化工作。而阿里云则提供容器生态（K8S, Docker 等）多方面技术的支持，同时也参与开源项目贡献和社区建设；阿里云称其会努力成为连接技术生态、企业和高校学术的桥梁，促进越来越多的技术合作。

不论是 CNCF 还是 OCI 都归属于 Linux 基金会，两个基金会成员中有很多 IT 商业公司。OCI 开放容器项目于 2015 年 6 月 22 日由 Docker 与 Linux 联合推出，加入的公司有 AWS、Cisco、CoreOS、IBM、Intel、Oracle、微软等 43 名成员。CNCF 是 Google 于 2015 年 7 月 20 日联合数家公司成立的开源组织，旗下有 Kubernetes 项目，CNCF 基金会中，除了有 eBay、ticketmaster、Twitter 等技术使用公司，还有 Cisco、Dell、Docker、Google、Huawei、IBM、阿里云、腾讯云等著名商业公司，也不乏才云科技、超算云、DaoCloud、EasyStack、谐云科技等创业公司，共计 76 名成员。

众人拾柴火焰高，IT 作为智慧密集型行业，流行的开源项目更容易进入快速发展的良性循环模式；而企业级的应用则更需要专注更专业 IT 服务，并预留特定的人力和精力。那么，基于开源项目提供的商业服务，则可以成为完美结合；比如 RedHat Linux 和 Oracle MySQL 就是很棒的成功先例。

IT 圈已经进化到开源与商业不再剑拔弩张的时代。

6 参考文章

https://www.datadoghq.com/docker-adoption/

http://www.zdnet.com/article/what-is-docker-and-why-is-it-so-darn-popular/

https://sysdig.com/blog/sysdig-docker-usage-report-2017/

作者介绍

木环，InfoQ 运维主编、高效开发运维（ID：DevOpsGeek）负责人，前程序媛。

易立，阿里资深专家，目前负责阿里云容器服务、开发者服务的研发。之前曾在 IBM 中国开发中心工作，担任资深技术专员；作为架构师和主要开发人员负责了一系列在云计算、中间件领域的产品研发和创新。

今日荐文

点击下方图片即可阅读