这篇文章发布时间超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

京东从 OpenStack 转向 Kubernetes 的内部情况

编者按：今天的帖子来自京东的基础设施平台部门团队，内容是关于他们从 OpenStack 过渡到 Kubernetes 的过程。京东是中国最大的公司之一，也是第一家进入全球财富 500 强榜单的中国互联网公司。

集群构建历史

物理机时代（2004-2014）

2014 年之前，我们公司的所有应用程序都部署在物理机上。在物理机时代，我们需要平均等待一周的时间才能将应用程序分配到上线。由于缺乏隔离，应用程序会相互影响，导致很多潜在的风险。当时，每台物理机上的 tomcat 实例的平均数量不超过 9 个。物理机资源被严重浪费，调度也不灵活。由于物理机故障，应用程序迁移需要数小时。而且无法实现自动扩展。为了提高应用程序部署的效率，我们开发了编译打包、自动部署、日志收集、资源监控和其他一些系统。

容器化时代（2014-2016）

由京东首席架构师刘海峰领导的基础设施平台部门 (IPD) 在 2014 年秋季寻求新的解决方案。Docker 进入了我们的视野。当时，docker 正在兴起，但略显薄弱，缺乏生产环境的经验。我们对 docker 进行了反复测试。此外，还对 docker 进行了定制，以修复设备映射器导致的系统崩溃和一些 Linux 内核错误等问题。我们还向 docker 添加了许多新功能，包括磁盘速度限制、容量管理和镜像构建中的层合并等等。

为了正确管理容器集群，我们选择了 OpenStack + Novadocker 驱动的架构。容器被作为虚拟机进行管理。这就是第一代京东容器引擎平台--JDOS1.0（京东数据中心操作系统）。JDOS 1.0 的主要目的是使基础设施容器化。从那时起，所有应用程序都在容器中运行，而不是物理机中。至于应用程序的运行和维护，我们充分利用了现有工具。开发人员在生产环境中请求计算资源的时间从一周减少到几分钟。计算资源池化后，即使扩展 1,000 个容器也可以在几秒钟内完成。应用程序实例彼此隔离。应用程序的平均部署密度和物理机利用率都提高了三倍，带来了巨大的经济效益。

我们在每个 IDC 中部署了集群，并提供了统一的全局 API 来支持跨 IDC 的部署。在我们的生产环境中，单个 OpenStack 分布式容器集群中最多有 10,000 个计算节点，最少有 4,000 个。第一代容器引擎平台 (JDOS 1.0) 成功支持了 2015 年和 2016 年的“6.18”和“11.11”促销活动。截至 2016 年 11 月，已在线运行 150,000 个容器。

“6.18”和“11.11”被称为京东最受欢迎的两次在线促销活动，类似于黑色星期五促销活动。2016 年 11 月 11 日完成的订单量达到 3000 万。

在开发和推广 JDOS 1.0 的实践中，应用程序直接从物理机迁移到容器。本质上，JDOS 1.0 是 IaaS 的一种实现。因此，应用程序的部署仍然严重依赖于编译打包和自动部署工具。然而，JDOS1.0 的实践非常有意义。首先，我们成功地将业务迁移到容器中。其次，我们对容器网络和存储有了深刻的理解，并知道如何将其优化到最佳状态。最后，所有这些经验为我们开发全新的应用程序容器平台奠定了坚实的基础。

新的容器引擎平台 (JDOS 2.0)

平台架构

当 JDOS 1.0 从 2,000 个容器增长到 100,000 个时，我们推出了新的容器引擎平台 (JDOS 2.0)。JDOS 2.0 的目标不仅仅是一个基础设施管理平台，还是一个面向应用程序的容器引擎平台。在 JDOS 1.0 和 Kubernetes 的基础上，JDOS 2.0 集成了 JDOS 1.0 的存储和网络，打通了从源代码到镜像，最后到部署的 CI/CD 过程。此外，JDOS 2.0 还提供日志、监控、故障排除、终端和编排等一站式服务。JDOS 2.0 的平台架构如下所示。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\arc.png

