v2.5 and after
CronWorkflow are workflows that run on a preset schedule. They are designed to be converted from
Workflow easily and to mimick the same options as Kubernetes
CronJob. In essence,
Workflow + some specific cron options.
CronWorkflow spec would look like:
apiVersion: argoproj.io/v1alpha1 kind: CronWorkflow metadata: name: test-cron-wf spec: schedule: "* * * * *" concurrencyPolicy: "Replace" startingDeadlineSeconds: 0 workflowSpec: entrypoint: whalesay templates: - name: whalesay container: image: alpine:3.6 command: [sh, -c] args: ["date; sleep 90"]
CronWorkflow.spec.workflowSpec is the same type as
Workflow.spec and serves as a template for
Workflow objects that are created from it. Everything under this spec will be converted to a
Workflow name will be a generated name based on the
CronWorkflow name. In this example it could be something like
CronWorkflow.spec.workflowMetadata can be used to add
|Option Name||Default Value||Description|
||None, must be provided||Schedule at which the
||Machine timezone||Timezone during which the Workflow will be run from the IANA timezone standard, e.g.
||Policy that determines what to do if multiple
||Number of seconds after the last successful run during which a missed
||Number of successful
||Number of failed
workflow-controller crashes (and hence the
CronWorkflow controller), there are some options you can set to ensure that
CronWorkflows that would have been scheduled while the controller was down can still run. Mainly
startingDeadlineSeconds can be set to specify the maximum number of seconds past the last successful run of a
CronWorkflow during which a missed run will still be executed.
For example, if a
CronWorkflow that runs every minute is last run at 12:05:00, and the controller crashes between 12:05:55 and 12:06:05, then the expected execution time of 12:06:00 would be missed. However, if
startingDeadlineSeconds is set to a value greater than 65 (the amount of time passing between the last scheduled run time of 12:05:00 and the current controller restart time of 12:06:05), then a single instance of the
CronWorkflow will be executed exactly at 12:06:05.
Currently only a single instance will be executed as a result of setting
This setting can also be configured in tandem with
concurrencyPolicy to achieve more fine-tuned control.
CronWorkflow can be created from the CLI by using basic commands:
$ argo cron create cron.yaml Name: test-cron-wf Namespace: argo Created: Mon Nov 18 10:17:06 -0800 (now) Schedule: * * * * * Suspended: false StartingDeadlineSeconds: 0 ConcurrencyPolicy: Forbid $ argo cron list NAME AGE LAST RUN SCHEDULE SUSPENDED test-cron-wf 49s N/A * * * * * false # some time passes $ argo cron list NAME AGE LAST RUN SCHEDULE SUSPENDED test-cron-wf 56s 2s * * * * * false $ argo cron get test-cron-wf Name: test-cron-wf Namespace: argo Created: Wed Oct 28 07:19:02 -0600 (23 hours ago) Schedule: * * * * * Suspended: false StartingDeadlineSeconds: 0 ConcurrencyPolicy: Replace LastScheduledTime: Thu Oct 29 06:51:00 -0600 (11 minutes ago) NextScheduledTime: Thu Oct 29 13:03:00 +0000 (32 seconds from now) Active Workflows: test-cron-wf-rt4nf
NextScheduledRun assumes that the workflow-controller uses UTC as its timezone
kubectl apply -f and
kubectl get cwf
See cron backfill.
GitOps via Argo CD¶
CronWorkflow resources can be managed with GitOps by using Argo CD
CronWorkflow resources can also be managed by the UI