Merge master into dev-1.20 to keep in sync

content/en/docs/reference/access-authn-authz/certificate-signing-requests.md

@@ -31,6 +31,7 @@ be issued, based on a signing request.
 The CertificateSigningRequest object includes a PEM-encoded PKCS#10 signing request in
 the `spec.request` field. The CertificateSigningRequest denotes the _signer_ (the
 recipient that the request is being made to) using the `spec.signerName` field.
+Note that `spec.signerName` is a required key after api version `certificates.k8s.io/v1`.
 
 Once created, a CertificateSigningRequest must be approved before it can be signed.
 Depending on the signer selected, a CertificateSigningRequest may be automatically approved
@@ -106,8 +107,9 @@ Kubernetes provides built-in signers that each have a well-known `signerName`:
     1. Expiration/certificate lifetime - minimum of CSR signer or request.
     1. CA bit allowed/disallowed - not allowed.
 
-1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some distributions may honor these as client
-  certs, but that behavior is not standard Kubernetes behavior.
+1. `kubernetes.io/legacy-unknown`:  has no guarantees for trust at all. Some third-party distributions of Kubernetes
+  may honor client certificates signed by it. The stable CertificateSigningRequest API (version `certificates.k8s.io/v1` and later)
+  does not allow to set the `signerName` as `kubernetes.io/legacy-unknown`.
   Never auto-approved by {{< glossary_tooltip term_id="kube-controller-manager" >}}.
     1. Trust distribution: None.  There is no standard trust or distribution for this signer in a Kubernetes cluster.
     1. Permitted subjects - any
@@ -227,7 +229,7 @@ rules:
 
 ## Normal User
 
-There are a few steps are required in order to get normal user to be able to authenticate and invoke API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate into the API call as the Certificate Header, or through the kubectl.
+A few steps are required in order to get normal user to be able to authenticate and invoke an API. First, this user must have certificate issued by the Kubernetes Cluster, and then present that Certificate to the API call as the Certificate Header or through the kubectl.
 
 ### Create Private Key
 

content/en/docs/reference/access-authn-authz/rbac.md

@@ -1096,37 +1096,37 @@ In order from most secure to least secure, the approaches are:
 
 2. Grant a role to the "default" service account in a namespace
 
-If an application does not specify a `serviceAccountName`, it uses the "default" service account.
+    If an application does not specify a `serviceAccountName`, it uses the "default" service account.
 
-{{< note >}}
-Permissions given to the "default" service account are available to any pod
-in the namespace that does not specify a `serviceAccountName`.
-{{< /note >}}
+    {{< note >}}
+    Permissions given to the "default" service account are available to any pod
+    in the namespace that does not specify a `serviceAccountName`.
+    {{< /note >}}
 
-For example, grant read-only permission within "my-namespace" to the "default" service account:
+    For example, grant read-only permission within "my-namespace" to the "default" service account:
 
-```shell
-kubectl create rolebinding default-view \
-  --clusterrole=view \
-  --serviceaccount=my-namespace:default \
-  --namespace=my-namespace
-```
+    ```shell
+    kubectl create rolebinding default-view \
+      --clusterrole=view \
+      --serviceaccount=my-namespace:default \
+      --namespace=my-namespace
+    ```
 
-Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
-"default" service account in the `kube-system` namespace.
-To allow those add-ons to run with super-user access, grant cluster-admin
-permissions to the "default" service account in the `kube-system` namespace.
+    Many [add-ons](/docs/concepts/cluster-administration/addons/) run as the
+    "default" service account in the `kube-system` namespace.
+    To allow those add-ons to run with super-user access, grant cluster-admin
+    permissions to the "default" service account in the `kube-system` namespace.
 
-{{< caution >}}
-Enabling this means the `kube-system` namespace contains Secrets
-that grant super-user access to your cluster's API.
-{{< /caution >}}
+    {{< caution >}}
+    Enabling this means the `kube-system` namespace contains Secrets
+    that grant super-user access to your cluster's API.
+    {{< /caution >}}
 
-```shell
-kubectl create clusterrolebinding add-on-cluster-admin \
-  --clusterrole=cluster-admin \
-  --serviceaccount=kube-system:default
-```
+    ```shell
+    kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin \
+      --serviceaccount=kube-system:default
+    ```
 
 3. Grant a role to all service accounts in a namespace
 
@@ -1193,7 +1193,7 @@ the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-fo
 ```
 
 To explain that first command line option in detail: if earlier authorizers, such as Node,
-deny a request, then the the RBAC authorizer attempts to authorize the API request. If RBAC
+deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC
 also denies that API request, the ABAC authorizer is then run. This means that any request
 allowed by *either* the RBAC or ABAC policies is allowed.
 

content/en/docs/reference/glossary/kubelet.md

@@ -9,7 +9,6 @@ short_description: >
 aka:
 tags:
 - fundamental
-- core-object
 ---
  An agent that runs on each {{< glossary_tooltip text="node" term_id="node" >}} in the cluster. It makes sure that {{< glossary_tooltip text="containers" term_id="container" >}} are running in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
 

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

@@ -19,7 +19,7 @@ The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should us
 The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
 For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
 Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code.
-A status code `200` indicates the the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
+A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
 The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
 
 The following examples will show how you can interact with the health API endpoints.