Как предотвратить повторную отправку Argo Workflow, если он уже запущен?

Пример использования состоит в том, что мы думаем о запуске рабочего процесса Argo через события Argo с PubSub. PubSub не гарантирует, что сообщение будет доставлено только один раз. Есть ли простой способ предотвратить повторный запуск рабочего процесса, когда он уже запущен?

Что-то вроде настройки concurrencyPolicy для CronWorkflows.

Чтобы было на что взглянуть - давайте предположим, что рабочий процесс whalesay:

apiVersion: argoproj.io/v1alpha1
kind: Workflow                  # new type of k8s spec
metadata:
  name: hello-world    # name of the workflow spec
  namespace: argo
spec:
  entrypoint: whalesay          # invoke the whalesay template
  templates:
  - name: whalesay              # name of the template
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world"]
      resources:                # limit the resources
        limits:
          memory: 32Mi
          cpu: 100m

Я обнаружил следующие две многообещающие проблемы, но мне не удалось найти решение этой проблемы.


argo-workflows argoproj synchronization
person Raffael    schedule 23.02.2021    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

apiVersion: v1
kind: ConfigMap
metadata:
 name: my-config
data:
  workflow: "1"  # Only one workflow can run at given time in particular namespace

---

apiVersion: argoproj.io/v1alpha1
kind: Workflow 
metadata:
  name: hello-world
spec:
  entrypoint: whalesay
  synchronization:
    semaphore:
      configMapKeyRef:
        name: my-config
        key: workflow
  templates:
  - name: whalesay
    container:
      image: docker/whalesay
# ...

Если вы хотите избежать обработки одного и того же сообщения дважды, вы можете добавить в рабочий процесс шаг для раннего выхода, если идентификатор сообщения находится в базе данных (или что-то в этом роде).

person Michael Crenshaw    schedule 23.02.2021
comment
Я думаю, что это тоже решение, предложенное в моих связанных обсуждениях github. Это немного волшебно - возможно, потому, что я еще недостаточно знаком с K8s и Argo. - person Raffael; 23.02.2021
comment
лол честно, я тоже ненавижу магию. По сути, рабочий процесс (для Kubernetes) - это просто груда yaml. Pod контроллера рабочего процесса Argo отвечает за то, чтобы видеть, когда появляется этот yaml, и что-то делать с ним (запускать Pod'ы и т. Д.). Модуль контроллера рабочего процесса отслеживает, сколько рабочих процессов потребовало семафор. Если обнаруживается рабочий процесс, превышающий лимит требований, контроллер рабочего процесса просто приостанавливает рабочий процесс до тех пор, пока не освободится требование. - person Michael Crenshaw; 23.02.2021