容器的编排和调度：计算型牛群的放牧(2)

从一个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(https://mesosphere.com/blog/2015/05/20/hyperscaling-docker-swarm-with-mesos-mesosphere-hackweek/),包括IBM的基于PaaS的云编排(http://www-03.ibm.com/software/products/en/ibm-cloud-orchestrator).

这里是一些我们在OpenCredo目前为止学习到的主要的学习经验：

工具链

• 尽可能的自动自动化,这可以节省时间,可以大规模的重用,可以减少基础设施和配置的差异.
• 不鼓励但是允许人工的干预,特别是当把尚处于新兴阶段的容器技术引入到公司的时候.我们都知道不应该直接SSH到生产环境的主机上,但是保留这个入口作为一种救命稻草,可能会在关键时候挽拯救你的商业.

性能错误

• 语法错误,又被称作“对业务造成影响(business impact)”错误,在云和容器的世界里尤其重要,甚至比底层的基础设施错误更加的重要.即使你一半的生产环境都挂掉了也没关系,只要你的系统仍然能优雅的降级并让客户正常获取价值.我们经常看到运维团队被基础设施错误警报淹没,但是他们不知道实际的对用户造成的影响.
• 了解Brendan Gregg的USE(Utilization、Saturation and Error,即利用率、饱和量和错误数)方法论和Tom Wilie的RED(Rate、Error and Duration,即请求频率、错误频次和时长分布)方法论.我们发现这些方法对于解决性能的问题特别的有用.

监控和资源竞争

• 在所有的层次都需要具备可见性.容器监控和管理是任何在生产环境中使用容器方案的公司应主要担心的问题.
• 正确地编写程序,只对于必要的信息记录日志.
• 提供业务层(语义)的指标.这有助于促进关键的相关利益者的采纳度,也会有助于解决故障.
• 网络：确保正确地规划计算实例的大小.例如,你的应用只需要一个小型实例提供的CPU和内存就够了,但是你配置了相应的网络带宽了吗?
• 一定要对于磁盘和CPU层进行全面的监控.对于CPU,如果你部署的是一个公有云,那请留意被偷窃时间(http://iamondemand.com/blog/who-stole-my-cpu/).
• 熵的缺少(lack of entropy)是很难调试的问题,在容器化的环境中经常出奇的看到多个容器在争夺主机的/dev/random.容器化的应用通常会不明所以就挂起(hang住),而在调试的时候回发现是一个安全方面的操作(如：会话或者加密的令牌生成操作)阻塞了它.

文/钟最龙?译

文章出处：Docker微信公众号

（编辑：ASP站长网）