京东618：容器技法日趋娴熟，60%业务已切换至Kubernetes

正文

请到「今天看啥」查看全文

从资源区域层面对业务分类，例如 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 系统的最好总结。而其提供的丰富的功能，使得京东可以投入更多精力在平台的整个生态上，比如网络性能的提升、容器的精准调度上，而不是容器管理平台本身。尤其是，副本控制的功能受到了业务线上应用运维工程师的追捧，应用的扩容缩容和高可用实现了秒级完成。

改造之路

请到「今天看啥」查看全文