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

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -30,9 +30,9 @@ mutating and validating (respectively)
 which are configured in the API.
 
 Admission controllers may be "validating", "mutating", or both. Mutating
-controllers may modify the objects they admit; validating controllers may not.
+controllers may modify related objects to the requests they admit; validating controllers may not.
 
-Admission controllers limit requests to create, delete, modify or connect to (proxy). They do not support read requests.
+Admission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects.
 
 The admission control process proceeds in two phases. In the first phase,
 mutating admission controllers are run. In the second phase, validating

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

@@ -104,7 +104,7 @@ See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for ho
 ### Static Token File
 
 The API server reads bearer tokens from a file when given the `--token-auth-file=SOMEFILE` option on the command line.  Currently, tokens last indefinitely, and the token list cannot be
-changed without restarting API server.
+changed without restarting the API server.
 
 The token file is a csv file with a minimum of 3 columns: token, user name, user uid,
 followed by optional group names.

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

@@ -134,7 +134,7 @@ The output is similar to this:
 no
 ```
 
-Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
+Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev`
 can list Pods in the Namespace `target`:
 
 ```bash

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

@@ -15,4 +15,4 @@ tags:
 
 <!--more--> 
 
-Allows for more control over how sensitive information is used and reduces the risk of accidental exposure, including [encryption](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) at rest.  A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.
+Allows for more control over how sensitive information is used and reduces the risk of accidental exposure. Secret values are encoded as base64 strings and stored unencrypted by default, but can be configured to be [encrypted at rest](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). A {{< glossary_tooltip text="Pod" term_id="pod" >}} references the secret as a file in a volume mount or by the kubelet pulling images for a pod. Secrets are great for confidential data and [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) for non-confidential data.

content/en/docs/reference/kubectl/cheatsheet.md

@@ -311,8 +311,7 @@ kubectl logs -f my-pod                              # stream pod logs (stdout)
 kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case)
 kubectl logs -f -l name=myLabel --all-containers    # stream all pods logs with label name=myLabel (stdout)
 kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell
-kubectl run nginx --image=nginx -n 
-mynamespace                                         # Run pod nginx in a specific namespace
+kubectl run nginx --image=nginx -n mynamespace      # Start a single instance of nginx pod in the namespace of mynamespace
 kubectl run nginx --image=nginx                     # Run pod nginx and write its spec into a file called pod.yaml
 --dry-run=client -o yaml > pod.yaml
 

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

@@ -62,6 +62,16 @@ The Kubelet populates this label with the hostname. Note that the hostname can b
 This label is also used as part of the topology hierarchy.  See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information.
 
 
+## kubernetes.io/change-cause {#change-cause}
+
+Example: `kubernetes.io/change-cause=kubectl edit --record deployment foo`
+
+Used on: All Objects
+
+This annotation is a best guess at why something was changed. 
+
+It is populated when adding `--record` to a `kubectl` command that may change an object.
+
 ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost}
 
 Example: `controller.kubernetes.io/pod-deletion-cost=10`