From bfff661ac0024fee950c9c9d9be991257a36ffae Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Tue, 10 May 2022 13:00:19 +0100 Subject: [PATCH] Clarify known limitation of Pod topology spread constraints The limitation is more around cluster autoscaling; nonetheless it seems to belong under Known limitations. --- .../topology-spread-constraints.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 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 1c1a33c5ed..77f4d1ea55 100644 --- a/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -406,12 +406,6 @@ Similarly, Kubernetes also respects `spec.nodeSelector`. {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} -The scheduler doesn't have prior knowledge of all the zones or other topology domains -that a cluster has. They are determined from the existing nodes in the cluster. This -could lead to a problem in autoscaled clusters, when a node pool (or node group) is -scaled to zero nodes and the user is expecting them to scale up, because, in this case, -those topology domains won't be considered until there is at least one node in them. - ## Implicit conventions There are some implicit conventions worth noting here: @@ -557,6 +551,16 @@ section of the enhancement proposal about Pod topology spread constraints. to rebalance the Pods distribution. - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921). +- The scheduler doesn't have prior knowledge of all the zones or other topology + domains that a cluster has. They are determined from the existing nodes in the + cluster. This could lead to a problem in autoscaled clusters, when a node pool (or + node group) is scaled to zero nodes, and you're expecting the cluster to scale up, + because, in this case, those topology domains won't be considered until there is + at least one node in them. + You can work around this by using an cluster autoscaling tool that is aware of + Pod topology spread constraints and is also aware of the overall set of topology + domains. + ## {{% heading "whatsnext" %}}