容器时代，集群调度谁家强？

如今，企业IT系统集群规模越来越大，各路计算系统、存储系统、应用系统随着业务的飞速发展，一个接一个地“噌噌”搭建起来。但同时问题也来了，比如部署运维繁琐、新系统上线周期长、集群整体利用率偏低等。这时候，企业迫切需要一套强大的集群资源调度系统来帮忙。考虑到时下集群负载容器化如火如荼，各路面向容器的调度系统眼花缭乱，小编打算挑几位人气颇高、来自“开源界”的资源调度高手——Docker Swarm、Apache Mesos和Google Kubernetes，讲讲TA们在大规模容器场景下如何各施本领的故事。

在高手出场前，让我们先快速回顾一下有关容器技术的背景知识。

从容器（Container）到Docker

1. 容器（Container)

提到虚拟化，很多人都会立刻想到虚拟机，其实它只是虚拟化的一种实现。容器是另一种虚拟化，一种操作系统级别的虚拟化。从本质上来说，容器就是提供一个与宿主机操作系统共享内核但与系统中的其它进程资源相隔离的执行环境。其轻量级部署运行和秒级启动特性，帮助开发者快速构建、发布、部署和实例化应用程序。

容器化最直接的好处在于简化DevOps，当应用采用了微服务架构（Micro-services architecture），每个容器就是一个微服务，而容器的灵活性意味着微服务可以随负载增长而快速横向扩展，且namespace（包含一个应用程序能够交互的所有资源）与资源隔离阻止了微服务实例之间的互相干扰。

2. Docker

Docker是时下流行的容器技术之一，起先是基于LXC（Linux Container）的开源容器管理引擎， 现在runC（标准化容器执行引擎，符合OCI标准的开放容器项目）更让它欣欣向荣向前发展。

与传统“重量级”的虚拟机相比，Docker在LXC之上融合AUFS分层镜像管理机制，抛弃传统虚拟机试图模拟完整机器的思路，而是以应用为单元进行“集装封箱”，是“轻量级”的虚拟化技术。

1. Docker Engine可以自动化部署应用到可移植的的容器中，这些容器独立于硬件、语言、框架、打包系统。一个标准的Docker容器包含一个软件组件及其所有的依赖，包括二进制文件，库，配置文件，脚本等，实现持续集成与部署，快速迭代应用程序。

2. Docker容器可以封装任何有效负载，几乎可以在任何服务器之间进行一致性运行。开发者构建的应用只需一次构建即可多平台运行。运营人员只需配置他们的服务，即可运行所有应用。

Docker的终极目标是简化容器的创建，并让这些容器可以作为开发者和系统管理者标准化、配置、交付应用的最佳方案。如果说Docker交付运行环境如同海运，那么OS如同一个货轮，每一个在OS上的App都如同一个集装箱，用户可以通过标准化手段自由组装运行环境， 同时集装箱的内容可由用户自定义，也可由专业人员制造。这样，交付一个应用，就是一系列标准化组件的集合交付。

高手登场了

身为一个容器调度高手，TA一定会选择最适合的Host来启动容器，并让容器之间紧密协同；对于失效容器立即自动替换，一切错误处理尽在掌控中；当高并发突然来袭，能迅速扩展容器来应对等等。那么今天的这三位主角——Docker Swarm、Apache Mesos、Google Kubernetes，在大规模集群容器场景的挑战下，又会表现出怎样的特征和本领？

1. Docker Swarm篇

Docker Swarm是Docker公司在2014年12月初发布的一套管理Docker集群的工具。它将一群Docker宿主机变成一个单一的虚拟主机，而且使用标准的Docker API接口作为其前端访问入口，这样一来，各种形式的Docker工具都可以很容易与Swarm进行集成。

Swarm架构特点

一套Docker Swarm架构由一个Swarm manager和若干Swarm节点组成，见下图。Swarm manager上运行Swarm daemon，用户只需跟Swarm manager通信，然后Swarm manager根据discovery service的信息选择一个Swarm节点来运行容器。

值得注意的是Swarm daemon 只是一个任务调度器（scheduler）和路由器（router）,它本身不运行容器，只接受 Docker client 发送过来的请求，调度合适的Swarm节点来运行容器。这意味着，即使Swarm daemon 由于某些原因挂掉了，已经运行起来的容器也不会有任何影响。

Swarm调度策略

Swarm支持以下三种调度策略来选择节点运行容器：spread，binpack和random。使用spread策略，Swarm会选择一个正在运行的容器数量最少的那个节点来运行容器；而binpack 则相反，Swarm会尽可能把所有容器放在一个节点上运行；random策略，顾名思义，不会做任何计算，只是单纯随机选择一个节点来启动容器，这种策略一般只做调试用。

