w88优德娱乐城

您的位置: 首页 > 加入公司

京东如何打造K8s全球最大集群支撑万亿电商交易

开始下载
  • 软件大小:[!--filesize--]
  • 软件类别: [!--softtype--] | 加入公司
  • 软件语言: [!--language--]
  • 运行环境: [!--softfj--]
  • 软件评级:
  • 更新时间: 2018-10-25 10:38:47
  • 软件授权: [!--softsq--]
  • 插件情况: 无插件,请放心使用
  • 相关链接: 无相关信息
  • 安全检测: 瑞星:安全 江民:安全 卡巴:安全

src="/img/ad415.png"

软件介绍

  在过去一年里,Kubernetes以其架构简洁性和灵活性,流行度持续快速上升。我们有理由相信在不远的未来,Kubernetes将成为通用的基础设施标准。京东在2016年底上线了京东新一代容器引擎平台JDOS2.0,成功从Openstack切换到JDOS2.0的Kubernetes技术栈,打造了完整高效的PaaS平台。

  其实数据中心就是围绕着几个东西来说:服务器、网络以及一些基础软件,剩下的就是集群的管理。这里要说明一下,我们认为基础软件是数据中心非常重要的一个环节,比如,域名解析、负载均衡、时钟这些东西,虽然Kubernetes管理了整个集群,但是这些东西它依然没有。也就是说,要是想把它用得非常好的话,这些软件也要进行一些适当的变革。

  京东在使用Kubernetes管理大数据中心的时候,也围绕着Kubernetes在我们内部的数据中心建了很多生态。首先是适合容器化的DNS,以及适合容器化的负载均衡,还有适合容器化的文件系统、镜像中心等等。这里面特别要说明一点,就是DNS跟LB,Kubernetes 1.9合入了高性能的负载均衡。

  如果在大规模生产环境中,高性能的负载均衡是必不可少的,但这个负载均衡又涉及到另外一些问题。首先,要跟现有的数据中心适配,京东自主研发了一套负载均衡以及DNS。虽然社区里有CoreDNS等等,但是这些DNS存在一个问题,就像昨天某厂的一个故障那样,你把所有的东西这个引导这个,那个引导那个。

  如果你的DNS不在容器内的话,带来的后果是很难料想的。因为京东容器已经发展了很多年,数据中心也比较大,我们单个Kubernetes集群能够做到8000到10000台。因为我们的机器实在太多,如果不做大集群的话,人力管理的投入上会非常大。后面我会解释怎么做到这么大规模的集群。

  京东容器化的数据中心建设已经四五年了,已经比较稳定了,虽然我们的Kubernetes还比较老,是1.6版本,但是我们已经有很多改进,我们现在的重点就是往阿基米德,也就是往数据中心的资源调度这个方向发展。

  去年双十一的时候阿基米德已经上线了,Kubernetes使用到后期的时候,你会发现Kubernetes并不能解决数据中心资源使用率的问题,它其实仅仅解决了你的发布,或者是管理资源的容器这方面的一些东西。

  上图是我们数据中心的基础架构,其实比较传统,我们会把负载均衡、域名,以及我们包的这个Kubernetes的API统一抽象出来,整个就是一套。然后在每个数据中心部署若干套Kubernetes集群,每一个Kubernetes集群,会管理三个物理Pod,大概是一万台的规模。

  为了配合这个规模,我们做了一些工作。DNS最早的时候,还没有CoreDNS来适配,大家知道每个数据中心最老的DNS是bind9,适配起来是非常痛苦的,它缺API,缺很多东西。所以我们就自己研发了一套基于Etcd的分布式DNS,当时提供了RestfulAPI,直接对接的Kubernetes的watch,这样的话我们就能够做一个非常好的适配。

  但是后来我们发现一个问题,原来你有可能10万台物理机,也就假设就是你的hostname的解析也就10万个,现在不一样了,一台物理机是100多个容器,即你增长了100倍。这时运维解析的请求量会激增,增长之后会带来一个问题,抖动、延迟都非常大,间接的就影响了你的业务的TP响应。因此我们后来又把我们域名解析的服务,改成了DBTK的服务,现在的性能是bind9的19倍,是CoreOS的60多倍,每秒查询率能冲到800万QBS。

  有人问,京东做一个这么大的Kubernetes集群,是不是特别复杂特别容易出错。确实,如果你的集群非常多,假设你有50个集群,那么你误操作的概率可能就是这50的概率相加。因此京东会把整个Kubernetes的集群做减法,并没有做加法,当然这是代表京东的一家之言了,因为我们是自用,并不是往外卖,所以我们主要是做减法,以适合我们使用。

  为了适用上万台Server的这种规模,最大的问题就是API的负载容易崩溃。比如你把config-map存到etcd里面去,这个设计本身就是有问题的。如果你的规模比较大的话,一定要去改,如果不改,你的集群很快就会崩溃。其实我们的做法其实还比较传统,就是采用一些缓存技术,就比如说config-map我们压根是不会放在etcd里去的。因为如果你把config-map放到etcd里去的话,首先假设有一个用户,给你传一百个20M的配置文件,你就完蛋了。

  其次,京东对controller也做了很多重构,虽然社区提供了很多controller,但我可以保证,这些controller绝对没有做严格的关联性测试,也就是说有些controller之间互相是有影响的。建议启用任何一个controller前都要做严格的分析跟测试。想做大集群的Kubernetes,必须得去改,而且是做减法式的改。

  Kubernetes号称的deployment、金丝雀发布等等一切都非常美好,但是我来自京东基础架构部门,基础部门要服务业务,而业务会给你提很多需求,第一次你听上去可能觉得这需求非常扯,但是你跟他仔细沟通之后,你会发现人家的需求是非常合理的。

  比如说,他说你金丝雀发布的时候,副本数随机的挑几个,升级了50%,但有的业务方会要求就要升级某一个特定IP。他不是对这个IP特别有感情,而是因为他配了很多host,除了有研发还有测试等等,所以你不得不去面临这个问题,像IP不变等等这样的一些需求就会蹦出来,我们都要满足他,才能继续往下走。

  还有,比如有人说京东大促的时候,我们Kubenetes整个的弹性速度非常快等等。但是我可以向你保证,如果真正是那种流量高峰瞬间来的时候,这个弹性是绝对跟不上的。因为等你还没弹完,老的已经被打死了,弹几个死几个,所以一般来说,你要用更多的实例,用调度的方式来做,而不是说通过scale out这种弹来做,来不及的。

  刚才也提到这些策略IP不变,还有我们这有一个很有意思的东西,就是支持容器的rebuild。我们的资源使用率,通过阿基米德调度之后,我们的资源使用率非常紧张,因为少买了很多机器,同时业务又在不断地增长,这个时候我们资源的限额都会被耗尽,在某些情况下甚至调度器也无能为力。

  这怎么办?我们采取了一种古老的方法,跳过调度器,进行本地rebuild。因为你的调度有的在排队,有的depending,但是有一些业务在发布的时候,他会提出一个问题,我原来有100个容器,我发布完之后只剩80了,另外20个容器的资源被别的业务抢走了,这是不能接受的,所以我们也有了这种所谓的优先rebuild,就是就地rebuild,这会带来很多好处。

  这么做最明显的一个好处,就是拉镜像至少省了一些时间。还有一个明显的好处是,虽然在数据中心依然很复杂,但当业务部署在某一台容器机器上之后,调用的依赖、调用数据库的链路都是经过了大量压测的,已达到相对最优的状态。如果你今天把这容器从pod1搬到pod2,我说物理pod,从房间1搬到房间2去了,那可能会带来抖动或者等等情况。当然这并不代表你损失了Kubernetes的很多特性。

  补充前面的一点,我们的deployment做了大量定制,原生的deployment其实还是很难满足这样的要求。比如说在线上,因为是面向生产环境,但是生产环境不会那么美好。首先业务,可能上100个容器就有两个容器,它的响应很差,这个时候要去排查或者要去进行其他的操作,这个时候用deployment做不到,因为一升级就没了。而我们,让它可以指定把这两个停掉,或者是其他操作,反正就是能够指定,就相当于你要改一些东西,改动量不大,只是在它原来基础之上改。

  下面说说我们目前的工作重点。京东整个数据中心规模很大,有老有新,整体的资源使用率会有明显的波峰波谷。比如上图黑底图上蓝色的线点时中国整个互联网的流量都比较低,但是到8点以后流量就开始逐渐攀升。那么1点到6点是一个非常浪费的阶段,因为我们有大量的计算资源,这时候我们就可以跟大数据产生互补,把在线应用的波谷算力贡献给大数据做离线计算,刚好大数据也是后半夜,相对来说离线任务更多,因为第二天早上要出报表,于是我们做了一个融合的混合部署的项目,就叫阿基米德,就是把大数据的业务给调到在线业务的平台上去。

  这里面就涉及到一个问题,就是隔离性。大家都觉得Docker的隔离性已经很优秀了,其实并非如此,它的隔离性没有大家想象的那么好,你看到的隔离都是Namespace的隔离,真正的性能隔离其实并没有完全做到位。例如内存回收,它其实是操作系统统一进行回收的。

  比如上面10个容器有5个容器狂读小文件,这时候突然内存已经到一定阀值了,它就要做一次slab回收。一旦slab回收,它就都被block住了,其他的在线业务都会被卡住,虽然只是毫秒级的,但是会有毛刺,业务就会来问你发生了什么。特别是在线大数据进来之后,这个问题就会被无限放大,因此在这块你要做适当的改动。京东做得比较早,从2013年就开始做容器,在过去几年我们在这块已经做了很多工作。

  还有另外一个,大家也都感同身受。业务说我需要100个容器,每个容器八个核,其实之后发现每个容器只跑了不到10%的CPU,这种情况是有可能的。那怎么办?你不能粗暴地只给业务两个核,出问题谁负责?那怎么办?我们就告诉业务我们给了他八个核(其实没有),只要不出事就行了,出了事解释也无用。这会带来一个巨大的收益,就像上图,绿色的部分是我们给的CPU,红色是实际使用的,那我们至少给他砍一半。这样做了之后你就会发现,即使一年不买机器,机器也是够的。

  调度方面的问题,京东整个数据中心都是用Kubenretes来管,我们取名为JDOS,即JD Datacenter OS,封包了Kubernetes然后做了大量的定制。往上层看,JDOS支持京东的在线年双十一的时候数据库全部都迁完了,到2018年初的时候,我们基本上像中间件类的也都大部分迁上来了,也就是说现在我们除了单纯的存储图片,还在用物理机那种存储型的服务器之外,剩下的全在容器上,现在京东已经看不到物理机了。现在正在做的就是把大数据也往上面导。这会带来一个非常好的收益。

  但是把大数据及很多其他业务放上JDOS之后我们发现,整个调度变得非常复杂,原来的调度器只是考虑哪一台适合放就可以了,用一句话说,它只负责杀,不负责埋。这会带来一个问题,容器运行之后,带来的影响Kubernetes是无能为力的,除非崩溃了,它给你再重新拉副本等等。这看上去会很美好,实际上业务会天天投诉你。

  为解决这一问题,我们应用上线的时候会要选优先级,如果你的优先级不高的话,有可能会被优先级高的驱逐掉,相当于我们单独对Kubernetes重新做一个东西,即我们的驱逐器。驱逐器会对pod打上很多标签,比如优先级、容忍度、副本数等等(例如只有一个副本的话,它优先级再低也不能杀)。

  这很像OM的排序,当宿主机的CPU、内存load达到一定上限的时候,我们就会启动这种排序,很快地把它排出来,立马就驱逐,而且驱逐之后,会告诉调度器不要再往这台上调了。因为有可能资源满了,它又给调回来了,你又给驱逐,就形成一个死循环了。

  其实基本的理念也非常简单,就是保障优先级的系统,大数据是最先优先级,但是在线业务的话,也要往下放,这样就能在有限资源的情况下发挥最大的作用,特别是大促的时候,如果都是靠买机器来支撑的话,这是非常恐怖的一件事情。因为每次大促我们都要按20倍来估,这要买多少机器啊。

预留广告位置

下载地址

相关说明

  • 推荐使用 网际快车 下载本站软件,用 WinRAR最新版 进行解压.
  • 目前很多国产软件以及汉化等安装程序捆绑流氓插件,大家在安装的时候务必留意每一个安装步骤.都客网不会接任何捆绑插件的广告.
  • 如果您发现此软件无法下载,请稍后再次尝试.
  • 京东如何打造K8s全球最大集群支撑万亿电商交易 已通过本站测试,测试结果请参看说明及截图.
  • 京东如何打造K8s全球最大集群支撑万亿电商交易 为网上收集,若无意中侵犯了您的版权,请与我们联系.
  • 本站为非营利性站点,所有资源均是网上搜集或私下交流学习之用,任何涉及商业盈利目的均不得使用,否则产生的一切后果将由您自己承担.
字母检索 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z