简单理解Kubernetes,Mesosphere和Docker Swarm

IT世界正在转向容器,但为了控制管理这些容器,我们又需要容器的管理程序。这就是需要使用Kubernetes,Mesosphere和Docker Swarm的理由。

容器是一种虚拟化应用程序的轻量级方法,是任何DevOps计划的重要元素。但是你怎么管理所有这些容器呢? 容器编排程序Kubernetes , Mesosphere Marathon和Docker Swarm使得管理容器变得轻松。这些开源工具不可互换,也不能直接相互竞争。 在一定程度上,它们都提供以下特征:

1.配备:这些工具可以在容器集群中设置或计划容器并启动它们。 理想情况下,它们会根据您的要求(例如资源和地理位置)在最佳VM中启动容器。

2.配置脚本:脚本允许您以相同的方式将特定的应用程序配置加载到容器中。通常,这些都是用YAML或JSON编写的。

3.监视:容器管理工具跟踪和监视处于集群中的容器的运行状况。 当容器崩溃时,监视工具将启动一个新实例。如果服务器失败,则该工具将重新启动另一台主机上的容器。 这些工具还运行系统运行状况检查,并报告容器他们所在的VM以及服务器的不正常情况。

4.滚动升级和回滚:部署新版本的容器时,或在容器中运行的应用程序时,容器管理工具会自动在容器集群中更新它们。 如果出现问题,您可以回滚到已知的良好配置。

5.服务发现:在旧式应用程序中,您需要明确指定软件可以找到运行所需的每项服务。容器使用服务发现来找到它们 。 听起来很熟悉? 这应该是的。 正如分析师Dan Kusnetzky指出的,容器的工作方式非常类似于在2000年代得到如此关注的面向服务的架构(SOA) 。 对于那些错过了这种技术的人来说,将应用程序分解成单独的独立服务有其技术障碍:网络通信比进程间通信慢一个数量级,容器因为倾向于使用同样的服务器资源,运行远远快于SOA。)这些工具帮助前端应用程序(比如WordPress实例)通过DNS或代理动态发现其对应的MySQL实例。

6.建立容器策略:您希望容器在哪里启动? 每个CPU应分配多少个?所有这些问题和更多可以通过设置正确的容器策略来回答。

7.互操作性:当然,他们应该与您现有的IT管理工具无缝一起工作。

最后,所有这三种容器管理工具都与各种云平台配合使用,包括OpenStack Magnum和Azure容器服务 。

以上是三者一般性介绍。 让我们来了解具体细节。

Docker Swarm
Docker Swarm是Docker Native Orchestration(Docker原生编排器,一个人很少使用的名字) - 它是一个本地Docker集群管理器。

Docker Swarm 在2016年6月(1.12)版本中将其功能并入完整的Docker应用程序之前,需要花费大量的手动工作来启动和运行。 它有几个新产品通常有的启动问题,例如服务发现程序(Consul或CoreOS etcd )会在Docker Swarm启动之前运行。 这造成了一个“鸡或蛋”问题,系统管理方面很难解决。即使在解决了这些启动问题后,仍然需要花费大量的精力部署Swarm。 因此,即使Docker是800磅的大型容器技术,其容器管理的计划在市场接受度方面也远远落后。

但是,Docker Swarm正在获得新的用户。 目前它仍然落后于Mesosphere的数据中心操作系统(DC / OS)和Kubernetes,但这可能会改变。 这是因为新的和改进的Docker Swarm更容易部署。 我已经和几个DevOps谈过,他们认为与运行Kubernetes或Mesos集群相比, Docker Swarm是一个快照。

如果你已经是一个有经验的Docker用户,Swarm的学习曲线很容易。 Docker原生编排器使用单节点Docker概念,并将它们扩展到Swarm。 一旦你有Docker节点运行,Swarm设置是很少的。 例如,您可以使用单个shell命令将Docker实例添加到Swarm集群。 更新的Swarm还包括支持滚动更新,节点之间的传输层安全加密,简单的负载平衡和容易的服务抽象。

当然,还有改进的余地。 例如,当前版本不支持运行状况检查和自动回滚。Swarm用户也抱怨很多实现问题 。 例如,许多用户抱怨Swarm不能正确支持多主机容器网络 。

由于Docker Swarm是内置在Docker中的,Swarm总是值得考虑的。 潜在用户应该意识到,这是一个正在进行的工作项目,而不是一个即可解决您的容器部署和管理问题的解决方案。

Mesosphere Marathon
Marathon是一个用于Mesosphere DC / OS和Apache Mesos的容器编排平台。 DC / OS是基于Mesos分布式系统内核的分布式操作系统。 Mesos又是一个开源集群管理系统。 Marathon提供现有状态应用程序和基于容器的无状态应用程序之间的管理集成。

