Merge pull request kubernetes#37957 from windsonsea/cronjob

Fix typos in cron-jobs.md

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

@@ -92,6 +92,7 @@ For example, the line below states that the task must be started every Friday at
 To generate CronJob schedule expressions, you can also use web tools like [crontab.guru](https://crontab.guru/).
 
 ## Time zones
+
 For CronJobs with no time zone specified, the kube-controller-manager interprets schedules relative to its local time zone.
 
 {{< feature-state for_k8s_version="v1.25" state="beta" >}}
@@ -101,7 +102,7 @@ you can specify a time zone for a CronJob (if you don't enable that feature gate
 Kubernetes that does not have experimental time zone support, all CronJobs in your cluster have an unspecified
 timezone).
 
-When you have the feature enabled, you can set `spec.timeZone` to the name of a valid [time zone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) name. For example, setting
+When you have the feature enabled, you can set `spec.timeZone` to the name of a valid [time zone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). For example, setting
 `spec.timeZone: "Etc/UTC"` instructs Kubernetes to interpret the schedule relative to Coordinated Universal Time.
 
 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.
@@ -121,23 +122,23 @@ 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.
 
-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.
+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.
 
 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.
+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 (i.e., 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.
@@ -146,7 +147,7 @@ the Job in turn is responsible for the management of the Pods it represents.
 
 Starting with Kubernetes v1.21 the second version of the CronJob controller
 is the default implementation. To disable the default CronJob controller
-and use the original CronJob controller instead, one pass the `CronJobControllerV2`
+and use the original CronJob controller instead, pass the `CronJobControllerV2`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 flag to the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}},
 and set this flag to `false`. For example: