Roberta SolimanRoberta Soliman

Open source

graviton-readiness: quais workloads do seu cluster podem rodar em Graviton

CLI em Go, Apache-2.0, que lê seus manifests e diz quais workloads Kubernetes podem rodar em nós Graviton (arm64), e o que bloqueia os que não podem. Com --check-images, lê do registry se cada imagem tem linux/arm64.

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

O que ele faz

  • 11 regras de arquitetura

    Seleção fixa em amd64, tipo de instância x86, NodePool que só provisiona amd64, imagem com amd64 no nome, imagem sem linux/arm64, Windows, GPU e mais. Cada workload recebe uma nota e um veredito.

  • NodePools do Karpenter

    Com os NodePools na pasta, liga cada workload ao pool que ele escolhe (por karpenter.sh/nodepool ou por label) e acusa quando o pool só provisiona amd64. Pools que não são do Karpenter, como node groups da AWS, GKE ou AKS, você declara com --node-pool. Sem um pool conhecido, a regra não inventa nada.

  • Checagem de imagens no registry

    Com --check-images, lê o manifest de cada imagem (nunca as camadas) e procura linux/arm64. Usa as credenciais do seu Docker config. O que o registry não responde fica como não verificado, nunca como pronto.

  • Sem rede por padrão

    Sem --check-images nada vai à rede, e nenhum workload é dado como pronto: o que está limpo fica como não verificado, porque nada confirma o arm64.

  • Potencial por CPU

    O resumo pondera os vereditos pela CPU requisitada e separa o que está verificado do que não está.

  • Plano de migração

    O comando plan agrupa o que mover agora, depois de uma conferência, depois de mudanças, o que verificar antes e o que manter em amd64, e separa o que já roda em Graviton, com a CPU de cada grupo e a ordem do trabalho.

  • Cluster vivo, só leitura

    Com --cluster, lê workloads, NodePools, EC2NodeClasses e nós, só com chamadas list. Os pools que não são do Karpenter (node group da AWS, GKE, AKS) ganham a arquitetura dos próprios nós, sem --node-pool.

  • SARIF e GitHub Action

    A saída SARIF aponta a linha do campo que causou cada achado. A Action comenta o relatório e o plano no pull request, sobe o SARIF e falha na pipeline.

Instalação

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

brew install robertasolimandonofreo/tap/graviton-readiness

A imagem Docker só lê os arquivos que você monta e não tem Docker config, então --check-images só alcança registries públicos a partir dela. Para registries privados, use o binário.

Como usar

Comece por uma pasta de manifests. Sem --check-images nada vai à rede e nada nos seus arquivos é alterado.

graviton-readiness scan ./k8s                    # a directory of manifests
graviton-readiness scan ./k8s ./karpenter     # the workloads and the NodePools together
graviton-readiness plan --check-images ./k8s ./karpenter   # what to move now, after changes, or never
graviton-readiness scan --cluster                # a live cluster, read-only
graviton-readiness scan -f sarif ./k8s > gr.sarif   # for GitHub code scanning
helm template my-release ./chart | graviton-readiness scan -
graviton-readiness scan --check-images ./k8s     # also read the image platforms
graviton-readiness scan -v ./k8s                 # explain every finding
graviton-readiness scan --check-images --fail-on not-ready ./k8s   # exit 1 in CI
graviton-readiness explain GR004                 # what a rule means

Exemplo de saída

$ graviton-readiness scan ./k8s
VERDICT     SCORE  WORKLOAD                         REPLICAS  CPU    FINDINGS
unverified  100    kube-system/daemonset/log-agent  -         -      GR008
unverified  100    shop/cronjob/report              -         -      -
not-ready   60     shop/deployment/api              2         1000m  GR001
unverified  100    shop/deployment/web              3         500m   -
not-ready   50     shop/deployment/worker           2         250m   GR003,GR006

5 workloads: 0 ready, 0 with caveats, 2 not ready, 3 unverified
Graviton potential: 0% of requested CPU (workloads ready or with caveats).
Unverified: 37% of requested CPU could move if the images support arm64.
Images were not checked: run with --check-images to read their platforms from the registry.

Saída real do testdata do repositório, sem --check-images.

O que ele não faz

  • Pronto não é seguro: ele lê configuração e o registry, e não sabe se a aplicação tem dependências nativas ou JIT que se comportam diferente em arm64. Teste em um nó Graviton antes de mover produção.
  • Uma imagem com linux/arm64 foi publicada para arm64, o que não garante que funcione.
  • Sem values do Helm: renderize os charts com helm template. Os NodePools do Karpenter são lidos dos manifests ou do cluster; os outros pools vêm dos nós (com --cluster) ou você os declara com --node-pool. O EC2NodeClass só prova Windows: a arquitetura de uma AMI customizada está na AWS e não é lida.
  • AWS primeiro: as regras de tipo de instância conhecem as famílias Graviton. Ampere no Azure e Axion no Google Cloud não são reconhecidos.

Depois do diagnóstico

Estimar a economia A calculadora de economia em Kubernetes inclui a alavanca de Graviton.Checar Spot também O spot-readiness diz quais workloads toleram interrupção de Spot.

Quer ajuda para migrar para Graviton?

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

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