Language en

- fix link for pod-topology-spread
    - markdown lint by vscode plugin

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

@@ -160,6 +160,7 @@ There are some implicit conventions worth noting here:
 - Only the Pods holding the same namespace as the incoming Pod can be matching candidates.
 
 - 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".
   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".
 
@@ -236,7 +237,7 @@ single topology domain.
 The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
 topology domains - to achieve high availability or cost-saving. This can also help on rolling update
 workloads and scaling out replicas smoothly.
-See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation) for more details.
+See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
 
 ## Known Limitations