Merge master into dev-1.19 to keep in sync

content/en/docs/concepts/workloads/pods/_index.md

@@ -19,7 +19,7 @@ A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
 for how to run the containers. A Pod's contents are always co-located and
 co-scheduled, and run in a shared context. A Pod models an
 application-specific "logical host": it contains one or more application
-containers which are relatively tightly coupled. 
+containers which are relatively tightly coupled.
 In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
 
 As well as application containers, a Pod can contain
@@ -51,7 +51,7 @@ with shared namespaces and shared filesystem volumes.
 
 Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
 term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
-If your Pods need to track state, consider the 
+If your Pods need to track state, consider the
 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
 
 Pods in a Kubernetes cluster are used in two main ways:
@@ -65,7 +65,7 @@ Pods in a Kubernetes cluster are used in two main ways:
   tightly coupled and need to share resources. These co-located containers
   form a single cohesive unit of service—for example, one container serving data
   stored in a shared volume to the public, while a separate _sidecar_ container
-  refreshes or updates those files.  
+  refreshes or updates those files.
   The Pod wraps these containers, storage resources, and an ephemeral network
   identity together as a single unit.
 
@@ -190,7 +190,7 @@ changing existing code.
 ## Resource sharing and communication
 
 Pods enable data sharing and communication among their constituent
-containters.
+containers.
 
 ### Storage in Pods {#pod-storage}
 
@@ -257,8 +257,8 @@ but cannot be controlled from there.
 * Lean about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
   configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
-* Read about [PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
-* Pod is a top-level resource in the Kubernetes REST API.  
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
+* Pod is a top-level resource in the Kubernetes REST API.
   The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
   object definition describes the object in detail.
 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -78,7 +78,7 @@ Here are the possible values for `phase`:
 
 Value | Description
 :-----|:-----------
-`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to bescheduled as well as the time spent downloading container images over the network.
+`Pending` | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network.
 `Running` | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting.
 `Succeeded` | All containers in the Pod have terminated in success, and will not be restarted.
 `Failed` | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system.
@@ -392,7 +392,7 @@ An example flow:
 ### Forced Pod termination {#pod-termination-forced}
 
 {{< caution >}}
-Forced deletions can be potentially disruptiove for some workloads and their Pods.
+Forced deletions can be potentially disruptive for some workloads and their Pods.
 {{< /caution >}}
 
 By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports

content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -160,10 +160,10 @@ There are some implicit conventions worth noting here:
 
 - Nodes without `topologySpreadConstraints[*].topologyKey` present will be bypassed. It implies that:
 
-  1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incomingPod will be scheduled into "zoneA".
+  1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA".
   2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone".
 
-- Be aware of what will happen if the incomingPod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
+- Be aware of what will happen if the incoming Pod’s `topologySpreadConstraints[*].labelSelector` doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s `topologySpreadConstraints[*].labelSelector` to match its own labels.
 
 - If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.