.spec.startingDeadlineSeconds 

Deadline (in seconds) for starting the Job if it misses its scheduled time. In some use cases, a task is valid only if it executed within a certain timeframe and is use‐ less when executed late. For example, if a Job is not executed in the desired time because of a lack of compute resources or other missing dependencies, it might be better to skip an execution because the data it is supposed to process is obso‐ lete already. 

.spec.concurrencyPolicy 

Specifies how to manage concurrent executions of Jobs created by the same CronJob. The default behavior Allow  creates new Job instances even if the previ‐ ous Jobs have not completed yet. If that is not the desired behavior, it is possible to skip the next run if the current one has not completed yet with Forbid  or to cancel the currently running Job and start a new one with Replace . 

.spec.suspend 

Field suspending all subsequent executions without affecting already started executions. 

.spec.successfulJobsHistoryLimit  and .spec.failedJobsHistoryLimit 

Fields specifying how many completed and failed Jobs should be kept for audit‐ ing purposes. 

CronJob is a very specialized primitive, and it applies only when a unit of work has a temporal dimension. Even if CronJob is not a general-purpose primitive, it is an excellent example of how Kubernetes capabilities build on top of each other and sup‐ port noncloud-native use cases as well. 

## Discussion 

As you can see, a CronJob is a pretty simple primitive that adds clustered, Cron-like behavior to the existing Job definition. But when it is combined with other primitives such as Pods, container resource isolation, and other Kubernetes features such as those described in Chapter 6, Automated Placement , or Chapter 4, Health Probe , it ends up being a very powerful Job scheduling system. This enables developers to focus solely on the problem domain and implement a containerized application that is responsible only for the business logic to be performed. The scheduling is per‐ formed outside the application, as part of the platform with all of its added benefits such as high availability, resiliency, capacity, and policy-driven Pod placement. Of course, similar to the Job implementation, when implementing a CronJob container, your application has to consider all corner and failure cases of duplicate runs, no runs, parallel runs, or cancellations. 

