graviton-readiness: which workloads in your cluster can run on Graviton

What it does

• 11 architecture rules

  Pinned to amd64, an x86 instance type, a NodePool that only provisions amd64, an image named amd64, an image without linux/arm64, Windows, GPU and more. Each workload gets a score and a verdict.

• Karpenter NodePools

  With the NodePools in the folder, it links each workload to the pool it selects (by karpenter.sh/nodepool or by label) and reports it when the pool only provisions amd64. Pools that are not Karpenter's, such as AWS node groups, GKE or AKS pools, are declared with --node-pool. With no known pool, the rule invents nothing.

• Image checks against the registry

  With --check-images, it reads the manifest of every image (never the layers) and looks for linux/arm64. It uses the credentials of your Docker config. What the registry does not answer is reported as not verified, never as ready.

• No network by default

  Without --check-images nothing goes to the network, and no workload is called ready: a clean configuration is reported as unverified, because nothing confirms arm64.

• Potential by CPU

  The summary weighs the verdicts by requested CPU and keeps what is verified apart from what is not.

• Migration plan

  The plan command groups what to move now, after a check, after changes, what to verify first and what to keep on amd64, and sets apart what already runs on Graviton, with the CPU of each group and the order of the work.

• Live cluster, read-only

  With --cluster, it reads workloads, NodePools, EC2NodeClasses and nodes, with list calls only. Pools that are not Karpenter's (an AWS node group, GKE, AKS) get the architecture of their own nodes, with no --node-pool.

• SARIF and a GitHub Action

  The SARIF output points at the line of the field behind each finding. The Action comments the report and the plan on the pull request, uploads the SARIF and fails the pipeline.

Example output

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

What it does not do

• Ready is not safe: it reads configuration and the registry, and cannot tell whether the application has native dependencies or JIT that behave differently on arm64. Test on a Graviton node before moving production.
• An image with linux/arm64 was published for arm64, which does not guarantee it works.
• No Helm values: render charts with helm template. Karpenter NodePools are read from the manifests or the cluster; other pools come from the nodes (with --cluster) or are declared with --node-pool. The EC2NodeClass only proves Windows: the architecture of a custom AMI is in AWS and is not read.
• AWS first: the instance-type rules know the Graviton families. Ampere on Azure and Axion on Google Cloud are not recognized.

Want help moving to Graviton?

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