作业帮上万个 CronJob 和在线业务混部，如何解决弱隔离问题并进一步提升资源利用率？

作者

吕亚霖，作业帮基础架构 - 架构研发团队负责人。负责技术中台和基础架构工作。在作业帮期间主导了云原生架构演进、推动实施容器化改造、服务治理、GO 微服务框架、DevOps 的落地实践。

别路，作业帮基础架构-高级研发工程师，在作业帮期间，负责多云 K8s 集群建设、K8s 组件研发、Linux 内核优化调优相关工作。

背景

作业帮在云原生容器化改造的过程中，随着集群规模越来越大、业务混合部署的场景越来越复杂，面临的集群问题也越来越多，走到了 Kubernetes 及容器化的深水区， 尤其是在上万个 CronJob 容器化，和在线业务混合部署在同一个生产集群后，问题就更加明显。

作业帮在线的生产业务使用 TKE 部署在黑石2.0 物理机上，单个机器规格比较大，部署的pod 也就比较多，而 cronjob 的特性是频繁、定时启动和销毁，同时也需要给这部分业务预留一定的固定资源，所以这块主要有 2 个问题；一是在大规模pod 频繁创建销毁场景下，cgroup 弱隔离性导致的节点稳定性问题，从而影响同一节点其他业务，二是资源预留导致的资源利用率低的问题。这两个问题其实已经超出了 原生 Kubernetes 的能力覆盖范围，我们需要新的思路来解决。

下面将详细介绍这两个问题产生的原因及解决办法。

问题一：集群内节点稳定性

由于业务上存在很多分钟级执行的定时任务，导致 pod 的创建和销毁非常频繁，单个节点平均每分钟有上百个容器创建和销毁，机器的稳定性问题频繁出现。

一个典型的问题是频繁创建 pod 导致节点上 cgroup 过多，特别是 memory cgroup 不能及时回收ÿ