Merge master into dev-1.22 to keep in sync

content/en/docs/reference/_index.md

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

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

@@ -2,6 +2,9 @@
 title: Feature Gates
 weight: 10
 content_type: concept
+card:
+  name: reference
+  weight: 60
 ---
 
 <!-- overview -->

content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md

@@ -10,7 +10,7 @@ content_type: concept
 
 <!-- overview -->
 
-In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver.
+In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver.
 In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly
 recommend using client TLS certificates on nodes.
 
@@ -44,7 +44,7 @@ Note that the above process depends upon:
 All of the following are responsibilities of whoever sets up and manages the cluster:
 
 1. Creating the CA key and certificate
-2. Distributing the CA certificate to the master nodes, where kube-apiserver is running
+2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running
 3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet
 4. Signing the kubelet certificate using the CA key
 5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running
@@ -90,9 +90,9 @@ In addition, you need your Kubernetes Certificate Authority (CA).
 ## Certificate Authority
 
 As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used
-to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes.
+to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes.
 
-For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
+For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key).
 We will refer to these as "Kubernetes CA certificate and key".
 
 All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded.
@@ -234,7 +234,7 @@ In order for the controller-manager to sign certificates, it needs the following
 
 ### Access to key and certificate
 
-As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes.
+As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes.
 These will be used by the controller-manager to sign the kubelet certificates.
 
 Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA
@@ -319,7 +319,7 @@ collection.
 
 ## kubelet configuration
 
-Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
+Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet.
 
 The kubelet requires the following configuration to bootstrap:
 

content/en/docs/reference/tools/_index.md

@@ -8,7 +8,7 @@ no_list: true
 ---
 
 <!-- overview -->
-Kubernetes contains several built-in tools to help you work with the Kubernetes system.
+Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function.
 
 
 <!-- body -->

content/en/docs/reference/using-api/health-checks.md

@@ -25,7 +25,7 @@ The more verbose options shown below are intended to be used by human operators
 The following examples will show how you can interact with the health API endpoints.
 
 For all endpoints you can use the `verbose` parameter to print out the checks and their status.
-This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine:
+This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine:
 
 ```shell
 curl -k https://localhost:6443/livez?verbose
@@ -93,7 +93,7 @@ The output show that the `etcd` check is excluded:
 
 {{< feature-state state="alpha" >}}
 
-Each individual health check exposes an http endpoint and could can be checked individually.
+Each individual health check exposes an HTTP endpoint and could can be checked individually.
 The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
 The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
 These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: