Merge master into dev-1.22 to keep in sync

Signed-off-by: Ritu Panjwani <panjwaniritu45@gmail.com>

content/en/docs/reference/_index.md

@@ -38,7 +38,7 @@ client libraries:
 - [Kubernetes Python client library](https://github.com/kubernetes-client/python)
 - [Kubernetes Java client library](https://github.com/kubernetes-client/java)
 - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript)
-- [Kubernetes Dotnet client library](https://github.com/kubernetes-client/csharp)
+- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp)
 - [Kubernetes Haskell Client library](https://github.com/kubernetes-client/haskell)
 
 ## CLI

content/en/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -58,7 +58,7 @@ It acts synchronously to modify pods as they are created or updated. When this p
 1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it.
 1. It adds a `volume` to the pod which contains a token for API access if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's `automountServiceAccountToken` is set to `false`.
 1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has created a volume for ServiceAccount token.
-1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod.
+1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` of the `ServiceAccount` are added to the pod.
 
 #### Bound Service Account Token Volume
 
@@ -91,14 +91,14 @@ add the following projected volume instead of a Secret-based volume for the non-
 This projected volume consists of three sources:
 
 1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience.
-1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate being enabled, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` is enabled by default in 1.20, and always enabled in 1.21+.
+1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from --feature-gate arg in 1.22)
 1. A DownwardAPI that references the namespace of the pod.
 
 See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/).
 
-You can manually migrate a secret-based service account volume to a projected volume when
+You can manually migrate a Secret-based service account volume to a projected volume when
 the `BoundServiceAccountTokenVolume` feature gate is not enabled by adding the above
-projected volume to the pod spec. However, `RootCAConfigMap` needs to be enabled.
+projected volume to the pod spec.
 
 ### Token Controller
 

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -852,7 +852,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `ValidateProxyRedirects`: This flag controls whether the API server should
   validate that redirects are only followed to the same host. Only used if the
   `StreamingProxyRedirects` flag is enabled.
-- 'VolumeCapacityPriority`: Enable support for prioritizing nodes in different
+- `VolumeCapacityPriority`: Enable support for prioritizing nodes in different
   topologies based on available PV capacity.
 - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource.
 - `VolumeScheduling`: Enable volume topology aware scheduling and make the

content/en/docs/reference/labels-annotations-taints.md

@@ -222,7 +222,9 @@ When a single IngressClass resource has this annotation set to `"true"`, new Ing
 
 ## kubernetes.io/ingress.class (deprecated)
 
-{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}}
+{{< note >}}
+Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`.
+{{< /note >}}
 
 ## storageclass.kubernetes.io/is-default-class
 
@@ -230,7 +232,8 @@ Example: `storageclass.kubernetes.io/is-default-class=true`
 
 Used on: StorageClass
 
-When a single StorageClass resource has this annotation set to `"true"`, new Physical Volume Claim resource without a class specified will be assigned this default class.
+When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim
+resource without a class specified will be assigned this default class.
 
 ## alpha.kubernetes.io/provided-node-ip
 

content/en/docs/reference/using-api/api-concepts.md

@@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path
 * Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
 * Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
 
-The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
+The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
 
 
 ## Efficient detection of changes
@@ -442,7 +442,7 @@ feature, see the section on
 
 ## Resource Versions
 
-Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
+Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
 
 ### ResourceVersion in metadata
 
@@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev
 
 ### The ResourceVersion Parameter
 
-The get, list and watch operations support the `resourceVersion` parameter.
+The get, list, and watch operations support the `resourceVersion` parameter.
 
 The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.
 

content/en/docs/reference/using-api/server-side-apply.md

@@ -245,7 +245,7 @@ field tags.
 
 ### Compatibility across topology changes
 
-On rare occurences, a CRD or built-in type author may want to change the
+On rare occurrences, a CRD or built-in type author may want to change the
 specific topology of a field in their resource without incrementing its
 version. Changing the topology of types, by upgrading the cluster or
 updating the CRD, has different consequences when updating existing
@@ -253,7 +253,7 @@ objects. There are two categories of changes: when a field goes from
 `map`/`set`/`granular` to `atomic` and the other way around.
 
 When the `listType`, `mapType`, or `structType` changes from
-`map`/`set`/`granular` to `atomic`, the whole list, map or struct of
+`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of
 existing objects will end-up being owned by actors who owned an element
 of these types. This means that any further change to these objects
 would cause a conflict.
@@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a
 read-modify-write and/or patch are the following:
 
 * the applied object must contain all the fields that the controller cares about.
-* there are no way to remove fields that haven't been applied by the controller
+* there is no way to remove fields that haven't been applied by the controller
   before (controller can still send a PATCH/UPDATE for these use-cases).
 * the object doesn't have to be read beforehand, `resourceVersion` doesn't have
   to be specified.
@@ -473,7 +473,7 @@ have an opinion about.
 ## Clearing ManagedFields
 
 It is possible to strip all managedFields from an object by overwriting them
-using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every
 non-apply operation. This can be done by overwriting the managedFields field
 with an empty entry. Two examples are: