BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

京东618:容器技法日趋娴熟,数个项目即将开源回馈社区

| 作者 鲍永成 关注 2 他的粉丝 发布于 2017年6月18日. 估计阅读时间: 15 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

容器技术火遍技术界,很多公司包括传统行业企业都已经从观望者转变为采用者。作为最早期采用容器技术的一批先锋者,京东从2015年的9千多实例扩大到如今容器作为业务上线默认选项,支撑全部业务运行以及中间件、数据库等。此外,在经历了从OpenStack到Kubernetes的迁移转变之后,京东容器引擎平台已经了从1.0迭代到2.0版本,并且于今年陆续开源数个项目。

罗马不是一天建成的。积累如此久并且支撑过618大促的京东容器技术是怎样的?有哪些革新又有哪些值得业界学习呢?已经开源的项目是怎样的呢?

ArchSummit全球架构师峰会深圳站将于2017年7月7日~8日在深圳·华侨城洲际酒店召开,大会设置了相关专题来深入解读电商大促背后的技术故事,大会还邀请了eBay、WalmartLabs等国外顶尖技术专家,分享AI促销、搜索引擎、异地多活、库存物流等核心架构实践。

容器技术整体概况

今年随着京东业务的飞速发展,京东容器数量上也对应迅速增加。不仅在去年完成京东业务全面运行在JDOS容器之上,并且在数据库,中间件等系统也全面容器化。同时,在这一年,京东上线了 JDOS 2.0 系统,开始了从OpenStack向 Kubernetes  的迁移。截止到 6 月 7 日,已经有 60%的业务运行在了 JDOS  2.0 平台中。

此外不得不提及发生的主要变化:业务系统全面基于容器镜像全量上线发布;全面使用集群编排;在生产环境尝试和运行抢占式调度,并自研单层单体全局调度器SchedulerX;让业务系统与硬件解耦与资源完全解耦,海量资源,从容大促。

自研单层单体全局调度器

正如上文所述,京东在生产环境尝试和运行抢占式调度,并自研单层单体全局调度器SchedulerX。

SchedulerX属于JDOS弹性计算项目,主要目的是从更高的层面来加强计算资源调度,以提供服务更强的弹性计算能力,提升数据中心资源利用率。

(点击放大图像)

JDOS2.0主要通过以下三个维度对业务进行优先级分类归集,并实施抢占式调度。

1)从业务负载层面来对业务分类,根据业务是长时间运行的任务(long time running)还是离线计算任务(offline),采用不同的资源占用优先级和调度模式

2)从业务高峰时间段会对各个业务进行归类,例如区分是否白天高峰期还是夜间高峰期,将任务进行混合调度,实现资源的错峰利用。

3)从资源区域层面对业务分类,例如GPU资源、CPU资源、SSD资源等。根据业务对于资源的实际需求进行调度。

在保证各个业务80%的资源的情况下,20%的资源在不同时间段可以互相抢占借用。(此比例可以根据实际运营进行调配。例如618、双11大促时,则不允许业务相互抢占,保证资源足够)

在当前没有空闲资源的情况下,JDOS会根据每个机器上运行的业务的分类对机器打分,如果该机器的分数较低,那么抢占就会发生,低优先级的业务首先会被驱逐(Eviction)抢占。

被抢占的作业重新回到PENDING队列里等待重新调度。

SchedulerX确保关键业务不会由于资源不足而停止运行,也会重新调度其他业务使其获得更好的安置。

重大决策:OpenStack No, Kubernetes  Yes!

应用容器化遇到的瓶颈

JDOS 1.0 解决了应用容器化的问题,但是依然存在很多不足。

首先是编译打包、自动部署等工具脱胎于物理机时代,与容器的开箱即用理念格格不入。容器启动之后仍然需要配套工具系统为其分发配置、部署应用等等。应用启动的速度受到了制约。

其次线上线下环境仍然存在不一致的情况,应用运行的操作环境,依赖的软件栈在线下自测时仍然需要进行单独搭建。线上线下环境不一致也造成了一些线上问题难于在线下复现。更无法达到镜像的“一次构建,随处运行”的理想状态。

再次,JDOS 1.0 时代的容器体量太重,应用需要依赖工具系统进行部署,导致业务的迁移仍然需要工具系统人工运维去实现,难以在通用的平台层实现灵活的扩容缩容与高可用。

