这篇文章是的电子书 《用Docker和容器玩转自动化与编排》 的一部分,现可以网上下载。
原谅我打了一个可能不恰当的比方,但是我们正在越来越多地被劝说把我们的基础设施和应用想象成家中的牲口。我们关心牲口,但是程度可能不如宠物。我们尽量不对牛群漠不关心让它们缺乏关爱;我们想要它们呆在在最好的牧地上啃草;我们不时地疏散走拥挤在一起或者踏入危险区域的牛群;如果它们生病了,我们想要有兽医能把它们照顾好直到康复。
在云原生容器平台( cloud-native container platforms )的世界中,如果我们的应用是牧场的牲口,那编排和调度器框架扮演了所有这些照顾者的角色。一个优秀的的应用牧民会将资源利用率最大化,同时均衡系统因容错需要不断变化的需求。
在IT界的有一个完美的风暴正在形成,其包含三个重要的趋势:真正可编程的基础设施架构的崛起,这包含云,配置管理工具和容器;高适应能力应用架构的开发,包含微服务的使用,大规模分布式消息/日志处理,和事件驱动的应用;新流程和新方法论的出现,如精益和DevOps。
在所有这些革新面前,为什么我们要在乎一个容器编排和调度的主题?原因是我们应该像后农业革命中那些的成功的牧民一样关心他们如何放牧牛群。
托管和部署容器化应用目前有很多的选择,如果我们我只考虑现代的云平台,我们可以把它们分成三类:基础设施即服务(IaaS),容器即服务(CaaS),和平台即服务(PaaS)。
根据部署的应用的差别,每个类别都有自身的强项和弱点。尽管一些机构趋向于根据直觉,分析报告或者与厂商现有的关系来简单地决定使用哪一种平台,但这是一个需要进行严肃评估的根本性决定。
平台的选择对于能实现哪一种编排和调度有重大的影响。下面的比较能让你了解每一种类型提供的关键抽象,控制面和合适的应用场景 。需要值得注意的是,容器即服务仍然是一个存在热烈争议的领域 - 很多人说我们传统上被称作的容器服务也是CaaS的一种;然而,Docker建议使用 一组不同的条件 来认定一个CaaS方案,而这些条件中最重要的是云基础设施不可知性( cloud infrastructure agnostic )。我们认为广阔市场对于这个产品类别仍然有被解释的空间。
顺着我们之前放牧的比方,我们把计算资源(CPU,内存,磁盘,网络等)想象成我们的牲口吃草玩耍的牧地。编排和调度的角色就是将应用和资源匹配,就如将牲口匹配到牧地,并保证方式以最有力有效。第一眼看,将应用高效地匹配到资源可能感觉不是特别困难,但是用解决装箱问题(bin-packing)的方式来优化资源利用率在计算上一个 NP 问题。再加上下面易失和临时的云网络,我们面对的绝对是一个困难的挑战。
从一个IaaS创建一个容器化的应用好比买一款空地然后从头开始修建你的牧场 - 这十分的费劲,但是你拥有最大程度的控制。而利用CaaS就像购买一块牧场,然后雇佣专业的牧人来搭建围栏并且看管牲口。这让你有对土地的可见性,声明你的想法,并且不需要自己做即时即地的决定。在PaaS上部署应用好比实际将牲口付托给另外的牧民。可以说,这样这就有多余的精力去关注真正值得关注的事情(购买并且培育最好的牲畜,最快的把你的牛推向市场),但是你可能就不知道牧地上都发生了什么事情,而且你可能不赞成其他牧民管理牧场的方式。
在我们的OpenCredo的工作日子里,我们和多个客户一起设计,构建并且管理容器化的应用和平台。下面的部分是我们经历的两个案例的分享。这些例子用来说明在创建这些编排的技术栈的时候经历的决策过程。
对于我们的第一个客户,我们实现的编排器是Apache Mesos。客户期望能混合持久运行的容器化应用服务和基于Spark的批量数据处理。Mesos自身实际上就是一个“数据中心内核”,因为它把计算资源从基础设施集群抽象了出来,并且把这些资源提供给了框架,比如让Mesosphere的Marathon运行持久运行服务,Chronos执行批量式任务,让Spark处理数据处理的工作量。部署和运行Mesos是一件运维复杂的事情;然而它已经被证明可以在大规模使用,它受到了Twitter,Airbnb和eBay的喜爱,可以混合不同类型的工作量,可以跨整个数据中心调度应用,这些对于客户来说都是非常有吸引力的提案。
Mesos通过Ansible进行部署和管理,并且通过Jenkins来构建容器化应用并且部署进Marathon框架。服务发现通过结合Consul, Registrator和srv_router来实现,而因为容错进行的服务重启或者重新分配是由Marathon提供的。QA团队可以在Google Cloud Platform中启动自己的的Mesos平台实例,这可以减少资源竞争以加快测试(这在之前是一个问题)。然而,我们吸取到了几个严重的教训,因为个人的环境资源受限和完整的平台是以不同方式调度工作量的。例如,在一个单机器组成的集群中运行多个Mesos框架通常导致其中一个框架资源耗尽。
在这个项目中,Kubenernetes通过Terraform和Ansible被部署到了AWS上,主要的目的是为开发者提供IaaS之上一层的抽象,让他们无需在PaaS花大工夫。 Google Container Engine因为客户端/厂商的限制无法使用。很容易说大多数的机构会最终构建某一种形式的PaaS,因为很多PaaS的特性对于一个典型的开发团队是必要的,如测试,部署,服务发现,存储,数据库集成和开发者社区引导。相应的,这个案例确实也实现了很多这种特性。
Kubenenetes提供了命名空间的隔离,这对于在同一个集群上运行多个测试和staging的部署有用。分隔的集群被用来做真正的隔离。部署是通过集成Kubenernetes API的或者kubectl CLI工具来管理的。持续集成使用的是Jenkins框架,它也负责构建和测试我们应用服务。服务发现由Kubernetes自带,开箱即用。因为具备Node健康检查和应用/容器级别的活动性探针健康检查,其也提供了良好的容错。其底层的IaaS层也提供了存储和数据库集成,并且结合版本控制系统和一个内维护良好的wiki,开发模式得到很好的共享和重用。
这篇文章的目的是基于你自己的需求,和相应的编排和调度机制,提供一些容器平台选择的参考。然而,这主要基于两个客户示例案例研究。有很多其他的产品组合及由其催生的技术栈,包括 全部混杂使用Docker Swarm和Mesos ,包括 IBM的基于PaaS的云编排 。
这里是一些我们在OpenCredo目前为止学习到的主要的学习经验:
/dev/random
。容器化的应用通常会不明所以就挂起(hang住),而在调试的时候回发现是一个安全方面的操作(如:会话或者加密的令牌生成操作)阻塞了它。 原文链接: Containaer Orchestration and Scheduling: Herding Computational Cattle (翻译:钟最龙)