写点什么

京东从 OpenStack 切换到 Kubernetes 的经验之谈

2017 年 2 月 26 日

背景介绍

2016 年底,京东新一代容器引擎平台 JDOS2.0 上线,京东从 OpenStack 切换到 Kubernetes。到目前为止,JDOS2.0 集群 2w+Pod 稳定运行,业务按 IDC 分布分批迁移到新平台,目前已迁移 20%,计划 Q2 全部切换到 Kubernetes 上,业务研发人员逐渐适应从基于自动部署上线切换到以镜像为中心的上线方式。JDOS2.0 统一提供京东业务,大数据实时离线,机器学习(GPU)计算集群。从 OpenStack 切换到 Kubernetes,这中间又有哪些经验值得借鉴呢?

本文将为读者介绍京东商城研发基础平台部如何从 0 到 JDOS1.0 再到 JDOS2.0 的发展历程和经验总结,主要包括:

  • 如何找准痛点作为基础平台系统业务切入点;
  • 如何一边实践一边保持技术视野;
  • 如何运维大规模容器平台;
  • 如何把容器技术与软件定义数据中心结合。

集群建设历史

物理机时代(2004-2014)

在 2014 年之前,公司的应用直接部署在物理机上。在物理机时代,应用上线从申请资源到最终分配物理机时间平均为一周。应用混合部署在一起,没有隔离的应用混部难免互相影响。为减少负面影响,在混部的比例平均每台物理机低于 9 个不同应用的 Tomcat 实例,因此造成了物理机资源浪费严重,而且调度极不灵活。物理机失效导致的应用实例迁移时间以小时计,自动化的弹性伸缩也难于实现。为提升应用部署效率,公司开发了诸如编译打包、自动部署、日志收集、资源监控等多个配套工具系统。

容器化时代(2014-2016)

2014 年第三季度,公司首席架构师刘海锋带领基础平台团队对于集群建设进行重新设计规划,Docker 容器是主要的选型方案。当时 Docker 虽然已经逐渐兴起,但是功能略显单薄,而且缺乏生产环境,特别是大规模生产环境的实践。团队对于 Docker 进行了反复测试,特别是进行了大规模长时间的压力和稳定性测试。根据测试结果,对于 Docker 进行了定制开发,修复了 Device Mapper 导致 crash、Linux 内核等问题,并增加了外挂盘限速、容量管理、镜像构建层级合并等功能。

对于容器的集群管理,团队选择了 OpenStack+nova-docker 的架构,用管理虚拟机的方式管理容器,并定义为京东第一代容器引擎平台 JDOS1.0(JD DataCenter OS)。JDOS1.0 的主要工作是实现了基础设施容器化,应用上线统一使用容器代替原来的物理机。在应用的运维方面,兼用了之前的配套工具系统。研发上线申请计算资源由之前的一周缩短到分钟级,不管是 1 台容器还是 1 千台容器,在经过计算资源池化后可实现秒级供应。同时,应用容器之间的资源使用也得到了有效的隔离,平均部署应用密度提升 3 倍,物理机使用率提升 3 倍,带来极大的经济收益。

我们采用多 IDC 部署方式,使用统一的全局 API 开放对接到上线系统,支撑业务跨 IDC 部署。单个 OpenStack 集群最大是 1 万台物理计算节点,最小是 4K 台计算节点,第一代容器引擎平台成功地支撑了 2015 和 2016 年的 618 和双十一的促销活动。至 2016 年 11 月,已经有 15W+ 的容器在稳定运行。

在完成的第一代容器引擎落地实践中,团队推动了业务从物理机上迁移到容器中来。在 JDOS1.0 中,我们使用的 IaaS 的方式,即使用管理虚拟机的方式来管理容器,因此应用的部署仍然严重依赖于物理机时代的编译打包、自动部署等工具系统。但是 JDOS1.0 的实践是非常有意义的,其意义在于完成了业务应用的容器化,将容器的网络、存储都逐渐磨合成熟,而这些都为我们后面基于 1.0 的经验,开发一个全新的应用容器引擎打下了坚实的基础。

新一代应用容器引擎(JDOS 2.0)

