容器化和微服务是当前最热话题,不久之前,笔者(据说因为现在都不用笔了,“笔者”的称谓已经不合适了,因为输入用键盘,叫“键人”更为合适)参加QCon上海一个微服务监控的Session,场面爆棚,我不得不在拥挤的过道听完了整个session。随着要管理的容器越来越多,容器的集群管理平台成为了刚需!
Docker Swarm
Swarm是Docker公司在2014年12月初新发布的容器集群管理工具。它可以把多个主机变成一个虚拟的Docker主机来管理。Swarm使用Go语言开发,并且开源,在github上可以找到它的全部source code。Swarm使用标准的Docker API,给Docker用户带来无缝的集群使用体验。2016年7月, Swarm已经被整合进入Docker Engine。
功能
Docker Swarm提供API 和CLI来在管理运行Docker的集群,它的功能和使用本地的Docker并没有本质的区别。但是可以通过增加Node带来和好的扩展性。理论上,你可以通过增加节点(Node)的方式拥有一个无限大的Docker主机。
Swarm并不提供UI,需要UI的话,可以安装UCP,不过很不幸,这个UCP是收费的。
架构
Swarm的架构并不复杂,可以说非常简单。Manager负责容器的调度,Node负责容器的运行,Node运行Docker Daemon和Manager之间通过HTTP来通信。Docker Client通过Manager上暴露的标准Docker API来使用Docker的功能。
Swarm的集群协调和业务发现可以支持不同的第三方组件,包括:
- Consul
- Etcd
- ZooKeeper
- Docker Hub
如果对集群协调的概念不熟悉,可以参考我的另一篇博客《使用Python进行分布式系统协调 (ZooKeeper,Consul, etcd )》
Swarm的基本容器调度策略有三种:
- spread 容器尽可能分布在不同的节点上
- binpack 容器尽可能分布在同一个节点上
- random 容器分布在随机的节点上
Swarm集群的高可用配置很容易,以下图为例:
manager配置在不同的AWS AZ中,通过领导选举选出Primary manager。
多个节点分布在不同的AZ中,同时Consul/etcd/ZooKeeper也需要配成冗余的。
特点
Docker Swarm的特点是配置和架构都很简单,使用Docker原生的API,可以很好的融合Docker的生态系统。
Kubernetes
Kubernetes是Google开发的一套开源的容器应用管理系统,用于管理应用的部署,维护和扩张。利用Kubernetes能方便地管理跨机器运行容器化的应用。Kubernetes也是用Go语言开发的,在github上可以找到源代码。
Kubernetes 源于谷歌公司的内部容器管理系统Borg,经过了多年的生产环境的历炼,所以功能非常强大。
功能
Kubernetes主要提供一下的功能:
- 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。
- 以集群的方式运行、管理跨机器的容器。
- 解决Docker跨机器容器之间的通讯问题。
- Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。
- 应用的高可用和靠扩展
- 支持应用的在线升级(Rolling Update)
- 支持跨云平台(IaaS)的部署
为了支持这些功能,Kubernetes做了做了很多的抽象概念,所以,刚开始使用Kubernetes,需要学习不少的新概念,包括:
- Pod
Pod是Kubernetes的基本操作单元,把相关的一个或多个容器构成一个Pod,通常Pod里的容器运行相同的应用,或者是相关的应用。Pod包含的容器运行在同一个Minion(Host)上,看作一个统一管理单元,共享相同的volumes和network namespace/IP和Port空间。 - Job
Job是一个生命周期比较短的应用,一般只会在出错的情况下重启,可以通过配置Job的并发和运行次数来扩展Job - Service
Service是一个生命周期比较长的应用,会在任何退出时重启,可以通过配置Service的复制(Replica)来达到高扩展和高可用 - Recplica Controller
Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods,一旦创建成功,pod 模板和创建的pods没有任何关联,可以修改pod 模板而不会对已创建pods有任何影响,也可以直接更新通过Replication Controller创建的pods
以上是一些核心概念,除了这些,Kubernetes还提供其它一些概念,来支持应用程序的运维,包括:
- Label
对系统中的对象通过Label的方式来管理 - Namespace
对对象,资源分组,可以用于支持多租户 - Config Map
提供全局的配置数据存储
总之,功能强大,系统概念繁多,比较复杂。
Kubernetes支持安装UI的addon,来管理整个系统:
架构
下图是Kubernetes的基本架构:
- Master
Master定义了Kubernetes 集群Master/API Server的主要声明,Client(Kubectl)调用Kubernetes API,管理Kubernetes主要构件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等组成。
Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况,然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod,那这些资源就不能再分配给其他Pod, 除非这些Pod被删除或者退出, 因此,Kubernetes需要分析集群中所有Minion的资源使用情况,保证分发的工作负载不会超出当前该Minion节点的可用资源范围 - Minion
Minion负责运行Pod,Service,Jobs, Minion通过Kubelet和Master通信。Proxy解决了外部网络能够访问跨机器集群中容器提供的应用服务。
- etcd
负责集群的协调和服务发现
特点
Kubernetes提供了很多应用级别的管理能力,包括高可用可高扩展,当然为了支持这些功能,它的架构和概念都比较复杂,当然我觉得为了获得这些功能,值!
Apache Mesos
Mesos是为软件定义数据中心而生的操作系统,跨数据中心的资源在这个系统中被统一管理。Mesos的初衷并非管理容器,只是随着容器的发展,Mesos加入了容器的功能。Mesos可以把不同机器的计算资源统一管理,就像同一个操作系统,用于运行分布式应用程序。
Mesos的起源于Google的数据中心资源管理系统Borg。你可以从WIRED杂志的这篇文章中了解更多关于Borg起源的信息及它对Mesos影响。
功能
Mesos的主要功能包括:
- 高度的可扩展和高可用
- 可自定义的两级调度
- 提供API进行应用的扩展
- 跨平台
下图是Mesos的管理界面:
架构
Mesos的基本架构如下
- Master
Master负责资源的统一协调和Slave的管理。 Master协调全部的Slave,并确定每个节点的可用资源,聚合计算跨节点的所有可用资源的报告,然后向注册到Master的Framework(作为Master的客户端)发出资源邀约。Mesos实现了两级调度架构,它可以管理多种类型的应用程序。第一级调度是Master的守护进程,管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成,用于运行应用程序的任务,比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。 - Slave
Salve运行执行器(Executor)进程来运行任务。 - Framework
Framework包括调度器(Scheduler)和执行器(Executor)进程,其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信,每种Framework由相应的应用集群管理。
Framework可以根据应用程序的需求,选择接受或拒绝来自master的资源邀约。一旦接受邀约,Master即协调Framework和Slave,调度参与节点上任务,并在容器中执行,以使多种类型的任务 - ZooKeeper
Zookeeper负责集群的协调,Master的领导选举等
特点
Mesos相比Kubernetes和Swarm更为成熟,但是Mesos主要要解决的是操作系统级别的抽象,并非为了容器专门设计,如果用户出了容器之外,还要集成其它的应用,例如Hadoop,Spark,Kafka等,Mesos更为合适。Mesos是一个更重量级的集群管理平台,功能更丰富,当然很多功能要基于各种Framework。
Mesos的扩展性非常好,最大支持50000节点,如果对扩展性要求非常高的话么,Mesos是最佳选择。
AWS ECS
ECS (Amazon EC2 Container Service )是亚马逊开发出的高度可扩展的高性能容器集群服务。在托管的 Amazon EC2 实例集群上轻松运行容器应用和服务。他最大的好处就是在云上,不需要自己管理数据中心的机器和网络。
功能
ECS继承了AWS服务的高扩展和高可用性,安全也可以得到保证。
在基本容器管理的基础上,ECS使用Task和Service的概念来管理应用。
Task类似Docker Compose,使用一个JSON描述要运行的应用。Service是更高一层的抽象,包含多个task的运行实例,通过修改task实例的数量,可以控制服务的伸缩。同时Service可以保证指定数量的Task在运行,当出现错误的时候,重启失败的Task
架构
下图是ECS的架构图:
使用EC2,ELB,安全组等大家熟悉的AWS的概念,AWS用户可以轻松管理你的容器集群。并且不需要付初基本资源以外的费用。
通过ECS agent可以是Container连接到ECS集群。ECS Agent使用Go开发,已开源。
我们并不清楚ECS的调度策略,但是AWS提供了一个例子,如果继承第三方的调度策略。
通过Cloud Watch Log,我们可以很方便的对整个集群进行监控。
特点
如果你是一个AWS的重度用户,ECS是个不错的选择,因为你可以是把你的容器集群运行在AWS的云上,管理起来非常方便。
比较
这里对几个平台做一个简单的比较:
Swarm | Kubernetes | Mesos | ECS | |
基本功能 | Docker原生的集群管理工具 | 开源的容器集群工具,提供应用级别的部署,维护和扩张功能 | 基于数据中心的操作系统 | 基于云的高可用,高扩展容器集群 |
高层次抽象 | 无 | Pod |
无 | Task Service |
应用扩展性 | 无 | 支持 | Framework 支持 | 支持 |
应用高可用性 | 无 | 支持 | Framework 支持 | 支持 |
集群协调和服务发现 | etcd |
etcd | ZooKeeper | / |
调度策略(Schedule) | 内置,可扩展 | 内置 | 两级别,可扩展 | 可扩展 |
监控 | Logging Driver | Heapter,ELK Addon | 内置 | CloudWatch |
用户界面 | CLI |
CLI API UI |
API UI |
CLI |
开发语言 | Go | Go | Java | NA |
开源 | 是 | 是 | 是 | 否 |
最大支持管理节点数 | 官方1000 |
官方1000 |
10000 | / |
总结
四个平台,Swarm是最轻量级的,功能也最简单,适于有大量Docker实例环境的用户。Kubernetes增加了很多应用级别的功能,适用于快速应用的部署和维护。Mesos最重,适用于已经有了相当的应用和容器混合的环境。ECS则推荐给AWS的用户或者不希望自己管理数据中心的云用户。