Swarm过滤器

在选择节点运行容器时，Swarm支持两种节点过滤器（Constraint和Health），三种容器配置过滤器（Affinity、Dependency和Port）。

1. Constraint （限制过滤器）是一个跟具体节点相关联的键值对，可以看做是每个节点的标记，这个标记可以在启动docker daemon时指定。

2. Health（健康过滤器）阻止容器运行于unhealthy节点上。

3. Affinity（关联过滤器）让容器运行在有关联关系的节点上，包括容器关联、镜像关联和标记关联。

4. Dependency（依赖过滤器）可以让一个容器“依赖”另一个容器运行，“依赖”是指两个容器共享卷，彼此互连，处于同一网络堆栈。

5. Port（端口过滤器）让容器运行于此端口可用的节点，避免端口冲突导致容器运行失败。

2. Apache Mesos篇

Apache Mesos是2009年加州大学伯克利分校AMPLab首先开发出的一款开源集群管理软件，主要用于搭建高效扩展的分布式系统来支持各式各样不断增长的Framework。毕竟像Hadoop和MPI这些Framework都是独立发展起来的，不太可能实现很好颗粒度的跨框架资源共享。但Mesos有增设一层“薄薄”的资源共享层，为各种Framework提供了通用接口来访问集群资源。下图为Mesosphere公司基于Mesos“核心”搭建的DCOS（数据中心操作系统）架构示意。

在Apache Mesos的术语中，使用Mesos API在集群中调度任务的Mesos应用程序称为Framework（框架）。下图为运行在Mesos上的各种Framework,不同颜色代表不同类型的应用。（图片摘自Mesosphere官网）

Mesos“两级调度机制”

Mesos以Framework的形式，提供两级调度机制。Mesos有两大关键组件：Mesos Master和Mesos Slave。Master是整个调度系统的核心，可理解为一个轻量级的Monolithic scheduler，负责接入Mesos的各种Framework和管理Slave，并将Slave上的资源按自定义策略分配给Framework
。而Slave负责接收并执行Master的命令，管理节点上的task，并为各task分配资源，同时Slave还将当前系统资源汇报给Master进行分配。

下图为Mesos“两级调度机制”示意图，图中只展示了Hadoop和MPI两种框架类型。（图片摘自网络）

Marathon是注册到Mesos的一款很重要的Framework，主要负责管理长时应用（long-running applications），由Mesosphere公司一手设计并主动维护的。如果把Mesos比作数据中心kernel的话，那么Marathon就是init或者upstart的daemon。

下图为Mesos应用Marathon的架构示意。

可见该集群系统共有4大核心元素：ZooKeeper、Marathon、Mesos Master和Mesos Slave。ZooKeeper帮助Marathon查找Mesos Master的地址，多实例可用来处理失效。Marathon启动、监控和扩展容器。Mesos Master将指定任务发送给Slave节点，而且当Slave节点有空闲的CPU/RAM时，Master会向Marathon提出邀约。Mesos Slave负责运行容器并提交可用资源清单。

Marathon的4大特性

1. Constraints

Marathon可以通过Constraints来控制其app在何处运行。也就是说通过Constraints，可以限制应用部署在指定的一个或多个Slave节点上。这类应用一般是有状态应用，或存储型应用，必须将应用的数据目录挂载出来，又或是应用需要部署在有特殊配置的Slave节点上，例如，应用需要使用GPU资源，而只有特定的Slave节点有GPU资源。Constraints由三个部分组成：字段名（field name），操作（operator）, 可选参数（optional parameter）。

1. 健康检查

Marathon对发布到它之上的应用支持基于TCP/HTTP协议的健康检查，大体逻辑是Marathon会周期性扫描应用的健康检查路径，如果响应时间连续n次超出阈值，那么Marathon会直接重启这个应用，即所谓的Fast failed。只要应用响应过慢，就应该杀掉它，响应过慢的应用会大大拖慢全局服务的响应速度，因此不再需要容器内部的失败重启，而是直接杀掉容器。

1. 服务发现和负载均衡

服务发现的功能实现是为DCOS中的服务提供便捷的网络通信，它的侧重点在于对服务进行注册，更新，查询等功能。DCOS的服务发现功能采用的是Mesos-DNS，一种Apache Mesos提供的基于DNS的服务发现策略，它可以结合多种Framework来工作（不止是Marathon）。

Mesos-DNS 是无状态的，可以自由复制，因此通过为每个Slave部署Mesos-DNS 的方式来保证高可用。而且采用Mesos-DNS策略，通过辅助脚本利用Marathon RESTful API定时产生HAProxy配置文件，通过diff生成的HAProxy配置文件与已有的HAProxy来判断是否进行重载HAProxy操作，从而实现负载均衡。

