Node consolidation that finishes the job
One stranded pod can keep an otherwise empty node running for weeks. Sedai Compactor finds those pods continuously and moves them, so your autoscaler can remove the node and the savings reach your bill.
Animation: six nodes are running, but three of them hold only a pod or two. Sedai Compactor finds the stranded pods and moves them onto fuller nodes, and the autoscaler removes the two nodes left empty. A protected pod is left where it is, so its node stays. Nodes running drop from six to four.
Kubernetes places a pod once and never looks back
Workloads scale down, deployments roll, traffic shifts. Your cluster’s layout drifts further from efficient every day, and nothing in Kubernetes puts it back.
No rebalancing, ever
Once a pod is placed, it stays put. As workloads shrink, nodes are left nearly empty, and Kubernetes doesn’t move pods to fix it.
One pod keeps a node alive
Your autoscaler can only remove a node once it’s empty or lightly loaded. A single stranded pod is enough to keep you paying for the whole node.
Manual compaction doesn’t stick
Someone has to remember to run it, and the default scheduler spreads new pods right back onto the nodes you just emptied.
Guardrails that are built in, not bolted on
Compactor moves running pods, so safety can’t be best-effort. Every eviction respects your disruption budgets, critical infrastructure is excluded by default, and production clusters get conservative settings automatically.
Works with the autoscaler you already run
Compactor never deletes a node. It clears the way, and your existing autoscaler removes the node on its own schedule. On Karpenter-managed node pools, it steps aside for Karpenter’s own consolidation. Everywhere else, including all of GKE and any EKS or AKS cluster on Cluster Autoscaler, it adds continuous consolidation those clusters didn’t have before. Paired with Sedai Scheduler, the nodes it empties stay empty long enough to be removed.
Bin packing & pod placement
Sedai Scheduler packs new pods densely, so emptied nodes don't refill
Pod rightsizing
Smaller, accurate requests open up the space needed for consolidation
Karpenter optimization
On Karpenter? Give it better inputs and denser placement.
Manual compaction vs. Sedai Compactor
Same goal. Only one of them keeps the nodes off your bill.
| Manual compaction | Sedai |
|---|---|
Runs only when someone remembers | Runs continuously, with no manual step |
Emptied nodes refill as new pods spread out | Paired with dense placement, so nodes stay empty |
Evictions scripted around disruption budgets | Every eviction honors PodDisruptionBudgets |
Critical infrastructure protected by hand | Core infrastructure excluded by default |
Same aggressiveness in every environment | Conservative defaults for production clusters |
Find the nodes you’re paying for but not using
See how much of your cluster is held up by stranded pods.
Frequently asked questions
No. Compactor moves stranded pods so a node can empty out. Your existing autoscaler removes the node, on its own schedule.
Compactor detects Karpenter-managed node pools and leaves them to Karpenter’s own consolidation. It adds continuous consolidation where none existed: all of GKE, and any EKS or AKS cluster still on Cluster Autoscaler or classic managed node groups.
Every eviction goes through the standard Kubernetes eviction API, which enforces your PodDisruptionBudgets. Production clusters also get conservative packing thresholds and longer grace periods by default.
Ingress, service mesh, CSI drivers, observability, and GitOps tooling are excluded by default. You can also exclude a namespace, a resource group, or a single workload, and opt-outs take effect immediately.
Yes. A recommendation-only mode is available for each cluster.
Without dense placement, the default scheduler spreads new pods back onto the nodes Compactor just emptied. Running both gives your autoscaler genuinely empty nodes, sooner and more often.
Node count typically trends down over the first one to two weeks as your autoscaler reclaims capacity.
Amazon EKS, Google Kubernetes Engine, and Azure Kubernetes Service, through the standard Sedai agent.