If you're running Kubernetes on AWS, you probably know that Karpenter is a better way to provision nodes than the default Cluster Autoscaler. AWS made Karpenter a first-class citizen of EKS, and it does things the default Cluster Autoscaler doesn't, including:
- Flexible instance selection. Karpenter can pick from any instance type or size that actually fits your workload's needs, rather than the narrow, pre-selected set of node types a traditional node group locks you into.
- Cost-aware provisioning. Every time it provisions a new node, Karpenter automatically finds the cheapest instance that still satisfies your workload's constraints, instead of you guessing at the right size ahead of time.
- Built-in, schedulable consolidation. Karpenter continuously looks for chances to consolidate your cluster onto fewer, better-packed nodes, and you decide when that's allowed to happen (say, only between 2 and 3 AM), rather than leaving it to whenever the autoscaler gets around to it.
If Karpenter is clearly better, why isn't everyone already running it?
Because migrating to Karpenter can be tricky. Cluster Autoscaler and Karpenter don't just work differently: they're configured in different languages. Everything you've encoded in your existing autoscaling setup has to be translated into Karpenter's model, layer by layer, and there's no universal one-to-one mapping. And if something goes sideways mid-migration, you're the one who has to notice it, diagnose it, and get your cluster back to a safe state, under pressure, in production.
That gap shows up in the data, too. Cluster Autoscaler still runs the majority of production EKS clusters today, even though the industry consensus has settled on Karpenter being the better choice for most workloads. It isn't only smaller teams stalling out. AWS's own case study on Salesforce's migration of a fleet of over 1,000 EKS clusters describes real turbulence mid-migration: their first approach, cordoning nodes in parallel, caused unexpected cluster health issues, forcing a redesign around sequential cordoning with added manual verification. If a team with Salesforce's engineering resources hit friction, it's a safe bet most teams would, which is exactly what something built specifically to de-risk the handoff is for.
That's the gap we built the Karpenter Migration Assistant to close.
What it does
The Migration Assistant automates the move from EKS Managed Node Groups to Karpenter, node pool by node pool, so you can migrate incrementally, with some node pools already on Karpenter while others stay on Cluster Autoscaler until you're ready. It handles two things most teams underestimate going in:
Translation. Before anything moves, Sedai reads your existing node group configuration and generates the equivalent Karpenter setup, surfacing every difference it finds. Anything with no safe Karpenter equivalent stops the migration outright rather than silently dropping it. Anything else, e.g. cosmetic or non-essential changes, gets recorded so you know exactly what shifted, with nothing left to discover after the fact.
Safety. Once you approve a migration, the cutover runs in careful, reversible phases — cordon, drain, validate — checking cluster health at every step. If validation ever fails, rollback is automatic: your workloads land back on your original infrastructure without anyone paging you at 2am. And you're not locked into a specific moment — migrations can be scheduled for your maintenance window, rescheduled, or cancelled any time before they start.
In short: hassle-free migration, with the same kind of safety net you'd expect from any Sedai automation.
Where it stands today
Sedai’s Karpenter Migration Assistant supports AWS EKS only, for now — Karpenter's ecosystem support on AWS is well ahead of what's available on GCP or AKS today, so that's where the automation lives first. It's generally available today.
If you're already sold on Karpenter's placement logic, wait until you see what's next
Karpenter is excellent at deciding how many nodes you need and which type is cheapest. What it's less opinionated about is exactly which pod goes where within that footprint — that still runs through Kubernetes' default scheduler. That's where Sedai's Smart Scheduler comes in: proactive, intelligent pod placement that layers on top of Karpenter's provisioning and consolidation, so you're not just running fewer, cheaper nodes — you're running them better packed, too.
Learn More
Migrating to Karpenter is a structural upgrade to how your cluster runs, day to day — and the Migration Assistant gets you there without the risk of doing it solo. Ready to see it on your own clusters?
