Cron task
A crontask schedules the execution of a job that will run code or a script to completion. For tasks that will be run only once, the task component type is the preferred option.
Basic information
The crontask contains a definition of the task to be executed with the addition of the scheduling configuration. Basic information includes the image
that will be launched with an optional cmd
property to define a command different from the one in the image entrypoint. Additionally, the container can define the requested CPU and memory to better utilize the available quota. Use count
to launch several replicas of the task. The following YAML file contains a minimal example of a task with basic information.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mycrontask # Name of the component
type: cron-task # Set to cron-task
properties:
image: my-app-image:v1.0.0 # (Required) Container image
count: 1 # (Required) number of tasks running. 1 by default
cmd: ["server", "run"] # (Optional) Commands to run in the container.
cpu: "0.5" # (Optional) Define the requested CPU.
memory: 256Mi # (Optional) Define the requested memory.
schedule: "*/1 * * * *" # (Required) cron schedule
Understanding cron scheduling
The method to schedule a task follows the standard Linux/Kubernetes approach. The schedule
field has the following syntax
<minute> <hour> <day of the month> <month> <day of the week>
where
Field | Values |
---|---|
minute | 0 - 59 |
hour | 0 - 23 |
day of the month | 1 - 31 |
month | 1 - 12 |
day of the week | 0 - 6, or sun, mon, tue, wed, thu, fri, sat |
Field modifier | Effect | Example |
---|---|---|
* | match any value | * |
, | used to specify a list of values | 15,30,45 |
- | range of values | 10-15 |
/ | step values | */5 |
Examples | schedule |
---|---|
Execute a task at 08:00 and 15:00 | * 8,15 * * * |
Execute a task on Mondays at 13:00 | 30 13 * * mon |
Execute tasks at one minute intervals from 09:45 to 09:59 | 45/1 9 * * * |
For other examples, check crontab.guru. The following snippet shows a crontask with all the scheduling options.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mycrontask # Name of the component
type: cron-task # Set to cron-task
properties:
image: my-app-image:v1.0.0 # (Required) Container image
count: 1 # (Required) number of tasks running. 1 by default
schedule: "*/1 * * * *" # (Required) cron schedule
startingDeadlineSeconds: 2 # (Optional) deadline for starting the job(in seconds)
concurrencyPolicy: Allow # (Optional) how to treat concurrent executions of a job ["Allow" (by default), "Forbid" or "Replace"]
successfulJobsHistoryLimit: 3 # (Optional) Specify how many completed jobs should be kept. 3 by default
failedJobsHistoryLimit: 1 # (Optional) Specify how many failed jobs should be kept. 3 by default
suspend: false # (Optional) If it is set to true, all subsequent executions are suspended. false by default
ttlSecondsAfterFinished?: 10 # (Optional) Limits the lifetime of a Job that has finished
activeDeadlineSeconds?: 10 # (Optional) applies to the duration of the job
backoffLimit: 6 # (Optional) to specify the number of retries before considering a Job as failed
Using volumes
The system supports different methods to attach a volume to a container. The main use cases are:
- Attaching a persistent volume to store information that should survive container reboots.
- Attaching a configmap to include the configuration file in a given path.
- Attaching a secret to include files (e.g., TLS certificates) in a given path.
- Attaching an empty dir as ephemeral storage for temporal files.
The following YAML file contains a minimal example of a crontask component with different volumes attached to it.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mycrontask # Name of the component
type: cron-task # Set to cron-task
properties:
image: my-app-image:v1.0.0 # (Required) Container image
count: 1 # (Required) number of tasks running. 1 by default
schedule: "*/1 * * * *" # (Required) cron schedule
volumes: # (Optional) Definition of the volumes
- name: vol1
mountPath: /vol1/
type: emptyDir # Using an ephemeral
- name: vol2
mountPath: /vol2/
type: configMap # Using a Config Map
cmName: game-demo
- name: vol3
mountPath: /vol3/
type: secret # Using a Secret
secretName: mysecret
- name: vol4
mountPath: /vol4/
type: pvc # Using a Persistent Volume Claim
claimName: mypvc
Full example
The following YAML shows a complete example of a crontask with all the major options.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mycrontask # Name of the component
type: cron-task # Set to cron-task
properties:
image: my-app-image:v1.0.0 # (Required) Container image
count: 1 # (Required) number of tasks running. 1 by default
cmd: ["server", "run"] # (Optional) Commands to run in the container.
cpu: "0.5" # (Optional) Define the requested CPU.
memory: 256Mi # (Optional) Define the requested memory.
schedule: "*/1 * * * *" # (Required) cron schedule
labels: # (Optional) labels
label1: value1
label2: value2
annotations: # (Optional) annotations
annotation1: value1
annotation2: value2
startingDeadlineSeconds: 2 # (Optional) deadline for starting the job(in seconds)
concurrencyPolicy: Allow # (Optional) how to treat concurrent executions of a job ["Allow" (by default), "Forbid" or "Replace"]
successfulJobsHistoryLimit: 3 # (Optional) Specify how many completed jobs should be kept. 3 by default
failedJobsHistoryLimit: 1 # (Optional) Specify how many failed jobs should be kept. 3 by default
suspend: false # (Optional) If it is set to true, all subsequent executions are suspended. false by default
ttlSecondsAfterFinished?: 10 # (Optional) Limits the lifetime of a Job that has finished
activeDeadlineSeconds?: 10 # (Optional) applies to the duration of the job
backoffLimit: 6 # (Optional) to specify the number of retries before considering a Job as failed
env: # (Optional) Definition of the environment variables for the container
- name: ENV_VAR1 # Setting the value directly
value: "value1"
- name: ENV_VAR2 # Using a secret to obtain a key value
valueFrom:
secretKeyRef:
name: secret-name
key: key2
- name: ENV_VAR3 # Using a configmap to obtain a key value
valueFrom:
configMapKeyRef:
name: config-map-name
key: key2
volumes: # (Optional) Definition of the volumes
- name: vol1
mountPath: /vol1/
type: emptyDir # Using an ephemeral
- name: vol2
mountPath: /vol2/
type: configMap # Using a Config Map
cmName: game-demo
- name: vol3
mountPath: /vol3/
type: secret # Using a Secret
secretName: mysecret
- name: vol4
mountPath: /vol4/
type: pvc # Using a Persistent Volume Claim
claimName: mypvc
readinessProbe: # (Optional) Definition of the readiness probe to determine the
# if the component can accept traffic.
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3 # Number of seconds after the container is started before the first
# probe is initiated. Set to 0 by default.
periodSeconds: 3 # How often, in seconds, to execute the probe. Set to 10 by default
livenessProbe: # (Optional) Definition of the liveness probe to determine the
# health status of a component rebooting it if needed
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3 # Number of seconds after the container is started before the first
# probe is initiated. Set to 0 by default.
periodSeconds: 3 # How often, in seconds, to execute the probe. Set to 10 by default