UDN-企业互联网技术人气社区

板块导航

浏览  : 811
回复  : 0

[技术交流] 京东:10万规模容器的实践及运营之道

[复制链接]
htmlman的头像 楼主
发表于 2016-5-20 11:08:05 | 显示全部楼层 |阅读模式
  正文

  大家好,我是来自京东的何小锋,今天我跟大家分享一下《京东Docker的实践经验》。
2.png

  1、京东容器之路

  1.1 面临的挑战

  京东为什么要使用Docker?京东在以前主要是基于物理机进行应用的部署,随着京东业务的发展,面临着很多挑战。
2.png

  比如说,硬件采购周期比较长,新的应用有可能会等一个月,物理机才会上线。

  很多应用部署到物理机上,应用资源的使用情况,大家掌握得不是很清楚,你没有办法精细化运营这个应用。

  它是用得多了还是用得少了?而且硬件的成本也很高,每年京东物理机采购上万台,成本很高。

  在双11或者6·18之前会做一些压力评估,需要快速扩容,现在扩容的话如果采用物理机的话,京东会花费一个月的时间进行扩容操作,非常慢。京东还有很多数据中心,要把整个部署完需要很长的时间。

  1.2 用户关注

  我们采用一些虚拟化或者容器的技术解决我们面临的问题,在跟用户沟通的过程中,用户真的不太关注你是采用物理机还是容器、虚拟化的技术,其实他们更关注的是,你给我换了技术以后,系统是不是稳定的?
2.png

  例如,一些下单操作、京东首页性能要求敏感的应用,对性能是非常看重的,如果使用容器,要确保性能没有损失。

  京东有五千多名研发人员,要确保用户的体验,如果你换了新的技术,还需要对所有的人再一次的培训,花费的时间是非常长的。

  1.3 容器化之路

  在2013年我们最初采用的是虚拟化的KVM的技术,在用的过程中,面临了性能的问题,有几个核心的应用性能达不到要求。

  在2014年我们看到容器发展比较迅速,在2014年四季度采取容器技术进行试点,最先试点的是京东图片系统,发现性能非常不错,而且我们做了弹性伸缩调度,效果也非常明显。
2.png

  所以,我们在2015年第一季度就把弹性的平台做起来了,在6·18的时候就用在了生产环境,在6·18的时候没有采用物理机来分配,能分配容器的全部使用容器分配,分配了差不多1万个容器。

  在6·18期间非常稳定,并且在下半年新机房的建设全部采用容器建设,目前京东的容器数已经差不多有10万的规模。

  1.4 选择Docker的原因

  我们从KVM切进Docker的时候,做了一个评估,我们觉得Docker还是非常胜任京东应用场景的。
2.png

  它比较轻量,性能比较好,可以快速部署,稳定性足够高,在京东的环境下对安全性也要求不高,所以说,我们用Docker非常合适京东私有云的环境。

  2、弹性计算架构

  其实京东的私有云的弹性的架构还是比较简单的,我们采用了开源和自研相结合的架构。

  基础的平台更多的采用社区开源的技术,包括OpenStack、Docker、虚拟化网络、OVS,存储是采用京东资源的分布式存储系统。

  在上层我们使用的是自己的一个调度系统,是一个CAP的调度,它做了一些应用的治理和部署,包括弹性的调度、监控。
2.png

  2.1 OpenStack

  在Docker的外面我们包了一个OpenStack,社区里有很多人不使用OpenStack,其实我们是结合京东的一个现状来采用的OpenStack。

  京东做虚拟化是从OpenStack开始做的,所以说下面的团队对OpenStack还是非常了解的,我们沿用OpenStack做集群的管理,而且OpenStack也相对比较成熟。
2.png

  我们做Docker的时候,社区这些都不是很完善。所以,我们就是沿用OpenStack,而且OpenStack社区的方案还是非常多的。

  还有一个目的,我们现有的京东公有云也是做了OpenStack做了集群的调度和管理。

  2.2 网络

  网络方面比较简单,我们就直接选择了OVS/VLan的模式进行处理,但是在性能上我们做了优化,特别是一些包的延迟,做了很大的提升。

  经过我们的优化以后,本身网络的一些性能会有20%的提升。

  为了保持用户的习惯,京东所有的基础设施都是以IP来做区分的,所以我们为每一个容器都分配一个独立的IP。
