Roberta SolimanRoberta Soliman

Open source

spot-readiness: which workloads in your cluster can run on Spot

A Go CLI, Apache-2.0, that reads your manifests or the cluster (read-only) and tells you which Kubernetes workloads tolerate Spot interruptions, what to fix first and in what order.

View on GitHubDownload binaryRead the articleCurrent version: v0.8.2

What it does

  • 19 workload rules

    Replicas, probes, PodDisruptionBudgets, graceful shutdown, Jobs and capacity flexibility. Each workload gets a score and a verdict: ready, ready with caveats or not ready.

  • Migration plan

    Groups what to move now, what to move after changes, what needs manual review and what to keep on On-Demand, with the vCPU of each group.

  • A fix for every finding

    With --suggest, each finding comes with a YAML snippet to adapt, already using your workload's names.

  • Cluster and Karpenter

    Reads pods and nodes, checks interruption handling and, with --karpenter, inspects NodePools, NodeClaims and EC2NodeClasses.

  • Built for CI

    Table, JSON, CSV, Markdown and SARIF output, a baseline to fail only on new problems and a GitHub Action that comments on the pull request.

Install

Binaries for Linux, macOS and Windows (amd64 and arm64), with checksums.

brew install robertasolimandonofreo/tap/spot-readiness

The Docker image only reads the files you mount. For cluster mode, use the binary if your kubeconfig relies on aws eks get-token or gcloud.

How to use it

Start with a folder of manifests. Nothing in your files is changed.

spot-readiness scan ./k8s                    # a directory of manifests
helm template my-release ./chart | spot-readiness scan -
spot-readiness scan --context prod -n shop   # the cluster (read-only)
spot-readiness scan --suggest ./k8s          # a suggested fix for every finding
spot-readiness plan ./k8s                    # what to move now, after changes, or never
spot-readiness scan --fail-on not-ready ./k8s  # exit 1 in CI

Example output

$ spot-readiness scan ./k8s
VERDICT             SCORE  WORKLOAD                REPLICAS  CPU    SPOT  FINDINGS
not-ready           15     shop/statefulset/db     1         2000m  -     SR001,SR006,SR007,SR009
not-ready           35     shop/deployment/worker  2         2000m  -     SR003,SR004,SR005,SR006,SR009
ready               100    shop/deployment/web     3         1500m  -

3 workloads: 1 ready, 0 with caveats, 2 not ready
Spot potential: 27% of requested CPU (workloads ready or with caveats).

Illustrative output, with made-up workloads.

In your pipeline

The repository is also a GitHub Action: it scans the manifests, comments on the pull request and can fail the job.

- uses: actions/checkout@v4
- uses: robertasolimandonofreo/spot-readiness@v0.8.2
  with:
    path: ./k8s
    comment: "true"              # one comment, updated on every push
    fail-on-regression: "true"   # fail only on new findings

What it does not do

  • Ready is not safe: it reads configuration and cannot tell whether the application handles SIGTERM or keeps state in memory.
  • The rules are heuristics. Read the findings instead of following only the score.
  • It does not measure real cost. OpenCost and Kubecost exist for that.
  • AWS first: the workload rules apply to any cluster, but GKE and AKS Spot are not recognized yet.

After the diagnosis

Estimate the savings See what Spot earns on your bill, after On-Demand fallback.Generate the NodePool Create a Karpenter Spot NodePool with On-Demand fallback.

Want help reading the result on your cluster?

I review your environment and build a prioritized Spot migration plan.

Book an assessmentSee the efficiency assessment