Originally published on KubeSimplify

Running Kubernetes in production means juggling cost and reliability — especially when mixing spot and on-demand instances. Spot instances can cut compute costs significantly, but they come with the risk of interruption. The challenge? Placing pods intelligently across these mixed instance types.

The Problem

In mixed instance setups, Kubernetes’ default scheduler doesn’t account for the distinction between spot and on-demand nodes. This can lead to:

  • Critical workloads landing entirely on spot instances
  • Uneven distribution causing availability gaps during spot reclamation
  • Over-provisioning on-demand nodes to compensate for unpredictable placement

Topology Spread Constraints to the Rescue

Topology Spread Constraints let you control how pods are distributed across your cluster’s topology — including node types, zones, and custom labels. By labeling nodes as spot or on-demand, you can enforce balanced pod distribution across both.

This gives you:

  • Better resilience — pods spread across instance types so spot reclamation doesn’t take down your service
  • Cost efficiency — you can confidently use more spot capacity knowing your workload is distributed
  • Fine-grained control — define max skew, topology keys, and scheduling behavior

Practical Considerations

While powerful, Topology Spread Constraints have limitations to keep in mind:

  • They work best with proper node labeling strategies
  • The maxSkew parameter needs careful tuning for your workload
  • Combining with pod anti-affinity rules can create scheduling conflicts
  • Cluster autoscaler behavior should be considered alongside these constraints

Read the full article on KubeSimplify for detailed examples and configurations.