Update cron-jobs.md (#11512)

* Update cron-jobs.md

Update to startingDeadlineSeconds concept

* Update jobs-run-to-completion.md

Syntax correction

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>

* Update content/en/docs/concepts/workloads/controllers/cron-jobs.md

Co-Authored-By: k-vishwa <vishwanath.k@kloud9.nyc>
This commit is contained in:
Vishwanath K
2019-02-17 18:34:32 -08:00
committed by Kubernetes Prow Robot
parent 8906e7e929
commit 9654ecc44f
2 changed files with 8 additions and 6 deletions
@@ -46,11 +46,13 @@ It is important to note that if the `startingDeadlineSeconds` field is set (not
A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If `concurrencyPolicy` is set to `Forbid` and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed.
For example, suppose a cron job is set to start at exactly `08:30:00` and its
`startingDeadlineSeconds` is set to 10, if the CronJob controller happens to
be down from `08:29:00` to `08:42:00`, the job will not start.
Set a longer `startingDeadlineSeconds` if starting later is better than not
starting at all.
For example, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
`startingDeadlineSeconds` field is not set. The default for this field is `100` seconds. If the CronJob controller happens to
be down from `08:29:00` to `10:21:00`, the job will not start as the number of missed jobs which missed their schedule is greater than 100.
To illustrate this concept further, suppose a CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
`startingDeadlineSeconds` is set to 200 seconds. If the CronJob controller happens to
be down for the same period as the previous example (`08:29:00` to `10:21:00`,) the Job will still start at 10:22:00. This happens as the controller now checks how many missed schedules happened in the last 200 seconds (ie, 3 missed schedules), rather than from the last scheduled time until now.
The Cronjob is only responsible for creating Jobs that match its schedule, and
the Job in turn is responsible for the management of the Pods it represents.
@@ -83,7 +83,7 @@ To view completed Pods of a Job, use `kubectl get pods`.
To list all the Pods that belong to a Job in a machine readable form, you can use a command like this:
```shell
$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath={.items..metadata.name})
$ pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
$ echo $pods
pi-aiw0a
```