容器现状：Docker 之外的选择、容器编排以及它们对微服务的影响

本文要点

• 容器技术市场日益拥挤。各种技术正力图在该新兴市场中争夺一席之地。
• 容器编排是在生产环境中成功部署和操作容器的关键。
• 本文详述了多种当前可用的容器技术平台和工具。
• 一些云厂商的服务可以帮助快速部署容器，并提供灵活的伸缩性，这些服务在不同程度上存在“技术锁定”。
• 我们建议开发人员在创建微服务时，应考虑与厂商和平台的无关性，以便在未来的容器部署中具有灵活的弹性。

我参加了由柏林微服务讨论会组织的一个称为“微服务编排”的活动。活动组织者邀请了来自各大企业（Google、Microsoft、Amazon、Mesosphere、CoreOS 和 DigitalOcean 等）的专家，分别报告了容器技术、云服务以及如何编排基于容器的微服务。本文扩充了这次活动的内容，为读者给出了多种不同容器技术的概览、差异以及未来的潜在发展。容器技术间的竞争已经开始！

定义：容器技术和编排引擎

只要你在这个星球上，就一定听说过 Docker 以及对它的大肆宣传。为了达成共识，我们首先对容器应用的两个关键概念做精简定义。

• 容器是一组运行在 Linux 操作系统上并使用命名空间进程进行分隔的进程，有了容器就无需再启动和维护虚拟机。与虚拟机技术相比，容器的最大不同之处在于打包格式和可移植性。构建容器的目的在于为现代基础设施降低占用空间和启动时间、提供重用性、更好地利用服务器资源，并更好地集成到整个开发生态系统中（例如持续集成和交付生命周期）。更多的细节可参见“微服务、容器及云原生架构”一文。
• 容器治理包含了如下一系列任务：调度（包括部署、复制、扩展、复活、重新调度、升级、降级等）、资源管理（内存、CPU、存储空间、端口、IP、镜像等）和服务管理（即使用标签、分组、命名空间、负载均衡和准备就绪检查将多个容器编排在一起）。该定义引用自 Mesophere 。

如果有人对容器编排依然不甚了解的话，可以观看一下这个非常好的视频：“ Kubernetes 启蒙指南”。该视频时长八分钟，是我见过的最好的技术视频之一，已经入门的人也值得一看。

可供选择的容器和用于编排的云服务

对于微服务的编排，在市场上存在着大量容器及相应的云服务可用。容器技术和编排引擎通常是结合在一起使用的，因而常被包含在同一工具中。云端提供的服务被称为 CaaS (容器即服务) ，其中“用户只为他们所使用的资源付费，例如计算实例、负载均衡和调度能力”。

在下面的列表中，我给出了多种不同容器平台的特性及各自的优缺点分析。应指出的是，该列表当然不是容器及编排产品的完全列表，但是我希望它能涵盖到它们中的大部分。

