Docker Swarm:经济高效的容器调度

本文讲的是Docker Swarm:经济高效的容器调度【编者的话】本文探讨了几种容器调度策略,并以内存约束为例,讨论了如何利用Docker Swarm,通过资源约束实现容器的合理调度。其中,对容器资源的约束,包括硬约束和软约束,硬约束是指内存资源的实际限制条件,而软约束则是当服务器实际内存资源有足余时,容器可自由使用,一旦内存资源有所紧缺,则约束开始生效。硬约束和软约束的结合使用,可以在减少资源浪费的同时保证服务的稳定性。

我们每天在数百台服务器上运行成百上千个容器,面临的最大一个挑战是怎样高效地调度容器。容器的调度是指在一组服务器上处理容器分配的问题,以保证服务能平稳运行。由于这些需要调度的容器是客户应用程序的组件,我们必须在还未知晓其性能特点之前进行调度。

不合适的调度方法会导致以下可能的结果:

  1. 过多的资源配置——意味着更高的成本。
  2. 过少的资源配置——意味着用户的稳定性差。

合适的调度方法对我们而言很重要,以经济高效的方式,提供最好的用户体验。

随机性调度策略

起初,在我们的早期产品中使用了相同的调度方法。这个方法(在Docker Swarm之前)没有以任何方式对容器的运行进行约束,而只是简单地随机选择一个服务器。

但是,运行全栈环境和运行代码段是完全不同的事——我们很快发现,这个解决方案并不理想。我们的服务器经常因繁忙导致CPU过载和内存不足。

硬约束条件

我们一起根据需要,定义了一种新的调度器:不再随机选择服务器;要能约束运行所需的资源分配,理想情况下,还要易于部署。

幸运的是,Docker Swarm拥有了全部这些特性,最近该工具的稳定性也已满足生产环境的要求。我们使用spread调度策略,以减少因服务器故障而损坏的容器数量。并设置了基于镜像的类别关系,同类容器可以运行在同样的服务器中。

我们使用了Datadog中Docker集成功能,可详细观测容器使用资源的情况。Datadog包含了所有我们需要的数据,可用来描述每个容器的内存或CPU使用率,以及每个服务器的磁盘使用率。

有了这份数据,我们发现内存是制约因素(不是CPU或磁盘),因此,我们决定利用内存约束来调度我们的容器。我们根据观测到的Datalog内存分配情况,设置我们的内存约束在99%的位置即1GB。我们还可以手动重置对每一个容器的约束。

结果显示,这个约束非常有效!我们将不会再看到服务器内存不足,或因超载而运行缓慢。

软约束条件

享受了这个发现所带来的稳定性,在一段时间后,我们注意到,这种策略过度占用了服务器资源。大多数容器实际的内存使用率远远低于该内存硬约束1GB。这意味着我们所付费的比实际使用的多很多。

我们想要更经济高效,但又不能损失稳定性。降低硬约束不是一个好的选择,因为耗内存的应用会因为这个约束而崩溃。

我们需要一种基于估计的约束,在必要时又可以被突破的调度方法。值得庆幸的是,Docker提供了--memory-reservation选项来设置内存软约束。当设置该软约束时,容器可以自由地使用所需的内存,但是,当服务器上有内存争用时,Docker会试图缩减内存到软约束值以内。基于软约束的调度会减少浪费,并设置一个硬约束来阻止失控。但Swarm没有这个功能,所以是时候需要我们使用Go语言,给Swarm建立一个定制版本分支,可调度软内存约束,而不是硬约束。再使用Datadog收集数据,基于概率选择理想的软约束阀值,并设置硬约束为容器使用的最大值。这个方法显著地减少了浪费,而且也没有影响到稳定。

动态范围和突破

Docker1.12.0版中,最酷的一个功能是调度软约束的能力。虽然它仍等待发布,不过我们已经提前尝试,可简便地使用如下命令来调度软约束。

docker service create --reserve-memory <SOFT_LIMIT>

鉴于软约束的成功,我们的下一步是为每个容器动态地选择软约束和硬约束。因为所有的数据都输送到了Datadog,可通过一个查询,得到理想的软硬约束阈值,保持容器稳定运行而又不浪费资源。敬请关注这个博客,我们一有结果就会让您知道!

原文链接:Cost-efficient container scheduling with Docker Swarm(翻译:陈晏娥,校对:黄帅)

===========================================

译者介绍

陈晏娥,鞍钢集团矿业公司信息开发中心高级工程师,专注虚拟化技术。

原文发布时间为:2016-08-17

本文作者:陈晏娥

本文来自合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:Docker Swarm:经济高效的容器调度

时间: 2024-08-21 13:57:18

Docker Swarm:经济高效的容器调度的相关文章

容器编排初探:探索Docker swarm mode、Kubernetes和Mesosphere

