京东构建了全球最大的Kubernetes集群,没有之一

百家 作者:聊聊架构 2018-06-18 07:14:00

从 2014 年开始,InfoQ 就一直在追踪京东 618 相关的技术报道,在我们的系列文章中,你肯定也能察觉到京东在技术上的成长速度。5 年之前,每逢大促,我的朋友圈中好似有很多人在看笑话,因为在高并发大流量面前,那时的京东总是有些脆弱,特别是对于淘宝 / 天猫。

几年时间,一晃而过。这次 618,我刻意搜索了下自己的朋友圈,发现基本没有人再去吐槽京东『逢促必挂』的技术笑话了,转而大家都在夸赞京东的送货速度以及服务品质。是的,当用户的目光聚焦到一家公司的业务本身时,这也证明他的技术已经相对成熟,起码足以支撑业务的发展速度。也就是说,对于京东来说,技术已经不再是业务增长的瓶颈。

我现在还清晰记得自己在 2015 年 618 当天去京东总部采访京东商城总架构师刘海锋时的情景,他当时激情澎湃地向我介绍了京东基于 Docker 容器和 OpenStack 的弹性计算云项目的种种优势,并笑着说,再过几年,随着这个项目的成熟,京东的技术人员面对大促,再也不用这么辛苦,这么紧张了。

我应该也是被他的话所感动,亦或者作为一个外行,我似乎也能理解一个技术人应有的技术信仰。所以在当时的采访文章里,我写下了这样的话:京东弹性计算云项目将深刻影响京东未来几年的基础架构。

然而,一年之后的 2016 年京东 618,当再次采访弹性云项目负责人鲍永成时,我们才明白,弹性云对于京东的真正价值和意义。永成说,这一年是弹性云在京东全面战略落地的重要一年,它也将全面提升京东的基础设施利用效率。

紧接着的 2017 年,京东的业务,以及相关的中间件已经全部迁移到了弹性云之上,并且永成表示,他们开始了新的技术升级,将会引入 Google 开源的 Kubernetes 技术来重构相关技术栈,并且自己也会为开源添砖加瓦,回馈社区。

2018 年 4 月底,我看到了京东宣布加入 CNCF 云原生计算基金会的消息。这时,我才明白,京东的 Kubernetes 集群已经是全球最大了,并且没有之一。

感慨之余,我又翻出了过去几年 InfoQ 对京东 618 的特别报道,当我站在历史的角度去审视这些采访时,我也才真正理解媒体记录的价值。我想,若干年后在去看这一系列的技术升级,你只要看这几年 InfoQ 的文章标题就足以理解变化的关键点。

  • 2015 年京东 618:Docker 扛大旗,弹性伸缩成重点

  • 2016 年京东 618:15 万个 Docker 实例,所有业务全部容器化

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

2018 年的 618,鲍永成和他的同事们写下了这篇文章,他们希望能够系统梳理过去几年京东在基础架构方面的点滴探索,也希望这系列文章能够帮助到更多的中小公司少走弯路。以下为系列文章的第一篇。

不在江湖久已。这两年来我们(京东)完成了从 Kubernetes 的落地、推广,到大规模运营的历程。走过了那些山水,看过了那些风景,现在,我想,是时候讲讲我们的故事了。

故事要从四年前讲起,JDOS(Jingdong Datacenter Operating System) 1.0 于 2014 年推出,基于 OpenStack 进行了深度定制,并在国内率先将容器引入生产环境。经历了 2015 年 6.18/11.11 的考验。团队积累了大量的容器运营经验,对 Linux 内核、网络、存储等深度定制,实现了容器秒级分配。

2016 年,我们将精力集中与了完善容器的监控、网络、存储,镜像中心等容器生态建设,并积累了丰富的运营监控数据。也是在这一年,我们渐渐意识到了 OpenStack 架构的笨重,启动了新一代容器引擎平台 (JDOS 2.0) 的研发。

2017 年,JDOS2.0 全面推出,JDOS 从基础设施升华到应用平台。2.0 推进了业务从源码到编译打包构建镜像到上线的全流程,建设了一站式应用运行平台。  这一年,我们逐步完善了容器的监控、网络、存储,镜像中心等容器生态建设,开发了基于 BGP 的 Skynet 网络、ContainerLB、ContainerDNS、ContainerFS 等多个项目。

并将其中部分项目进行了开源 (github.com/tiglabs/)。我们为我们的容器生态起了一个全新的名字:阿基米德,意为撬动数据中心的人。

