Merge branch 'master' into dev-1.18

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

@@ -17,9 +17,14 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
 One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
 on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
 
-{{< note >}}
-All **CronJob** `schedule:` times are based on the timezone of the master where the job is initiated.
-{{< /note >}}
+{{< caution >}}
+All **CronJob** `schedule:` times are based on the timezone of the
+{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
+
+If your control plane runs the kube-controller-manager in Pods or bare
+containers, the timezone set for the kube-controller-manager container determines the timezone
+that the cron job controller uses.
+{{< /caution >}}
 
 When creating the manifest for a CronJob resource, make sure the name you provide
 is no longer than 52 characters. This is because the CronJob controller will automatically

content/en/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -36,7 +36,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
 [example](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
 The TTL controller will assume that a resource is eligible to be cleaned up
 TTL seconds after the resource has finished, in other words, when the TTL has expired. When the
-TTL controller cleans up a resource, it will delete it cascadingly, i.e. delete
+TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete
 its dependent objects together with it. Note that when the resource is deleted,
 its lifecycle guarantees, such as finalizers, will be honored.