Great question! Let's break down your options clearly, since you want a one-time scheduled execution instead of recurring runs—no need to stick with persistent CronWorkflows if you don't want to.

1. Best Approach: Use a One-Time CronWorkflow #

Argo's CronWorkflow is designed for scheduling, and you can easily configure it to run exactly once at your target time. This is far more reliable than trying to hack delays into a regular Workflow, since it leverages Argo's native scheduling system.

Key Configuration Details #

Instead of a recurring Cron expression, use a one-time schedule (e.g., 30 14 5 10 * for UTC 14:30 on October 5th). Pair this with settings to clean up after execution and prevent accidental repeats:

Example CronWorkflow (Using Your Existing WorkflowTemplate)

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: one-time-scheduled-run
spec:
  # Set your target time as a one-time Cron expression
  schedule: "30 14 5 10 *"
  # If the schedule is missed by less than 60s, still run it (adjust as needed)
  startingDeadlineSeconds: 60
  # Reference your existing WorkflowTemplate
  workflowTemplateRef:
    name: my-workflow-template
  # Prevent duplicate runs if something goes wrong
  concurrencyPolicy: Forbid
  # Keep minimal history to avoid cluttering your cluster
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1
  # Optional: Auto-delete the CronWorkflow 1 hour after completion
  ttlStrategy:
    secondsAfterCompletion: 3600

Submit via REST API #

You can POST this YAML directly to Argo's API endpoint:

curl -X POST \
  http://<your-argo-server-url>/apis/argoproj.io/v1alpha1/namespaces/<your-namespace>/cronworkflows \
  -H "Content-Type: application/yaml" \
  -d @one-time-cwf.yaml

2. Can You Use a Regular Workflow with Delay? #

Short answer: Yes, but it's not recommended. Regular Workflows start immediately when submitted, so you'd have to add a manual delay step (like a sleep script) to wait until your target time.

Example Delayed Workflow

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: delayed-manual-run
spec:
  entrypoint: wait-then-execute
  templates:
    - name: wait-then-execute
      steps:
        - - name: delay-step
            template: sleep-until-target
        - - name: run-workflow
            templateRef:
              name: my-workflow-template
              template: <your-template-entrypoint>
    - name: sleep-until-target
      script:
        image: alpine:3.18
        command: [sh]
        source: |
          TARGET="2024-10-05T14:30:00Z"
          NOW=$(date -u +%s)
          TARGET_TIMESTAMP=$(date -u -d "$TARGET" +%s)
          DELAY=$((TARGET_TIMESTAMP - NOW))
          if [ $DELAY -gt 0 ]; then
            sleep $DELAY
          fi

The big downside here is reliability: if the delay pod restarts or the Argo controller goes down, your timing will break. Stick with CronWorkflow for production use.

3. Using CronWorkflowTemplate with REST API #

Absolutely! If you want to reuse common CronWorkflow settings (like history limits or concurrency rules), define a CronWorkflowTemplate first, then create one-time instances from it via API.

Step 1: Define the CronWorkflowTemplate #

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflowTemplate
metadata:
  name: my-reusable-cwf-template
spec:
  workflowTemplateRef:
    name: my-workflow-template
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 1
  failedJobsHistoryLimit: 1

Step 2: Create a One-Time Instance via API #

Submit a CronWorkflow that references the template and sets your one-time schedule:

curl -X POST \
  http://<your-argo-server-url>/apis/argoproj.io/v1alpha1/namespaces/<your-namespace>/cronworkflows \
  -H "Content-Type: application/yaml" \
  -d '
apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: one-time-from-template
spec:
  schedule: "30 14 5 10 *"
  startingDeadlineSeconds: 60
  cronWorkflowTemplateRef:
    name: my-reusable-cwf-template
  ttlStrategy:
    secondsAfterCompletion: 3600
'

Quick Recap #

• Recommended: Use a one-time CronWorkflow (or CronWorkflowTemplate instance) for reliable, native scheduling.
• Avoid: Regular Workflows with manual delays—they're prone to failure.
• No recurring runs: Since you're creating a CronWorkflow with a one-time schedule and auto-delete TTL, it won't run again after its target time.

内容的提问来源于stack exchange，提问作者Chayan Ghosh