Plan a safe spot migration

The platform team has a quarterly cost target and spot instances are the obvious lever. Spot is also the obvious way to wake up to a 3 a.m. incident if you migrate the wrong workload. Kubeadapt's per-cluster Spot Migration page scores every workload on eligibility and risk; this guide walks you through the short list, the blockers to read before you touch anything, and how to move the safe ones.

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 for compounding savings
• Available Savings — the org-wide rollup across all optimization categories