Clean up page assign-pod-node

Author: Zhuzhenghao

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

@@ -8,16 +8,15 @@ content_type: concept
 weight: 20
 ---
 
-
 <!-- overview -->
 
-You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it is 
+You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it is
 _restricted_ to run on particular {{< glossary_tooltip text="node(s)" term_id="node" >}},
 or to _prefer_ to run on particular nodes.
 There are several ways to do this and the recommended approaches all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
 Often, you do not need to set any such constraints; the
-{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}  will automatically do a reasonable placement
+{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} will automatically do a reasonable placement
 (for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
 However, there are some circumstances where you may want to control which node
 the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it,
@@ -28,10 +27,10 @@ or to co-locate Pods from two different services that communicate a lot into the
 You can use any of the following methods to choose where Kubernetes schedules
 specific Pods:
 
-  * [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
-  * [Affinity and anti-affinity](#affinity-and-anti-affinity)
-  * [nodeName](#nodename) field
-  * [Pod topology spread constraints](#pod-topology-spread-constraints)
+- [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
+- [Affinity and anti-affinity](#affinity-and-anti-affinity)
+- [nodeName](#nodename) field
+- [Pod topology spread constraints](#pod-topology-spread-constraints)
 
 ## Node labels {#built-in-node-labels}
 
@@ -51,15 +50,15 @@ and a different value in other environments.
 Adding labels to nodes allows you to target Pods for scheduling on specific
 nodes or groups of nodes. You can use this functionality to ensure that specific
 Pods only run on nodes with certain isolation, security, or regulatory
-properties. 
+properties.
 
 If you use labels for node isolation, choose label keys that the {{<glossary_tooltip text="kubelet" term_id="kubelet">}}
 cannot modify. This prevents a compromised node from setting those labels on
 itself so that the scheduler schedules workloads onto the compromised node.
 
 The [`NodeRestriction` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
 prevents the kubelet from setting or modifying labels with a
-`node-restriction.kubernetes.io/` prefix. 
+`node-restriction.kubernetes.io/` prefix.
 
 To make use of that label prefix for node isolation:
 
@@ -73,7 +72,7 @@ To make use of that label prefix for node isolation:
 You can add the `nodeSelector` field to your Pod specification and specify the
 [node labels](#built-in-node-labels) you want the target node to have.
 Kubernetes only schedules the Pod onto nodes that have each of the labels you
-specify. 
+specify.
 
 See [Assign Pods to Nodes](/docs/tasks/configure-pod-container/assign-pods-nodes) for more
 information.
@@ -84,20 +83,20 @@ information.
 labels. Affinity and anti-affinity expands the types of constraints you can
 define. Some of the benefits of affinity and anti-affinity include:
 
-* The affinity/anti-affinity language is more expressive. `nodeSelector` only
+- The affinity/anti-affinity language is more expressive. `nodeSelector` only
   selects nodes with all the specified labels. Affinity/anti-affinity gives you
   more control over the selection logic.
-* You can indicate that a rule is *soft* or *preferred*, so that the scheduler
+- You can indicate that a rule is *soft* or *preferred*, so that the scheduler
   still schedules the Pod even if it can't find a matching node.
-* You can constrain a Pod using labels on other Pods running on the node (or other topological domain),
+- You can constrain a Pod using labels on other Pods running on the node (or other topological domain),
   instead of just node labels, which allows you to define rules for which Pods
   can be co-located on a node.
 
 The affinity feature consists of two types of affinity:
 
-* *Node affinity* functions like the `nodeSelector` field but is more expressive and
+- *Node affinity* functions like the `nodeSelector` field but is more expressive and
   allows you to specify soft rules. 
-* *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
+- *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
   on other Pods.
 
 ### Node affinity
@@ -106,12 +105,12 @@ Node affinity is conceptually similar to `nodeSelector`, allowing you to constra
 Pod can be scheduled on based on node labels. There are two types of node
 affinity:
 
-  * `requiredDuringSchedulingIgnoredDuringExecution`: The scheduler can't
-    schedule the Pod unless the rule is met. This functions like `nodeSelector`,
-    but with a more expressive syntax.
-  * `preferredDuringSchedulingIgnoredDuringExecution`: The scheduler tries to
-    find a node that meets the rule. If a matching node is not available, the
-    scheduler still schedules the Pod.
+- `requiredDuringSchedulingIgnoredDuringExecution`: The scheduler can't
+  schedule the Pod unless the rule is met. This functions like `nodeSelector`,
+  but with a more expressive syntax.
+- `preferredDuringSchedulingIgnoredDuringExecution`: The scheduler tries to
+  find a node that meets the rule. If a matching node is not available, the
+  scheduler still schedules the Pod.
 
 {{<note>}}
 In the preceding types, `IgnoredDuringExecution` means that if the node labels
@@ -127,17 +126,17 @@ For example, consider the following Pod spec:
 
 In this example, the following rules apply:
 
-  * The node *must* have a label with the key `topology.kubernetes.io/zone` and
-    the value of that label *must* be either `antarctica-east1` or `antarctica-west1`.
-  * The node *preferably* has a label with the key `another-node-label-key` and
-    the value `another-node-label-value`.
+- The node *must* have a label with the key `topology.kubernetes.io/zone` and
+  the value of that label *must* be either `antarctica-east1` or `antarctica-west1`.
+- The node *preferably* has a label with the key `another-node-label-key` and
+  the value `another-node-label-value`.
 
 You can use the `operator` field to specify a logical operator for Kubernetes to use when
 interpreting the rules. You can use `In`, `NotIn`, `Exists`, `DoesNotExist`,
 `Gt` and `Lt`.
 
 `NotIn` and `DoesNotExist` allow you to define node anti-affinity behavior.
-Alternatively, you can use [node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) 
+Alternatively, you can use [node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/)
 to repel Pods from specific nodes.
 
 {{<note>}}
@@ -168,7 +167,7 @@ The final sum is added to the score of other priority functions for the node.
 Nodes with the highest total score are prioritized when the scheduler makes a
 scheduling decision for the Pod.
 
-For example, consider the following Pod spec: 
+For example, consider the following Pod spec:
 
 {{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}}
 
@@ -268,8 +267,8 @@ to unintended behavior.
 Similar to [node affinity](#node-affinity) are two types of Pod affinity and
 anti-affinity as follows:
 
-  * `requiredDuringSchedulingIgnoredDuringExecution`
-  * `preferredDuringSchedulingIgnoredDuringExecution`
+- `requiredDuringSchedulingIgnoredDuringExecution`
+- `preferredDuringSchedulingIgnoredDuringExecution`
 
 For example, you could use
 `requiredDuringSchedulingIgnoredDuringExecution` affinity to tell the scheduler to
@@ -297,7 +296,7 @@ The affinity rule says that the scheduler can only schedule a Pod onto a node if
 the node is in the same zone as one or more existing Pods with the label
 `security=S1`. More precisely, the scheduler must place the Pod on a node that has the
 `topology.kubernetes.io/zone=V` label, as long as there is at least one node in
-that zone that currently has one or more Pods with the Pod label `security=S1`. 
+that zone that currently has one or more Pods with the Pod label `security=S1`.
 
 The anti-affinity rule says that the scheduler should try to avoid scheduling
 the Pod onto a node that is in the same zone as one or more Pods with the label
@@ -314,9 +313,9 @@ You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the
 In principle, the `topologyKey` can be any allowed label key with the following
 exceptions for performance and security reasons:
 
-* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
+- For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
   and `preferredDuringSchedulingIgnoredDuringExecution`.
-* For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules,
+- For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules,
   the admission controller `LimitPodHardAntiAffinityTopology` limits
   `topologyKey` to `kubernetes.io/hostname`. You can modify or disable the
   admission controller if you want to allow custom topologies.
@@ -328,17 +327,18 @@ If omitted or empty, `namespaces` defaults to the namespace of the Pod where the
 affinity/anti-affinity definition appears.
 
 #### Namespace selector
+
 {{< feature-state for_k8s_version="v1.24" state="stable" >}}
 
 You can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
 The affinity term is applied to namespaces selected by both `namespaceSelector` and the `namespaces` field.
-Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and 
+Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and
 null `namespaceSelector` matches the namespace of the Pod where the rule is defined.
 
 #### More practical use-cases
 
 Inter-pod affinity and anti-affinity can be even more useful when they are used with higher
-level collections such as ReplicaSets, StatefulSets, Deployments, etc.  These
+level collections such as ReplicaSets, StatefulSets, Deployments, etc. These
 rules allow you to configure that a set of workloads should
 be co-located in the same defined topology; for example, preferring to place two related
 Pods onto the same node.
@@ -430,10 +430,10 @@ spec:
 Creating the two preceding Deployments results in the following cluster layout,
 where each web server is co-located with a cache, on three separate nodes.
 
-|       node-1         |       node-2        |       node-3       |
-|:--------------------:|:-------------------:|:------------------:|
-| *webserver-1*        |   *webserver-2*     |    *webserver-3*   |
-|  *cache-1*           |     *cache-2*       |     *cache-3*      |
+|    node-1     |    node-2     |    node-3     |
+| :-----------: | :-----------: | :-----------: |
+| *webserver-1* | *webserver-2* | *webserver-3* |
+|   *cache-1*   |   *cache-2*   |   *cache-3*   |
 
 The overall effect is that each cache instance is likely to be accessed by a single client, that
 is running on the same node. This approach aims to minimize both skew (imbalanced load) and latency.
@@ -453,13 +453,12 @@ tries to place the Pod on that node. Using `nodeName` overrules using
 
 Some of the limitations of using `nodeName` to select nodes are:
 
--   If the named node does not exist, the Pod will not run, and in
-    some cases may be automatically deleted.
--   If the named node does not have the resources to accommodate the
-    Pod, the Pod will fail and its reason will indicate why,
-    for example OutOfmemory or OutOfcpu.
--   Node names in cloud environments are not always predictable or
-    stable.
+- If the named node does not exist, the Pod will not run, and in
+  some cases may be automatically deleted.
+- If the named node does not have the resources to accommodate the
+  Pod, the Pod will fail and its reason will indicate why,
+  for example OutOfmemory or OutOfcpu.
+- Node names in cloud environments are not always predictable or stable.
 
 {{< note >}}
 `nodeName` is intended for use by custom schedulers or advanced use cases where
@@ -495,12 +494,10 @@ to learn more about how these work.
 
 ## {{% heading "whatsnext" %}}
 
-* Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
-* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
+- Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
+- Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
   and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
-* Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
-  resource allocation decisions. 
-* Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
-* Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
-
-
+- Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
+  resource allocation decisions.
+- Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
+- Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).