容器与容器编排

在相当长的时间里，“把应用程序部署到生产环境中去”，许多资深研发和运维人员都有很多故事可以讲。系统上线过程中，各种说不清道不明的灵异事件，层出不穷。这一窘境让很多IT从业者对软件开发所面临的风险心怀畏惧，企业技术升级迭代也因此受阻。

Chef，Puppet，Ansible，持续集成和部署这些工具的出现，使测试和部署的标准化更加容易。这些工具把开发人员和运维人员从琐碎的部署运维细节中解救了出来。近些年火起来的容器也可以标准化环境并抽象出硬件和底层操作系统的细节。

容器是一种软件技术，它给操作系统级的虚拟化提供了一个抽象和自动化层。Docker 是开源的广泛应用的容器引擎。Docker产生的初衷是为了克服部署在同一系统中的多个应用之间的库和依赖的版本冲突问题。

为了减轻用户在处理系统配置问题上的负担，Docker利用Linux的cgroups和namespaces的功能，将应用及其依赖封装在特殊的包中。这个包就是容器的镜像，只要是装了Docker引擎的系统上，都可以根据镜像来创建容器实例并运行。不会受系统中其它容器或者系统本身安装的依赖的影响。这种让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上的技术。

Docker由Solomon Hykes创建于2013年。到2017年，它已经成为用于部署的最热门的开源项目之一。Docker在开发和运维领域发展势头正猛。其中一个主要原因就是它具有跨环境的一致性。

Docker非常适合持续部署和测试。Docker容器能在多个开发和发布周期之间保持一致性，有助于标准化运行环境。单个的容器主机本身可以把开发和生产环境中从底部抽象出来，但是在实际生产环境中只使用Docker容器，还会面临诸多问题。

经过多年的发展，Docker已经开始被考虑在生产环境中进行部署使用了。为了推进Docker技术的商业化进展，在实际生产环境中，在多台物理主机中协调容器资源成为首要要解决的问题。这一问题被统称为容器编排。容器领域现阶段争论的重点也正在于为容器主机群管理提供怎样容器编排架构与功能。

目前比较流行的容器编排工具包括Docker Swarm，Kubernetes和Mesos+Marathon。容器编排让容器使用者不必去考虑哪个服务将托管于哪个特定容器，也不用关注对容器的启停，监控等具体的操作。容器使用的最核心问题也恰是容器编排，如何部署和管理这些容器。Docker Swarm，Kubernetes，Mesos+Marathon都可用于容器的部署、管理以及实现基于容器的应用扩缩容，但这三种容器编排工具着重处理和适用的问题是非常不同的。这些容器编排工具在架构、周边生态环境等方面也都不尽相同。

Docker Swarm

Swarm是Docker自己的容器编排工具。它使用标准的Docker API和网络，易于融入已经使用Docker容器的环境中。

图 1 Docker Swarm 架构示意图

（来源：ibm developerworks）

如图 1所示，Swarm由管理器和运行服务的工作节点组成。管理器在整个集群中分配任务，一个管理器协调管理众多构成群集的工作节点。工作节点运行管理器分配的Docker容器。服务是在群集中运行的某组特定Docker容器的接口。任务是某特定服务所需的命令以及运行镜像的Docker容器。Swarm的设置简单。使用Docker Engine来启动主节点，并可提供一个可在每个工作节点上使用的命令以将这些节点添加到集群。群集一旦运行，可使用Docker Compose指定服务。服务启动后，它们将部署在群集的各个主机上，而不是单个主机上。用户定义的任何网络也可以跨整个群集工作。

Swarm有一定的模块化, 用户可以置换出键值存储，并且已有实验使用 Mesos 作为备用调度程序。Swarm不仅以容器为中心, 而且是以Docker为中心。Docker公司在Docker Swarm投入了大量精力，所以其发展迅速。

到目前为止，Swarm 已被认为至少是适合于实验和小规模部署的，虽然它还是不如 Kubernetes 和 Mesos承认度高。Docker Swarm 提供了一个轻松的方式来进行容器编排，且不违背对现有 Docker 工具和思维的熟悉度。

Kubernetes

Kubernetes基于Google在生产环境中大规模工作负载经验，虽然不是Google容器编排系统Borg的开放源码，但是借鉴了Google从运行Borg获得的经验教训。Kubernetes是受Google内部管理系统Borg启发而催生的一个新的开源项目。Borg曾经号称是Google内部最重要的系统，更可以说是Google的秘密武器。2016年3月，Google把Kubernetes项目交给了CNCF来维护，但Google还仍然是Kubernetes的主要贡献力量。

