Pod Topology Spread: Spreading Pods for High Availability
Pod Topology Spread Constraints prevent putting all your pods in one basket. They instruct the scheduler to distribute a service's pods evenly across nodes or zones, improving availability. The main footgun is that it's a soft preference by default.
Why it exists
By default, the Kubernetes scheduler might place multiple pods from the same service onto a single node to optimize resource usage. This creates a single point of failure. If that node goes down, your service suffers a significant outage. Pod Topology Spread Constraints were created to solve this by providing a declarative way to ensure high availability through controlled distribution.
The mental model
Think of it like dealing cards to players in a game. You don't give all the aces to one player. Instead, you deal the cards out one by one to ensure each player gets a relatively even hand. Pod Topology Spread Constraints are the dealing rules for the Kubernetes scheduler. You define the "players" (e.g., availability zones, nodes) and the scheduler deals pods evenly among them, preventing any single one from being overloaded with critical replicas.
How it works
You add a topologySpreadConstraints section to your Pod's specification. It requires three main fields. First, topologyKey defines the failure domain, using a node label like topology.kubernetes.io/zone or kubernetes.io/hostname. Second, maxSkew defines the maximum allowed difference in the number of pods between any two domains. A maxSkew of 1 means the distribution must be nearly perfectly balanced. Third, whenUnsatisfiable tells the scheduler what to do if the constraint can't be met: DoNotSchedule (a hard requirement) or ScheduleAnyway (a soft preference, the default).
When to use it
Use this for stateless, multi-replica applications where availability is critical. Spreading pods for a web server Deployment across availability zones is a classic use case. It ensures that the failure of a single zone doesn't take down your entire service. It's also useful for spreading across nodes to limit the blast radius of a single node failure.
When not to use it
Avoid using it for workloads that require specific node placement, such as stateful applications that need to be co-located with their storage via node affinity. Be cautious with whenUnsatisfiable: DoNotSchedule in small or resource-constrained clusters; if you don't have enough nodes in enough domains to satisfy the constraint, your pods will remain pending indefinitely.
One canonical example
To ensure a web-server Deployment is spread across availability zones, you would define a constraint with topologyKey: topology.kubernetes.io/zone, maxSkew: 1, and whenUnsatisfiable: DoNotSchedule. If you have nodes in zones A, B, and C, the scheduler will attempt to place one replica in each zone. If a fourth pod is added, it will go to any of the three zones, and the skew will remain 1.
Interview question
A Kubernetes service with Pod Topology Spread Constraints is observed to have its pods concentrated on a few nodes, even though other nodes have available capacity. What is the most likely reason for this uneven distribution?
- a.The whenUnsatisfiable field is set to its default value, treating the constraint as a soft preference.Correct
- b.The topologyKey used in the constraint does not exist as a label on the cluster's nodes.
- c.The maxSkew parameter is configured with a value that is too high, permitting significant imbalance.
- d.The pods are part of a stateful application, which inherently resists topology spreading.
Why? this is the answer
The card highlights that the default for whenUnsatisfiable is ScheduleAnyway, making the constraint a soft preference. This allows the scheduler to place pods unevenly if it prioritizes other factors, leading to concentration despite the constraint's presence. While a high maxSkew could permit imbalance, the default soft preference is explicitly called out as a 'footgun' for unexpected concentration.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #scheduling
- #high-availability
- #devops
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles