Kubernetes spot nodes guide: cutting node cost with interruptible capacity

Quick answer

Spot nodes run your Kubernetes workloads on spare cloud capacity at a steep discount, often well over half off on-demand pricing, in exchange for the provider reclaiming the node at short notice. They suit stateless, fault-tolerant, and batch workloads that can tolerate a pod being rescheduled. The keys to using spot safely: spread across many instance types and zones to reduce simultaneous interruptions, handle the termination notice gracefully (drain the node), keep critical stateful workloads on on-demand, and mix spot with a baseline of on-demand so the cluster stays healthy through reclaims.

Spot capacity is the cloud's spare inventory, sold cheap because the provider can take it back when it needs it. For Kubernetes, spot nodes are one of the largest available compute savings, frequently well over half off on-demand, and Kubernetes is unusually well suited to spot because its scheduler already reschedules pods when a node disappears. The art is using spot for the right workloads and handling interruptions gracefully.

What spot saves and costs you

Node type	Price	Interruption
On-demand	Full price	Never reclaimed
Spot	Often well over half off	Reclaimed at short notice
Commitment-backed	Discounted for steady baseline	Never reclaimed

The tradeoff is stark: spot is dramatically cheaper but can be taken back with only a brief warning. That makes it ideal for workloads that tolerate a pod moving, and risky for workloads that cannot. This same spot-versus-on-demand logic underlies the node choices in EKS Fargate versus EC2 nodes and the provisioning decisions in Karpenter versus Cluster Autoscaler.

Which workloads suit spot

Good spot candidates are stateless services with multiple replicas (losing one pod is invisible), batch and data processing jobs (a reclaimed task just reruns), CI runners, and non-production environments. Poor candidates are singleton stateful workloads, databases, and anything that cannot tolerate an abrupt reschedule. A common pattern is to run a baseline of critical workloads on on-demand and burst everything interruptible onto spot, capturing most of the savings without risking the parts that matter.

Handling interruptions gracefully

The provider gives a short termination notice before reclaiming a spot node. Handle it: run a component that watches for the notice and cordons and drains the node so pods reschedule elsewhere before it disappears. Set pod disruption budgets so the scheduler does not evict too many replicas at once. Spread your spot nodes across many instance types and availability zones, because the more diverse your pool, the less likely a single capacity reclaim takes out many nodes simultaneously. Diversity is the main defense against a spot shortage cascading into an outage.

Mixing spot and on-demand

The safest high-savings pattern is a blend: a minimum baseline of on-demand nodes for critical workloads and stability, with spot layered on top for everything interruptible. Modern autoscalers can express this as a target ratio, so the cluster keeps a healthy on-demand floor while maximizing spot above it. For the steady on-demand baseline you keep, layering a commitment discount on top (see how much savings plans save) stacks another reduction, so spot and commitments together attack the bill from both sides.

Is it worth it?

For fault-tolerant workloads, spot is usually the highest-value single change you can make to Kubernetes compute cost, because the discount is large and Kubernetes already handles rescheduling. The cost is the engineering work to handle interruptions and diversify pools, which is modest and one-time. Estimate the savings by pricing your interruptible node capacity at spot versus on-demand, fold it into your cluster cost estimate, and roll it out to non-production first to build confidence before trusting production spot.

FAQ

How much do Kubernetes spot nodes save?

Often well over half off on-demand pricing, sometimes more, since spot sells the cloud's spare capacity at a steep discount. The exact discount varies by instance type, region, and current demand. Because Kubernetes already reschedules pods when a node disappears, it captures those savings unusually well for fault-tolerant workloads, making spot one of the largest available Kubernetes compute savings.

What workloads should run on spot nodes?

Stateless services with multiple replicas (losing one pod is invisible), batch and data processing jobs (a reclaimed task reruns), CI runners, and non-production environments. Avoid spot for singleton stateful workloads, databases, and anything that cannot tolerate an abrupt reschedule. A common pattern runs critical workloads on on-demand and bursts everything interruptible onto spot for most of the savings without the risk.

How do I handle spot interruptions in Kubernetes?

Run a component that watches for the provider's termination notice and cordons and drains the node so pods reschedule before it disappears, set pod disruption budgets so too many replicas are not evicted at once, and spread spot nodes across many instance types and availability zones. Diversity is the main defense: the more varied your pool, the less likely one capacity reclaim removes many nodes simultaneously.

Should I run my whole cluster on spot?

No. The safest high-savings pattern is a blend: keep a minimum baseline of on-demand nodes for critical workloads and stability, and layer spot on top for everything interruptible. Modern autoscalers can express this as a target ratio, keeping a healthy on-demand floor while maximizing spot above it. Running everything on spot risks the whole cluster becoming unstable during a broad capacity reclaim.

Can I combine spot with reserved capacity or savings plans?

Yes, and it stacks well. Use spot for interruptible workloads to get the large spot discount, and apply a savings plan or commitment discount to the steady on-demand baseline you keep running. Spot cuts the cost of flexible capacity while commitments cut the cost of your reliable floor, so together they attack the compute bill from both directions rather than competing.

Does C3X help evaluate spot node savings?

C3X reads your Terraform and prices the node and instance resources backing your cluster against a live catalog before deploy, so you can see the cost of capacity you plan to run. That makes it easier to reason about the on-demand versus spot split for your node groups at design time, before the cluster is provisioned and the bill is incurred.

What to do next

Price your on-demand and spot node mix before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.