From 9151b93cd98c5025697c9d24e84dc1a230b95507 Mon Sep 17 00:00:00 2001 From: vaibhav2107 Date: Fri, 27 Oct 2023 00:28:20 +0530 Subject: [PATCH] Add the link of supposed example in topology-spread-constraints.md --- .../scheduling-eviction/topology-spread-constraints.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md index 3cbc5b01ac..a28b807152 100644 --- a/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -480,8 +480,8 @@ There are some implicit conventions worth noting here: - The scheduler bypasses any nodes that don't have any `topologySpreadConstraints[*].topologyKey` present. This implies that: - 1. any Pods located on those bypassed nodes do not impact `maxSkew` calculation - in the - above example, suppose the node `node1` does not have a label "zone", then the 2 Pods will + 1. any Pods located on those bypassed nodes do not impact `maxSkew` calculation - [in the + above example](#example-conflicting-topologyspreadconstraints), suppose the node `node1` does not have a label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into zone `A`. 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a node `node5` has the **mistyped** label `zone-typo: zoneC`