另外,容器的调度方式较为单一,只能简单根据物理机剩余资源是否满足要求来进行筛选调度。在提升应用的性能和平台的使用率方面存在天花板。

OpenStack PK Kubernetes

Kubernetes 方案与 OpenStack 方案相比,架构更为简洁。OpenStack 整体运营成本较高,因为牵涉多个项目,每个项目各自有多个不同的组件,组件之间通过 RPC(一般使用 MQ)进行通讯。为提高可用性和性能,还需要考虑各个组件的扩展和备份等。这些都加剧了整体方案的复杂性。问题的排查和定位难度也相应提升,对于运维人员的要求也相应提高。

与之相比,Kubernetes 的组件较少,功能清晰。其核心理念(对于资源,任务的理解),灵活的设计(标签)和声明式的 API 是对 Google 多年来 borg 系统的最好总结。而其提供的丰富的功能,使得京东可以投入更多精力在平台的整个生态上,比如网络性能的提升、容器的精准调度上,而不是容器管理平台本身。尤其是,副本控制的功能受到了业务线上应用运维工程师的追捧,应用的扩容缩容和高可用实现了秒级完成。

改造之路

有了 1.0 的大规模稳定运营作为基础,业务对于使用容器已经给予了相当的信任和支持。但是平台化的容器和基础设施化的容器对于应用的要求也不尽相同。比如,平台化的应用容器IP 并不是固定的,因为当一个容器失效,平台会自动启动另一个容器来替代。新的容器 IP 可能与原 IP 不同。这就要求服务发现不能再以容器 IP 作为主要标识,而是需要采用域名,负载均衡或者服务自注册等方式。因此,在 JDOS 2.0 推广过程中,京东也推动了业务的微服务化,服务框架的升级改造等。

在近两年随着大数据、人工智能等研发规模的扩大,消耗的计算资源也随之增大。因此,京东将大数据、深度学习等离线计算服务也迁移进入 JDOS 2.0。目前是主要采用单独划分区域的方式,各自的服务仍然使用相对独立的计算资源,但是已经纳入 JDOS 2.0 平台进行统一管理。未来,京东将在此基础上,通过调度将离线计算服务在集群资源充足(如夜晚)时给予计算资源扩充,提高计算的效率。

研发成果,两大开源项目

1 分布式高性能DNS项目

JDOS 是如何支持业务的弹性伸缩的?

对于业务的扩展,直接通过调整副本数,横向扩充容器的实例个数。业务如果是 L4/L7 类型的, 使用一个负载均衡来进行流量的分导。 负载均衡项目 ContainerLB是京东自研的一套基于 DPDK 实现的高性能 L4 负载均衡服务,主要负责 JDOS2.0 的 service中 LoadBalancer 的实现。