本文讲的是容器编排初探:探索Docker swarm mode.Kubernetes和Mesosphere[编者的话]本文首先介绍了容器技术的基础知识,说明了容器技术的前景和市场份额.容器技术的重点之一是容器的管理编排.作者介绍了三种编排工具的共同特点和各自的特性.表明企业应该根据自身需求来选择使用那一款工具或者混合使用. [上海站|3天烧脑式微服务架构训练营]培训内容包括:DevOps.微服务.Spring Cloud.Eureka.Ribbon.Feign.Hystrix.Zuul.Spri

为什么用Yarn来做Docker容器调度引擎

前言 Mesos 其实我不是非常熟悉,所以有些内容可能会有失偏颇,带有个人喜好.大家也还是需要有自己的鉴别能力 Mesos和Yarn 都非常棒,都是可编程的框架.一个硬件,不能编程,就是死的,一旦可以编程就活了,就可以各种折腾,有各种奇思妙想可以实现,同样的,一个软件,只要是可编程的,基本也就活了,容易形成生态. Yarn VS Mesos 我先说说在做容器调度引擎的时候,为什么选择Yarn而不是Mesos. 可部署性 先说明下,这里探讨的是Yarn或者Mesos集群的部署,不涉其上的应用.Ya

【干货】全自主研发Docker容器调度引擎——Newbon

背景:       大家所熟知的Docker容器调度引擎包括,K8S, Swarm, Mesos和Rancher,这些调度引擎都是开源的国外引擎,各有各的特点.在同客户和圈内人士沟通中,很多人直言国内容器创业公司大多只是将各种开源组件集成在一起,同质化严重,没有核心竞争力.作为国内第一批的容器创业公司--Ghostcloud精灵云,深知国内需要在容器的诸多领域拥有真正完全可控,同时具有核心竞争力的产品.因此,容器云平台最核心的调度引擎迫切需要一个完全可控,自主的产品,在这种背景下Newbon应运

使用 docker+tmux 加强容器调度

使用 docker+tmux 加强容器调度 摘要 为了让自己做事更加自动化,把重复的工作尽可能降到最低,平时不但需要写很多固定操作的脚本来加快工作效率. 搞搞调度环境也是需要的. 本篇通过Docker+Tmux在RancherOS上做开发平台来实现最快速的Docker调度方便自己开发. 可以最快速度进入到调度容器中. 该容器有docker deamon 的所有控制权限. 可以在容器内的Tmux中跳转到其他容器中.方便调度开发. 经过2个版本的迭代终于搞定.到达1.0版本 Docker Regis

OpenStack Magnum如何部署Docker Swarm等容器

OpenStack Magnum通常用于部署和监控容器--如Docker Swarm.Google Kubernetes 和 Apache Mesos等,但是除此之外这个项目还有一些其他有用工具. 易于部署,并且体积要比hypervisor小很多,这些都是容器技术日益流行的原因,此外,单个容器只需要完成特定任务.现在最为常见的三种容器是Docker Swarm.Google Kubernetes和Apache Mesos. 使用容器技术,管理员能够部署完整应用或者是应用的重要组成部分,并且其体积

在 Docker 中运行 MySQL:多主机网络下 Docker Swarm 模式的容器管理

本文将以多主机网络环境为基础,探讨如何利用内置编排工具 Docker Swarm 模式对各主机上的容器加以管理. Docker Engine – Swarm 模式 在多台主机之上运行 MySQL 容器拥有一定程度的复杂性,而具体水平则取决于您所选择的集群技术. 在尝试利用容器加多主机网络运行 MySQL 之前,我们首先需要理解镜像的起效原理.各资源的分配方式(包括磁盘.内存与 CPU).网络(覆盖网络驱动因素,默认情况下包括 flannel 与 weave 等)以及容错机制(容器如何实现重新定位

Docker Swarm 中最重要的概念- 每天5分钟玩转 Docker 容器技术(94)

从主机的层面来看,Docker Swarm 管理的是 Docker Host 集群.所以先来讨论一个重要的概念 - 集群化(Clustering). 服务器集群由一组网络上相互连接的服务器组成,它们一起协同工作.一个集群和一堆服务器最显著的区别在于: 集群能够像 单个 系统那样工作,同时提供高可用.负载均衡和并行处理. 如果我们部署应用和服务时选择的是多个独立的服务器而非集群,资源的整体利用率则很难达到最优,因为我们无法提前知道如何分布这些应用才能达到资源利用的最大化.而且,应用使用资源的趋势是

CodePicnic的Docker Swarm之路

本文讲的是CodePicnic的Docker Swarm之路[编者的话]本文描述了CodePicnic发展过程中的遇到的问题,使用的工具,以及选择的理由. 在CodePicnic,Docker很早就成了基础设施的核心部分.从0.11版本开始,我们不但看到了Docker的成长,更看到了一整个相关生态的建立. 与此同时,CodePicnic也在发展,我们有了不同于其他基于容器平台的特性.这也导致我们开始考虑在可扩展并且控制成本的前提下,(使之成为)一个稳定且高效的平台. 我们的应用负责以一种简单高效

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 本文选自<架构解密:从分布式到微服务>. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm. ZeroC IceGrid微服