Move Pod Topology Spread Constraints into scheduling

These constraints apply specifically to the mechanism for placing Pods
onto nodes (that is, scheduling).

Author: Tim Bannister

content/en/blog/_posts/2020-05-05-introducing-podtopologyspread.md

@@ -67,7 +67,7 @@ Let's see an example of a cluster to understand this API.
 As the feature name "PodTopologySpread" implies, the basic usage of this feature
 is to run your workload with an absolute even manner (maxSkew=1), or relatively
 even manner (maxSkew>=2). See the [official
-document](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+document](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 for more details.
 
 In addition to this basic usage, there are some advanced usage examples that

content/en/blog/_posts/2020-09-30-writing-crl-scheduler/index.md

@@ -70,7 +70,7 @@ To correct the latter issue, we now employ a "hunt and peck" approach to removin
 ### 1. Upgrade to kubernetes 1.18 and make use of Pod Topology Spread Constraints
 
 While this seems like it could have been the perfect solution, at the time of writing Kubernetes 1.18 was unavailable on the two most common managed Kubernetes services in public cloud, EKS and GKE.
-Furthermore, [pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) were still a [beta feature in 1.18](https://v1-18.docs.kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
+Furthermore, [pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/) were still a beta feature in 1.18 which meant that it [wasn't guaranteed to be available in managed clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#kubernetes_feature_choices) even when v1.18 became available.
 The entire endeavour was concerningly reminiscent of checking [caniuse.com](https://caniuse.com/) when Internet Explorer 8 was still around.
 
 ### 2. Deploy a statefulset _per zone_.

content/en/docs/concepts/scheduling-eviction/_index.md

@@ -23,6 +23,7 @@ of terminating one or more Pods on Nodes.
 * [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
 * [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
 * [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
+* [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/)
 * [Scheduling Framework](/docs/concepts/scheduling-eviction/scheduling-framework)
 * [Scheduler Performance Tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)

content/en/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -83,7 +83,7 @@ of the scheduler:
 ## {{% heading "whatsnext" %}}
 
 * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
-* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
 * Read the [kube-scheduler config (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)

content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md renamed to content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md

@@ -320,12 +320,12 @@ in the Pod Lifecycle documentation.
 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
 * Learn 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](/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 {{< api-reference page="workload-resources/pod-v1" >}}
   object definition describes the object in detail.
 * [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
+* Read about [Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 
 To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
 

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

@@ -438,7 +438,7 @@ Note that the live editor doesn't recognize Hugo shortcodes.
 ### Example 1 - Pod topology spread constraints
 
 Figure 6 shows the diagram appearing in the
-[Pod topology pread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels)
+[Pod topology pread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/#node-labels)
 page.
 
 {{< mermaid >}}

content/en/docs/contribute/style/diagram-guide.md

@@ -808,7 +808,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   availability during update per node.
   See [Perform a Rolling Update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/).
 - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do
-  [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints).
+  [default spreading](/docs/concepts/scheduling-eviction/topology-spread-constraints/#internal-default-constraints).
 - `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the
   role of applying `fsGroup` from a Pod's `securityContext` to the driver by
   passing `fsGroup` through the NodeStageVolume and NodePublishVolume CSI calls.
@@ -854,7 +854,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
   {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}}
   to running pods.
 - `EvenPodsSpread`: Enable pods to be scheduled evenly across topology domains. See
-  [Pod Topology Spread Constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+  [Pod Topology Spread Constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
 - `ExecProbeTimeout`: Ensure kubelet respects exec probe timeouts.
   This feature gate exists in case any of your existing workloads depend on a
   now-corrected fault where Kubernetes ignored exec probe timeouts. See
@@ -995,7 +995,7 @@ Each feature gate is designed for enabling/disabling a specific feature:
 - `MemoryQoS`: Enable memory protection and usage throttle on pod / container using
   cgroup v2 memory controller.
 - `MinDomainsInPodTopologySpread`: Enable `minDomains` in Pod
-  [topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+  [topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
 - `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type
   Service instance.
 - `MountContainers`: Enable using utility containers on host as the volume mounter.

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

@@ -123,7 +123,7 @@ extension points:
   and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
   Extension points: `filter`, `score`.
 - `PodTopologySpread`: Implements
-  [Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
+  [Pod topology spread](/docs/concepts/scheduling-eviction/topology-spread-constraints/).
   Extension points: `preFilter`, `filter`, `preScore`, `score`.
 - `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
   true.

content/en/docs/reference/scheduling/config.md

@@ -63,7 +63,7 @@ These labels can include
 
 If your cluster spans multiple zones or regions, you can use node labels
 in conjunction with
-[Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
+[Pod topology spread constraints](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 to control how Pods are spread across your cluster among fault domains:
 regions, zones, and even specific nodes.
 These hints enable the