功能产品
源代码管理Gitlab
容器工具Docker
容器网络Cane
容器引擎Kubernetes
镜像注册表Harbor
CI 工具Jenkins
日志管理Logstash + Elastic Search
监控Prometheus

在 JDOS 2.0 中，我们定义了两个级别，系统和应用程序。一个系统由多个应用程序组成，一个应用程序由多个提供相同服务的 Pod 组成。一般来说，一个部门可以申请一个或多个直接对应于 Kubernetes 命名空间的系统。这意味着同一系统的 Pod 将位于同一命名空间中。

JDOS 2.0 的大部分组件（GitLab / Jenkins / Harbor / Logstash / Elastic Search / Prometheus）也都被容器化并部署在 Kubernetes 平台上。

一站式解决方案

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\cicd.png

  1. 1. JDOS 2.0 以 docker 镜像为核心，实现持续集成和持续部署。
  2. 2. 开发人员将代码推送到 git。
  3. 3. Git 触发 jenkins master 生成构建作业。
  4. 4. Jenkins master 调用 Kubernetes 创建 jenkins slave Pod。
  5. 5. Jenkins slave 拉取源代码，进行编译和打包。
  6. 6. Jenkins slave 将软件包和 Dockerfile 发送到带有 docker 的镜像构建节点。
  7. 7. 镜像构建节点构建镜像。
  8. 8. 镜像构建节点将镜像推送到镜像注册表 Harbor。
  9. 9. 用户在不同区域创建或更新应用程序 Pod。

JDOS 1.0 中的 Docker 镜像主要包含操作系统和应用程序的运行时软件栈。因此，应用程序的部署仍然依赖于自动部署和其他一些工具。而在 JDOS 2.0 中，应用程序的部署是在镜像构建过程中完成的。并且镜像包含了完整的软件栈，包括应用程序。有了这个镜像，我们就可以实现在任何环境中按照设计运行应用程序的目标。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\image.png

网络和外部服务负载均衡

JDOS 2.0 采用了 JDOS 1.0 的网络解决方案，该方案使用 OpenStack Neutron 的 VLAN 模型实现。该方案实现了容器之间的高效通信，使其非常适合公司内部的集群环境。每个 Pod 在 Neutron 中占用一个端口，并具有单独的 IP。基于容器网络接口标准 (CNI) 标准，我们开发了一个名为 Cane 的新项目，用于集成 kubelet 和 Neutron。

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\network.png

同时，Cane 也负责 Kubernetes 服务中 LoadBalancer 的管理。当创建/删除/修改 LoadBalancer 时，Cane 将调用 Neutron 中 lbaas 服务的创建/删除/修改接口。此外，Cane 项目中的 Hades 组件为 Pod 提供内部 DNS 解析服务。

Cane 项目的源代码目前正在完成中，并将很快在 GitHub 上发布。

灵活的调度

D:\\百度云同步盘\\徐新坤-新人培训计划\\docker\\MAE\\分享\\schedule.pngJDOS 2.0 支持访问各种应用程序，包括大数据、Web 应用程序、深度学习和其他一些类型，并采用更多样化和灵活的调度方法。在一些 IDC 中，我们尝试混合部署在线任务和离线任务。与 JDOS 1.0 相比，整体资源利用率提高了约 30%。

总结

Kubernetes 丰富的功能使我们能够更多地关注平台的整个生态系统，例如网络性能，而不是平台本身。特别是，SREs 非常赞赏复制控制器的功能。有了它，应用程序的扩展可以在几秒钟内完成。JDOS 2.0 现在已经接入了大约 20% 的应用程序，并部署了 2 个集群，每天运行约 20,000 个 Pod。我们计划接入公司更多的应用程序，以取代当前的 JDOS 1.0。我们也乐于与社区分享我们在这一过程中的经验。

感谢 Kubernetes 和其他开源项目的所有贡献者。

--京东基础设施平台部门团队