Merge pull request #44909 from drewhagen/merged-main-dev-1.30

Merged main dev 1.30

Author: k8s-ci-robot

OWNERS

@@ -7,7 +7,6 @@ approvers:
 - sig-docs-en-owners # Defined in OWNERS_ALIASES
 
 emeritus_approvers:
-# - celestehorgan, commented out to disable PR assignments
 # - chenopis, commented out to disable PR assignments
 # - irvifa, commented out to disable PR assignments
 # - jaredbhatti, commented out to disable PR assignments

OWNERS_ALIASES

@@ -26,9 +26,10 @@ aliases:
     - bene2k1
     - rlenferink
   sig-docs-en-owners: # Admins for English content
+    - celestehorgan
     - divya-mohan0209
-    - katcosgrove # RT 1.30 Lead
     - drewhagen # RT 1.30 Docs Lead
+    - katcosgrove # RT 1.30 Lead
     - natalisucks
     - nate-double-u
     - onlydole

content/en/docs/concepts/storage/persistent-volumes.md

@@ -358,7 +358,7 @@ spec:
   ...
 ```
 
-This is useful if you want to consume PersistentVolumes that have their `claimPolicy` set
+This is useful if you want to consume PersistentVolumes that have their `persistentVolumeReclaimPolicy` set
 to `Retain`, including cases where you are reusing an existing PV.
 
 ### Expanding Persistent Volumes Claims

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,41 +101,43 @@ 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.
 
 For Jobs that miss their configured deadline, Kubernetes treats them as failed Jobs.
 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
-* `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
 
@@ -149,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
 