与 ContainerLB 项目非常密切的还有分布式高性能 DNS 项目ContainerDNS。(https://github.com/ipdcode/skydns)  为容器提供了内部的 DNS 解析服务。业务如果是微服务类型京东叫 JSF,即需要在 JSF 上进行服务注册与发现的类型,京东则是在容器扩充后,通过服务中间层监听到容器已经启动成功,则对应 Notify JSF。

ContainerDNS,作为京东商城软件定义数据中心的关键基础服务之一,具有以下特点:

  • 高可用
  • 支持自动发现服务域名
  • 支持后端IP+Port,以及URL探活
  • 易于维护和横向动态扩展

(点击放大图像)

ContainerDNS 包括四大组件 DNS server、service to DNS 、user API 、IP status check。这四个组件通过etcd 数据库集群结合在一起,彼此独立,降低了耦合性,每个模块可以单独部署。DNS server 用于提供DNS 查询服务的主体,目前支持了大部分常用的查询类型(A、AAAA、SRV、NS、TXT、MX、CNAME等)。service to DNS 组件是k8s 集群与DNS server的中间环节,会实时监控k8s集群的服务的创建,将服务转化为域名信息,存入etcd 数据库中。

user API 组件提供restful api,用户可以创建自己的域名信息,数据同样保持到etcd数据库中。IP status check 模块用于对系统中域名所对应的ip做探活处理,数据状态也会存入到etcd数据库中。如果某一个域名对应的某一个ip地址不能对外提供服务,DNS server 会在查询这个域名的时候,将这个不能提供服务的ip地址自动过滤掉。(关于ContainerDNS的更多内容详见本系列的另外一篇文章《京东商城分布式智能容器DNS实践》)。

2分布式共享存储 ContainerFS 项目 

JDOS 是如何支持有状态服务和无状态服务的?

无状态业务的支持相对容易一些,可以直接通过调度自动调整副本数来实现服务的弹性伸

缩。对于有状态的业务,原生的Kubernetes有 StatefulSet 进行支持,但是 StatefulSet 需要容器一个个启动, 另外社区在这个方面开发进度缓慢。 因此京东选择了自己定制 Kubernetes 进行支持,主要是为本集(RC/RS/deployment)提供了 IP 保持不变和存储自动迁移的功能来进行支持。

通过对于每个副本集维护一个小的 IP 池。当副本数调整时,也对应增加或者减少 IP 池中的IP 的数量。副本集中的容器创建时,则使用这个 IP 池中的 IP 进行创建;容器删除时,则将IP 返回到副本集的 IP 池中。

存储也是类似, 对于一个副本集有一个对应的持久化存储(persistent  volume)的集合。当副本集中的容器创建时,则使用这个 PV 集合中的一个 PV 进行绑定核存储挂载。容器删除时,则对应进行卸载和解除绑定。

针对于容器的存储, 京东没有选用社区已有的 glusterfs 等方案。而是自研一套分布式共享存储 ContainerFS  的项目来专门提供容器的存储。

Container File System (简称ContainerFS)是为JDOS2.0 系统针对性开发的一个分布式文件系统,同时适用于原生Kubernetes集群以及其他应用场景。 

ContainerFS的核心概念是:

a volume = a metadata table + multiple block groups

ContainerFS的架构图如下:

(点击放大图像)

ContainerFS的产品特性:

  • 无缝集成:支持标准的文件访问协议,支持fuse挂载,业务应用无需任何修改即可无缝使用
  • 共享访问:共享访问帮助多个业务应用获得相同的数据来源
  • 弹性伸缩 :可满足业务增长对文件存储的容量诉求
  • 线性扩展的性能:线性扩展的存储性能,非常适合数据吞吐型的应用

ContainerFS典型应用:

做为JDOS2.0 的数据存储引擎,ContainerFS提供了独享、共享等类型的volume,并通过PV机制挂载给POD或者容器使用。

(点击放大图像)

使用效果:

(点击放大图像)

目前ContainerDNS, ContainerFS已经开源,ContainerLB会近期在GitHub上开源。

写在最后

为什么要将京东底层技术开源呢?主要两个方面原因:

在底层技术方面,开源是大势所趋。Google的borg系统在过去十余年间一直处于保密状态,但是现在不但公开了,而且利用起核心思想,孵化出了Kubernetes项目。而Kubernetes项目一经发布,也立即受到了热捧。同时,社区的完善也为Kubernetes和Google的borg提供了更为有益的建议和帮助。当然,不仅仅是Google,CoreOS、OpenStack、Docker等等公司和项目的开源大热也说明了这一趋势。

在容器平台实践路上,京东是走的比较早也是比较坚定的。在实践过程中有很多理解和技术视野。比如我们认为容器技术本质是linux kernel技术,容器技术需要数据中心底层基础软件全力配合,如分布式域名解析,高性能负载均衡,分布式共享存储,精确授时等等。

因此京东在这方面不希望闭门造车,而是能够更多的同业界来分享我们的经验。一方面,为许多底层技术还在摸索中的业内同仁提供一点借鉴和帮助,另一方面,也是希望获取业界的指导,提升京东的基础平台系统和技术思路。

作者简介

鲍永成,京东商城 基础平台部技术总监。2013年加入京东,负责京东容器集群平台(JDOS)研发,带领团队完成京东容器大规模落地战略项目,有效承载京东全部业务系统和80%数据库,特别在大促期间 scale up 秒级弹性应对高峰流量。目前聚焦在京东容器集群 JDOS 2.0 以及京东敏捷智能数据中心研发。服务过土豆网(TUDOU.COM),思科(CRDC)等,在分布式、虚拟化、容器、数据中心建设有丰富的实践经验。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT