运维教程-京东:10万规模容器的实践及运营之道

跨零代码为大家提供高品质的解决方案,请大家多多来访,跨零不胜感激,在此谢过。

本文根据〖2016 全球运维大会•深圳站〗现场演讲嘉宾何小锋老师分享内容整理而成,文字编辑:吴召军@腾讯,录音整理:刘玉强@京东。

欢迎关注“高效运维(微信ID:greatops)”公众号并置顶,以抢先赏阅干货满满的各种原创文章。

讲师介绍:何小锋
拥有18年的研发经验,喜欢技术,追求卓越。
2011年加入京东,担任了京东两届架构委员会常委。在京东负责过百亿级的分布式消息系统。2014年下半年开始负责基于Docker的弹性技术平台,通过诺亚方舟项目,成功的让京东各个业务系统全面迁移到容器上。
在京东期间支持过多次的618和双11大促,见证了京东的技术演进过程,在弹性计算、中间件、存储和大并发分布式系统等方面积累了丰富的实践经验。

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

京东:10万规模容器的实践及运营之道

1、京东容器之路

1.1 面临的挑战

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

京东:10万规模容器的实践及运营之道

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

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

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

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

1.2 用户关注

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

京东:10万规模容器的实践及运营之道

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

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

1.3 容器化之路

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

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

京东:10万规模容器的实践及运营之道

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

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

1.4 选择Docker的原因

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

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

京东:10万规模容器的实践及运营之道

2、弹性计算架构

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

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

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

京东:10万规模容器的实践及运营之道

2.1 OpenStack

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

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

京东:10万规模容器的实践及运营之道

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

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

2.2 网络

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

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

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

京东:10万规模容器的实践及运营之道

2.3 存储

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

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

京东:10万规模容器的实践及运营之道

2.4 镜像分层合并

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

京东:10万规模容器的实践及运营之道

2.5 镜像中心

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

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

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

京东:10万规模容器的实践及运营之道

2.6 配置中心

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

京东:10万规模容器的实践及运营之道

2.7 调度系统

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

为什么要采用这样呢?

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

京东:10万规模容器的实践及运营之道

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

京东:10万规模容器的实践及运营之道

2.8 弹性扩容流程

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

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

京东:10万规模容器的实践及运营之道

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

2.9 故障迁移流程

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

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

京东:10万规模容器的实践及运营之道

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

2.10 弹性调度算法

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

京东:10万规模容器的实践及运营之道

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

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

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

3、弹性计算应用场景

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

京东:10万规模容器的实践及运营之道

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

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

4、自动化运维

4.1 系统监控指标

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

京东:10万规模容器的实践及运营之道

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

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

京东:10万规模容器的实践及运营之道

4.2 监控页面

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

京东:10万规模容器的实践及运营之道

4.3 报警策略

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

京东:10万规模容器的实践及运营之道

4.4 一键水平扩容

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

京东:10万规模容器的实践及运营之道

4.5 一键垂直扩容

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

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

京东:10万规模容器的实践及运营之道

4.6 宕机探测架构

自动化容器宕机检测

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

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

京东:10万规模容器的实践及运营之道

4.7 硬件故障探测

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

京东:10万规模容器的实践及运营之道

4.8 故障通知

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

京东:10万规模容器的实践及运营之道

4.9 应用部署巡检

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

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

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

京东:10万规模容器的实践及运营之道

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

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

5.1 资源利用率

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

京东:10万规模容器的实践及运营之道

5.2 容器资源利用率

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

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

京东:10万规模容器的实践及运营之道

京东:10万规模容器的实践及运营之道

5.3 部门资源利用率

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

京东:10万规模容器的实践及运营之道

5.4 资源剩余情况

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

京东:10万规模容器的实践及运营之道

5.5 配额管理

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

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

京东:10万规模容器的实践及运营之道

6、实践经验

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

京东:10万规模容器的实践及运营之道

今天我跟大家分享的内容就到这里,谢谢大家!

Q&A

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

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

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

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

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

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

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

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

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

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

提问:新建的容器呢?

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

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

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

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

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

提问:是存储的系统吗?

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

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

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

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

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

提示1:点击文末“阅读原文”链接,即可下载本演讲的PPT及实况录音。边听边看,岂不快哉?

提示2:更加精彩的GOPS全球运维大会·上海站即将于9月23-24日举行,约么😄

get运维新技能,怎么总是抢先一步?

文/何小锋
文章来自高效运维微信公众号

从零到一,创造未来!跨零综合IT问题解决服务站,欢迎你的到来。运维教程 只为你绽放。

本文固定链接: http://kua0.com/2018/12/29/运维教程-京东:10万规模容器的实践及运营之道/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注