Karpenter is only as good as your pod requests
Karpenter packs nodes based on what your pods request, not what they use. Sedai right-sizes those requests continuously, so Karpenter provisions fewer, cheaper nodes without putting performance at risk.
Animation: pods with inflated CPU requests force Karpenter to run four nodes. Sedai right-sizes the requests to match real usage, Karpenter repacks the same pods onto two nodes, and the other two are released.
Karpenter makes good decisions from bad inputs
Karpenter is fast, flexible, and cost-aware. But it can only work with the numbers it’s given, and in most clusters those numbers are wrong.
Inflated requests, inflated nodes
Karpenter bins pods by their declared requests. Oversized requests mean bigger nodes and lower density, whatever your real utilization is.
The full catalog, no guidance
NodePools either allow every instance type or get hand-pruned once and go stale. Neither reflects how your workloads actually run.
Placement is still the default
Karpenter decides how many nodes you need and which type. Which pod lands on which node still runs through the default scheduler.
An intelligence layer for Karpenter
Sedai doesn’t replace Karpenter. It fixes the inputs Karpenter scales from and fills the gaps around it.
Right-size pods before Karpenter packs them
Sedai learns from live workload behavior and adjusts requests and limits in small, safe increments. Smaller, accurate requests mean Karpenter packs more pods onto fewer nodes.
Recommend the instance types that fit
Sedai builds a targeted instance type list from real usage, pricing, and your existing savings plans, so Karpenter chooses from options that suit your workloads instead of the whole catalog.
Place pods where they pack best
Karpenter only steps in once a pod can’t be scheduled, so every pod that fits is still spread by the default scheduler. Sedai Scheduler packs pods densely at placement, within the footprint Karpenter provisions.
Scale horizontally and vertically together
Sedai’s vertical scaling works alongside HPA without the usual VPA conflict, and tunes HPA targets against your SLOs.
Choose from the instances that fit
Left wide open, a NodePool lets Karpenter pick from the entire instance catalog. Sedai recommends a focused list of instance types based on your workloads’ shape and pricing, so Karpenter provisions right-shaped, cost-effective nodes.
Karpenter alone vs. Karpenter with Sedai
Same autoscaler. Better inputs, better outcomes.
| Karpenter alone | Sedai |
|---|---|
Packs pods by stale, inflated requests | Packs pods by continuously right-sized requests |
Provisions bigger nodes than workloads need | Provisions fewer nodes that match real usage |
Picks from the full instance catalog | Chooses from a targeted, usage-based instance list |
Leaves pod placement to the default scheduler | Sedai Scheduler packs pods densely at placement |
Requests tuned by hand, if at all | Tuned autonomously and validated against SLOs |
Not on Karpenter yet?
You don’t have to migrate to get the benefits. On Cluster Autoscaler and all of GKE, Sedai Scheduler and Sedai Compactor deliver continuous consolidation. And when you’re ready to move, the Migration Assistant handles the cutover safely.
Karpenter Migration Assistant
Move from EKS Managed Node Groups to Karpenter one node at a time, with automatic rollback.
Bin Packing & Pod Placement
Sedai Scheduler packs compatible workloads densely, with or without Karpenter.
Pod Rightsizing
Continuously right-size requests and limits across every workload, based on real behavior.
See what Karpenter could do with better inputs
Find out how many nodes your clusters really need.
Frequently asked questions
No. Karpenter keeps provisioning and consolidating nodes. Sedai improves the inputs it works from, right-sizing pod requests and recommending instance types, and adds smarter pod placement on top.
Karpenter packs pods by their declared requests. When requests match real usage, more pods fit on each node, so Karpenter provisions fewer and smaller nodes.
No. Kubernetes doesn’t let VPA and HPA scale the same workload, but Sedai’s vertical scaling works alongside HPA, adjusting requests and limits in small increments.
Every change is based on live workload behavior and SLOs, applied incrementally, and verified before, during, and after execution, with automatic rollback if anything drifts.
No. Sedai works with Cluster Autoscaler too, and Sedai Compactor provides continuous consolidation there. If you decide to move, the Karpenter Migration Assistant automates the cutover on Amazon EKS.