• Docker 是最受大众关注的容器技术，并且现在“几乎”成为事实上的容器标准。虽然 Docker 公司是“官方的”Docker 项目持有公司，但是 Docker 是开源的，并且得到很多厂商的支持。最近 Docker 公司在主要的容器项目中添加了编排引擎 Docker Swarm 。Red Hat 和 IBM 等其它一些公司对开源代码也有贡献。多个厂商提供了针对 Docker 的支持、咨询和云服务（例如公开的或者私有的 Docker Registry）。
• Core OS 提供的 rkt （发音为“rocket”）是另一种容器技术，它是随容器编排引擎 Fleet 一并提供的。rkt 是一种底层架构，直接构建于 systemd 之上，常用作更高层解决方案的“基础层”。rkt 侧重于安全性、可组合性（例如与原生 Unix 的集成）和标准化或兼容性。rkt 通过使用“ rktnetes ”与 Kubernetes 集成，就可以和 Docker 一样原生地运行 Docker 镜像。由此 CoreOS 提供了称为 Tectonic 的“企业级 Kubernetes 解决方案”，这使得更多的项目将来可能会采用 rkt 解决方案。
• Cloud Foundry 提供的 Garden 。Garden 容器是开源 PaaS CloudFoundry 的基础。考虑到 IBM、SAP 和 Pivotal 等多个相关软件厂商的 PaaS 战略都是基于 CloudFoundry 构建的，因此可以说这些企业“在暗地里”使用。与 Docker 和 rkt 不同的是，如果离开了 CoudFoundry 的应用场景，Garden 容器并不具有真正意义上的市场。
• Kubernetes 是一款受到社区大力支持的容器编排引擎。该项目最早由 Google 在今年初开源发布，现在 Kubernetes 的贡献者还来自 Red Hat、CoreOS、Mesosphere 等软件厂商。这些贡献者实现了让 Kubernetes 运行多种不同的容器，其中包括了 Docker（当前使用最为广泛的容器技术）或是 CoreOS 的 rkt（发音为“rocket”）。 Google Container Engine （公共 Kubernetes 服务）和 Red Hat 的开源 PaaS 产品 OpenShift （基于 Kubernetes，用于混合云部署）是最广为人知的两个 Kubernetes 产品。其中后者在 Kubernetes 上添加了一些有用的特性，包括改进的 Web 用户接口，以及“从源码到部署”自动化系统，无需要了解底层容器或 Docker 子系统的细节。
• Amazon AWS ECS 是一个公共 CaaS，用于管理 Docker 镜像（可存储于共生的 ECS Registry 中）、运行 Docker 容器（ECS Runtime 服务），以及容器实例的调度、编排、监控（AWS CloudWatch 服务）。这些服务还可以与其它的 AWS 服务整合，例如 Elastic Load Balancer（AWS ELB）和 Identity and Access Management (AWS IAM)。此外，为了实现在 AWS Simplified Workflow 服务中使用 Docker CLI 命令（例如 push、pull、list、tag 等），该服务也与 AWS ECS 紧密集成。
• 还有一些云服务提供商提供了基于 Docker 的 CaaS 云产品。 Microsoft Azure 容器服务（ACS）可与 Docker Swarm 或是基于 Mesos 的 DC/OS 一起工作，共同构成容器编排引擎。Rancher Labs 提供的 Rancher 平台也支持 Docker Swarm、Kubernetes 和 Apache Mesos。需要注意的是，用户仍必须首先创建服务实例（例如 AWS EC2），这也是绝大多数 CaaS 的共同特点。用户并非为运行自己的 CaaS 容器实例本身付费，而是为运行容器的服务实例付费。如果想要采用以容器实例计费的方式，用户需要使用“无服务架构”（该内容稍后再做讨论）。Docker 公司也提供了 Docker 云服务，其中包括了部署和管理 Docker 应用的 Docker Cloud，以及在企业软件供应链中集成 Docker 的 Docker Datacenter 。
• 基于 Apache Mesos 的 DC/OS 是一种运行于私有和共有云架构上的“分布式操作系统”，它对机器集群的资源进行抽象，进而提供通用的服务，因此被用作集群资源的协调器。Mesos 运行于编排层（Swarm、Kubernetes 等）之下，是一种辅助性工具。Apache Mesos 在设计上“仅需”实现 Mesos 架构的接口就可以运行多种大规模、多用途的集群。Mesos 支持多种架构，例如通过 Marathon 支持 Docker 和 rkt 容器技术、通过 Chronos 支持批处理，以及 Apache Hadoop、Apache Spark、Apache Kafka 这类大数据解决方案。作为 Apache Mesos 的主要贡献者， Mesosphere 公司还提供了一个称为 DC/OS 的开源软件产品。DC/OS 基于 Mesos 构建，两者间的关系类似于 Apache Hadoop 与其发布版 Cloudera 或是 Hortonworks 间的关系。
• Flockport 是一个初创企业，它的核心业务在于构建基于 LXC 容器的 App 商店，使用户可以在任何的服务器、云以及服务提供平台上以秒级速度部署容器。Flockport 侧重于简单易用性，即如何使服务运行起来，目标在于为用户提供可移植的实例和工作负载，这些实例和负载将具有与云端一样的灵活性，易于在服务器间迁移。博客文章“ LXC 和 Docker 容器的主要差异”对此做出了很好的解释。
• DigitalOcean 是一个云架构提供商，它让开发人员可以通过在全局云数据中心上创建所谓的 Droplet（即工作单元），借助块存储和联网特性去构建并部署微服务。Droplet 可以是一个操作系统镜像的实例，也可以是一个 Docker 容器应用。DigitalOcean 还为 Droplet 解决资源分配、监控及其它跟平台相关的问题。Droplet 可与多种编排工具集成，例如 Docker Swarm、Kubernetes、Apache Mesos 或 Dokku（一种基于 Docker 的微型 Heroku PaaS 产品）等。因此相比于 AWS EC2，DigitalOcean 更像是一种 IaaS，侧重于微服务集群部署和运行的易用性。
• Microsoft Azure Service Fabric 是一个微服务框架和容器编排引擎。它并非完全依赖 Microsoft Azure，也可以用于企业内部或云端（因此说名称中的“Azure”一词对产品有点误导）。Service Fabric 借助 Docker 实现了 Linux 和 Windows 上的容器管理，其中可以使用多种编程语言（例如 C#、Java、Powershell 等）。未来该产品有望支持 Docker 之外的更多容器技术以及编程语言。
• 无服务器的容器架构：这是一个新近出现的概念，目的在于能够部署“真正的”函数式类型的云原生微服务。该架构的主要理念是实现对付费资源百分之百的利用率。在该架构中，用户只需为函数调用付费（可参见 AWS Lambda 、 Google Cloud Functions 、 Microsoft Azure Functions 等）。它与 CaaS 产品的不同之处在于无需用户亲自去管理底层操作系统实例（即运行、扩展、使用和付费等操作）。但是无服务器容器架构产品通常仅支持对有限的几种编程语言的函数调用，例如 Java 和 Python。 IBM OpenWhisk 和 funktion （分别由 Red Hat 和 JBoss 所支持）是两个无服务器架构的开源产品，它们与软件厂商无关，通过支持 Dockers 容器实现了无服务器的容器架构。OpenWhisk 正在成为一个“真正的产品”，而 funktion 是一个小型框架，近期更新较少。在不久的将来，大型云服务提供商很有希望会提供 Docker 容器。

