capitalize Jobs in CronJob doc

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

@@ -19,7 +19,7 @@ A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repe
 
 CronJob is meant for performing regular scheduled actions such as backups, report generation,
 and so on. One CronJob object is like one line of a _crontab_ (cron table) file on a
-Unix system. It runs a job periodically on a given schedule, written in
+Unix system. It runs a Job periodically on a given schedule, written in
 [Cron](https://en.wikipedia.org/wiki/Cron) format.
 
 CronJobs have limitations and idiosyncrasies.
@@ -101,14 +101,14 @@ You can specify common metadata for the templated Jobs, such as
 {{< glossary_tooltip text="annotations" term_id="annotation" >}}.
 For information about writing a Job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec).
 
-### Deadline for delayed job start {#starting-deadline}
+### Deadline for delayed Job start {#starting-deadline}
 
 The `.spec.startingDeadlineSeconds` field is optional.
 This field defines a deadline (in whole seconds) for starting the Job, if that Job misses its scheduled time
 for any reason.
 
 After missing the deadline, the CronJob skips that instance of the Job (future occurrences are still scheduled).
-For example, if you have a backup job that runs twice a day, you might allow it to start up to 8 hours late,
+For example, if you have a backup Job that runs twice a day, you might allow it to start up to 8 hours late,
 but no later, because a backup taken any later wouldn't be useful: you would instead prefer to wait for
 the next scheduled run.
 
@@ -116,28 +116,28 @@ For Jobs that miss their configured deadline, Kubernetes treats them as failed J
 If you don't specify `startingDeadlineSeconds` for a CronJob, the Job occurrences have no deadline.
 
 If the `.spec.startingDeadlineSeconds` field is set (not null), the CronJob
-controller measures the time between when a job is expected to be created and
+controller measures the time between when a Job is expected to be created and
 now. If the difference is higher than that limit, it will skip this execution.
 
-For example, if it is set to `200`, it allows a job to be created for up to 200
+For example, if it is set to `200`, it allows a Job to be created for up to 200
 seconds after the actual schedule.
 
 ### Concurrency policy
 
 The `.spec.concurrencyPolicy` field is also optional.
-It specifies how to treat concurrent executions of a job that is created by this CronJob.
+It specifies how to treat concurrent executions of a Job that is created by this CronJob.
 The spec may specify only one of the following concurrency policies:
 
-* `Allow` (default): The CronJob allows concurrently running jobs
-* `Forbid`: The CronJob does not allow concurrent runs; if it is time for a new job run and the
-  previous job run hasn't finished yet, the CronJob skips the new job run. Also note that when the
-  previous job run finishes, `.spec.startingDeadlineSeconds` is still taken into account and may
-  result in a new job run.
-* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the
-  CronJob replaces the currently running job run with a new job run
+* `Allow` (default): The CronJob allows concurrently running Jobs
+* `Forbid`: The CronJob does not allow concurrent runs; if it is time for a new Job run and the
+  previous Job run hasn't finished yet, the CronJob skips the new Job run. Also note that when the
+  previous Job run finishes, `.spec.startingDeadlineSeconds` is still taken into account and may
+  result in a new Job run.
+* `Replace`: If it is time for a new Job run and the previous Job run hasn't finished yet, the
+  CronJob replaces the currently running Job run with a new Job run
 
-Note that concurrency policy only applies to the jobs created by the same cron job.
-If there are multiple CronJobs, their respective jobs are always allowed to run concurrently.
+Note that concurrency policy only applies to the Jobs created by the same CronJob.
+If there are multiple CronJobs, their respective Jobs are always allowed to run concurrently.
 
 ### Schedule suspension
 
@@ -151,19 +151,19 @@ scheduled, but the CronJob controller does not start the Jobs to run the tasks)
 you unsuspend the CronJob.
 
 {{< caution >}}
-Executions that are suspended during their scheduled time count as missed jobs.
+Executions that are suspended during their scheduled time count as missed Jobs.
 When `.spec.suspend` changes from `true` to `false` on an existing CronJob without a
-[starting deadline](#starting-deadline), the missed jobs are scheduled immediately.
+[starting deadline](#starting-deadline), the missed Jobs are scheduled immediately.
 {{< /caution >}}
 
 ### Jobs history limits
 
 The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional.
-These fields specify how many completed and failed jobs should be kept.
+These fields specify how many completed and failed Jobs should be kept.
 By default, they are set to 3 and 1 respectively.  Setting a limit to `0` corresponds to keeping
-none of the corresponding kind of jobs after they finish.
+none of the corresponding kind of Jobs after they finish.
 
-For another way to clean up jobs automatically, see [Clean up finished jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
+For another way to clean up Jobs automatically, see [Clean up finished Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically).
 
 ### Time zones
 
@@ -209,7 +209,7 @@ Kubernetes tries to avoid those situations, but does not completely prevent them
 the Jobs that you define should be _idempotent_.
 
 If `startingDeadlineSeconds` is set to a large value or left unset (the default)
-and if `concurrencyPolicy` is set to `Allow`, the jobs will always run
+and if `concurrencyPolicy` is set to `Allow`, the Jobs will always run
 at least once.
 
 {{< caution >}}
@@ -217,19 +217,19 @@ If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob
 {{< /caution >}}
 
 
-For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error.
+For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the Job and logs the error.
 
 ```
 Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
 ```
 
-It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed jobs occurred in the last 200 seconds.
+It is important to note that if the `startingDeadlineSeconds` field is set (not `nil`), the controller counts how many missed Jobs occurred from the value of `startingDeadlineSeconds` until now rather than from the last scheduled time until now. For example, if `startingDeadlineSeconds` is `200`, the controller counts how many missed Jobs occurred in the last 200 seconds.
 
 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 CronJob is set to schedule a new Job every one minute beginning at `08:30:00`, and its
 `startingDeadlineSeconds` field is not set. 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.
+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