Pod Topology Spread Constraints

FEATURE STATE: Kubernetes v1.19 [stable]

You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.

Note: In versions of Kubernetes before v1.19, you must enable the EvenPodsSpread feature gate on the API server and the scheduler in order to use Pod topology spread constraints.

Prerequisites

Node Labels

Topology spread constraints rely on node labels to identify the topology domain(s) that each Node is in. For example, a Node might have labels: node=node1,zone=us-east-1a,region=us-east-1

Suppose you have a 4-node cluster with the following labels:

  1. NAME    STATUS   ROLES    AGE     VERSION   LABELS
  2. node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
  3. node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
  4. node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
  5. node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB

Then the cluster is logically viewed as below:

graph TB subgraph “zoneB” n3(Node3) n4(Node4) end subgraph “zoneA” n1(Node1) n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4 k8s; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

Instead of manually applying labels, you can also reuse the well-known labels that are created and populated automatically on most clusters.

Spread Constraints for Pods

API

The API field pod.spec.topologySpreadConstraints is defined as below:

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: mypod
  5. spec:
  6.   topologySpreadConstraints:
  7.     - maxSkew: <integer>
  8.       topologyKey: <string>
  9.       whenUnsatisfiable: <string>
  10.       labelSelector: <object>

You can define one or multiple topologySpreadConstraint to instruct the kube-scheduler how to place each incoming Pod in relation to the existing Pods across your cluster. The fields are:

  • maxSkew describes the degree to which Pods may be unevenly distributed. It’s the maximum permitted difference between the number of matching Pods in any two topology domains of a given topology type. It must be greater than zero. Its semantics differs according to the value of whenUnsatisfiable:
    • when whenUnsatisfiable equals to “DoNotSchedule”, maxSkew is the maximum permitted difference between the number of matching pods in the target topology and the global minimum.
    • when whenUnsatisfiable equals to “ScheduleAnyway”, scheduler gives higher precedence to topologies that would help reduce the skew.
  • topologyKey is the key of node labels. If two Nodes are labelled with this key and have identical values for that label, the scheduler treats both Nodes as being in the same topology. The scheduler tries to place a balanced number of Pods into each topology domain.
  • whenUnsatisfiable indicates how to deal with a Pod if it doesn’t satisfy the spread constraint:
    • DoNotSchedule (default) tells the scheduler not to schedule it.
    • ScheduleAnyway tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.
  • labelSelector is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain. See Label Selectors for more details.

You can read more about this field by running kubectl explain Pod.spec.topologySpreadConstraints.

Example: One TopologySpreadConstraint

Suppose you have a 4-node cluster where 3 Pods labeled foo:bar are located in node1, node2 and node3 respectively:

graph BT subgraph “zoneB” p3(Pod) —> n3(Node3) n4(Node4) end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as:

pods/topology-spread-constraints/one-constraint.yaml Pod Topology Spread Constraints - 图1

  1. kind: Pod
  2. apiVersion: v1
  3. metadata:
  4.   name: mypod
  5.   labels:
  6.     foo: bar
  7. spec:
  8.   topologySpreadConstraints:
  9.   - maxSkew: 1
  10.     topologyKey: zone
  11.     whenUnsatisfiable: DoNotSchedule
  12.     labelSelector:
  13.       matchLabels:
  14.         foo: bar
  15.   containers:
  16.   - name: pause
  17.     image: k8s.gcr.io/pause:3.1

topologyKey: zone implies the even distribution will only be applied to the nodes which have label pair “zone:<any value>” present. whenUnsatisfiable: DoNotSchedule tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.

If the scheduler placed this incoming Pod into “zoneA”, the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates maxSkew: 1. In this example, the incoming Pod can only be placed onto “zoneB”:

graph BT subgraph “zoneB” p3(Pod) —> n3(Node3) p4(mypod) —> n4(Node4) end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

OR

graph BT subgraph “zoneB” p3(Pod) —> n3(Node3) p4(mypod) —> n3 n4(Node4) end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

You can tweak the Pod spec to meet various kinds of requirements:

  • Change maxSkew to a bigger value like “2” so that the incoming Pod can be placed onto “zoneA” as well.
  • Change topologyKey to “node” so as to distribute the Pods evenly across nodes instead of zones. In the above example, if maxSkew remains “1”, the incoming Pod can only be placed onto “node4”.
  • Change whenUnsatisfiable: DoNotSchedule to whenUnsatisfiable: ScheduleAnyway to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it’s preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.)

Example: Multiple TopologySpreadConstraints

This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled foo:bar are located in node1, node2 and node3 respectively:

graph BT subgraph “zoneB” p3(Pod) —> n3(Node3) n4(Node4) end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node:

pods/topology-spread-constraints/two-constraints.yaml Pod Topology Spread Constraints - 图2

  1. kind: Pod
  2. apiVersion: v1
  3. metadata:
  4.   name: mypod
  5.   labels:
  6.     foo: bar
  7. spec:
  8.   topologySpreadConstraints:
  9.   - maxSkew: 1
  10.     topologyKey: zone
  11.     whenUnsatisfiable: DoNotSchedule
  12.     labelSelector:
  13.       matchLabels:
  14.         foo: bar
  15.   - maxSkew: 1
  16.     topologyKey: node
  17.     whenUnsatisfiable: DoNotSchedule
  18.     labelSelector:
  19.       matchLabels:
  20.         foo: bar
  21.   containers:
  22.   - name: pause
  23.     image: k8s.gcr.io/pause:3.1

In this case, to match the first constraint, the incoming Pod can only be placed onto “zoneB”; while in terms of the second constraint, the incoming Pod can only be placed onto “node4”. Then the results of 2 constraints are ANDed, so the only viable option is to place on “node4”.

Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones:

