容器技术火遍技术界，很多公司包括传统行业企业都已经从观望者转变为采用者。作为最早期采用容器技术的一批先锋者，京东从 2015 年的 9 千多实例扩大到如今容器作为业务上线默认选项，支撑全部业务运行以及中间件、数据库等。此外，在经历了从 OpenStack 到 Kubernetes 的迁移转变之后，京东容器引擎平台已经从 1.0 迭代到 2.0 版本，并且于今年陆续开源数个项目。
罗马不是一天建成的。
积累如此久并且支撑过 618 大促的京东容器技术是怎样的？有哪些革新又有哪些值得业界学习呢？已经开源的项目是怎样的呢？
今年随着京东业务的飞速发展，京东容器数量上也对应迅速增加。不仅在去年完成京东业务全面运行在 JDOS 容器之上，并且在数据库，中间件等系统也全面容器化。同时，在这一年，京东上线了 JDOS 2.0 系统，开始了从 OpenStack 向 Kubernetes 的迁移。截止到 6 月 7 日，已经有 60% 的业务运行在了 JDOS 2.0 平台中。
此外不得不提及发生的主要变化：
业务系统全面基于容器镜像全量上线发布；全面使用集群编排；在生产环境尝试和运行抢占式调度，并自研单层单体全局调度器 SchedulerX；让业务系统与硬件解耦与资源完全解耦，海量资源，从容大促。
正如上文所述，京东在生产环境尝试和运行抢占式调度，并自研单层单体全局调度器 SchedulerX。
SchedulerX 属于 JDOS 弹性计算项目，主要目的是从更高的层面来加强计算资源调度，以提供服务更强的弹性计算能力，提升数据中心资源利用率。
JDOS2.0 主要通过以下三个维度对业务进行优先级分类归集，并实施抢占式调度。
-
从业务负载层面来对业务分类，根据业务是长时间运行的任务 (long time running) 还是离线计算任务 (offline)，采用不同的资源占用优先级和调度模式。
-
从业务高峰时间段会对各个业务进行归类，例如区分是否白天高峰期还是夜间高峰期，将任务进行混合调度，实现资源的错峰利用。
-
从资源区域层面对业务分类，例如 GPU 资源、CPU 资源、SSD 资源等。根据业务对于资源的实际需求进行调度。
在保证各个业务 80% 的资源的情况下，20% 的资源在不同时间段可以互相抢占借用。（此比例可以根据实际运营进行调配。例如 618、双 11 大促时，则不允许业务相互抢占，保证资源足够）
在当前没有空闲资源的情况下，JDOS 会根据每个机器上运行的业务的分类对机器打分，如果该机器的分数较低，那么抢占就会发生，低优先级的业务首先会被驱逐 (Eviction) 抢占。被抢占的作业重新回到 PENDING 队列里等待重新调度。
SchedulerX 确保关键业务不会由于资源不足而停止运行，也会重新调度其他业务使其获得更好的安置。
OpenStack No, Kubernetes Yes!
JDOS 1.0 解决了应用容器化的问题，但是依然存在很多不足。
首先是编译打包、自动部署等工具脱胎于物理机时代，与容器的开箱即用理念格格不入
。容器启动之后仍然需要配套工具系统为其分发配置、部署应用等等。应用启动的速度受到了制约。其次线上线下环境仍然存在不一致的情况，应用运行的操作环境，依赖的软件栈在线下自测时仍然需要进行单独搭建。线上线下环境不一致也造成了一些线上问题难于在线下复现。更无法达到镜像的“一次构建，随处运行”的理想状态。
再次，JDOS 1.0 时代的容器体量太重，应用需要依赖工具系统进行部署，导致业务的迁移仍然需要工具系统人工运维去实现，难以在通用的平台层实现灵活的扩容缩容与高可用
。另外，容器的调度方式较为单一，只能简单根据物理机剩余资源是否满足要求来进行筛选调度。在提升应用的性能和平台的使用率方面存在天花板。
Kubernetes 方案与 OpenStack 方案相比，架构更为简洁。OpenStack 整体运营成本较高，因为牵涉多个项目，每个项目各自有多个不同的组件，组件之间通过 RPC(一般使用 MQ) 进行通讯。为提高可用性和性能，还需要考虑各个组件的扩展和备份等。这些都加剧了整体方案的复杂性。问题的排查和定位难度也相应提升，对于运维人员的要求也相应提高。
与之相比，Kubernetes 的组件较少，功能清晰。其核心理念 (对于资源，任务的理解)，灵活的设计 (标签) 和声明式的 API 是对 Google 多年来 borg 系统的最好总结。而其提供的丰富的功能，使得京东可以投入更多精力在平台的整个生态上，比如网络性能的提升、容器的精准调度上，而不是容器管理平台本身。尤其是，副本控制的功能受到了业务线上应用运维工程师的追捧，应用的扩容缩容和高可用实现了秒级完成。
有了 1.0 的大规模稳定运营作为基础，业务对于使用容器已经给予了相当的信任和支持。但是平台化的容器和基础设施化的容器对于应用的要求也不尽相同。比如，平台化的应用容器IP 并不是固定的，因为当一个容器失效，平台会自动启动另一个容器来替代。新的容器 IP 可能与原 IP 不同。这就要求服务发现不能再以容器 IP 作为主要标识，而是需要采用域名，负载均衡或者服务自注册等方式。因此，在 JDOS 2.0 推广过程中，京东也推动了业务的微服务化，服务框架的升级改造等。
在近两年随着大数据、人工智能等研发规模的扩大，消耗的计算资源也随之增大。因此， 京东将大数据、深度学习等离线计算服务也迁移进入 JDOS 2.0。
目前是主要采用单独划分区域的方式，各自的服务仍然使用相对独立的计算资源，但是已经纳入 JDOS 2.0 平台进行统一管理。未来，京东将在此基础上，通过调度将离线计算服务在集群资源充足 (如夜晚) 时给予计算资源扩充，提高计算的效率。
JDOS 是如何支持业务的弹性伸缩的？
对于业务的扩展，直接通过调整副本数，横向扩充容器的实例个数。业务如果是 L4/L7 类型的， 使用一个负载均衡来进行流量的分导。 负载均衡项目 ContainerLB 是京东自研的一套基于 DPDK 实现的高性能 L4 负载均衡服务，主要负责 JDOS2.0 的 service 中 LoadBalancer 的实现。