图 2 Kubernetes架构图示

（来源：Wikipedia）

Swarm始于扩展单主机Docker，而Kubernetes的起始点就是集群本身。使用Kubernetes,须跳出Docker思维模式。如图 2所示，Kubernetes集群默认情况下，单个master处理API调用，分配工作负载并维护配置状态。Minion是运行工作负载和其他任何不在master上的工作的服务器。Pods是一些由一个或几个部署在同一主机上的容器组成的计算能力单位，它们共同执行任务，且在pods内具有单个IP地址和网络。服务是pods的负载平衡器和前端，它可提供一个浮动IP用于访问为服务提供支持的pods，这意味着在pod发生更改的同时可以保持接口稳定。复制控制器负责维护pod的多个副本。标签是用户和系统用于标识pod，复制控制器和服务的键值标记。

使用Kubernetes与单独使用Docker的方式不同。虽然Kubernetes的CLI和API与Docker的不同，但因其风头正劲，所以找到适用的组件大多数情况还是可以办到的。模块化是Kubernetes方法的基础。例如，用户可以选择Flannel，Weave，Calico和其他网络选项。用户也可以置换出stock调度程序而使用Mesos代替。这种模块化还可以扩展到容器本身。

Kubernetes不仅限于在Docker上使用，它还可以使用rkt和其他容器格式。Kubernetes对于应用开发人员来说是降低对基础设施和运维人员依赖性的利器。Kubernetes功能丰富。基于Kubernetes来开发商业化的容器云产品也相对容易。部署和运维Kubernetes的难度也比早期下降了不少。Kubernetes是在CNCF管理下的开源项目，比起受控于Docker公司的Docker Swarm，更加吸引开源贡献者。Kubernetes的核心诉求是为便利无状态Docker容器的运维管理。Kubernetes在有状态服务和大数据方面也有意要推进，但是目前没有得到充分的发展。因而有状态服务和大数据应用要采用Kubernetes，目前并不是合适的选择。

Kubernetes非常适合运行复杂应用程序的中大型集群。如果用户有多套无状态微服务器，那么Kubernetes可以提供一个框架以建立它们之间的交互规则并运行这个结构。Kubernetes到目前为止还是不太适合要运行有状态的应用程序（如数据库）的用户，已开始支持具有配置依赖项并需要有状态的失效备援的“pet”式容器。Kubernetes的学习曲线和设置比Docker Swarm需要花费更多的精力，但是它模块化做得比较好，具有灵活性，适应于大规模部署应用的部署。

Mesos和Marathon

Apache Mesos比Docker出现得更早，被称做是分布式系统内核。Mesos抽象了多台计算机，形成单一逻辑视图。Mesos是使计算资源可用于框架的集群管理器。Marathon是一个专门在Mesos集群上运行应用程序和容器的计算框架。Marathon早在2014年就提供了对Docker镜像的支持。Mesos和Marathon在一起提供了相当于Kubernetes的功能，但却同时支持非容器化的工作负载。

Mesos采用模块化的架构设计，被Twitter、Uber、Apple、Netflix等公司所青睐，不仅仅支持微服务，还支持大数据和实时数据分析等。Mesos是集群资源管理工具，和Kubernetes所处理的问题属于不同的层次。Mesos将数据数据中心资源抽象为统一的资源池，打破不同的业务负载的资源分配界限以提高资源分配的效率。Mesos集群管理的自动化工具丰富，可以为集群架构高容错高可用。扩展集群功能和规模时，不会对原先部署在集群上的应用以及集群管理系统产生影响。

图 3 基于Mesos的容器编排架构

（来源： Apache Mesos）

如图 3所示，Mesos运行两级调度。Mesos从节点向主节点报告自己的可用资源。Mesos根据先前设置的策略将该资源提供给上层计算框架。计算框架再根据定义的策略将资源提供给进程。在Mesos上层可以同时运行多个计算框架，例如Marathon、Cassandra、Storm、Spark。Marathon还可以来部署其他计算框架，来利用Marathon的健康检查功能来实现计算框架的高可用。

