Roberta SolimanRoberta Soliman

Open source

spot-readiness: quais workloads do seu cluster podem rodar em Spot

CLI em Go, Apache-2.0, que lê seus manifests ou o cluster (somente leitura) e diz quais workloads Kubernetes toleram interrupção de Spot, o que corrigir primeiro e em que ordem.

Ver no GitHubBaixar binárioLer o artigoVersão atual: v0.8.2

O que ele faz

  • 19 regras de workload

    Réplicas, probes, PodDisruptionBudget, desligamento gracioso, Jobs e flexibilidade de capacidade. Cada workload recebe uma nota e um veredito: pronto, pronto com ressalvas ou não pronto.

  • Plano de migração

    Agrupa o que mover agora, o que mover depois de mudanças, o que pede revisão manual e o que manter em On-Demand, com a vCPU de cada grupo.

  • Correção para cada achado

    Com --suggest, cada achado traz um trecho de YAML para adaptar, já com os nomes do seu workload.

  • Cluster e Karpenter

    Lê pods e nós, avalia o tratamento de interrupção e, com --karpenter, confere NodePools, NodeClaims e EC2NodeClasses.

  • Feito para CI

    Saída em tabela, JSON, CSV, Markdown e SARIF, baseline para falhar só em problemas novos e uma GitHub Action que comenta no pull request.

Instalação

Binários para Linux, macOS e Windows (amd64 e arm64), com checksums.

brew install robertasolimandonofreo/tap/spot-readiness

A imagem Docker só lê os arquivos que você monta. Para o modo cluster, use o binário se o seu kubeconfig depende de aws eks get-token ou gcloud.

Como usar

Comece por uma pasta de manifests. Nada é alterado nos seus arquivos.

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

Exemplo de saída

$ 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).

Saída ilustrativa, com workloads fictícios.

Na sua pipeline

O repositório também é uma GitHub Action: ela escaneia os manifests, comenta no pull request e pode falhar o 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

O que ele não faz

  • Pronto não é seguro: ele lê configuração e não sabe se a aplicação trata SIGTERM ou guarda estado em memória.
  • As regras são heurísticas. Leia os achados em vez de seguir só a nota.
  • Não mede custo real. Para isso existem o OpenCost e o Kubecost.
  • AWS primeiro: as regras de workload valem para qualquer cluster, mas Spot do GKE e do AKS ainda não são reconhecidos.

Depois do diagnóstico

Estimar a economia Veja quanto o Spot rende na sua conta, já descontando o fallback para On-Demand.Gerar o NodePool Crie um NodePool Spot do Karpenter com fallback para On-Demand.

Quer ajuda para ler o resultado no seu cluster?

Eu reviso o seu ambiente e monto um plano priorizado de migração para Spot.

Agendar um diagnósticoConheça o assessment de eficiência