Kubernetes bin packing that knows your workloads
The default scheduler spreads pods to balance load, with no sense of which workloads belong together. Sedai Scheduler places every pod by its workload profile, packing compatible workloads densely so the nodes left empty are ones your autoscaler can remove.
Animation: the default scheduler spreads fourteen pods thinly across four nodes. Sedai Scheduler profiles each workload as CPU-bound, memory-bound, general, or sensitive, and as pods restart it places them densely onto two nodes, with sensitive pods grouped together. The other two nodes are left empty for the autoscaler to remove. Node utilization rises from 44% to 88%.
The default scheduler isn’t built to save you money
kube-scheduler finds a node that fits and keeps load balanced. Packing was never its job, and it shows: Research attributes 54% of container spend to cluster idle, capacity that’s provisioned but never requested.
Spread thin by design
Balancing load keeps every node partly full, and Kubernetes never rebalances pods after placement. No node empties out enough to be reclaimed.
Blind to workload type
CPU-bound, memory-bound, and fragile low-replica services all get placed the same way. Capacity gets stranded on one resource while the other sits idle.
Karpenter doesn’t change it
Karpenter only steps in once a pod can’t be scheduled. Every pod that fits somewhere is still placed by the spread-favoring default scheduler.
Every workload gets a profile
Sedai Scheduler reads how each workload actually behaves, classifies it, and packs it as densely as that profile allows. Sensitive workloads are grouped onto a few shared nodes instead of scattered one per node across the fleet.
From right-sized pods to a smaller bill
Right-sizing alone frees capacity in small pieces across every node. Placement and consolidation turn those pieces into nodes you stop paying for.
Right-size every pod
Sedai right-sizes requests as pods are created, without fighting your CI/CD pipeline or triggering drift alerts.
Pack the freed capacity
Sedai Scheduler places smaller, accurate pods densely, grouped by how they actually behave.
Consolidate and reclaim
Sedai Compactor clears stranded pods so your autoscaler can remove empty nodes, and dense placement keeps them from refilling.
Bin packing on any cloud, no migration required
Sedai Scheduler is available on EKS, GKE, and AKS through the standard Sedai agent, with nothing new to deploy. On Karpenter-managed node pools, it improves placement within Karpenter’s footprint. Everywhere else, including all of GKE, pair it with Sedai Compactor for the continuous consolidation teams usually go to Karpenter for.
Node consolidation
Sedai Compactor clears stranded pods so your autoscaler can remove empty nodes
Pod right-sizing
Give the scheduler accurate requests to pack, based on real workload behavior
Karpenter optimization
Already on Karpenter? Give it better inputs and smarter placement on top.
Default scheduler vs. Sedai Scheduler
Same cluster, same workloads. Very different node count.
| Default scheduler | Sedai |
|---|---|
Spreads pods thin to balance load | Packs compatible workloads densely |
Places every workload the same way | Places by profile: CPU, memory, general, sensitive |
Scatters sensitive pods one per node | Groups sensitive pods on a few shared nodes |
Keeps every node partly full | Concentrates load so nodes empty out |
Honors your affinity and topology rules | Honors the same rules, so no pod becomes unschedulable |
See how tightly your clusters could pack
Walk through Sedai Scheduler on your own workloads with a Sedai engineer.
Frequently asked questions
No. It works alongside the native scheduler and never claims workloads already assigned to a custom scheduler. Switching it off returns every onboarded workload to the default scheduler.
No. Each placement is a scoring preference among the nodes your affinity and topology-spread rules already allow. It changes which feasible node is chosen, never which nodes are feasible.
No. Sedai Scheduler changes where pods run, not how they’re sized. Right-sizing is handled separately and works best alongside it.
Each workload gets one rolling restart, and only workloads with at least two replicas, all healthy, and a rolling-update strategy are onboarded. You can exclude any namespace or workload, and opt-outs take effect immediately.
Karpenter only acts once a pod can’t be scheduled. Every pod that fits somewhere is still placed by the default scheduler, which spreads load. Sedai Scheduler handles density at placement time, within the footprint Karpenter provisions.
Packing starts with the next pod placed. 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.