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