Kubernetes的核心优势是为应用程序开发人员提供强大的工具来编排无状态的Docker容器。虽然有多个计划将项目的范围扩展到更多的工作负载(如分析和有状态的数据服务),但这些计划仍然处于非常早期的阶段,还有待观察。
Apache Mesos
Apache Mesos最初是UCBerkeley为创建下一代集群管理器而诞生的项目,并从如谷歌的Borg和Facebook的Tupperware中吸取经验教训。但是Borg和Tupperware是单体架构,并且是和物理基础设施绑定的封源专有技术。Mesos引入了模块化架构,采用开源的方法,且其设计完全独立于底层基础架构。基于这些因素,Mesos很快被Twitter、Apple(Siri)、Yelp、Uber、Netflix以及许多领先的科技公司所采用,以支持他们在微服务、大数据和实时分析到弹性伸缩的一切实践。
作为一个集群管理器,Mesos的架构是为了解决一组非常不同的挑战:
1.将数据中心资源整合成一个单一的池,以简化资源配置,同时在私有或公共云之间提供一致的应用程序和操作体验;
2.在相同的基础设施上使用不同的工作负载,比如分析、无状态微服务、分布式数据服务和传统应用程序,以提高利用率,降低成本和空间;
3.特定应用程序的任务(如部署、自修复、扩展和升级)设置为自动化day-two 操作;提供高可用的容错基础设施;
4.在不修改集群管理器或现有应用程序的情况下,提供常绿的可扩展性来运行新的应用程序和技术;
5.将应用程序和底层基础设施弹性扩展到数万个节点。
Mesos的独特之处还在于,可以单独管理各种不同的工作负载——包括传统的应用程序,如Java、无状态Docker微服务、批处理作业、实时分析和有状态的分布式数据服务。Mesos广泛的工作负载覆盖来自于它的两级架构,它支持“应用感知”的调度。应用感知调度是通过将应用程序特定操作逻辑封装到“Mesos框架”(类似于运行中的runbook)来完成的。
Mesos Master资源管理器,提供这些底层基础设施的框架部分,同时保持隔离。这种方法允许每个工作负载有自己专用的应用程序调度器,它了解其对部署、缩放和升级的具体操作需求。应用程序调度程序也独立地被开发、管理和更新,这让Mesos保持高度可扩展性,支持新的工作负载,或者随着时间的推移增加更多的操作能力。
以一个团队如何管理升级为例。无状态应用程序可以从“蓝/绿”部署方法中获益;当旧的应用程序还在使用的时候,另一个完整版本的应用程序已经spun up,当旧的应用程序被销毁时,流量切换到新的应用程序。但是,升级像HDFS或Cassandra这样的数据工作负载需要一次脱机,维护本地数据量以避免数据丢失,执行特定序列的升级,并在升级之前和之后对每个节点类型执行特殊检查和命令。这些步骤中的所有环节针对特定的应用程序或服务,甚至是特定版本进行的。这使得用常规容器编排调度器管理数据服务变得非常困难。
Mesos具备按需管理每个工作负载的能力,使得许多公司将Mesos作为一个统一的平台,并通过其将微服务和数据服务结合运行。运行数据密集型应用程序的一个通用参考架构是“SMACK堆栈”。
清晰时刻
注意:我们在描述Apache Mesos的过程中,没有提及任何关于容器编排的内容。那么,为什么人们总是会将Mesos与容器编排联系起来呢?容器编排是一个可以在Mesos模块化架构上运行的工作负载的例子,它使用的是构建在Mesos上的一个专门的编排“框架”Marathon。Marathon最初是为了在cgroup容器中编排应用程序(如JARs、tarball、ZIP文件)而开发的,并且在2014年成为第一批支持Docker容器的容器编排之一。
因此,当人们拿Docker、Kubernetes和Mesos比较时,他们实际上是在对比Kubernetes、Docker Swarm和Mesos上运行的Marathon。
为什么这很重要?因为Mesos根本不关心上面跑的是什么。Mesos可以为Java应用服务器、Docker容器编排、Jenkins CI Jobs, Apache Spark analytics, Apache Kafka streaming以及更多的共享基础设施提供集群服务。Mesos甚至可以运行Kubernetes或其他容器编排,尽管还没有对外集成。
Mesos的另一个考虑(以及为什么它对许多企业架构师有吸引力)是它在运行任务关键工作负载时的成熟度。Mesos已经在大规模生产环境下运行(数万台服务器)超过7年,这就是为什么它比市场上其他技术更成熟,更可靠的原因。