K8s Pod Anti Affinity for Cronjob Pod甚至调度

问题描述

在具有500 namespaces的多租户场景中，每个场景都具有相同的Cronjob，分别标记为app=some-job和20 worker nodes，可以强制k8s调度程序传播在20个节点上平均分配500个Cronjob Pod，这样一个节点在给定时间只能完成约25个和/或正在运行的Pod吗？

我已经注意到，500个Cronjob Pod往往只安排在20个节点中的大约7个上，并且KubeletTooManyPods会触发警报，即使大多数Pod都处于“已完成”状态。

我正在考虑一种解决方案，可能是在标签app=some-job上加上topologyKey=kubernetes.io/hostname来使用Pod反亲和力，但是不确定是否会尊重Completed Pod，以及是否一旦所有20个节点上都至少有1个Pod，它将进行平均分配，这时每个节点都将通过反亲和度失败，但是我希望preferredDuringSchedulingIgnoreDuringExecution将允许调度继续进行平均分配。 / p>

是否有更好的方法来实现这种传播，也许是自定义调度程序？

编辑：想提一下我们正在使用EKS 1.17 编辑2：错字

解决方法

Complete作业的存在不会影响调度逻辑，因此我怀疑podTopologySpreadConstraints会有所帮助。您最好使用历史记录限制（kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs /...)

您的评论之一表明您需要日志：将pod的日志作为作业的一部分上传，即在cronjob运行的脚本结尾处，推送到s3或fluentbit或任何地方。这样可以保证在cronjob完成之后，日志是安全的。作业日志可能由于各种原因而消失（可以清除它们，可以逐出或删除Pod等），因此，依靠Completed作业的存在来访问它们不是一个好主意。