Семафор рабочих процессов Argo со значением 0

Я изучаю семафоры в рабочих процессах проекта Argo, чтобы избежать одновременных рабочих процессов, использующих один и тот же ресурс.

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

Думаю, у меня есть два варианта:

  • Я протестировал ручную установку значения семафора в configMap на значение 0, но Арго все равно запустил один рабочий процесс.
  • Я могу запустить рабочий процесс, который будет выполняться вечно, пока он не будет удален, требуя блокировки синхронизации, но это требует дополнительных накладных расходов для запуска рабочих процессов, которые ничего не делают.

Так что мне интересно, как это должно работать, если я установлю значение семафора на 0, я думаю, что тогда он не должен запускать рабочий процесс, поскольку он говорит 0. У кого-нибудь есть информация об этом?

Вот шаги, которые я выполнил:

  1. Сначала я применяю свою конфигурационную карту с помощью kubectl -f.
  2. Затем я отправляю несколько рабочих процессов, и, поскольку все они используют один и тот же семафор, Арго запустит один, а остальные будут выполняться по порядку по одному.
  3. Затем я изменяю значение семапура с помощью kubectl edit configMap
  4. Отправьте новое задание, которое затем выполнит Арго.

Возможно, Арго не перезагрузит configMap, когда я обновлю configMap через kubectl edit? Я хотел бы программно обновить конфигурационную карту в будущем, но сейчас использовал kubectl edit для тестирования.


kubernetes argo-workflows argoproj semaphore
person tse    schedule 19.10.2020    source источник
comment
Вы можете опубликовать точные шаги воспроизведения? Я только что протестировал семафор со значением 0, и он вел себя так, как ожидалось (выполнение рабочего процесса заблокировано).   -  person Michael Crenshaw    schedule 19.10.2020

Ответы (1)


arrow_upward
2
arrow_downward

Быстрое исправление: после применения изменения ConfigMap выполните цикл модуля контроллера рабочего процесса. Это заставит его перезагрузить состояние семафора.

Я не смог воспроизвести вашу точную проблему. После использования kubectl edit для установки семафора на 0 все вновь отправленные рабочие процессы остались Pending.

Я действительно столкнулся с проблемой, когда использование kubectl edit для увеличения лимита семафоров не запускало автоматически ни один из Pending рабочих процессов. Переключение модуля контроллера рабочего процесса позволило снова запустить рабочий процесс.

Помимо использования быстрого исправления, я бы рекомендовал отправить проблему. Синхронизация - новая функция, и, возможно, она еще не на 100% надежна.

person Michael Crenshaw    schedule 19.10.2020
comment
Хорошо, я столкнулся с той же проблемой, которая возникла после включения диспетчера рабочих процессов. Спасибо за вашу быструю помощь, и я опубликую вопрос на их странице github. - person tse; 19.10.2020