3. Google Kubernetes篇

Kubernetes是一个容器集群的编排管理系统，主要面向跨Docker主机场景之下容器集群的统一管理，据Wikipedia介绍，最初是由Google在2014年提出的开源项目，其开发设计思想深受Google的Borg系统影响。

Kubernetes架构特点

Kubernetes是一个典型的Master/Slave架构，见下图。

Kubernetes Master

Kubernetes Master节点提供了集群统一视图的中心控制点，包括组件有：

1. API Server: 作为Kubernetes集群系统的统一管理入口，封装了核心对象的增删改查操作，以RESTful接口方式提供给外部客户和内部组件调用。

2. Scheduler: 负责集群的资源调度，为新建的Pod分配物理机。Pod是Kubernetes集群里最小的可部署单元，它表示同属于一个应用的容器群的逻辑集合。

3. Controller Manager：负责执行各种控制器，目前有Endpoint Controller和Replication Controller两类。Endpoint Controller：定期关联Service和Pod，保证Service到Pod的映射总是最新的。Service也是Kubernetes的基本操作单元，是Pod的路由代理抽象，用于解决Pod之间的服务发现问题。Replication Controller：它是Pod的复制抽象，用于解决Pod的扩缩容问题。定期关联Replication Controller和Pod，保证Replication Controller定义的复制数量与实际运行Pod的数量总是一致的。

注：Pod、Replication Controller和Service是Kubernetes最基本的三个操作对象。而Service和Replication Controller都是建立在Pod之上的抽象，通过Label与Pod关联，Label就是为Pod加上可用于搜索或关联的一组key/value标签。

Kubernetes Slave

Kubernetes Slave节点又称作Minion，它是一个工作节点，负责运行Master节点交付的任务。Minions能运行一个或多个Pod，它包括组件有：

1. Kubelet： 在每个Minion上负责管控Docker容器，如启动/停止、监控运行状态等。它会定期从Etcd获取分配到本机的Pod，并根据Pod信息启动/停止相应的容器。同时，它也会接收API Server的HTTP请求，汇报Pod的运行状态。

2. Proxy： 负责为Pod提供代理。它会定期从Etcd获取所有的Service，并根据Service信息创建代理。当某个客户Pod要访问其他Pod时，访问请求会经过本机Proxy做转发。

3. Docker: Kubernetes使用的容器技术来创建容器。

Kubernetes功能特性

Kubernetes为容器化的应用提供资源调度、部署启动、运行监控、服务发现、错误处理和扩容缩容等一系列功能，本质上可以看作是基于容器技术的mini-PaaS平台。由于Kubernetes更关注对服务级别的控制而非仅仅对容器级别的控制，把服务看成一个整体，这种增强的协同工作方式，让开发者的生产力得到提高，服务的可用性也进一步增强，大规模集群部署工作也更加敏捷。

最终点评：高手没有最强，只有最“适合”

以上三大高手中，Docker Swarm是最简单的调度器。而且它与Docker环境的集成度很高，它使用Docker Engine同样的API，使用Docker Compose描述文件，因此对还不是很熟悉更复杂调度器的开发者很适合。尤其当开发者想要搭建特殊工作流时，Swarm能提供一个快速开始且高配置度的调度平台。此外，Swarm并未与特定的云供应商绑定，背后是一个完全开源的强大社区作支持。

而Mesos加Marathon更适合Mesos集群。事实上，它也使用类似Docker Compose的描述文件来指定任务，很适合在集群中部署容器的情况。Mesosphere推出的以Mesos为核心的一整套DCOS解决方案，则为生产环境下的容器调度提供了便捷而强有力的支持。

Kubernetes采用了与标准Docker完全不同的逻辑原理，它是围绕Pod和Service等核心概念另辟一种使用容器的有趣新方式，当然它也从未停止过思考与其它生态圈的连接问题。不过Google推出Kubernetes主要还是为Google自己生态圈里的开发者提供一种简单便捷的集群调度方案，一种逻辑选择。

没有最强大的容器调度高手，但有根据你的需要，你实际的集群环境，最适合你的那一款选型。下图是一个Swarm项目，在Swarm顶端允许部署Kubernetes，Mesos + Marathon，未来还将支持Cloud Foundry，Nomad以及更多的容器调度框架。Swarm集群在其它manager（比如Mesos + Marathon，Kubernetes）的管理下，容器实现跨集群迁移。事实上，这种“大联合”可以让你“随心所欲”地对容器进行调度和编排。

最后

以上就是健康小甜瓜为你收集整理的容器时代，集群调度谁家强？的全部内容，希望文章能够帮你解决容器时代，集群调度谁家强？所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。