Plan a safe spot migration

Kubeadapt's per-cluster Spot Migration page scores every workload on eligibility and risk. This guide walks through the shortlist, the blockers to read before you change anything, and how to move the workloads that are safe to move.

1. Open the Spot Migration page for one cluster

Clusters → pick a cluster → Spot Instance Migration in the cluster nav.

The page lists every workload in the cluster with four columns that matter for this decision:

• Eligibility: Eligible or Not Eligible
• Risk level: Low, Medium, or High
• Eligibility score: 0-100
• Monthly savings: what Kubeadapt projects you'd save by moving this workload to spot

The summary cards at the top tell you total monthly savings if you migrated everything eligible, the count of eligible workloads, and the average risk.

2. Filter to low risk

Use the Risk Level dropdown to filter to Low. Optionally narrow the Namespace dropdown to one team's namespace so you can iterate one team at a time.

Sort the table by Monthly savings descending so you're working the highest-impact workloads first.

3. Read the blockers per workload

Click a row to expand the detail view. Kubeadapt flags any of these per workload:

• Single replica: losing the only pod means downtime; spot interruption rate makes this expensive
• No PodDisruptionBudget: the scheduler has nothing to honor when a node is reclaimed
• Persistent storage: local PVCs and most regional storage classes don't survive a node swap
• Stateful kind: StatefulSets need explicit reasoning, not a blanket spot policy

A workload showing Risk: Low with no blockers is the cleanest candidate. A workload with one blocker but high savings is a conversation with the owning team, not a unilateral move.

4. Apply the change outside Kubeadapt

The Spot Migration page is read-only — it scores and ranks, it doesn't mutate workloads. To actually move a workload to spot, you change the scheduling on your side. The most common patterns:

1# Patch a Deployment to land on spot nodes
2spec:
3  template:
4    spec:
5      nodeSelector:
6        karpenter.sh/capacity-type: spot
7      tolerations:
8        - key: karpenter.sh/disruption
9          operator: Exists
10          effect: NoSchedule

For Karpenter, EKS managed node groups, GKE Spot VMs, and AKS Spot VMs the exact label and taint keys differ — match what your cluster autoscaler already uses for spot pools.

Apply, wait for the rollout, then watch the workload for one interruption cycle (typically 24-72 hours).

5. Confirm the savings

Come back to Spot Migration → the workload now lists Not Eligible because it's already running on spot. Open Cost Explorer, filter to the workload, and compare the last 7 days to the previous 7. Real-world savings track Kubeadapt's projection within a few percent when the workload runs to completion; sustained interruptions show up as the workload's cost not dropping by the projected amount.

Next steps

• Spot migration concepts: eligibility scoring, the blocker rules, and how the risk levels are computed
• Right-sizing guide: pair spot migration with rightsizing