Мы можем определить две спецификации для параллельных заданий:
1. Параллельные задания с фиксированным числом выполнений:
- указать ненулевое положительное значениедля .spec.completions.
- Задание представляет общую задачу и завершается, когда имеется один успешный Pod для каждого значения в диапазоне от 1 до
.spec.completions - , еще не реализованный: каждыйPod передается другой индекс в диапазоне от 1 до .spec.completions.
2. Параллельные задания с рабочей очередью:
не указывайте .spec.completions, по умолчанию .spec.parallelism
модули должны координировать между собой или внешней службой, чтобы определить, над чем каждый должен работать.
Например, Pod может получить пакет из N элементов в рабочей очереди. каждый Модуль независимо способен определить, все ли его одноранговые узлы выполнены, и, таким образом, все задание выполнено.
- когда любой модуль из задания завершается успешно, новые модули не создаются
- как только по крайней мере один модуль завершился успешно, и все модули были завершены, затем задание завершено успешно
- после того, как любой модуль завершился успешно, ни один другой модуль не должен выполнять никакой работы. для этой задачи или написания любого вывода. Все они должны находиться в процессе выхода
. Для задания с фиксированным завершением count вы должны установить .spec.completions на необходимое количество завершений. Вы можете установить .spec.parallelism или оставить его неустановленным, и по умолчанию он будет равен 1.
Для рабочей очереди Job вы должны оставить .spec.completions unset, а set .spec.parallelism -неотрицательное целое число.
Дополнительные сведения о том, как использовать различные типы заданий, см. в разделе шаблоны заданий .
Вы также можете взятьпосмотрите на одно задание, которое запускает модуль контроллера: этот шаблон предназначен для одного задания, чтобы создать модуль, который затем создает другие модули, действуя как своего рода пользовательский контроллер для этих модулей. Это обеспечивает большую гибкость, но может быть несколько сложным для начала и предлагает меньшую интеграцию с Kubernetes.
Одним из примеров этого шаблона может быть задание, которое запускает модуль, который запускает скрипт, который, в свою очередь, запускаетГлавный контроллер Spark (см. Пример Spark), запускает драйвер Spark и затем очищает его.
Преимущество этого подхода состоит в том, что весь процесс получает гарантию завершения объекта Job, но полный контроль над какими модулямисоздаются и как им назначается работа.
В то же время принимайте во внимание, что статус завершения задания задан dafault - при достижении заданного числа успешных завершений он гарантирует, что все задачи выполнены должным образом. Применение этого статуса до завершения всех задач не является безопасным решением.
Вы также должны знать, что готовые задания обычно больше не нужны в системе. Хранение их в системе будет оказывать давление на сервер API. Если задания управляются непосредственно контроллером более высокого уровня, например CronJobs, задания можно очистить с помощью CronJobs в соответствии с указанной политикой очистки на основе емкости.
Вот официальные документы: параллельная обработка заданий , параллельная обработка заданий . Полезный блог: статья-параллельная работа .