2.png

  2.3 存储

  我们是使用了京东的自研的分布式系统来接JFS来做块存储,本地存储是用于满足日志的需求。

  把日志打在物理机上,不是打在容器里面,主要是为了满足容器丢了,日志还可以查看一段时间,通过分布式的日志系统,近实时地把日志采集走,如果容器宕机的情况下,它可能会有那么一丁点时间日志没有上传到分布式日志系统中,但是可以人工地恢复这一块的数据。
2.png

  2.4 镜像分层合并

  镜像分层上,我们采用了OS层、基础层、应用层的架构,把平时变更比较频繁的应用层做了镜像,相对比较小,这样可以减小一些存储的压力。
2.png

  2.5 镜像中心

  在京东有比较严格的项目管控机制,我们会对生产环境、线上的环境、预发布环境、开发、测试环境,我们会对线下的测试环境把镜像做好,做好之后再推到生产环境。

  镜像在开放环境和生产环境是严格隔离的,必须要经过一些处理才能上传到生产的环境上。

  镜像的存储还是使用我们京东的JFS这样一个分布式的对象存储,它也支持块存储。
2.png

  2.6 配置中心

  京东有很多不同的环境,它的配置是不一样的。所以,构建了自己的配置中心,在容器或应用启动的时候,可以自动拉取对应的配置,可以满足一个镜像尽量不用改动就可以部署在多个环境里面。
2.png

  2.7 调度系统

  我们自研的调度系统是一个类似于工作流的引擎,能够做到动态服务发现,便于扩容。

  为什么要采用这样呢?

  容器调度更多的是一个流程的调度,它要把京东的基础设施等按照一定的流程串起来。

  我们目前实现的一些调度流程,包括线上做一些镜像,包括上线、下线、重启、故障牵引、弹性收缩。
2.png

  2.8 弹性扩容流程

  这一块的流程,我们首先做了弹性的评估,觉得要进行一个弹性扩容以后,首先会创建整个容器,会做一些相关的授权。

  比如说,可能会有一些MySQL的授权,还有一些其他权限的授权,通过我们的部署系统把这个应用部署上,再去检测这个应用是否起来了,这个应用起来的时候也有可能出现一些故障。
2.png

  在整个起来以后,才为把我们的监控、统一日志注册上,最后正式起来以后才会把流量打进来,调用一些负载均衡,让它把流量可以引到这台容器上,最后再上一个弹性的流程,才是一个完整的结束。

  2.9 故障迁移流程

  在一些故障迁移方面,如果检测到某一台主机或者容器出现故障的情况下,也会触发它迁移的过程。

  牵引首先会把流量摘掉,让没有流量打到容器上,创建一个新的容器把应用部署上,然后把它注册起来。
2.png

  我们在牵引的过程中会保持整个容器的IP不变,这样就少了很多其他授权的一些操作了,数据库授权这些东西就不用再去做了。

  2.10 弹性调度算法

  京东也实现了自动的弹性调度,弹性调度的算法相对还是比较复杂,它会根据我们现有应用的一些元素和信息,包括应用的重要程度、所属的业务域、需要的软硬件来进行评估,还有需要的规格,这个应用需要部署哪些机房,所有的信息我们都会弹性调度选择对应的机房机架。
2.png

  我们还做了一个扩展,集成了京东微服的一个框架,会把微服采集到的一些性能数据给汇报上来做一个评估,是否要对这个应用进行扩展,进行一个弹性调度。

  弹性角度目前是根据应用的分组,在一个机房的负载情况下做一个弹性,而不是根据一个容器实时地进行弹性,最后是应用整体情况负载做一个弹性。

  因为有时候出现一些应用程序的Bug,可能某台负载比较高,但是整体负载比较低。

  3、弹性计算应用场景

  现在核心的一些应用,除了大数据的应用,其他应用基本上全部牵到这个容器上,我们现在所有的机房都是用容器建设的,主要应用的技术架构都可以牵进来。
2.png

  比如Nginx等,还有我们京东的微服的架构JSF,包括Oracle的一些应用,还有redis,redis在京东是一个非常大的容器集群,它也是放在我们这个容器上。

  京东也在用容器做MySQL的管理,不是所有的应用都需要微软很高性能的MySQL独享物理机,我们有一个云数据库是提供一些其他应用来使用的。

  4、自动化运维

  4.1 系统监控指标

  我们采纳容器来做推广以后,对我们一些自动化的运维也做了很大的帮助。首先是监控,我们会把所有容器的基本指标都能采集到,包括系统的负载、网络的流入和流出,在这方面的一些指标采集也做了扩展。
