#kubernetes #kubernetes-cronjob
#kubernetes #kubernetes-cronjob
Вопрос:
В многопользовательском сценарии с 500 namespaces , каждый с идентичным Cronjob , помеченным app=some-job , и 20 worker nodes , возможно ли заставить планировщик k8s равномерно распределить 500 модулей Cronjob по 20 узлам, чтобы на любом узле было только ~ 25 завершенных и / или запущенных модулей в данный момент времени?
Я заметил, что 500 модулей Cronjob, как правило, запланированы только примерно на 7 из 20 узлов, и KubeletTooManyPods срабатывает аварийный сигнал, хотя большинство модулей находятся в завершенном состоянии.
Я думаю, что решением могло бы быть применение анти-сродства Pod к ярлыку app=some-job с помощью topologyKey=kubernetes.io/hostname , но не уверен, соблюдает ли это Completed Pods, и если бы это делало равномерный разброс, когда на всех 20 узлах было по крайней мере 1 Pod, и в этот момент каждый узел не выполнял бы анти-сродствослучай, но я надеюсь preferredDuringSchedulingIgnoreDuringExecution , позволит продолжить планирование с равномерным распределением.
Есть ли лучший способ добиться такого распространения, может быть, пользовательский планировщик?
Редактировать: хотел упомянуть, что мы используем EKS 1.17 Редактировать 2: опечатка
Комментарии:
1.Похоже
podTopologySpreadConstraints, что он был разработан для этого сценария. Обновление до версии 1.18 сделает это доступным, поэтому я посмотрю, принесет ли это желаемое results:docs.aws.amazon.com/eks/latest/userguide/…kubernetes.io/docs/concepts/workloads/pods /…2. Наличие завершенных заданий не влияет на логику планирования, поэтому я сомневаюсь
podTopologySpreadConstraints, что это поможет. Вам лучше использовать ограничения истории ( kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs /… ).3. В зависимости от того, что делает cronjob, рассматривали ли вы возможность использования наборов демонов, если хотите, чтобы они были равномерно распределены по узлам? Это объекты с пространством имен
4. @Oliver, отличная идея по ограничению истории! На данный момент у меня есть ограничение в 1, но нет причин сохранять эти ссылки на успешные задания, просто нужно, если произошел сбой. Ведение журнала является незначительной проблемой, если требуется какое-то исследование после выполнения задания, но мы отправляем логи в ES w / fluent-bit, поэтому они могут быть у нас, в зависимости от времени, когда журналы контейнера исчезают с рабочего узла после удаления модуля…
5. @MariuszK. Спасибо за информацию! В этом конкретном сценарии я не думаю, что deamonset может заменить cronjobs
Ответ №1:
Наличие Complete заданий не влияет на логику планирования, поэтому я сомневаюсь podTopologySpreadConstraints , что это поможет. Вам лучше использовать ограничения истории (kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs /…)
В одном из ваших комментариев указано, что вам нужны журналы: загрузите журналы модуля как часть задания, т.Е. В конце скрипта, запускаемого cronjob, нажмите на s3 или fluentbit или где угодно. Тогда вам гарантируется, что после завершения cronjob журналы будут в безопасности. Журналы заданий могут исчезать по разным причинам (их можно очистить, модули могут быть удалены или удалены и т. Д.), Поэтому Не стоит полагаться на наличие Completed заданий для доступа к ним.