罗马不是一天建成的。在容器化的过程中,我们经历了很多,在这里我认为有必要回顾一下我们的经验和教训,有资于后来者借鉴与参考。

  1. 不轻易放弃用户。如果大量的改造工作都由业务方来承担,那么容器化的推动将会是一件极其艰难的事情。许多老的业务可能没有那么无状态,甚而有一些诸如 IP 不变等的特殊需求。为用户的定制和改造,不仅是一种妥协,更是提供一个兼容老的业务方式以使其容器化的方案。如果总是拒绝用户,那么在失去用户的同时,也失去了与他们一起成长的机会。贴近用户,了解用户的需求,进行分析、归类和适应性的改造。在成就了业务的同时,也是成就了自己。

  2. 幻想一蹴而就和急功近利,都是容器化过程中的大忌。对于应用进行改造的理想很丰满,现实却总是很骨感。因为这需要业务的大量的人力、物力、财力的支持。我们在容器化的过程中,采用了渐进式的策略。在开始,允许用户将容器以虚拟机 / 物理机的使用方式进行使用,由其传统的应用运维使用以往的工具进行部署和维护。同时,我们也提供了编译构建上线的一站式服务,支持滚动升级、灰度发布、负载均衡、域名解析等等服务。用便捷的运维管理方式吸引用户自主进行转变。再后来,我们放开了镜像的构建过程。已经有越来越多的用户愿意自己去学习 Dockerfile,以便构建起属于自己业务的镜像了。

  3. 对于技术上的质疑要用技术来解决。新技术的推广难免受到质疑与挑战。要用于接受这些质疑和挑战,并用技术和数据来证明自己。当然这也对团队自身提出了更高的要求。对于新技术不是了解就可以了,而是能够吃深吃透,进而根据场景进行定制。

  4. 架构要能化繁为简,易于维护运营和排障。社区的功能总是大而全,而对于我们具体的落地实践来说,我们更多要做的是减法,将原本繁杂的架构和流程梳理清晰,剪除不必要的功能,保证整个平台良好的可维护性。

  5. 守住稳定的底线。稳定才是作为平台赖以生存的基础。将平台进行加固,确保其稳定,不是说说而已,这其中有大量的工作需要做。稳定不是保守,不是守住现在的版本不再研发。而是要对于整个平台的每个环节都能进行代码级的精准掌握,对于上线前功能、性能进行充分测试,对于突发状况有预案处理。从流程上能抑制雪崩问题的发生,并能够控制故障的影响范围。这些我们的具体工作将在未来的章节进行详述。

调度的意义与难点

在实现了 99.9% 的业务容器化后,阿基米德迎来了全新的挑战。近几年硬件成本上涨带来的 ROI 压力以及建设异地多活的数据中心的实际需求,使得阿基米德 JDOS 的重点从容器集群管理转向了调度,JDOS 也从集群管理平台的角色逐渐转换为了调度平台。

调度的意义从微观上来说,是为每个容器寻找到一个合适的落脚点,也就是节点。但是从宏观角度来说,其意义在于将整个数据中心计算效能的提升。具体来说,调度可以在缩减资源碎片,资源时空复用,节能降耗以及提升计算效率方面取得巨大收益。而且该收益随着集群规模的扩大,会有更为明显的提升。

调度虽然收益颇丰,但是要实现也非轻而易举。调度不是空中楼阁,它依赖于大量的基础工作。这其中一些典型的问题,需要一一解决,比如异构、隔离、监控、评估等问题。

在 JDOS 1.0 中,因为容器更多的是以胖容器的形式存在,因此容器的使用相对来说是静态的,也就是一次调度完成后容器不会轻易迁移。除非节点故障、维护等特殊情况,则将其迁移到别的节点。而在 JDOS 2.0 中,情况就变得更为复杂了。JDOS 2.0 允许用户自动或者手动地进行应用的扩容缩容。并且,由于大数据、AI、serverless 等任务的引入,平台在将其与业务容器进行混合部署的同时,也需要具备对相关任务进行实时监控和异常驱逐的能力。而这些,对于调度平台的动态处理能力、时间规划能力都提出了更高的要求。

接下来,我们将用一系列的文章,深入解剖阿基米德调度平台。下一章预告《第一章:事非经过不知难,Kubernetes 的定制与优化》,欢迎关注聊聊架构微信公众号,第一时间阅读系列文章。


当前分布式系统是大势所趋,Google、Facebook 等大型系统架构也是以分布式系统架构为基础。过去二十年,整个分布式系统架构演进史是从 C/S→B/S→分布式系统→网格计算→云计算,包括目标、定位、场景,影响深远。未来,如何从全球多域的角度去规划分布式架构呢?

下个月深圳 ArchSummit 架构师峰会邀请了 Pinterest 武永胜、百度王耀、菜鸟网络黄浩、美团宋斌来分享他们的一手分布式系统设计经验,这些内容一定可以助你一臂之力。

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接