2.png

  把这些数据采集起来之后做一些实时的计算,存在基于Hbase的数据库下,这个量也非常大,我们现在容器量很大了,每一分钟都有这样的数据上传下来,所以数据量是非常大的。

  然后,会做一些监控报警,根据自己的一些指标进行配置,是否需要去做监控报警。另外,根据这个指标其实也可以触发我们自动弹性的一个伸缩策略。
2.png

  4.2 监控页面

  可以对一个容器进行监控,也可以对一个应用做一个整体的评估,包括这个应用网络流出、整体CPU占用量,可以从多个维度进行查看。
2.png

  4.3 报警策略

  可以让应用进行个性化的设置,只需要设一套策略以后,每一个容器出现问题都会进行实时的报警,包括一些邮件、短信的通知。这也是跟我们京东所有的用户体系打通的。
2.png

  4.4 一键水平扩容

  我们要做扩容,以前扩容要部署物理机,各种情况也是非常麻烦的,现在我们可以快速地扩容,一键地进行扩容。
2.png

  4.5 一键垂直扩容

  除了这种水平的扩容之外,还支持垂直的扩容,因为应用有可能会对一些规格进行一些调整,比如要把自己的内存扩大,这方面也做了一定的垂直扩容。

  但是这里是有一定局限的,如果本机上不够的话,我们只能牵引到其他机器上进行扩容。
2.png

  4.6 宕机探测架构

  自动化容器宕机检测

  因为有很多机房,有可能一个点去检测机器的话,评估出来的报告是不准确的。

  所以,我们在每个机房里都会有很多检测的程序,每个机房只负责检查本机房的容器,分布在不同的机架上、不同的交换机上,同时检测某一台容器,如果说全部认为这台机器可能会宕机,我们认为它的评估是比较准确的,认为这个容器宕机了就触发故障迁移流程。
2.png

  4.7 硬件故障探测

  对于硬件故障我们进行了一些检测,这里主要是通过一些协议,拿物理机硬件报警的一些信息,京东的物理机数量越来越多,但是采购的机器或多或说的经常会有一些问题,所以说我们需要自动地检测出来,及时地进行通知,做一些故障牵引。
2.png

  4.8 故障通知

  我们检测到物理机出新故障以后,会马上给相关的人做一些通知,进行一些处理。
2.png

  4.9 应用部署巡检

  在使用容器建设过程中,随着新机房的建设,逐步的扩容会造成一些应用部署的情况并不是非常健康。

  我们会从应用的整体架构会做一个巡检,报告某个机房部署过多,如果需要跨机房容灾的话,必须确保两个机房的数量一致,还需要确保应用跨交换机部署。

  如果应用在一个交换机下部署过多的话,该交换机宕机会影响应用的承载能力。
2.png

  所以,我们会从多个角度巡检部署是否是健康的,做一个邮件的报告,让应用进行一些调整。

  5、数据驱动的精细化运营

  5.1 资源利用率

  在精细化运营上,会以每个小时为单位计算容器资源使用率,然后根据容器的资源使用率计算应用的资源使用率,通过应用和部门关系,计算部门资源使用率。这样,我们能够很好地控制目前的应用随意申请容器。
2.png

  5.2 容器资源利用率

  通过容器资源使用率,通过简单的数据的分析,可以计算出应用使用情况。

  如果一个新的应用来申请容器,可以找到一个类似的应用评估一下容量的数量,包括负载的情况,可以得出一个合理的数据。
2.png

2.png

  5.3 部门资源利用率

  部门的资源使用率可以作为部门考核的依据,这样可以看出部门申请了多少资源,整体的资源使用率是高还是低。
2.png

  5.4 资源剩余情况

  掌握现有资源情况,还剩余多少,是否需要尽快补充资源,可以给硬件采购的人提供一些建议。
2.png

  5.5 配额管理

  京东有一个比较特色的东西就是配额的管理,因为京东是一个非常大的集团,大家资源的需求可能各不相同,为了满足一些重要系统的需求,我们会对一、二级部门进行一个资源的隔离。

  界定这个部门最多可以使用多少资源,做一个整体的划分,下面所有容器的申请、弹性的角度都必须在总体的配额下进行管理。