1.0 的痛点

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

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

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

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

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

平台架构

鉴于以上不足,在当 JDOS1.0 从一千、两千的容器规模,逐渐增长到六万、十万的规模时,我们就已经启动了新一代容器引擎平台 (JDOS 2.0) 研发。JDOS 2.0 的目标不仅仅是一个基础设施的管理平台,更是一个直面应用的容器引擎。JDOS 2.0 在原 1.0 的基础上,围绕 Kubernetes,整合了 JDOS 1.0 的存储、网络,打通了从源码到镜像,再到上线部署的 CI/CD 全流程,提供从日志、监控、排障、终端、编排等一站式的功能。JDOS 2.0 的平台架构如下图所示。

功能

选型

容器工具

Docker

容器网络

Cane

容器引擎

Kubernetes

镜像中心

Harbor

持续集成工具

Jenkins

日志管理

Logstash + Elastic Search

监控管理

Prometheus

在 JDOS 2.0 中,我们定义了系统与应用两个级别。一个系统包含若干个应用,一个应用包含若干个提供相同服务的容器实例。一般来说,一个大的部门可以申请一个或者多个系统,系统级别直接对应于 Kubernetes 中的 namespace,同一个系统下的所有容器实例会在同一个 Kubernetes 的 namespace 中。应用不仅仅提供了容器实例数量的管理,还包括版本管理、域名解析、负载均衡、配置文件等服务。

不仅仅是公司各个业务的应用,大部分的 JDOS 2.0 组件 (Gitlab/Jenkins/Harbor/Logstash/Elastic Search/Prometheus) 也实现了容器化,在 Kubernetes 平台上进行部署。

开发者一站式解决方案

JDOS 2.0 实现了以镜像为核心的持续集成和持续部署。

  1. 开发者提交代码到源码管理库
  2. 触发 Jenkins Master 生成构建任务
  3. Jenkins Master 使用 Kubernetes 生成 Jenkins Slave Pod
  4. Jenkins Slave 拉取源码进行编译打包
  5. 将打包好的文件和 Dockerfile 发送到构建节点
  6. 在构建节点中构建生成镜像
  7. 将镜像推送到镜像中心 Harbor
  8. 根据需要在不同环境生产 / 更新应用容器

在 JDOS 1.0,容器的镜像主要包含了操作系统和应用的运行时软件栈。APP 的部署仍然依赖于以往运维的自动部署等工具。在 2.0 中,我们将应用的部署在镜像的构建过程中完成,镜像包含了 APP 在内的完整软件栈,真正实现了开箱即用。

网络与外部服务负载均衡

JDOS 2.0 继承了 JDOS 1.0 的方案,采用 OpenStack-Neutron 的 VLAN 模式,该方案实现了容器之间的高效通信,非常适合公司内部的集群环境。每个 Pod 占用 Neutron 中的一个 port,拥有独立的 IP。基于 CNI 标准,我们开发了新的项目 Cane,用于将 Kubelet 和 Neutron 集成起来。

