【问题标题】:How to prevent Argo Workflow from being resubmitted if it is already running?如果 Argo Workflow 已经在运行,如何防止它被重新提交?
【发布时间】:2021-02-23 16:04:28
【问题描述】:

用例是我们考虑通过带有 PubSub 的 Argo 事件触发 Argo 工作流。 PubSub 不保证一条消息只传递一次。是否有一种简单的方法可以防止已经运行的工作流再次被触发?

类似于 CronWorkflows 的 concurrencyPolicy 设置。

有一些东西要看 - 让我们假设whalsay工作流程:

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

我发现了以下两个有希望的问题 - 但我无法提取此问题的解决方案。

【问题讨论】:

    标签: synchronization argo-workflows argoproj


    【解决方案1】:

    如果您只需要确保工作流不会同时运行多个实例,请使用 Argo 的内置 synchronization 功能。

    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
    # ...
    

    如果您想避免两次处理同一条消息,您可以在工作流中添加一个步骤,以便在消息 ID 在数据库中(或类似的东西)时提前退出。

    【讨论】:

    • 我认为这也是我链接的 github 讨论中建议的解决方案。感觉有点“神奇”——也许是因为我对 K8s 和 Argo 还不够熟悉。
    • 哈哈公平,我也讨厌魔法。基本上,工作流(就 Kubernetes 而言)几乎只是一堆 yaml。 Argo 工作流控制器 Pod 负责查看该 yaml 何时出现并对其进行处理(启动 Pod 等)。工作流控制器 Pod 跟踪有多少工作流声明了一个信号量。如果显示的工作流超过了声明限制,则工作流控制器只会将该工作流置于冰上,直到释放声明为止。
    最近更新 更多