基于Docker的容器调度系统

Docker Swarm（三）架构篇

Swarm调度介绍

Swarm提供了几种不同的方法来控制服务任务可以在哪些节点上运行。
可以指定服务是需要运行特定数量的副本还是应该在每个工作节点上全局运行。
您可以配置服务的 CPU或内存要求，该服务仅在满足这些要求的节点上运行。

swarm在用命令swarm manager启动swarm manager时，可用--strategy指定调度策略。
swarm提供了三种调度策略计算节点的排名，在调度（例如选择哪一个节点运行容器时）时，取排名最前的节点

这三种调度策略是：

• spread 默认策略，swarm优先选择占用资源（如CPU、内存等）最少的节点，能保证集群中所有节点资源的均匀使用。
• binpack 与spread相反，它的目的是尽可能地填满一个节点，以保证更多空余的节点。
• random 随机选择节点。一般用于开发测试阶段。

面向容器技术资源调度关键技术对比

面向容器技术资源调度关键技术对比
原文：面向容器技术资源调度关键技术对比

在资源调度器中，资源分配理念：拍卖、预算或抢占，往往是混合运用。资源分配理念，折射出了资源调度器所在的生态系统或者说周边配合系统的成熟度、运行习惯。例如，Google从最早的广告拍卖机制起，拍卖的理念在Google内部就形成了一种经验、选择的爱好或者内部的默契，那么资源竞拍被分配出来的结果，大家很容易达成一致、理解。而国内企业，往往是预算驱动，周边系统的运行习惯，更趋向预算、采购，谁预算谁使用。这种环境下，资源被谁使用基本可以预见，成本也是比较容易找到归属者。在拍卖机制下资源抢占，初始分配是不大会发生，只有在运行时发生资源不够用的时候出现，低优先级的任务被Kill。在预算机制下，资源分配初期、运行时过程中，都会发生抢占。不同哪种分配背后共同追求的资源流动性是一致的。拍卖的另外一种好处是便于资源流动起来，不仅是资源利用率提升，更是资源投入产出比的最大化。而预算往往是一次性的，重点业务资源优先保障，使得适应性、灵活性、激励业务效率提升变得不如拍卖。

资源共享

资源共享的过程离不开两个维度：资源粒度、时间片。资源的效率=Σ(在线资源粒度时间片利用率) -Σ(资源离线粒度*时间片)。资源效率包括两部分，在线部分和离线部分，离线部分主要是机器故障到恢复的过程，优化这部分资源效率，提升服务器在线率。软硬件故障通用措施有：故障预警、故障检测、故障自动修复、故障自动化处理流程等。效率简单的按照在线减去离线，只是为了描述：减少离线的浪费，有利于总体资源效率的提升。实际计算出来的数值不一定和真实现状相一致的含义。下面章节提到的资源共享，主要是在线资源部分。