graph BT subgraph “zoneB” p4(Pod) —> n3(Node3) p5(Pod) —> n3 end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n1 p3(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s; class zoneA,zoneB cluster;

.mermaid{display:none}

[JavaScript must be enabled to view content]

If you apply “two-constraints.yaml” to this cluster, you will notice “mypod” stays in Pending state. This is because: to satisfy the first constraint, “mypod” can only be put to “zoneB”; while in terms of the second constraint, “mypod” can only put to “node2”. Then a joint result of “zoneB” and “node2” returns nothing.

To overcome this situation, you can either increase the maxSkew or modify one of the constraints to use whenUnsatisfiable: ScheduleAnyway.

Conventions

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 incoming Pod 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”.

  • Be aware of what will happen if the incomingPod’s topologySpreadConstraints[*].labelSelector doesn’t match its own labels. In the above example, if we remove the incoming Pod’s labels, it can still be placed onto “zoneB” since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it’s still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload’s topologySpreadConstraints[*].labelSelector to match its own labels.

  • If the incoming Pod has spec.nodeSelector or spec.affinity.nodeAffinity defined, nodes not matching them will be bypassed.

    Suppose you have a 5-node cluster ranging from zoneA to zoneC:

    graph BT subgraph “zoneB” p3(Pod) —> n3(Node3) n4(Node4) end subgraph “zoneA” p1(Pod) —> n1(Node1) p2(Pod) —> n2(Node2) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n1,n2,n3,n4,p1,p2,p3 k8s; class p4 plain; class zoneA,zoneB cluster;

    .mermaid{display:none}

    [JavaScript must be enabled to view content]

    graph BT subgraph “zoneC” n5(Node5) end classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; class n5 k8s; class zoneC cluster;

    .mermaid{display:none}

    [JavaScript must be enabled to view content]

    and you know that “zoneC” must be excluded. In this case, you can compose the yaml as below, so that “mypod” will be placed onto “zoneB” instead of “zoneC”. Similarly spec.nodeSelector is also respected.

    pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml Pod Topology Spread Constraints - 图3

    1. kind: Pod
    2. apiVersion: v1
    3. metadata:
    4.   name: mypod
    5.   labels:
    6.     foo: bar
    7. spec:
    8.   topologySpreadConstraints:
    9.   - maxSkew: 1
    10.     topologyKey: zone
    11.     whenUnsatisfiable: DoNotSchedule
    12.     labelSelector:
    13.       matchLabels:
    14.         foo: bar
    15.   affinity:
    16.     nodeAffinity:
    17.       requiredDuringSchedulingIgnoredDuringExecution:
    18.         nodeSelectorTerms:
    19.         - matchExpressions:
    20.           - key: zone
    21.             operator: NotIn
    22.             values:
    23.             - zoneC
    24.   containers:
    25.   - name: pause
    26.     image: k8s.gcr.io/pause:3.1

Cluster-level default constraints

It is possible to set default topology spread constraints for a cluster. Default topology spread constraints are applied to a Pod if, and only if:

  • It doesn’t define any constraints in its .spec.topologySpreadConstraints.
  • It belongs to a service, replication controller, replica set or stateful set.

Default constraints can be set as part of the PodTopologySpread plugin args in a scheduling profile. The constraints are specified with the same API above, except that labelSelector must be empty. The selectors are calculated from the services, replication controllers, replica sets or stateful sets that the Pod belongs to.

An example configuration might look like follows:

  1. apiVersion: kubescheduler.config.k8s.io/v1beta1
  2. kind: KubeSchedulerConfiguration
  4. profiles:
  5.   - pluginConfig:
  6.       - name: PodTopologySpread
  7.         args:
  8.           defaultConstraints:
  9.             - maxSkew: 1
  10.               topologyKey: topology.kubernetes.io/zone
  11.               whenUnsatisfiable: ScheduleAnyway
  12.           defaultingType: List

Note: The score produced by default scheduling constraints might conflict with the score produced by the SelectorSpread plugin. It is recommended that you disable this plugin in the scheduling profile when using default constraints for PodTopologySpread.

Internal default constraints

FEATURE STATE: Kubernetes v1.20 [beta]

With the DefaultPodTopologySpread feature gate, enabled by default, the legacy SelectorSpread plugin is disabled. kube-scheduler uses the following default topology constraints for the PodTopologySpread plugin configuration:

  1. defaultConstraints:
  2.   - maxSkew: 3
  3.     topologyKey: "kubernetes.io/hostname"
  4.     whenUnsatisfiable: ScheduleAnyway
  5.   - maxSkew: 5
  6.     topologyKey: "topology.kubernetes.io/zone"
  7.     whenUnsatisfiable: ScheduleAnyway

Also, the legacy SelectorSpread plugin, which provides an equivalent behavior, is disabled.

Note:

If your nodes are not expected to have both kubernetes.io/hostname and topology.kubernetes.io/zone labels set, define your own constraints instead of using the Kubernetes defaults.

The PodTopologySpread plugin does not score the nodes that don’t have the topology keys specified in the spreading constraints.

If you don’t want to use the default Pod spreading constraints for your cluster, you can disable those defaults by setting defaultingType to List and leaving empty defaultConstraints in the PodTopologySpread plugin configuration:

  1. apiVersion: kubescheduler.config.k8s.io/v1beta1
  2. kind: KubeSchedulerConfiguration
  4. profiles:
  5.   - pluginConfig:
  6.       - name: PodTopologySpread
  7.         args:
  8.           defaultConstraints: []
  9.           defaultingType: List

Comparison with PodAffinity/PodAntiAffinity

In Kubernetes, directives related to “Affinity” control how Pods are scheduled - more packed or more scattered.

  • For PodAffinity, you can try to pack any number of Pods into qualifying topology domain(s)
  • For PodAntiAffinity, only one Pod can be scheduled into a single topology domain.

For finer control, you can specify topology spread constraints to distribute Pods across different topology domains - to achieve either high availability or cost-saving. This can also help on rolling update workloads and scaling out replicas smoothly. See Motivation for more details.

Known Limitations

  • Scaling down a Deployment may result in imbalanced Pods distribution.
  • Pods matched on tainted nodes are respected. See Issue 80921

What’s next