大部分软件系统是随时间演进的,新旧功能会交替,不断变化的用户需求意味着一个高效的系统必须能够迅速扩展或收缩资源。通常在一个单独的数据中心或区域为完成接近零宕机的目标,就需要自动故障转移(fail-over)到预调校就绪(pre-provisioned )的备份系统,。
因此,一些大型公司和单位经常有多个这样的备份系统在运行,另外一种情况是,一些系统区别于主要系统,是为了偶尔运行的数据挖掘任务,但是又需要更多资源而且需要和现存系统交互。
当拥有这样多个资源系统时,重要的是要确保他们有效地使用,不要被闲置,可以应对突然激增的需求。因此需要在成本效益与迅速扩张的规模之间平衡是一项非常艰巨的任务。
管理这样的不平凡系统是一项具有挑战性工作,复杂性是不能确定的,也是不可能在某个层次特别关照某个机器,当一台机器发生问题是,应该是立即关机消失并被替换,而不是像护士医生治病一样修复后再上线。
当前有各种工具和解决方案能够帮助实现这些挑战,这里主要集中几个orchestration工具,这些工具能帮助我们以集群方式在主机上启动容器,并能够彼此连接,同时也要考虑扩展性和自动失败恢复特性。
Swarm
Swarm 是一个基于Docker的原生集群工具,Swarm使用的是标准Docker API,这意味着容器能够使用docker run命令启动,Swarm将会接管一切,选择合适的主机来运行容器,这也意味着其他使用Docker API的工具比如Compose 和 bespoke脚本也能在无需任何改变情况下使用Swarm,从而享受到集群的优点而不是单个主机。
Swarm基本架构是直接的,每个主机运行一个Swarm代理,一个主机运行一个Swarm管理者,这个管理者负责指挥和调度这些主机上的容器,Swarm能以高可用性模式运行,etcd, Consul or ZooKeeper 中任何一个都可以用来将失败恢复提交给后备管理者处理,当有新主机加入到集群,有几种发现主机的方式,也就是discovery发现方式,缺省默认情况,基于discovery的token被使用,也就是主机地址会被保存到一个列表中,而列表存储在Docker Hub上。
Fleet
Fleet 是一个来自CoreOS的集群管理工具,自诩为低级别的集群引擎,也就意味着,它可支持从基础层到高层解决方案如Kubernetes。
fleet最显著的特点是基于systemd建立,后者提供单个机器的系统和服务初始化,fleet扩展到集群上的机器,Fleet能够读取systemd单元文件,然后能在单个机器或集群中集群中进行调度。
上述图显示每个机器运行一个引擎和一个代理,任何时候在集群中只有一个引擎会被激活,但是所有代理会一直运行,Systemd unit单元文件被提交给引擎,然后在 “least-loaded” 最少加载的机器上用来调用任务工作,单元文件会简单运行一个容器,代理会照顾启动单元unit和报告状态,Etcd用来激活机器之间的通讯,存储集群和unit单元的状态。
这个架构用来设计为失败冗余,如果一个机器当机,这个机器上的任何单元unit会在新的主机上被重新启动。
Kubernetes
Kubernetes 是一个由google推出的容器管理工具,基于他们上个世纪基于容器产品化管理的经验,它的几个概念比较特殊需要理解。如Pods、Flat Networking Space、Labels 和Services
Kubernetes简单介绍
Mesos 和 Marathon
Apache Mesos是一个开源集群管理器,是为大型集群入数百数千台主机规模而设计,支持在多租户之间分发工作负载,一个用户的Docker容器运行另外一个用户的Hadoop 任务。
详细见 使用Mesos和Marathon管理Docker集群
总结比较
1. Swarm的优点和缺点都是使用标准的Docker接口,使用简单,容易集成到现有系统,但是更困难支持更复杂的调度,比如以定制接口方式定义的调度。
2.Fleet是低层次且相当简单的管理指挥层,能作为运行高级别管理工具如Kubernetes 的基础。
3.Kubernetes 是自成体系的管理工具,有自己的服务发现和复制,需要对现有应用的重新设计,但是能支持失败冗余和扩展系统。
4.Mesos是低级别 battle-hardened调度器,支持几种容器管理框架如Marathon, Kubernetes, and Swarm,现在Kubernetes 和 Mesos稳定性超过Swarm,在扩展性方面,Mesos已经被证明支持超大规模的系统,比如数百数千台主机,但是,如果你需要小的集群,比如少于一打数量的节点服务器数量,Mesos也许过于复杂了。
原文: Swarm v. Fleet v. Kubernetes v. Mesos