mv "Assign Pods" and "Taints and Tolerations" concepts to "Scheduling and Eviction"

* Moved "Assigning Pods to Nodes" article to Concepts -> Scheduling and Eviction
* Moved "Taints and Tolerations" article to Concepts -> Scheduling and Eviction
* Updated weight of the "Kubernetes Scheduler" article so it appears first
* Updated redirects
* Replaced links to "Assigning Pods to Nodes" and "Taints and Tolerations" articles
to avoid redirects.

Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>

content/en/docs/concepts/architecture/nodes.md

@@ -191,7 +191,7 @@ all the Pod objects running on the node to be deleted from the API server, and f
 names.
 
 The node lifecycle controller automatically creates
-[taints](/docs/concepts/configuration/taint-and-toleration/) that represent conditions.
+[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions.
 The scheduler takes the Node's taints into consideration when assigning a Pod to a Node.
 Pods can also have tolerations which let them tolerate a Node's taints.
 

content/en/docs/concepts/containers/runtime-class.md

@@ -163,7 +163,7 @@ with the pod's tolerations in admission, effectively taking the union of the set
 by each.
 
 To learn more about configuring the node selector and tolerations, see [Assigning Pods to
-Nodes](/docs/concepts/configuration/assign-pod-node/).
+Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
 
 [RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass
 

content/en/docs/concepts/overview/working-with-objects/labels.md

@@ -226,6 +226,6 @@ selector:
 #### Selecting sets of nodes
 
 One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule.
-See the documentation on [node selection](/docs/concepts/configuration/assign-pod-node/) for more information.
+See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information.
 
 {{% /capture %}}

content/en/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -155,7 +155,7 @@ value is `another-node-label-value` should be preferred.
 
 You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
 You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
-[node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes.
+[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
 
 If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
 to be scheduled onto a candidate node.
@@ -392,7 +392,7 @@ The above pod will run on the node kube-01.
 
 {{% capture whatsnext %}}
 
-[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods.
+[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
 
 The design documents for
 [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)

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

@@ -1,7 +1,7 @@
 ---
 title: Kubernetes Scheduler
 content_template: templates/concept
-weight: 50
+weight: 10
 ---
 
 {{% capture overview %}}

content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -10,7 +10,7 @@ weight: 40
 
 
 {{% capture overview %}}
-[_Node affinity_](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
 is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
 a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
 hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.

content/en/docs/concepts/services-networking/service.md

@@ -905,7 +905,7 @@ the NLB Target Group's health check on the auto-assigned
 `.spec.healthCheckNodePort` and not receive any traffic.
 
 In order to achieve even traffic, either use a DaemonSet or specify a
-[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
+[pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
 to not locate on the same node.
 
 You can also use NLB Services with the [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer)

content/en/docs/concepts/storage/storage-classes.md

@@ -169,9 +169,9 @@ will delay the binding and provisioning of a PersistentVolume until a Pod using
 PersistentVolumes will be selected or provisioned conforming to the topology that is
 specified by the Pod's scheduling constraints. These include, but are not limited to, [resource
 requirements](/docs/concepts/configuration/manage-compute-resources-container),
-[node selectors](/docs/concepts/configuration/assign-pod-node/#nodeselector),
+[node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector),
 [pod affinity and
-anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity),
+anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
 and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration).
 
 The following plugins support `WaitForFirstConsumer` with dynamic provisioning:

content/en/docs/concepts/workloads/controllers/daemonset.md

@@ -99,8 +99,8 @@ create a Pod with a different value on a node for testing.
 
 If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will
 create Pods on nodes which match that [node
-selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
-then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/).
+selector](/docs/concepts/scheduling-eviction/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`,
+then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/).
 If you do not specify either, then the DaemonSet controller will create Pods on all nodes.
 
 ## How Daemon Pods are Scheduled