Merge remote-tracking branch 'upstream/main' into dev-1.23

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

@@ -17,8 +17,6 @@ A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repe
 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.
 
-In addition, the CronJob schedule supports timezone handling, you can specify the timezone by adding "CRON_TZ=<time zone>" at the beginning of the CronJob schedule, and it is recommended to always set `CRON_TZ`.
-
 {{< caution >}}
 All **CronJob** `schedule:` times are based on the timezone of the
 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}.
@@ -28,6 +26,16 @@ containers, the timezone set for the kube-controller-manager container determine
 that the cron job controller uses.
 {{< /caution >}}
 
+{{< caution >}}
+The [v1 CronJob API](/docs/reference/kubernetes-api/workload-resources/cron-job-v1/)
+does not officially support setting timezone as explained above.
+
+Setting variables such as `CRON_TZ` or `TZ` is not officially supported by the Kubernetes project.
+`CRON_TZ` or `TZ` is an implementation detail of the internal library being used
+for parsing and calculating the next Job creation time. Any usage of it is not
+recommended in a production cluster.
+{{< /caution >}}
+
 When creating the manifest for a CronJob resource, make sure the name you provide
 is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 The name must be no longer than 52 characters. This is because the CronJob controller will automatically
@@ -55,16 +63,15 @@ takes you through this example in more detail).
 ### Cron schedule syntax
 
 ```
-#      ┌────────────────── timezone (optional)
-#      |      ┌───────────── minute (0 - 59)
-#      |      │ ┌───────────── hour (0 - 23)
-#      |      │ │ ┌───────────── day of the month (1 - 31)
-#      |      │ │ │ ┌───────────── month (1 - 12)
-#      |      │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
-#      |      │ │ │ │ │                                   7 is also Sunday on some systems)
-#      |      │ │ │ │ │
-#      |      │ │ │ │ │
-# CRON_TZ=UTC * * * * *
+# ┌───────────── minute (0 - 59)
+# │ ┌───────────── hour (0 - 23)
+# │ │ ┌───────────── day of the month (1 - 31)
+# │ │ │ ┌───────────── month (1 - 12)
+# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
+# │ │ │ │ │                                   7 is also Sunday on some systems)
+# │ │ │ │ │
+# │ │ │ │ │
+# * * * * *
 ```
 
 
@@ -78,9 +85,9 @@ takes you through this example in more detail).
 
 
 
-For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight(in UTC):
+For example, the line below states that the task must be started every Friday at midnight, as well as on the 13th of each month at midnight:
 
-`CRON_TZ=UTC 0 0 13 * 5`
+`0 0 13 * 5`
 
 To generate CronJob schedule expressions, you can also use web tools like [crontab.guru](https://crontab.guru/).
 

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

@@ -703,6 +703,7 @@ You can pause a Deployment before triggering one or more updates and then resume
 apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.
 
 * For example, with a Deployment that was created:
+
   Get the Deployment details:
   ```shell
   kubectl get deploy
@@ -753,7 +754,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
     REVISION  CHANGE-CAUSE
     1   <none>
     ```
-* Get the rollout status to ensure that the Deployment is updated successfully:
+* Get the rollout status to verify that the existing ReplicaSet has not changed:
     ```shell
     kubectl get rs
     ```

content/en/docs/concepts/workloads/pods/init-containers.md

@@ -282,7 +282,7 @@ define readiness distinct from completion. This is enforced during validation.
 
 Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever.
 The active deadline includes init containers.
-However it is recommended to use `activeDeadlineSeconds` if user deploy their application
+However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application
 as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished.
 The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.
 

content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -236,41 +236,41 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
 
 Suppose you have a 5-node cluster ranging from zoneA to zoneC:
 
-    {{<mermaid>}}
-    graph BT
-        subgraph "zoneB"
-            p3(Pod) --> n3(Node3)
-            n4(Node4)
-        end
-        subgraph "zoneA"
-            p1(Pod) --> n1(Node1)
-            p2(Pod) --> n2(Node2)
-        end
+{{<mermaid>}}
+graph BT
+    subgraph "zoneB"
+        p3(Pod) --> n3(Node3)
+        n4(Node4)
+    end
+    subgraph "zoneA"
+        p1(Pod) --> n1(Node1)
+        p2(Pod) --> n2(Node2)
+    end
 
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n1,n2,n3,n4,p1,p2,p3 k8s;
-    class p4 plain;
-    class zoneA,zoneB cluster;
-    {{< /mermaid >}}
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+class n1,n2,n3,n4,p1,p2,p3 k8s;
+class p4 plain;
+class zoneA,zoneB cluster;
+{{< /mermaid >}}
 
-    {{<mermaid>}}
-    graph BT
-        subgraph "zoneC"
-            n5(Node5)
-        end
+{{<mermaid>}}
+graph BT
+    subgraph "zoneC"
+        n5(Node5)
+    end
 
-    classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
-    classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
-    classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
-    class n5 k8s;
-    class zoneC cluster;
-    {{< /mermaid >}}
+classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
+classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
+class n5 k8s;
+class zoneC cluster;
+{{< /mermaid >}}
 
 and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
 
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
+{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
 
 The scheduler doesn't have prior knowledge of all the zones or other topology domains that a cluster has. They are determined from the existing nodes in the cluster. This could lead to a problem in autoscaled clusters, when a node pool (or node group) is scaled to zero nodes and the user is expecting them to scale up, because, in this case, those topology domains won't be considered until there is at least one node in them.