<strong>Salesforce moved over 1,000 Amazon EKS clusters to Karpenter to speed provisioning and cut costs by improving node provisioning time and resource...
Why Salesforce Migrated 1,000+ EKS Clusters to Karpenter (and What It Means for You)
Salesforce moved over 1,000 Amazon EKS clusters to Karpenter to speed provisioning and cut costs by improving node provisioning time and resource packing. Short summary? Karpenter provisions nodes faster, packs pods better, and gives you more instance choices per schedule window—so you get lower pending times and often better cost efficiency.
— Ernie Castro
Key Takeaways
- Karpenter replaces or augments the Cluster Autoscaler to provision nodes faster and more granularly.
- For large fleets, Karpenter reduces provisioning latency and often improves cost efficiency, especially with spot instances and right-sized instance types.
- Migration requires IAM, instance profile, and scheduler awareness changes—plan for testing and rollbacks.
What is Karpenter?
Short answer first. Karpenter is an open-source provisioner for Kubernetes that launches nodes fast.
It reacts to unschedulable pods and creates EC2 instances tailored to pod constraints, choosing instance families, sizes, and purchase options that match requested CPU, memory, and scheduling constraints, and it removes the slower reconciliation steps that older autoscalers rely on—this matters when pods must move from pending to running in seconds rather than many minutes.
Simple enough?
Here is what Karpenter actually does in practice, in plain terms: it watches your cluster for pods that the scheduler cannot place, it groups those pods by constraints, and it calls the cloud API to provision nodes that fit, often using spot capacity where configured while retaining on-demand fallbacks for reliability.
When I ran on-call for multi-region services we cared about the window between a spike and a running replica, and Karpenter shortens that window noticeably.
Want the docs? You can read the project homepage and official guides—Karpenter project site, the Karpenter GitHub, and AWS guidance on integrating Karpenter with EKS: EKS Karpenter docs.
Core Benefits/Importance
Short version first. Karpenter reduces provisioning time and often cuts cost.
For large fleets that support customer-facing APIs, the speed at which additional capacity appears matters for error budgets and user experience, and Karpenter shortens the path to a running pod by handling instance selection and provisioning in a single focused loop, avoiding delays from multiple controllers reconciling nodegroups and autoscaler attachments.
Sound useful?
Here are the primary benefits you should care about as an engineer or engineering manager:
- Faster node provisioning: Karpenter often launches nodes in seconds to low minutes versus the longer cycles with nodegroup scaling.
- Better instance packing: By choosing instance sizes that fit many pods, Karpenter can reduce the number of instances required, which lowers cost and shortens blast radius for maintenance.
- Flexible instance selection: Use a broader set of instance types across families to avoid capacity constraints in a single family.
- Spot and fallback strategies: Karpenter supports spot capacity policies with configured fallbacks to on-demand, so you can balance cost and availability.
- Simpler multi-zone operation: It can schedule across AZs using a small set of provisioning rules instead of many nodegroups.
When I led a migration effort at an enterprise where cost and SLA were both important, Karpenter allowed us to reduce purchase friction and simplify runbooks because engineers no longer had to tune multiple nodegroups per service; one policy often covered many needs.
There is also an ethical angle that quietly matters: using compute efficiently reflects stewardship of resources and the dignity of work for platform teams who otherwise spend hours fighting flare-ups and noisy neighbors.
Step-by-Step Implementation/Guide
Short step first. Start with a small pilot and a canary namespace.
Follow this careful, tested plan—audit, configure, deploy, test, measure, and iterate—because the smallest permission missing or the wrong topology constraint can lead to pods staying pending or nodes launching with the wrong profile, and you want safe rollback points and monitoring in place before broad rollout.
Ready to start?
- Audit workloads and cluster settings. Record typical pod CPU and memory requests, startup patterns, use of InitContainers, ephemeral storage needs, and any node selectors or custom scheduler constraints. Pay attention to critical system pods and how they tolerate interruptions.
- Map current nodegroups and scaling patterns. Identify which services use spot, which require on-demand, and which run in specific AZs or with GPU instances. This gives you a migration path and helps set Karpenter provisioner rules without surprises.
- Prepare IAM and instance profiles. Create an IAM role that allows Karpenter to create, describe, tag, and terminate EC2 instances and access capacity-optimization APIs. Attach the role to the Karpenter ServiceAccount using IRSA on EKS; verify permissions in a staging account first.
- Deploy Karpenter in a canary cluster or namespace. Use conservative provisioning limits—small maximum node counts and narrow instance families—so you can observe behavior without blowing your cloud bill. Use the official helm or manifests from Karpenter GitHub.
- Test typical failure modes. Simulate node termination, spot interruptions, and AZ capacity loss. Verify fallback behavior and that critical pods still land on nodes with required taints and tolerations.
- Measure: Track pod pending time, node launch time, packing efficiency, and cost per workload. Pair these with alerting on unexpected scale events so you catch regressions quickly.
- Rollout gradually. Move low-risk workloads first, then progressively include latency-sensitive services once you’re confident in policies and monitoring.
- Update runbooks and on-call playbooks. Include steps for node termination, spot eviction handling, and how to revert a service to a managed nodegroup in case of emergency.
When I did this at scale, the worst mistakes were skipped IAM checks and missing taint/toleration mappings, which caused system pods to be scheduled onto spot nodes and then get evicted, creating noisy pager traffic for a week—plan for that and keep fallback on-demand capacity while you learn.
Comparison Table
Short comparison first. Karpenter and Cluster Autoscaler aim to achieve similar outcomes but follow different models.
Here is a compact view comparing the two on the dimensions that matter for enterprise migrations.
| Feature | **Karpenter** | **Cluster Autoscaler** |
|---|---:|---:|
| Provisioning latency | Faster (seconds to low minutes) | Slower (minutes, depending on nodegroup lifecycle) |
| Instance selection | Flexible across families and sizes | Constrained to predefined nodegroups |
| Spot/On-Demand mixing | Native policy-based support | Manual setup, more complex |
| Operational model | Declarative provisioner, needs IAM | Controller that changes nodegroup sizes |
| Complexity for large fleets | Scales well with fewer configs | Can become many nodegroups to manage |
| Best for | Bursty, latency-sensitive workloads | Simple predictable workloads |
Common Mistakes to Avoid
Short warning first. Many teams assume Karpenter is plug-and-play and skip testing at scale.
That assumption breaks things because Karpenter changes how nodes are created and labeled, which can interact badly with PodTopologySpread, affinity rules, and custom admission controllers that expect certain node labels or lifecycle behaviors, and you must plan for these interactions before moving hundreds of clusters.
Want a list of mistakes?
- Missing IAM permissions: Without correct IRSA roles and EC2 permissions, Karpenter cannot provision nodes. Test in a staging account with the least privilege model.
- Not testing taints/tolerations: System pods without tolerations can end up on inappropriate nodes if you don’t enforce taints for spot or GPU workloads.
- Over-reliance on spot without fallback: Spot reduces cost but increases churn. Always provide on-demand fallbacks for critical paths.
- Ignoring scheduler signals: Pod topologySpread and inter-pod affinity affect placement; misconfigurations lead to noisy neighbors and uneven packing.
- Skipping cost and SLA monitoring: Karpenter can reduce cost but if you only look at cluster-level cost you might miss higher per-pod cost due to wrong instance family choice.
- Large-scale simultaneous rollout: Rolling out to 1,000+ clusters without phased canaries invites disaster; do staged rollout and automated health checks.
Frankly, most published guides say "just switch it on," but my experience shows that real success comes from conservative pilots, clear metrics, and respecting the dignity of the teams who will be called at 2 a.m. to respond to regressions.
Frequently Asked Questions
Short FAQ intro. Here are short answers to questions people ask most.
Curious?
- Q: Will Karpenter replace Cluster Autoscaler entirely?
- A: Not always. Some shops keep both for specific workloads; others replace autoscaler on newer clusters. The decision depends on workload predictability, tooling, and how much operational change you accept.
- Q: Does Karpenter save money?
- A: Often, yes, but it depends. Savings come from better packing and spot usage, but results vary with traffic patterns and instance pricing. Measure before and after.
- Q: Is the migration risky?
- A: It can be if you skip IAM, taints, and scheduler testing. Plan for canaries, fallbacks, and rollbacks to minimize risk.
- Q: Where can I find official resources?
- A: The Karpenter project site (karpenter.sh), the Github repo (github.com/aws/karpenter), and AWS EKS guidance (EKS docs) are good starting points.
Final Thought
Short final line. The Salesforce migration shows that large enterprises can move to a faster provisioning model and still keep cost and reliability under control.
I remember leading a migration where we underestimated a single custom admission controller, which caused a week of noisy pages until we rolled back the affected services—so here's my practical advice: plan conservatively, automate tests, and treat platform stewardship as a moral responsibility because efficient resources and steady services serve people who rely on them.
Want a sober take? Karpenter is powerful, but it requires discipline: think permissions, think scheduler interactions, and think about the human teams who maintain the system.
— Ernie Castro
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Will Karpenter replace Cluster Autoscaler entirely?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Not always. Some organizations keep both tools for different workload types. Choose based on workload predictability and operational constraints."
}
},
{
"@type": "Question",
"name": "Does Karpenter save money?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Often yes, due to better packing and spot usage, but results depend on traffic patterns and instance pricing. Measure before and after."
}
},
{
"@type": "Question",
"name": "Is migrating to Karpenter risky?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Migration can be risky without testing IAM, taints/tolerations, and scheduler signals. Use canaries and have rollback plans."
}
}
]
}