Mesos上的应用负载可以是各种类型的，如无状态微服务、批处理任务、有状态服务、实时数据分析处理任务以及传统应用。Mesos集群用Zookeeper管理至少三个主节点，并通过规定这些节点的额定数目来实现高可用性。从节点运行框架传递的任务。Mesos本身对工作负载一无所知，而计算框架决定如何处理Mesos提供给它们的资源。在Mesos顶层，Marathon是高可用性的计算框架。通过专用的DNS服务以及其他选项提供服务发现。通过HAProxy提供负载平衡。为了控制集群中某些工作负载的运行位置，约束管理为这些工作负载维护一定的资源水平，实现机架感知和其他约束。用户可以在集群上运行的长期运行Docker容器或其他类型的工作负载。REST API可以用于部署，更改和销毁工作负载。

Mesos和Marathon都可扩展到上万节点规模。对于相对较小的集群，这么大的系统资源运行和管理开销并不太合适。特别是与Docker Swarm相比，它的设置也更加复杂。Mesos和Marathon的使用也和Swarm或Kubernetes有所不同。它有另一套工具和API。

Mesos已在生产环境中被成千上万的节点证明了可靠性。Mesos和Marathon比Kubernetes或Swarm出现时间更早有更多的验证助其修复bug并在大规模的长期运行的实践中收获了用户群。如果用户需要与容器同时运行非容器式工作负载且运行规模巨大，Mesos和Marathon是不二之选。但它的学习曲线更陡峭。

结论

无论选择Kubernetes、Docker Swarm还是Mesos+Marathon作为容器编排技术路线，都可以用来管理容器实践基于容器来打包应用这种方式的可移植和可扩展性。对于不同编排方式的选择，最根本的还是要根据上层业务的实际需求。

表格 1 容器编排技术选型

如表格 1所示，如果上层应用的需求是构建一个稳定的，业务类型混杂的容器平台，那么Mesos+Marathon是最恰当的选择。这种架构甚至可以将公有云资源纳管进来，对复杂多变的甚至不确定的用户需求非常实用。如果要采用当前流行的Kubernetes，那么评估一下实际的应用场景是不是专注于Devops以及持续集成，对数据分析处理以及其他业务是否也有潜在的容器化需求。当然，并不是所有想用Docker的团队都得花精力来跟Kubernetes和 Mesos+Marathon这样的高复杂性的技术架构打交道。如果团队的目的只是将自己的应用以Docker容器的形式来打包，以适应容器这种虚拟化技术以及应用微服务化的这种发展趋势。方便搭建使用的Docker Swarm就够用了。

如果暂时应用场景不明确，为了构建容器平台而构建，也不用感到困惑。因为，上容器平台这个选择，无论选择了哪种技术路线，都会方便计算存储资源的高效利用，让软件开发以及应用打包方式更加灵活以及适应于容器化这一明朗的IT架构发展趋势。在这种情况下，编排管理工具的选择则可以从其它方面来考虑。

目前容器编排相关标准化工作还不够到位，找到一个满足企业个性化需求的集群管理方案并不容易。对于容器初级用户，这三者间两个最大的差异就是它们的学习曲线和可扩展性了。团队技能和人数是不可忽视的因素，这决定了企业可以在多大程度上优化集群管理器以实现最佳配置。Docker Swarm最便于使用， Docker API灵活性，易于集成，还可以用自定义接口和调度来定制脚本或构建应用等。Kubernetes更加通用，开源社区发展迅速。Mesos和Marathon更加适用于大型系统，有最大的冗余。Kubernetes和Mesos灵活性开放性更高，但是开发运维工作量对IT团队要求比较高。Mesos最适用于已经运行数百或数千台主机的公司，并且已经在上万节点规模上得到了证实，适用于大规模数据解决方案。Swarm对于中小型系统，价值极大，易于扩展。Kubernetes最适合中等规模，高度冗余的系统，对技术团队要求较高。Mesos是最稳定的平台，但对于10-20个节点的小型系统来说过于复杂。

这三个主要容器编排工具在实现以及与用户互动方式上有很大差异。Docker的Swarm提供了编排Docker主机群集的最简单的方式。Kubernetes以容器为中心，但相对于容器本身，更多着力于部署和管理。Marathon的Mesos可以承载巨大的规模，使用复杂性也不低。当然，在实际项目需求中，单靠文档调研来确定技术路线选型无法做出最客观的选择。系统原型实测结合应用程序的工作原理以及负载分析仅可以辅助技术选型。

更多曙光相关资讯，欢迎搜索微信公众号“中科曙光/sugoncn”，关注曙光公司官方微信