2.png

  6、实践经验

  • 无状态,同时对磁盘IO要求不高的应用,很适合部署到弹性云
  • 微服务应用由于能自动服务注册发现,辅助均衡,非常适合部署到弹性云
  • 推荐使用万兆网络和网卡,避免网络共享出现资源竞争
  • 选择稳定的操作系统版本,不同的版本可能会有一些内核的Bug,一旦出现问题,整个系统都会出现问题,对应用来说是灾难性的
  • 推荐高配置物理机,合理得CPU和内存比,便于充分利用资源。如果说不合理的话,会浪费很多CPU和内存
  • 采购高质量的交换机和物理机。如果物理机有质量问题,可能会影响非常多的应用,对这方面我们的要求把关是非常严格的

2.png

  Q&A

  提问:现在容器的应用已经差不多到了十万的规模,看到监控整个容器里面的情况,光容器这部分的指标就已经达到了近百亿了,对监控的数据信息是怎么处理和保存的?

  何小锋:我们是使用的Open TSDB这样 基于Hbase的,京东有一个大数据部门,它会运营Hbase,它有一个非常大的集群,我们全部存在里面,数据一直不会删除,这样会之间地根据数据分析应用的资源情况,也可以做资源的未来预测。

  提问:接着上一个朋友的问题问一下,MySQL其实也是部署在容器里面的,但是一般来说MySQL数据库是不建议这么做的,您当时是出于什么样的考虑?

  何小锋:京东有一些非常核心的应用的MySQL,目前还没有部署在容器里面。但是还有很多的应用对IO要求不是很高,如果每个应用独占一个MySQL,其实是非常浪费的。

  所以,我们会采用一个云数据库的方案进行管理,主要是做资源的隔离,为性能要求不是很高的应用,提供MySQL的服务。

  提问:一般我们用Docker如果这个出现问题,直接把它停掉直接推一个,但是数据是放在上面,一推全部的数据都丢了。

  何小锋:京东本身的MySQL也要做高可用的方案,它也有自己的主从、数据的复制,当一台数据丢了,通过DBA主从切换,继续提供服务。

  提问:原生的Open STDB只支持数值型的数据插入,对于字符型数据是怎么处理的,是直接操作原生Hbase吗?

  何小锋:我们现在存的全部是数值型的,没有字符上的。

  提问:你里面有一个注册日志服务的功能,我想了解一下注册日志服务的应用场景和所应用到的技术,比如有没有用到流处理?注册的话,应该有一个日志的收集,收集包含了什么样的应用和系统,Docker支持吗?这方面希望关注一些。

  何小锋:京东的日志有专门的一套平台进行采集和收集,你建了一个容器以后,需要把应用和信息推给它,它才能把容器产生的日志、目录这里面的数据采集到。它是一个单独的日志系统,它会实时地采集数据流,发布到平台上供检索。

  提问:我们发现在共享磁盘的情况下,它的高速读写会有一些性能损耗,可能没有那么高,IO不能达到那么高。这样,假如说日志打得很满的话,打到数据磁盘这一块怎么处理?

  何小锋:有几个日志要求性能非常高,我们并不是直接打到物理机的硬盘上,采用了内存文件系统方式,让它的性能更高一下。

  提问:本身做了一个第三方的内存文件系统。

  何小锋:对。

  提问:比如说,像你们非常多的容器,整体的服务发现调度能再说一下吗?

  何小锋:京东很早就有一个微服务的架构,目前京东的应用都是基于该服务架构,它本身原生已经支持了服务发现,我不用在容器上再做很多的服务发现的扩展工作,应用起来本身会自动地把一些服务(地址)提供上去,让消费者就可以连上来进行数据的处理。

  提问:请您详细说一下,您刚才说容器对高IO不是很好,您怎么得出这个结论的?

  何小锋:本身一台物理机上会有非常多的容器,有非常多的应用在跑,大家如果都是高IO的话,肯定会有竞争的问题,如果是独享,IO影响不大,但是如果大家的应用都是同时享IO的话,就会影响。

  比如说,一个应用是大数据的,它拉大量的数据,又遇到一个应用是疯狂地刷日志的情况,肯定会对IO有影响,现在也经常有这样的问题需要我们去解决。

  提问:您说的CPU和内存比指的是物理服务器,能不能分享一下您这边推荐什么样的CPU和内存?

  何小锋:这是根据不同公司而定的,我们京东采集一般都是64G、256G的内存,京东为了性能,把很多本地化内存为了充分地利用起来,一个应用起来可能希望你给8G、16G的内存。

  我们根据这个应用它需要多少,如果是普通的应用,需要4C、8C,如果内存过低,如果用4C,差不多有60多个核,可能会用15个容器。如果是15个容器,每个应用希望是16G的内存,太少了,你根本就生不了那么多。

  所以,可能需要你的内存,满足应用的需求。但是不同的公司是不一样的,要根据自己公司的情况去计算。

  提问:刚才说的十万个容器,Docker引擎一直在升级,对于我们的容器存续时间这么长,容器升级是怎么做的?

  何小锋:我们到现在还没有升级,现在还使用的是最原始版本。

  提问:新建的容器呢?

  何小锋:容器的版本和操作系统一样,不会随便去升,虽然新版本容器提供了很多新的功能,但是一旦要升的话,我们所有的架构需要做一些调整,对系统的稳定性影响是比较大的。

  提问:终于有这个提问的机会,今天是唯一一个在容器中讲到存储的,我是做存储的。我说的数据库是更底层的,我们的容器和存储之间能不能做一个配合,我们一个系统解决方案中做容灾,容器容灾有两种办法,基于容器的解决办法本身怎么做,两者之间有没有结合?京东有什么考虑?

  何小锋:存储也是可以做容灾的,我们现在是分布式的部署,我们目前的应用就是做了一个分布式的存储系统。一旦应用要上容器,我们要跟他沟通应用的场景,比如说数据恢复以后,宕机以后数据还是有需要的,从另一台机器恢复,这样的场景我们都会使用分布式的存储系统。如果本身数据影响不是很大的话,就可以让它使用本地存储,没有去做严格的规定。

  提问:我想问一下,京东的监控代理是在每个主机上部署,还有选择性的部署?

  何小锋:我们每个主机上都会有,其实我们现在监控是系统层面的监控和应用层面的监控,应用层面的监控是在每个容器里面都有的。

  我们现在有很多应用的指标,调用到一些性能,这些东西我们是在每个容器里都有。我们容器里面监控的指标会占到5%左右的CPU,本身性能对应用影响不是很。

  提问:京东的容器布在物理机上,你们有没有做业务隔离,两个应用系统用了容器做安全性的隔离?

  何小锋:我们对应用的业务域或者重要级别是有区别的,根据应用单独把物理机做一些划分出来,比如这一台物理机就是给某一台重要的业务做的。

  提问:物理机各个应用之间不会互用这台物理机,是吧?

  何小锋:对,如果是应用有这方面的需求,我们是可以这样做的。

  提问:你们当初把它建在物理机之前,有没有考虑在虚拟机上搭容器?

  何小锋:虚拟机的话,它的性能已经满足不了应用的需求。

  提问:是存储的系统吗?

  何小锋:虚拟机的性能是达不到的,它本身要做一些系统的调度,资源的开销还是比较大的,因为京东6·18的压力非常大,一旦有10%、20% 性能损耗都不可以。

  提问:固态容器里的应用应该是分布式的,虚拟机损耗的点通过更多的容器来支撑,应该问题不大?

  何小锋:但是虚拟机性能比较多,需要的资源会更多。

  提问:应用是不共享物理资源的,如果新上来一个开发应用,新上的应用比较多,这个资源池会提前做好吗?

  何小锋:也不是所有的应用都共享,我们只对核心应用的策略做一些划分,大的应用可能一台共享这个资源,如果应用上来我们会根据业务域,我们知道这个业务是否是重要的,这个业务是用于下单的还是生产的,它的业务域不一样的话,重要性也是不一样的。

  提问:何老师说要用好的网卡、好的服务器,请问你们用的是什么网卡?是英特尔的,戴尔,还是IBM x86服务器?

  何小锋:我们用的是x86服务器,采用大厂商的服务器,如戴尔。网卡的话,目前新采购的都是万兆网卡,英特尔的比较多。

  提问:你们的虚拟化用的是什么样的软件?是KVM吗?

  何小锋:KVM已经被我们放弃了,我们就是基于容器。

  提问:是在物理机上,是吗?

  何小锋:对。

原文作者:何小锋 来源:高效运维
2.png

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部