各种容器技术间的竞争

正如你所看到的，当前市场上已有多种容器打包与编排技术、框架及云服务可用，乃至上面的列表都未能涵盖全部。仍有新的事物在不断地涌现。

从开发人员的角度可以给出的一个重要结论是，不要聚焦于在后台为容器开发代码，而应该将注意力放到业务逻辑上，采用软件厂商无关的方式实现自己的微服务。

要避免重蹈我们曾在 J2EE/Java EE 上所犯的错误。彼时虽然所有的软件厂商都采用同一标准规范，但是他们仍然在所谓的“标准实现”中提供了与特定厂商相关的特性和“附加值”。这导致将应用迁移到另一个 Java EE 应用服务器上时，需要做大量的工作（重开发、测试，诸如此类）。很多情况下，重写代码反而比迁移更加容易和快速。

虽然当前 Docker 的发展势头很好，但依然存在对 Docker 未来发展的顾虑。一些使用了 Docker 的软件厂商并不乐意看到 Docker 公司一家独大。例如在 Docker 项目中集成 Docker Swarm 的模式会令 Red Hat 或 Google 等其它的编排服务提供商高兴不起来，因为这些厂商偏重于使用 Kubernetes 做容器编排工具。为了能够在不使用Docker 的情况下在Kubernetes 中运行容器，这些厂商又建立了一个新的开源项目，称为“CRI-O”。更多的相关信息可以参阅InfoWorld 的这篇文章：“ Red Hat 的新项目看上去非常像是 Docker 的分支”，文章中给出了从 Docker 拉出一个分支作为一个独立开源项目的相关讨论。

整合各种容器技术及工具

应注意的是，上面所讨论的技术和工具可以被放在一起使用。各种技术和工具之间通常是互补的，并没有必要去一争高低。

例如在 Kubernetes 集群中，可以同时使用 Docker 或 rkt 等各种容器技术去管理 pods。另一个例子，Apache Mesos 可管理不同集群，其中包括基本的 Docker Swarm 集群、Kubernetes 集群，以及使用了 Apache Hadoop 或 Apache Spark 的大数据集群。不要小觑这种特性！我举一个例子， Apache Hadoop 将提供对 Docker 的支持，用于实现在 Hadoop 容器中部署 Apache Kafka 或是 Apache Spark 等独立组件（Hortonwork 在上周的路演大会上展示了它的 Hadoop 战略，我在其中看到了这个路线图）。

容器的未来：是否会走向标准化？

让我们来看看 Docker 的潜在分支及关于容器技术标准化的讨论将会为我们带来什么。明年将存在三种可能的发展：

1. Docker 成为事实上的标准。
2. 不同的技术并驾齐驱，其中可能包括 Docker 的各个分支。
3. 容器技术标准化（至少部分标准化），各个技术厂商采用该标准。

我希望会是第三项可能性。倡议和讨论仍在继续，其中包括 appc（ App Container specification ，App 容器规范）、CNI （ Container Network Interface ，容器网络接口）、CNCF（ Cloud Native Computing Foundation ，云原生计算基础）和 OCI （ Open Container Initiative ，开放容器倡议）等。举例来说，OCI 的目的在于标准化容器镜像的定义，它得到了 Docker、CoreOS、Google、Red Hat、Facebook、Amazon 及其它一些企业的共同支持。

结论：开发容器无关的微服务

在本文中探讨了多种神奇的容器技术、编排平台和云服务，每种技术都有其优缺点。此外市场变化也很快。

在这里我们给出一个关键结论，就是以厂商无关的方式开发微服务，提升它们的未来适应性，并很好地利用微服务和容器的优点和特性，抛弃单体和笨重的虚拟机。在“我们能否避免被云供应商套牢? ”一文中，详细论述了这个问题。

总而言之，无论你是否在具有源代码（使用Java、.Net 或是Go 等技术）或是可视编码（例如中间件技术）的微服务之中开发业务逻辑，你应该做到的是一次开发并可在各种容器、测试环境或者云服务提供商平台中部署，无需重新开发甚至是必须要去改变之前所选用的技术。

关于作者

Kai Wähners是 TIBCO 软件公司的技术布道师和社区主管。TIBCO 软件公司是集成和分析中间件产品的领导提供商。Wähners 主要擅长的领域是大数据、高级分析、机器学习、集成、SOA、微服务、业务流程管理（BPM）、云技术、物联网技术以及包括 Java EE、Groovy 和 Golang 在内的编程语言。他时常在个人博客上分享新技术、文章和大会报告内容。

查看英文原文： The Container Landscape: Docker Alternatives, Orchestration, and Implications for Microservices

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。