Marathon实际上早于容器。 正如Mesosphere联合创始人兼首席技术官Tobias Knaup在最近的一次采访中所解释的,“ Marathon从一开始就被设计为通用工作负载管理 ,甚至在Docker变成一件大事之前。 目标是建立一个从旧世界到新世界的桥梁,使现有的应用程序可以部署和扩展,只需很少改变或无须改变。“以Knaup的观点看,至少,这使它非常适合长时间运行的任何东西,它是一个现代应用程序架构,如微服务或更传统的三层企业应用程序。

虽然Marathon有一个用户界面,你会将其视为一个应用程序,其实更可以将其作为一个来管理容器的框架。 这对DevOps的开发人员有帮助,因为容器通过REST API与Marathon一起工作。

Marathon具有许多功能,包括高可用性、服务发现和负载平衡 。 如果在DC / OS上运行它,您的应用程序也会获得虚拟IP路由。

作为一个更成熟的项目,Marathon没有Docker Swarm的初期问题。另一方面,Marathon有一个更陡峭的学习曲线。由于Marathon只能在带有Mesos的软件堆栈上运行,这增加了另一层的复杂性。 最后,一些功能(例如身份验证)仅适用于DC / OS上的Marathon。这为你的堆栈增加了一个抽象层。

Kubernetes
Kubernetes,又名K8S,开始是作为一个Google程序: Borg 。

自从Kubernetes推出以来,它已被移植到Azure,DC / OS以及几乎所有可以命名的云平台。 唯一的例外是Amazon Web Services(AWS) 。 即使这样,CoreOS也让用户在AWS上部署Kubernetes集群 。

Kubernetes有巨大的供应商支持。 今天,Kubernetes由Linux基金会的云原生计算基金会主办 。 此外,还有来自众多公司的Kubernetes发行版,包括Red Hat OpenShift , Kubernetes的Canonical发行版 , CoreOS Tectonic以及英特尔和Mirantis 。

为什么使用它? 除了它自己部署在Google的大型数据中心是一个证明外,Kubernetes还拥有自我修复 , 自动化推出和回滚和存储编排。这个功能列表会持续增加。总之,无论你想用你的容器做什么,Kubernetes都可以管理它。

互操作性也是一个Kubernetes巨大加分选项。 Sam Ghods是基础架构即服务(IaaS)云提供商Box的联合创始人,他称赞Kubernetes说:“我可以编写一个JSON规范,并将其提交给在任何地方运行的任何Kubernetes集群,并能够重新创建正确的拓扑和完全正确的基础设施,根据我的需要。“

另一个优点是“Kubernetes是cloud-agnostic,”软件工程师Erez Rabih说。 “你可以在AWS,Google Cloud,Microsoft的Azure,Rackspace等上运行你的集群,它应该或多或少都可以运行。”确实,Kubernetes开发人员的短期目标是使你使用群集Cluster Federation跨多个云架构运行由Kubernetes管理的Docker容器。

当然,Kubernetes不是完美的。 有出现两个问题。 首先, 负载平衡很困难 。 当然最终,Kubernetes ingress 会使得从Kubernetes内部运行外部负载均衡器变得容易,但这仍然是一件进展中的工作。 其次,Kubernetes擅长自动修复问题。但它是如此优秀,容器一旦崩溃,会很快重新启动,你甚至不会注意到你的容器崩溃了。 为了解决这个问题,您需要添加一个集中式日志系统。

哪一个适合你?
Kubernetes的首席工程师Brendan Burns显然有自己的偏见,但他总结了这些容器管理系统之间的差异:“ Mesos和Kubernetes主要旨在解决运行集群应用程序的类似问题 ; 他们有不同的历史和不同的方法来解决这个问题。 Mesos是聚焦集中在非常通用的调度和插入多个不同的调度器;相反,Kubernetes从根本上被设计为容器构建分布式应用程序的环境。 它将复制和服务发现的作为原生核心功能,而这样的事情在Mesos中是通过框架添加。 ... Swarm是Docker努力扩展现有的Docker API,使一群机器看起来像一个单一的Docker API。

听上去好像是对的。

如果从长期的支持视图和功能列表比较,赢家显然是Kubernetes。在AWS和Docker之外,每个人都支持它。

幸运的是,您可以混合和匹配这些程序,以创建您公司需要的独特混合。所有三个人都可以很好地彼此工作。 这不容易,但它是可行的 - 值得探索 。

但是,最佳选择取决于您的具体需求。例如,如果你的公司有Docker专业人员,你可能已经在运行Docker Swarm。 如果它为你工作得很好,为什么还要切换到另一个系统? Docker也将长期存在。 Marathon有独特的优势,给你一种方式(虽然是多层次的方式)来处理你的容器和你的旧应用程序。 几个DevOps专家告诉我,Marathon也比Kubernetes更灵活。

A guide to Kubernetes, Mesosphere, and Docker Swar