@@ -207,27 +209,27 @@ 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 >}}
 If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds.
 {{< /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

content/en/docs/contribute/localization.md

@@ -187,8 +187,11 @@ script and use it in the theme. Assign "language name in latin script" to
 `languageNameLatinScript`. For example, `languageNameLatinScript ="Korean"` or
 `languageNameLatinScript = "Deutsch"`.
 
-When assigning a `weight` parameter for your block, find the language block with
-the highest weight and add 1 to that value.
+The `weight` parameter determines the order of languages in the language selection bar.
+A lower weight takes precedence, resulting in the language appearing first. 
+When assigning the `weight` parameter, it is important to examine the existing languages 
+block and adjust their weights to ensure they are in a sorted order relative to all languages,
+including any newly added language.
 
 For more information about Hugo's multilingual support, see
 "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)".

content/en/docs/contribute/style/style-guide.md

@@ -156,7 +156,7 @@ Run the process as a DaemonSet in the `kube-system` namespace. | Run the process
 {{< table caption = "Do and Don't - Use code style for Kubernetes command tool and component names" >}}
 Do | Don't
 :--| :-----
-The kubelet preserves node stability. | The `kubelet` preserves node stability.
+The `kubelet` preserves node stability. | The kubelet preserves node stability.
 The `kubectl` handles locating and authenticating to the API server. | The kubectl handles locating and authenticating to the apiserver.
 Run the process with the certificate, `kube-apiserver --client-ca-file=FILENAME`. | Run the process with the certificate, kube-apiserver --client-ca-file=FILENAME. |
 {{< /table >}}

content/en/docs/reference/using-api/deprecation-guide.md

@@ -35,11 +35,11 @@ The **flowcontrol.apiserver.k8s.io/v1beta3** API version of FlowSchema and Prior
 
 ### v1.29
 
-The **v1.29** release will stop serving the following deprecated API versions:
+The **v1.29** release stopped serving the following deprecated API versions:
 
 #### Flow control resources {#flowcontrol-resources-v129}
 
-The **flowcontrol.apiserver.k8s.io/v1beta2** API version of FlowSchema and PriorityLevelConfiguration will no longer be served in v1.29.
+The **flowcontrol.apiserver.k8s.io/v1beta2** API version of FlowSchema and PriorityLevelConfiguration is no longer served as of v1.29.
 
 * Migrate manifests and API clients to use the **flowcontrol.apiserver.k8s.io/v1** API version, available since v1.29, or the **flowcontrol.apiserver.k8s.io/v1beta3** API version, available since v1.26.
 * All existing persisted objects are accessible via the new API
@@ -54,7 +54,7 @@ The **v1.27** release stopped serving the following deprecated API versions:
 
 #### CSIStorageCapacity {#csistoragecapacity-v127}
 
-The **storage.k8s.io/v1beta1** API version of CSIStorageCapacity will no longer be served in v1.27.
+The **storage.k8s.io/v1beta1** API version of CSIStorageCapacity is no longer served as of v1.27.
 
 * Migrate manifests and API clients to use the **storage.k8s.io/v1** API version, available since v1.24.
 * All existing persisted objects are accessible via the new API

content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -344,13 +344,7 @@ Before starting the restore operation, a snapshot file must be present. It can
 either be a snapshot file from a previous backup operation, or from a remaining
 [data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir).
 
-Here is an example:
-
-```shell
-ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshot.db
-```
-
-Another example for restoring using `etcdctl` options:
+When restoring the cluster, use the `--data-dir` option to specify to which folder the cluster should be restored:
 
 ```shell
 ETCDCTL_API=3 etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db
@@ -364,6 +358,8 @@ export ETCDCTL_API=3
 etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db
 ```
 
+If `<data-dir-location>` is the same folder as before, delete it and stop etcd process before restoring the cluster. Else change etcd configuration and restart the etcd process after restoration to make it use the new data directory.
+
 For more information and examples on restoring a cluster from a snapshot file, see
 [etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).
 

content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md

@@ -33,12 +33,12 @@ kubectl get deployment --namespace=kube-system
 
 The output is similar to this:
 
-    NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
+    NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
     ...
-    dns-autoscaler            1/1     1            1           ...
+    kube-dns-autoscaler    1/1     1            1           ...
     ...
 
-If you see "dns-autoscaler" in the output, DNS horizontal autoscaling is
+If you see "kube-dns-autoscaler" in the output, DNS horizontal autoscaling is
 already enabled, and you can skip to
 [Tuning autoscaling parameters](#tuning-autoscaling-parameters).
 
@@ -99,13 +99,13 @@ kubectl apply -f dns-horizontal-autoscaler.yaml
 
 The output of a successful command is:
 
-    deployment.apps/dns-autoscaler created
+    deployment.apps/kube-dns-autoscaler created
 
 DNS horizontal autoscaling is now enabled.
 
 ## Tune DNS autoscaling parameters {#tuning-autoscaling-parameters}
 
-Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists:
+Verify that the kube-dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists:
 
 ```shell
 kubectl get configmap --namespace=kube-system
@@ -115,13 +115,13 @@ The output is similar to this:
 
     NAME                  DATA      AGE
     ...
-    dns-autoscaler        1         ...
+    kube-dns-autoscaler   1         ...
     ...
 
 Modify the data in the ConfigMap:
 
 ```shell
-kubectl edit configmap dns-autoscaler --namespace=kube-system
+kubectl edit configmap kube-dns-autoscaler --namespace=kube-system
 ```
 
 Look for this line:
@@ -151,17 +151,17 @@ There are other supported scaling patterns. For details, see
 There are a few options for tuning DNS horizontal autoscaling. Which option to
 use depends on different conditions.
 
-### Option 1: Scale down the dns-autoscaler deployment to 0 replicas
+### Option 1: Scale down the kube-dns-autoscaler deployment to 0 replicas
 
 This option works for all situations. Enter this command:
 
 ```shell
-kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
+kubectl scale deployment --replicas=0 kube-dns-autoscaler --namespace=kube-system
 ```
 
 The output is:
 
-    deployment.apps/dns-autoscaler scaled
+    deployment.apps/kube-dns-autoscaler scaled
 
 Verify that the replica count is zero:
 
@@ -171,37 +171,37 @@ kubectl get rs --namespace=kube-system
 
 The output displays 0 in the DESIRED and CURRENT columns:
 
-    NAME                                 DESIRED   CURRENT   READY   AGE
+    NAME                                  DESIRED   CURRENT   READY   AGE
     ...
-    dns-autoscaler-6b59789fc8            0         0         0       ...
+    kube-dns-autoscaler-6b59789fc8        0         0         0       ...
     ...
 
-### Option 2: Delete the dns-autoscaler deployment
+### Option 2: Delete the kube-dns-autoscaler deployment
 
-This option works if dns-autoscaler is under your own control, which means
+This option works if kube-dns-autoscaler is under your own control, which means
 no one will re-create it:
 
 ```shell
-kubectl delete deployment dns-autoscaler --namespace=kube-system
+kubectl delete deployment kube-dns-autoscaler --namespace=kube-system
 ```
 
 The output is:
 
-    deployment.apps "dns-autoscaler" deleted
+    deployment.apps "kube-dns-autoscaler" deleted
 
-### Option 3: Delete the dns-autoscaler manifest file from the master node
+### Option 3: Delete the kube-dns-autoscaler manifest file from the master node
 
-This option works if dns-autoscaler is under control of the (deprecated)
+This option works if kube-dns-autoscaler is under control of the (deprecated)
 [Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md),
 and you have write access to the master node.
 
 Sign in to the master node and delete the corresponding manifest file.
-The common path for this dns-autoscaler is:
+The common path for this kube-dns-autoscaler is:
 
     /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml
 
 After the manifest file is deleted, the Addon Manager will delete the
-dns-autoscaler Deployment.
+kube-dns-autoscaler Deployment.
 
 
 

content/en/docs/tasks/administer-cluster/encrypt-data.md

@@ -50,12 +50,27 @@ to either:
 
 <!-- steps -->
 
-## Configuration and determining whether encryption at rest is already enabled
+## Determine whether encryption at rest is already enabled {#determining-whether-encryption-at-rest-is-already-enabled}
+
+By default, the API server stores plain-text representations of resources into etcd, with
+no at-rest encryption.
 
 The `kube-apiserver` process accepts an argument `--encryption-provider-config`
-that controls how API data is encrypted in etcd.
-The configuration is provided as an API named
-[`EncryptionConfiguration`](/docs/reference/config-api/apiserver-encryption.v1/). An example configuration is provided below.
+that specifies a path to a configuration file. The contents of that file, if you specify one,
+control how Kubernetes API data is encrypted in etcd.
+If you are running the kube-apiserver without the `--encryption-provider-config` command line
+argument, you do not have encryption at rest enabled. If you are running the kube-apiserver
+with the `--encryption-provider-config` command line argument, and the file that it references
+specifies the `identity` provider as the first encryption provider in the list, then you
+do not have at-rest encryption enabled
+(**the default `identity` provider does not provide any confidentiality protection.**)
+
+If you are running the kube-apiserver
+with the `--encryption-provider-config` command line argument, and the file that it references
+specifies a provider other than `identity` as the first encryption provider in the list, then
+you already have at-rest encryption enabled. However, that check does not tell you whether
+a previous migration to encrypted storage has succeeded. If you are not sure, see
+[ensure all relevant data are encrypted](#ensure-all-secrets-are-encrypted).
 
 {{< caution >}}
 **IMPORTANT:** For high-availability configurations (with two or more control plane nodes), the