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

content/en/docs/concepts/architecture/nodes.md

@@ -93,7 +93,7 @@ For self-registration, the kubelet is started with the following options:
     No-op if `register-node` is false.
   - `--node-ip` - IP address of the node.
   - `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)).
-  - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master.
+  - `--node-status-update-frequency` - Specifies how often kubelet posts its node status to the API server.
 
 When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled,
@@ -335,7 +335,7 @@ the same time:
   (default 0.01) per second.
 
 The reason these policies are implemented per availability zone is because one
-availability zone might become partitioned from the master while the others remain
+availability zone might become partitioned from the control plane while the others remain
 connected. If your cluster does not span multiple cloud provider availability zones,
 then the eviction mechanism does not take per-zone unavailability into account.
 

content/en/docs/concepts/cluster-administration/logging.md

@@ -57,7 +57,15 @@ The output is:
 ...
 ```
 
-You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container. If your pod has multiple containers, specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
+You can use `kubectl logs --previous` to retrieve logs from a previous instantiation of a container.
+If your pod has multiple containers, specify which container's logs you want to access by
+appending a container name to the command, with a `-c` flag, like so:
+
+```console
+kubectl logs counter -c count
+```
+
+See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
 
 ## Logging at the node level
 

content/en/docs/concepts/configuration/secret.md

@@ -146,14 +146,6 @@ data:
   extra: YmFyCg==
 ```
 
-When creating a `Pod`, Kubernetes automatically creates a service account Secret
-and automatically modifies your Pod to use this Secret. The service account token
-Secret contains credentials for accessing the API.
-
-The automatic creation and use of API credentials can be disabled or
-overridden if desired. However, if all you need to do is securely access the
-API server, this is the recommended workflow.
-
 See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)
 documentation for more information on how service accounts work.
 You can also check the `automountServiceAccountToken` field and the
@@ -161,6 +153,20 @@ You can also check the `automountServiceAccountToken` field and the
 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 for information on referencing service account from Pods.
 
+{{< note >}}
+Automatic creation of API credentials in secrets to mount into running pods
+is no longer used in v1.22 and newer versions. Instead, API credentials are 
+obtained directly by using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API,
+and are mounted into Pods using a [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).
+The tokens obtained using this method have bounded lifetimes, and are automatically
+invalidated when the Pod they are mounted into is deleted.
+
+Service account token secrets can still be [created manually](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
+if you need a token that never expires.
+However, using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
+subresource to obtain a token to access the API is recommended instead.
+{{< /note >}}
+
 ### Docker config Secrets
 
 You can use one of the following `type` values to create a Secret to

content/en/docs/concepts/extend-kubernetes/_index.md

@@ -39,6 +39,7 @@ Customization approaches can be broadly divided into *configuration*, which only
 *Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary:
 
 * [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
 * [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).

content/en/docs/concepts/extend-kubernetes/service-catalog.md

@@ -230,7 +230,6 @@ The following example describes how to map secret values into application enviro
 * If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/).
 * View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers).
 * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project.
-* View [svc-cat.io](https://svc-cat.io/docs/).
 
 
 

content/en/docs/concepts/overview/components.md

@@ -30,7 +30,7 @@ Control plane components can be run on any machine in the cluster. However,
 for simplicity, set up scripts typically start all control plane components on
 the same machine, and do not run user containers on this machine. See
 [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/)
-for an example control plane setup that runs across multiple VMs.
+for an example control plane setup that runs across multiple machines.
 
 ### kube-apiserver
 

content/en/docs/concepts/policy/pod-security-policy.md

@@ -11,9 +11,13 @@ weight: 30
 
 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
 
-PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. It has been replaced by
-[Pod Security Admission](/docs/concepts/security/pod-security-admission/). For more information on the deprecation,
+{{< caution >}}
+PodSecurityPolicy is deprecated as of Kubernetes v1.21, and **will be removed in v1.25**. We recommend migrating to
+[Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.
+For a migration guide, see [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
+For more information on the deprecation,
 see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
+{{< /caution >}}
 
 Pod Security Policies enable fine-grained authorization of pod creation and
 updates.

content/en/docs/concepts/security/overview.md

@@ -123,7 +123,7 @@ Area of Concern for Containers | Recommendation |
 Container Vulnerability Scanning and OS Dependency Security | As part of an image build step, you should scan your containers for known vulnerabilities.
 Image Signing and Enforcement | Sign container images to maintain a system of trust for the content of your containers.
 Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container.
-Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provider stronger isolation
+Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation
 
 ## Code
 

content/en/docs/concepts/security/pod-security-admission.md

@@ -19,7 +19,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta
 different isolation levels for Pods. These standards let you define how you want to restrict the
 behavior of pods in a clear, consistent fashion.
 
-As an Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
+As a Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
 text="admission controller" term_id="admission-controller" >}}, the successor
 to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
 are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
@@ -125,7 +125,7 @@ applied to workload resources, only to the resulting pod objects.
 
 ## Exemptions
 
-You can define _exemptions_ from pod security enforcement in order allow the creation of pods that
+You can define _exemptions_ from pod security enforcement in order to allow the creation of pods that
 would have otherwise been prohibited due to the policy associated with a given namespace.
 Exemptions can be statically configured in the
 [Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller).

content/en/docs/concepts/security/pod-security-standards.md

@@ -52,8 +52,8 @@ fail validation.
 	<caption style="display:none">Baseline policy specification</caption>
 	<tbody>
 		<tr>
-			<td><strong>Control</strong></td>
-			<td><strong>Policy</strong></td>
+			<th>Control</th>
+			<th>Policy</th>
 		</tr>
 		<tr>
 			<td style="white-space: nowrap">HostProcess</td>

content/en/docs/concepts/services-networking/endpoint-slices.md

@@ -147,9 +147,9 @@ In the v1 API, the per endpoint `topology` was effectively removed in favor of
 the dedicated fields `nodeName` and `zone`.
 
 Setting arbitrary topology fields on the `endpoint` field of an `EndpointSlice`
-resource has been deprecated and is not be supported in the v1 API. Instead,
-the v1 API supports setting individual `nodeName` and `zone` fields. These
-fields are automatically translated between API versions. For example, the
+resource has been deprecated and is not supported in the v1 API.
+Instead, the v1 API supports setting individual `nodeName` and `zone` fields.
+These fields are automatically translated between API versions. For example, the
 value of the `"topology.kubernetes.io/zone"` key in the `topology` field in
 the v1beta1 API is accessible as the `zone` field in the v1 API.
 {{< /note >}}