Ограничение по времени в задании Kubernetes - .spe c .activeDeadlineSeconds per pod

Question

Как объяснено в Kuberenetes документах в топе c заданий:

activeDeadlineSeconds применяется к продолжительности задания, независимо от того, сколько модулей созданы. Как только задание достигает activeDeadlineSeconds, все его работающие блоки завершаются, и статус задания становится type: Failed с reason: DeadlineExceeded.

Однако я хочу ограничить время каждый стручок . Если модуль занимает слишком много времени, я хочу, чтобы он потерпел неудачу, но я хочу, чтобы другие модули продолжили работу, и, если необходимо, для создания дополнительных модулей.

Я немного объясню свою задачу, просто чтобы прояснить проблему. Задание состоит из получения элементов из базы данных Redis, где база данных служит своего рода очередью. Каждый модуль обрабатывает один элемент (ну, число может варьироваться). Если для обработки элемента требуется слишком много времени, я хочу, чтобы он потерпел неудачу. Однако другие модули должны продолжаться, и задание должно продолжать создавать модули и извлекать дополнительные элементы из базы данных.

Answer 1

Ваш вариант использования кажется идентичным этому примеру из документации kubernetes.
Как вы сказали, activeDeadlineSeconds не тот параметр, который вы должны использовать здесь.

Я не уверен, почему вы хотите, чтобы модуль не работал, если он не может обработать элемент в течение определенного периода времени. Я вижу несколько разных подходов, которые вы можете использовать здесь, но требуется больше информации о природе вашей проблемы, чтобы знать, какой из них выбрать. Одним из подходов к решению вашей проблемы было бы установить параллелизм задания на количество модулей, которые вы хотели бы запустить одновременно, и установить это поведение в самом коде -

• Если проблема, задерживающая обработку, является временной , вы, вероятно, захотите завершить текущую транзакцию, сохранить элемент в своей очереди и возобновить обработку того же элемента
• Если один и тот же элемент не прошел x раз, его следует удалить из очереди и отправить в какой-то вид очереди недоставленных сообщений, ожидающей устранения неполадок в более поздний момент времени

Другой подход заключается в разветвлении сообщений в очереди таким образом, что будет вызывать рабочий модуль для каждого сообщения, так же как этот пример изображен.
Выбор этого решения действительно приведет к тому, что каждый модуль будет слишком долго обрабатывать элемент, чтобы выйти из строя, и если вы установите restartPolicy созданных вами модулей на never, вы должны иметь список неисправных модулей на ваших руках, которые соответствуют количеству обработанных элементов.

Сказав все это, я не ошибаюсь в модулях. Это правильный подход, и отслеживание неудачных событий обработки должно осуществляться с помощью инструментария, либо по журналам контейнеров, либо по метрикам.