内容简介：京东618：容器技法日趋娴熟，数个项目即将开源回馈社区
容器技术火遍技术界，很多公司包括传统行业企业都已经从观望者转变为采用者。作为最早期采用容器技术的一批先锋者，京东从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）等，在分布式、虚拟化、容器、数据中心建设有丰富的实践经验。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- Nginx 之大并发服务器架构实战技法三
- Python实用技法第33篇：字符串连接及合并
- Python实用技法第30篇：从字符串中去掉不需要的字符
- 周年回馈——劲爆折扣疯狂价（手慢无）
- 研究发现回馈开源软件能带来竞争优势
- 回馈社区，九州云深耕OpenStack三大试点项目
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
