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

《容器的编排和调度：计算型牛群的放牧》要点：
本文介绍了容器的编排和调度：计算型牛群的放牧，希望对您有用。如果有疑问，可以联系我们。

原谅我打了一个可能不恰当的比方,但是我们正在越来越多地被劝说把我们的基础设施和应用想象成家中的牲口.我们关心牲口,但是程度可能不如宠物.我们尽量不对牛群漠不关心让它们缺乏关爱；我们想要它们呆在在最好的牧地上啃草；我们不时地疏散走拥挤在一起或者踏入危险区域的牛群；如果它们生病了,我们想要有兽医能把它们照顾好直到康复.

在云原生容器平台(cloud-native container platforms)的世界中,如果我们的应用是牧场的牲口,那编排和调度器框架扮演了所有这些照顾者的角色.一个优秀的应用“牧民”(application “farmers”)会将资源利用率最大化,同时均衡系统因容错需要不断变化的需求.

在IT界的有一个完美的风暴正在形成,其包含三个重要的趋势：真正可编程的基础设施架构的崛起,这包含云,配置管理工具和容器；高适应能力应用架构的开发,包含微服务的使用,大规模分布式消息/日志处理,和事件驱动的应用；新流程和新方法论的出现,如精益和DevOps.

在所有这些革新面前,为什么我们要在乎一个容器编排和调度的主题?原因是我们应该像后农业革命中那些成功的牧民一样关心他们如何放牧牛群.

托管和部署容器化应用目前有很多的选择,如果我们我只考虑现代的云平台,我们可以把它们分成三类：基础设施即服务(IaaS)、容器即服务(CaaS)和平台即服务(PaaS).

根据部署的应用的差别,每个类别都有自身的强项和弱点.尽管一些机构趋向于根据直觉,分析报告或者与厂商现有的关系来简单地决定使用哪一种平台,但这是一个需要进行严肃评估的根本性决定.

平台的选择对于能实现哪一种编排和调度有重大的影响.下面的比较能让你了解每一种类型提供的关键抽象,控制面和合适的应用场景 .需要值得注意的是,容器即服务仍然是一个存在热烈争议的领域 – 很多人说我们传统上被称作的容器服务也是CaaS的一种；然而,Docker建议使用一组不同的条件来认定一个CaaS方案,而这些条件中最重要的是云基础设施不可知性(cloud infrastructure agnostic).我们认为广阔市场对于这个产品类别仍然有被解释的空间.

1. 基础设施即服务(IaaS)

描述：在应用部署之前必须组合并准备好的抽象化计算资源(CPU、内存、存储、网络等)

抽象核心：计算资源

示例：AWS、Azure、Digital Ocean、Google Cloud Platform、IBM Cloud Infrastructure、VMware

应用调度：

• 手动或者通过配置管理(CM)工具
• 资源需求通常通过基础设施选择和配置指定
• 容错通常由程序实现(implemented procedurally)

服务发现：

• 手动或者通过配置管理工具,如Puppet、Chef或Ansible
• CM工具通常与分布式的KV存储结合,如Consul或Zookeeper,以进行服务发现

资源分配(provisioning)：

• 手动或者通过配置管理工具,如Puppet,Chef或者Ansible
• 操作员根据资源分配和分布来进行容错和伸缩的措施

数据存储/中间件：通常是数据库即服务(DBaaS)或者自托管

典型应用场景：进行云迁移并且需要迁移内部部署的虚拟机和同类型应用,或者需要对资源的组合和分配进行更细粒度控制的公司机构

2. 容器即服务(CaaS)/容器化服务

描述：在计算资源的基础上提供了一层抽象以允许容器的部署和编排

抽象核心：容器

示例：CoreOS Tectonic、Docker Cloud、Google Container Engine(GKE)、HashiCorp Nomad、IBM Container Service、Joyent Triton、Mesosphere Datacenter Operation System(DCOS)

应用调度：

• 容器调度通常由平台自带,能力水平可能很原始可以很复杂
• 资源需求以声明式的方式指定
• 自动处理容错

服务发现：从程序式的指定方式(如在Mesos中,Registrator和srv_router)和声明式指定方式(如Kubernete中的service和label)

资源分配(provisioning)：

• 通常由平台自带,并且有如bin-packing and spread等算法来最大化资源利用率和容错
• 容器实例的伸缩可以通过平台实现

数据存储/中间件：通常是基于IaaS的DBaaS,也有可能供容器化的数据库

典型应用场景：已经在开发云原生的应用,并且想从IaaS的运维复杂度中解放出来,但是不想使用那些不合胃口的PaaS的公司.

3. 平台即服务(PaaS)

描述：在计算基础设施上提供了一层抽象允许应用的部署和编排

抽象核心：应用

示例：AWS Elastic Beanstalk、Deis、Google App Engine、Heroku、IBM Bluemix、Pivotal Cloud Platform、Red Hat OpenShift

应用调度：

• 平台自带
• 资源需求以声明式的方式指定
• 自动处理容错

服务发现：通常平台自带,如服务发现“作为一个服务”提供

资源分配(provisioning)：

• 对用户不可见
• 费用开销通常基于资源的分配和消耗情况

数据存储/中间件：作为平台的一部分进行提供,例如,作为一个服务的代理(broker)

典型应用场景：可以是那些想要削减维护平台基础设施的创业公司,也可以是寻求标准化流程和提升开发者效率的大规模机构.

顺着我们之前放牧的比方,我们把计算资源(CPU、内存、磁盘、网络等)想象成我们的牲口吃草玩耍的牧地.编排和调度的角色就是将应用和资源匹配,就如将牲口匹配到牧地,并保证方式以最有力有效.第一眼看,将应用高效地匹配到资源可能感觉不是特别困难,但是用解决装箱问题(bin-packing)的方式来优化资源利用率在计算上一个NP-hard问题.再加上下面易失和临时的云网络,我们面对的绝对是一个困难的挑战.

（编辑：ASP站长网）