Kubernetes is a core component of an OpenShift Container Platform. So, the things we will discuss apply to both Kubernetes and Openshift.
The time zone feature for CronJobs was first introduced as alpha in Kubernetes version 1.24. Before that, All cron job schedule times are based on the timezone of the master node where the job is initiated.
The beta version was released in Kubernetes version 1.25. Finally, a stable version was released in Kubernetes 1.27.
Openshift
Kubernetes
4.11
1.24
4.12
1.25
4.14
1.27
Openshit with its corresponding Kubernetes versions
Creating a Cron Job with timeZone
A cron job builds on a regular job by allowing you to specifically schedule how the job should be run. Cron jobs are part of the Kubernetes API, which can be managed with oc commands like other object types.
The following is an example of a CronJob resource:
For CronJobs with no time zone specified, the kube-controller-manager interprets schedules relative to its local time zone.
You can specify a time zone for a CronJob by setting .spec.timeZone it to the name of a valid time zone. For example, the setting .spec.timeZone: "Etc/UTC" instructs Kubernetes to interpret the schedule relative to Coordinated Universal Time. The time zone name for the given schedule, see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
A time zone database from the Go standard library is included in the binaries and used as a fallback in case an external database is not available on the system.
Unsupported TimeZone specification
Specifying a timezone using CRON_TZ or TZ variables inside .spec.schedule is not officially supported (and never has been).
Starting with Kubernetes 1.29 if you try to set a schedule that includes TZ or CRON_TZ timezone specification, Kubernetes will fail to create the resource with a validation error. Updates to CronJobs already using TZ or CRON_TZ will continue to report a warning to the client.
The CronJob Properties mentioned in the above example:-
schedule
The schedule field for the job is specified in cron format. In this example, the job runs every minute.
concurrencyPolicy
Optional: The concurrency policy specifies how the job controller treats concurrent jobs within a cron job. Only one of the following policies can be specified:
Allow allows multiple instances of the job to run concurrently. Allow is the default value.
Forbid prevents multiple instances of the job from running concurrently. Scheduled runs are skipped if the previous run has not finished.
Replace cancels a currently running instance of the job and replaces the job with a new instance.
startingDeadlineSeconds
Optional: The starting deadline specifies a deadline (in seconds) for starting the job if a scheduled run is missed for any reason. After the deadline, the cron job does not start the job. Missed job runs are counted as failed jobs. By default, jobs have no deadline. Be aware that when this field is set, the cron job controller counts the number of missed jobs that occur in the interval between the value for the deadline and the current moment. For example, if startingDeadlineSeconds is set to 200, the controller counts the number of missed jobs in the last 200 seconds. For more information, see the limitations for cron jobs in the Kubernetes documentation for cron job concepts.
suspend
Optional: The suspend field is used to prevent subsequent runs of the cron job. If set to true, then all subsequent runs are prevented from starting. By default, the value is false, and jobs are run.
successfulJobsHistoryLimit
Optional: The successful jobs history limit specifies the number of finished jobs to retain. By default, three jobs are retained.
failedJobsHistoryLimit
Optional: The failed jobs history limit specifies the number of failed jobs to retain. By default, one job is retained.
jobTemplate
The job template specifies the job to run. The field is similar to the job example.
labels
Optional: The labels field specifies a label to set for jobs that are started by the cron job. In this example, jobs receive the label parent=cronjobtheCodersStop.
restartPolicy
Optional: The restart policy for pods that are started to run the job. The policy can be set to Always, OnFailure, or Never. By default, containers are always restarted. Be aware that this field does not apply to the job controller. See Known Limitations for details.
I hope you have enjoyed this post and it helped you to understand the CronJob in Kubernetes/Openshift and how it works. Please like and share and feel free to comment if you have any suggestions or feedback.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Pradeep Mishra
Share post:
Overview
Kubernetes is a core component of an OpenShift Container Platform. So, the things we will discuss apply to both Kubernetes and Openshift.
The time zone feature for CronJobs was first introduced as alpha in Kubernetes version 1.24. Before that, All cron job schedule times are based on the timezone of the master node where the job is initiated.
The beta version was released in Kubernetes version 1.25. Finally, a stable version was released in Kubernetes 1.27.
Creating a Cron Job with timeZone
A cron job builds on a regular job by allowing you to specifically schedule how the job should be run. Cron jobs are part of the Kubernetes API, which can be managed with
occommands like other object types.The following is an example of a CronJob resource:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: theCodersStop spec: schedule: "*/1 * * * *" timeZone: 'America/New_York' #Change timezone as per requirement concurrencyPolicy: "Replace" startingDeadlineSeconds: 200 suspend: false successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 1 jobTemplate: spec: template: metadata: labels: parent: "cronjobtheCodersStop" spec: containers: - name: theCodersStop image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: OnFailureTime zones
For CronJobs with no time zone specified, the kube-controller-manager interprets schedules relative to its local time zone.
You can specify a time zone for a CronJob by setting
.spec.timeZoneit to the name of a valid time zone. For example, the setting.spec.timeZone: "Etc/UTC"instructs Kubernetes to interpret the schedule relative to Coordinated Universal Time. The time zone name for the given schedule, see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.A time zone database from the Go standard library is included in the binaries and used as a fallback in case an external database is not available on the system.
Unsupported TimeZone specification
Specifying a timezone using
CRON_TZorTZvariables inside.spec.scheduleis not officially supported (and never has been).Starting with Kubernetes 1.29 if you try to set a schedule that includes
TZorCRON_TZtimezone specification, Kubernetes will fail to create the resource with a validation error. Updates to CronJobs already usingTZorCRON_TZwill continue to report a warning to the client.The CronJob Properties mentioned in the above example:-
Allowallows multiple instances of the job to run concurrently.Allowis the default value.Forbidprevents multiple instances of the job from running concurrently. Scheduled runs are skipped if the previous run has not finished.Replacecancels a currently running instance of the job and replaces the job with a new instance.startingDeadlineSecondsis set to200, the controller counts the number of missed jobs in the last 200 seconds. For more information, see the limitations for cron jobs in the Kubernetes documentation for cron job concepts.true, then all subsequent runs are prevented from starting. By default, the value isfalse, and jobs are run.parent=cronjobtheCodersStop.Always,OnFailure, orNever. By default, containers are always restarted. Be aware that this field does not apply to the job controller. See Known Limitations for details.I hope you have enjoyed this post and it helped you to understand the CronJob in Kubernetes/Openshift and how it works. Please like and share and feel free to comment if you have any suggestions or feedback.
Resources:
https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones
https://docs.openshift.com/container-platform/4.14/rest_api/workloads_apis/cronjob-batch-v1.html
Share this:
Like this: