Update cron-jobs.md (kubernetes#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 <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]> * Update content/en/docs/concepts/workloads/controllers/cron-jobs.md Co-Authored-By: k-vishwa <[email protected]>
kwiesmueller · Feb 28, 2019 · b05ab02 · b05ab02
1 parent f3e1fd5
commit b05ab02
Show file tree

Hide file tree

Showing 2 changed files with 8 additions and 6 deletions.
diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
@@ -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.

diff --git a/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/en/docs/concepts/workloads/controllers/jobs-run-to-completion.md
@@ -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
 ```