同时,Cane 负责 Kubernetes 中 service 中的 LoadBalancer 的创建。当有 LoadBalancer 类型的 service 创建 / 删除 / 修改时,Cane 将对应的调用 Neutron 中创建 / 删除 / 修改 LBaaS 的服务接口,从而实现外部服务负载均衡的管理。另外,Cane 项目中的 Hades( https://github.com/ipdcode/hades 京东开源在 GitHub 上) 组件为容器提供了内部的 DNS 解析服务。

灵活调度

JDOS 2.0 接入了包括大数据、Web 应用、深度学习等多种类型的应用,并为每种应用根据类型采用了不同的资源限制方式,并打上了 Kubernetes 的不同标签。基于多样的标签,我们实现了更为多样和灵活的调度方式,并在部分 IDC 实验性地混合部署了在线任务和离线任务。相较于 1.0,整体资源利用率提升了约 30%。

推广与展望

有了 1.0 的大规模稳定运营作为基础,业务对于使用容器已经给予了相当的信任和支持,但是平台化的容器和基础设施化的容器对于应用的要求也不尽相同。比如,平台化的应用容器 IP 并不是固定的,因为当一个容器失效,平台会自动启动另一个容器来替代,新的容器 IP 可能与原 IP 不同。这就要求服务发现不能再以容器 IP 作为主要标识,而是需要采用域名,负载均衡或者服务自注册等方式。因此,在 JDOS2.0 推广过程中,我们也推动了业务方主要关注应用服务,减少对单个容器等细节的操作,以此自研了全新智能域名解析服务和基于 DPDK 高性能负载均衡服务,与 Kubernetes 有效地配合支持。

近两年,随着大数据、人工智能等研发规模的扩大,消耗的计算资源也随之增大。因此,我们将大数据、深度学习等离线计算服务也迁移进入 JDOS2.0。目前是主要采用单独划分区域的方式,各自的服务仍然使用相对独立的计算资源,但是已经纳入 JDOS2.0 平台进行统一管理,并通过机器学习方法,提升计算资源使用效率。

灵活的标签给予了集群调度无限的可能。未来我们将丰富调度算法,并配以节能的相关技术,提高集群整体的 ROI,从而为打造一个低能耗、高性能的绿色数据中心打下基础。

回望与总结

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

与之相比,Kubernetes 的组件较少,功能清晰。其核心理念(对于资源和任务的理解)、灵活的设计(标签)和声明式的 API 是对 Google 多年来 Borg 系统的最好总结,而其提供的丰富的功能,使得我们可以投入更多精力在平台的整个生态上,比如网络性能的提升、容器的精准调度上,而不是平台本身。尤其是,副本控制的功能受到了业务线上应用运维工程师的追捧,应用的扩容缩容和高可用实现了秒级完成。JDOS 2.0 目前已经接入了约 20% 的应用,部署有 2 个集群,目前日常运行的容器有 20000 个,仍在逐步推广中。

真诚感谢 Kubernetes 社区和相关开源项目的贡献者,目前京东已经加入 CNCF 组织,并在社区排名达到 TOP30。

作者介绍

鲍永成,京东基础平台部技术总监,带领基础平台部集群技术团队从 2014 年上线京东容器引擎平台 JDOS1.0 到现在的 JDOS2.0,作为坚实的统一计算运行平台承载京东全部业务稳定运行。目前主要工作方向是 JDOS2.0 研发和京东第一代软件定义数据中心建设。


感谢孟夕对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017 年 2 月 26 日 16:119663

评论

发布
暂无评论
  • 中国移动一级业务支撑系统网状网 PaaS 之路

    移动业务支撑中心和网状网项目技术团队经过大量的研讨,创新的提出了APU(Application Process Unit)的概念,解决未来的系统的发展和管理瓶颈。并且通过深入的技术研究和实践探索,提出采用Kunbernet+Docker技术方案来构建网状网的PaaS平台,真正实现APU的理念的落地。截止2015年底,已经完成了电子渠道各种业务、流量统付、10085等核心业务的支撑,业务高峰达到10万笔/分钟,系统的弹性扩展能力和稳定性得到了充分的体现。

  • 拉勾网基于 UK8S 平台的容器化改造实践

    拉勾网于2019年3月份开始尝试将生产环境的业务从UHost迁移到UK8S,截至2019年9月份,QA环境的大部分业务模块已经完成容器化改造,生产环境中,后台管理服务已全部迁移到UK8S,部分业务模块也已完成容器化。

  • 京东如何从 OpenStack 迁移至 Kubernetes

    中国最大电商公司之一的京东,最近分享了自己通过Kubernetes对基于应用程序容器的基础架构进行革新,取代OpenStack托管的IaaS基础架构过程中所获得的经验。本次迁移同时涉及内部网络组件,借此可将资源利用率提高30%。

  • 从太平洋保险 DCOS 实践看传统企业的魅力变革

    在传统企业正在积极拥抱“互联网+”,寻求IT转型之道的背景下,本文以太平洋保险DCOS成功迎战今年“春节全民抢红包”的实践为例,详细介绍了DCOS的核心技术以及这次实践效果,从而表明DCOS凭借其数据中心轻量级弹性伸缩能力为传统IT的敏捷转型提供了新机遇。

  • 一份来自美图历时三年全面容器化的经验纪实

    容器调度,其实是为了解决资源利用率最大化的问题,本质上是一个整数规划问题。

  • 如何打通企业级容器云的技术环节

    作为国内第一家基于kubernetes的CaaS云平台及解决方案提供商,时速云发布了企业级容器云产品及解决方案。针对企业如何将容器技术以高质量、低成本、易维护的方式落地到企业的生产环境中来,以及如何高效的进行大规模容器的管理、自动化的DevOps、容器的安全、微服务实施等主要环节,时速云推出了四大企业级核心云产品,涵盖了企业级容器云平台、企业级镜像仓库、持续集成和持续交付(CI/CD)、镜像及安全服务中心。同时发布了DevOps解决方案,云端开发、测试解决方案和微服务架构等解决方案。

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

    不知不觉中,年中的618和年终的11.11已经成为中国电商的两大促销日,当然,这两天也是一年中系统访问压力最大的两天。对于京东而言,618更是这一年中最大的一次考试,考点是系统的扩展性、稳定性、容灾能力、运维能力、紧急故障处理能力。弹性计算云是京东2015年研发部战略项目,它基于Docker简化了应用的部署和扩容,提高了系统的伸缩能力。目前京东的图片系统、单品页、频道页、风控系统、缓存、登录、团购、O2O、无线、拍拍等业务都已经运行在弹性计算云系统中。

  • 高可用、弹性动态的金融级移动架构在蚂蚁金服的演进之路

    演讲嘉宾罗其平 蚂蚁金服 支付宝事业群技术专家内容介绍支付宝在无线领域投入了大量的开发资源,面向高并发、超大业务体量构建并完善了一套成熟的移动开发架构,在用户体验、应用稳定性、性能提升方面都有相应的建树。本演讲将着重围绕支付宝高可用、弹性动态的金融级移动架构演进之路展开讨论,并结合输出完整的开发工具链帮助传统银行完成架构升级的案例辅以解析。演讲会重点介绍支付宝移动端开发框架的设计理念和演进;以及监控、分析、应急响应等具体业务场景实践。内容大纲 支付宝在移动端的架构演进与思考; 高可用、弹性动态的移动金融架构演进; 剖析如何快速构建、复制稳定、高可用移动金融应用。

    2019 年 1 月 2 日

  • 紧跟社区,网易云容器平台 Kubernetes 持续升级实践

    演讲嘉宾娄超,网易云容器编排技术负责人内容介绍K8S社区一直在持续发布功能更全、更稳定、性能更好的新版本,升级是基于Kubernetes的云平台和用户必然会面临的场景和挑战。 K8S诞生初期,网易就基于K8S 1.0推出了Serverless架构的容器云平台,一直以来紧跟K8S社区发展,进行了几次线上大版本升级,至今已经持续线上运行1000天以上。 本次演讲将分享网易云如何不断改造原生K8S并与网易云基础设施结合,来支撑客户业务多样化的需求,以及网易云如何紧跟社区,快速有效地对生产环境集群进行无感知的在线升级经验,并将总结网易云Kubernetes定制化场景升级的难度和方法。

    2018 年 12 月 18 日

  • 迈向云端:云原生应用时代的平台思考

    在云原生时代,我们需要打造的也应该是一个自动化、服务化、高度扩展的平台。

    2019 年 12 月 21 日

  • 新浪微博混合云架构实践挑战之弹性调度揭秘

    《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践。本文是该系列的第三篇,主要讲解了在新浪微博业务背景下DCP的弹性调度揭秘。

  • 搭建私有 Serverless(二):基于 K8s 的 Serverless

    这节课继续学习如何搭建私有的Serverless环境。

    2020 年 5 月 6 日

  • Kubernetes 如何改变美团的云基础设施?

    在容器时代,不能只看 Kubernetes 本身,对于企业内的基础设施,“向上”和“向下”的融合和兼容问题也很关键。

  • 数据中心的 Yarn on Docker 集群方案

    数据中心中的应用一般独立部署,为了保证环境隔离与方便管理,保证应用最大资源 数据中心中普遍存在如下问题: 1.主机资源利用率低 2.部署和扩展复杂 3.资源隔离无法动态调整 4.无法快速响应业务。

  • Kubernetes 在宜信落地实践

    伴随着微服务的架构的普及,结合开源的Dubbo和Spring Cloud等微服务框架,宜信内部很多业务线逐渐了从原来的单体架构逐渐转移到微服务架构。

  • 构建高性能微服务架构

    随着移动互联网时代的兴起,提供高性能、高可用性、高扩展性的服务已经不仅仅是大公司的专利,而逐渐成为所有互联网+公司的标配需求。本文介绍网易如何利用多年的互联网架构经验和网易蜂巢的平台,帮助客户进行架构改进、微服务化、性能调优。

  • 云上容器服务:从 Docker 到 Kubernetes,迎接云原生浪潮

    从Docker到Kubernetes,容器生态不断地发展,云原生的技术浪潮已经袭来。

    2020 年 4 月 3 日

  • 微软 Azure PaaS 发展之路

    云计算通常包括IaaS, SaaS和PaaS三个层面,相较于已成气候的IaaS和SaaS,最近几年云计算领域的集中发力点在PaaS层面。微软作为全球老牌IT巨头,也是PaaS供应商的领导者。微软的PaaS之路是怎么一步步发展起来的?对此我们专访了微软Azure资深架构师Steven,来了解微软Azure PaaS的发展之路。

  • CoreOS 为 Kubernetes 量身打造分布式存储方案 Torus

    CoreOS最近发布的开源分布式存储系统Torus,这种系统在设计上可以为通过Kubernetes编排和管理的容器集群提供可靠可扩展的存储。这种技术在设计上主要针对目前运行分布式应用程序的团队所面临的一些重要的共同问题。

  • 经验:Serverless 架构应该如何选型?

    这节课讲解如何让本地的Knative应用打破云服务商的锁定,部署上云。

    2020 年 5 月 8 日

发现更多内容

架构师训练营第十一周作业

李日盛

看完这篇还不懂线程与线程池你来打我

码农的荒岛求生

数字版权资源价值日益凸显

CECBC区块链专委会

版权保护

意想不到,这个神奇的bug让我加班到深夜

码农的荒岛求生

bug修复

LeetCode题解:264. 丑数 II,暴力法,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

甲方日常 78

句子

工作 随笔杂谈 日常

读取文件时,程序经历了什么

码农的荒岛求生

后端 文件 操作系统 进程 线程’

区块链游戏开发注意事项

CECBC区块链专委会

区块链 区块链游戏

数据爬虫

RainGod

爬虫

架构师训练营第十一周笔记

李日盛

笔记

架构师训练营第十一周作业

丁乐洪

架構師訓練營 大作業二

ilake

在 Emit 代码中如何await一个异步方法

八苦-瞿昙

Spring 源码学习 12:registerBeanPostProcessors

程序员小航

Java spring 源码

食堂就餐卡系统设计

永不言弃

架构

北极科考:我们为什么要在北极呆上一年?

脑极体

第六周学习心得

cc

架构师大作业

_

大作业 架构师训练营第 1 期

架构师训练营- 食堂就餐卡系统设计

Geek_d7f0e4

系统安全高可用总结

Mars

2021你好 | 一名五道口程序员的年终总结

herongwei

程序员 职场 自媒体 年终总结 新年

架构师训练营 1 期:大作业(一)

piercebn

架构师训练营第 1 期

上地七街

潇潇雨歇

第九周 作业1

Mr_No爱学习

系统高可用原因分析&方案

Mars

分析了2020年3万多条的微博热搜,我看到了什么

CoderW

Python 程序人生 爬虫 后端 微博热搜

第九周-学习总结

Mr_No爱学习

第六周命题作业

cc

时间戳——区块链不可篡改特性的重中之重

CECBC区块链专委会

区块链

一次线上cpu过高问题

kcnf

架構師訓練營 大作業一

ilake

京东从OpenStack切换到Kubernetes的经验之谈-InfoQ