2 min read | by Jordi Prats
Ensuring high availability and fault tolerance in a Kubernetes cluster is a complex task: One important feature that allows us to addresses this challenge is Topology Spread Constraints.
Topology Spread Constraints in Kubernetes are a set of rules that define how pods of the same application should be distributed across the nodes in a cluster. This way we can make sue that a node failure does not impact, for example, all the available replicas of a
Deployment. With Topology Spread Constraints we can tell Kubernetes to spread Pods across different failure domains, such as nodes, racks, zones, ...
We can achieve the same goal using podAntiAffinity, which is a little simpler. While with Topology Spread Constraints you'll be able to define hierarchical topologies (nodes spread across logical domains of topology), with Pod Affinity, on the other hand, you will only be able to configure linear topologies (all nodes on the same level).
Nevertheless, you can combine both. In this scenario, Kubernetes is going to try to find a node that matches both rules.
A basic example would be the following:
apiVersion: v1 kind: Pod metadata: name: example spec: (...) topologySpreadConstraints: - labelSelector: matchLabels: app.kubernetes.io/name: myapp maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway - labelSelector: matchLabels: app.kubernetes.io/name: myapp maxSkew: 1 topologyKey: kubernetes.io/hostname whenUnsatisfiable: ScheduleAnyway
This example uses
whenUnsatisfiable=ScheduleAnyway which is equivalent of using
preferredDuringSchedulingIgnoredDuringExecution: If the condition cannot be satisfied, it's going to schedule the Pods anyway instead of leaving it in Pending state.
You can user kubectl explain to get more tails on how to use topologySpreadConstraints:
kubectl explain pod.spec.topologySpreadConstraints
Posted on 10/07/2023