Karpenter vs Cluster Autoscaler for GPU Nodes: 2026 Cost Guide
GPU capacity is the single biggest line item in most ML infrastructure budgets, and the autoscaler underneath it decides whether that spend turns into training throughput or sits idle overnight. The karpenter vs cluster autoscaler gpu decision is not cosmetic: it changes bin-packing quality, how spot interruptions are absorbed, how long a node takes to become schedulable, and whether MIG or time-sliced GPUs are even practical to run. Cluster Autoscaler scales fixed, hand-defined node groups up and down. Karpenter provisions individual nodes just-in-time from a flexible pool of instance types and tears them down the moment they stop earning their keep. On a CPU fleet, the gap between the two shows up as a few points of waste. On a fleet where one idle node burns $30 to $50 an hour, it shows up as a line item finance asks about.
What this covers: bin-packing and instance-type flexibility across GPU families, spot handling and interruption behavior for GPU capacity, cold-start latency from multi-gigabyte GPU AMIs and driver initialization, consolidation, drift, and disruption budgets, how MIG and time-slicing interact with each autoscaler, and a worked monthly cost comparison for a mixed training and inference cluster.
Context and Background
Cluster Autoscaler is the original Kubernetes SIG-Autoscaling project. It watches for unschedulable pods, matches them against the node groups you’ve already defined — AWS Auto Scaling Groups, GCP Managed Instance Groups, Azure VM Scale Sets — and calls the cloud provider’s scaling API to add or remove instances from those groups. It has been the default answer to “how do I autoscale nodes” since Kubernetes 1.x, and it still ships as a first-class option in every major managed Kubernetes offering.
Karpenter took a different starting point. Instead of scaling pre-defined groups, it watches unschedulable pods and asks the cloud API directly for whatever instance best fits them, subject to constraints you define once. It shipped from AWS in 2021, moved under kubernetes-sigs as a community project, and reached v1.0 general availability in September 2024, when the original Provisioner and AWSNodeTemplate custom resources were replaced by the stable NodePool and cloud-specific NodeClass APIs (EC2NodeClass on AWS). Kubernetes’ own node autoscaling documentation now covers Cluster Autoscaler and Karpenter side by side as the two supported approaches, rather than treating Karpenter as a fringe alternative.
By 2026 Karpenter has kept shipping past that GA line — releases through the first half of the year added a “Balanced” consolidation policy and early support for Dynamic Resource Allocation, Kubernetes’ structured mechanism for describing partitionable and consumable devices like MIG slices. Cluster Autoscaler, meanwhile, has stayed close to its original design: it is stable, well-understood, and still the default node autoscaler in plenty of production EKS, GKE, and AKS clusters, including many that also run expensive accelerator fleets. That stability is also its ceiling, and it’s the reason GPU teams keep re-litigating this comparison — see our related Karpenter node autoscaling production deep-dive for the general-purpose version of this argument before we narrow it to accelerators specifically.
Bin-Packing, Instance Flexibility, and Cold-Start Mechanics for GPU Nodes
Figure 2: Cluster Autoscaler can only scale node groups you defined in advance — it matches a pending GPU pod to a group, scales that Auto Scaling Group by one, and waits for a fixed-AMI node to boot and initialize its GPU driver.
Figure 2 makes the core constraint visible: Cluster Autoscaler reasons at the granularity of preconfigured groups, so instance-type flexibility is only as wide as the groups an operator remembered to create.
Karpenter bin-packs GPU pods against dozens of eligible instance types at once and launches whichever one is cheapest and still fits, while Cluster Autoscaler bin-packs only within whichever node groups you already built — so its packing quality is capped by how many GPU node groups you’re willing to define, keep patched, and pay to keep warm.
How Cluster Autoscaler Bin-Packs GPU Pods
Cluster Autoscaler’s scheduling simulation is a template match, not a live scheduling decision. Each node group carries a fixed instance type (or a small, explicitly configured set under mixed-instance ASGs), a fixed AMI, and a fixed max size. When a GPU pod goes pending, CA simulates whether it would fit on a new copy of an existing node group’s template — it does not ask “what is the single cheapest instance across every GPU family that satisfies this request.” If your g5 node group is scaled to its ceiling and a pod requests two GPUs while only single-GPU g5 nodes exist in that group, CA cannot spontaneously reach for a g5.12xlarge unless you built a second group for it and tuned an expander to pick it correctly.
In practice this means GPU-heavy platform teams run five, ten, sometimes fifteen parallel node groups — one per instance type and often per availability zone, because CA node groups are usually single-AZ for predictable scheduling. Each group needs its own minimum size, maximum size, taints, labels, and often its own AMI pin for a specific CUDA/driver combination. Bin-packing quality is bounded by how much of that matrix you maintain, and every group you don’t maintain is a workload shape CA simply can’t serve without manual intervention.
Cluster Autoscaler also exposes an “expander” setting that decides which of several eligible node groups to grow when more than one could satisfy a pending pod — options include least-waste (pick the group leaving the smallest unused resource remainder), priority (an operator-ranked list), and random. On CPU fleets these are a minor tuning knob. On GPU fleets they’re load-bearing: if a pending pod could be served by either a cheaper g6.xlarge group or a pricier g6.2xlarge group and the expander is left on a default that doesn’t account for GPU-hour cost, CA will happily grow the more expensive group first. Karpenter doesn’t need an expander at all, because cost-aware selection is the default behavior of its scheduling simulation, not an optional strategy layered on top.
How Karpenter’s NodePool Evaluates GPU Instance Types
Karpenter inverts the model. A single NodePool expresses constraints — GPU vendor, instance family, minimum vCPU, capacity type — and an EC2NodeClass expresses the AMI, subnets, security groups, and bootstrap logic. When a GPU pod goes pending, Karpenter’s scheduling simulator evaluates every instance type permitted by the NodePool’s requirements, filters to the ones that satisfy the pod’s GPU, memory, and topology needs, and launches the cheapest one that fits — potentially bin-packing several smaller pending pods onto one larger instance if that’s cheaper than launching multiples of a smaller one. One NodePool can legitimately span g6.xlarge through g6.48xlarge, or across L4, L40S, and A10G families, letting the scheduler pick width dynamically instead of you pre-committing to a shape.
This matters disproportionately for GPU workloads because GPU instance families are far less fungible than CPU ones. A training job pinned to 8x A100 needs a p4d.24xlarge-class instance; there’s no smaller substitute. But an inference workload that just needs “a GPU with at least 16GB of VRAM and reasonable memory bandwidth” can run on several different instance types at meaningfully different price points, and that’s exactly the search space Cluster Autoscaler’s group-per-type model was never built to explore live.
Cold-Start Latency: Why GPU Nodes Are Slow No Matter Which Autoscaler You Use
Both autoscalers share the same physical bottleneck: a GPU node is not schedulable the instant the cloud API returns success. The instance has to boot, pull a multi-gigabyte AMI with CUDA drivers and container runtime baked in (or install them at boot), initialize the NVIDIA driver and device plugin, and register GPU resources with the kubelet before the scheduler will bind anything to it. Reported field experience puts CPU node cold-start at roughly 30–60 seconds and GPU node cold-start at roughly 5–10 minutes for exactly this reason — the delta is driver initialization and image size, not the cloud provider’s launch API.
Where the autoscalers diverge is what happens while that clock is running. Karpenter’s just-in-time model means every scale-up pays this latency cold, every time, unless you deliberately keep spare capacity via a low-priority placeholder NodePool. Cluster Autoscaler’s fixed-group model lets you set a nonzero minimum size on a GPU group, keeping one or two nodes permanently warm so bursts land instantly — at the cost of paying for that idle capacity around the clock. Neither approach eliminates the driver-init tax; they just decide who eats the latency versus who eats the idle-hour cost. Pre-baking a custom AMI with drivers already installed (rather than installing them via user-data at boot) is the single highest-leverage fix for either autoscaler, and it matters more for Karpenter precisely because Karpenter takes that cold-start hit more often.
Figure 1: Karpenter’s provisioning loop evaluates GPU instance types against NodePool requirements, launches the cheapest fit via EC2NodeClass, then continuously re-checks utilization for consolidation.
The long-description version: a pending GPU pod triggers a search across every instance type the NodePool allows; the winning type’s AMI and bootstrap script come from the EC2NodeClass; the node joins, the pod binds, and the same loop then watches that node for consolidation opportunities — it never stops running, which is the mechanical reason Karpenter clusters trend toward fewer wasted GPU-hours than statically-sized node groups over time.
Spot Handling, Consolidation, Disruption Budgets, and MIG Interplay
Figure 4: When a pod requests a fractional GPU, the device plugin advertises MIG or time-sliced capacity; Cluster Autoscaler still sees only fixed node groups, while Karpenter can match a NodePool to the requested slice shape and add or consolidate nodes accordingly.
Figure 4 highlights the second-order effect of GPU sharing: fractional requests change the shape of what needs provisioning, and only a provisioner that reasons about instance shape on the fly can respond without a human editing node groups first.
Karpenter treats spot interruption, idle consolidation, and fractional-GPU scheduling as three faces of the same disruption problem and exposes one policy surface for all three; Cluster Autoscaler treats them as three separate concerns bolted onto node groups that were never designed to be torn down opportunistically, which is why GPU teams on CA often disable aggressive scale-down entirely.
Spot Interruption and GPU Capacity
GPU spot capacity is where the savings are largest and the interruption risk is highest — H100 and A100 spot pools get reclaimed under demand pressure more often than commodity CPU spot pools simply because so few instances exist per pool. Karpenter subscribes to the two-minute AWS spot interruption notice directly and proactively begins draining and replacing the node, and because it can fall back to any instance type permitted by the NodePool, a reclaimed p5.48xlarge slot can be backfilled by a different GPU family if that’s what’s available, rather than waiting on a single ASG’s spot pool to refill.
Cluster Autoscaler doesn’t itself watch for interruption notices — that job typically falls to a sidecar like AWS Node Termination Handler running alongside CA-managed node groups. When a spot node is reclaimed, CA’s job is only to notice the resulting capacity shortfall and scale the same node group back up, which means it retries the same narrow instance-type pool that just got reclaimed. Diversifying spot risk under CA means manually building mixed-instance ASGs across several GPU types, which reintroduces the same node-group-matrix maintenance burden bin-packing already imposes.
There’s a second-order effect that GPU teams underestimate: spot capacity for large multi-GPU instances (p4d, p5-class) is thin enough that a single ASG’s spot pool can be genuinely empty for stretches, not just briefly interrupted. A CA node group with no on-demand fallback path simply stays at zero until that pool frees up, silently stalling a training queue. Karpenter’s NodePool can express an ordered capacity-type preference — spot first, on-demand as fallback — inside the same NodePool, so a stalled spot search degrades to a working, if pricier, on-demand node automatically rather than paging someone at 2 a.m.
Consolidation, Drift, and Disruption Budgets
Karpenter’s consolidation controller runs continuously, looking for nodes that are empty, underutilized, or replaceable by a cheaper instance carrying the same workload, and voluntarily deletes or replaces them. This is the mechanism that actually recovers the savings instance-type flexibility promises — without it, Karpenter would just launch cheap nodes and then let them sit half-empty like any other autoscaler. Two guardrails keep this from becoming disruptive on GPU workloads specifically:
- Disruption budgets cap how many nodes in a NodePool can be disrupted concurrently — the default is 10% of the NodePool’s nodes, and GPU NodePools are routinely configured tighter (or scheduled to a narrow maintenance window) because interrupting a multi-hour training job mid-epoch is far costlier than interrupting a stateless web pod. See Karpenter’s own disruption documentation for the full budget syntax.
- The
karpenter.sh/do-not-disrupt: "true"pod annotation exempts a specific pod’s node from voluntary consolidation entirely, which is the standard way to protect a long-running training job while still letting Karpenter consolidate every other GPU node around it.
Karpenter also drifts: if a NodePool’s requirements or NodeClass configuration changes — a new AMI, a new subnet — nodes provisioned under the old spec are marked as drifted and rolled over on the same disruption-budget-gated schedule, so a driver upgrade doesn’t have to be a manual fleet-wide event.
Consolidation itself is a policy choice, not a single fixed behavior. WhenEmpty only removes nodes with zero workload pods on them — the conservative option, and a reasonable default for GPU NodePools where you’d rather under-consolidate than risk disturbing a running job. WhenEmptyOrUnderutilized also replaces nodes that are technically occupied but poorly packed, which is where most of the savings live but also where the do-not-disrupt annotation earns its keep. The newer Balanced policy, added in Karpenter’s 2026 releases, tries to split the difference by weighing consolidation aggressiveness against how recently a node was disrupted, reducing the node churn that pure underutilization-based consolidation can produce on spiky GPU inference traffic.
Cluster Autoscaler’s scale-down path is comparatively blunt: a node is a scale-down candidate once utilization drops below a threshold for a sustained period, and CA removes it if doing so doesn’t violate PodDisruptionBudgets. There’s no cross-instance-type rebalancing — CA never asks “would a smaller, cheaper node serve this same workload,” because it isn’t evaluating alternative instance types at all, only whether to keep or remove capacity within a group whose shape was already decided.
Figure 3: Before consolidating a GPU node, Karpenter checks the do-not-disrupt annotation, then the disruption budget, then any PodDisruptionBudget, before it will replace or delete.
MIG and Time-Slicing: Where Both Autoscalers Run Into the Same Wall
Multi-Instance GPU (MIG) partitions a single physical GPU (A100, H100) into isolated hardware slices with their own memory and compute; time-slicing shares one GPU across pods without hardware isolation, trading isolation for simpler scheduling of bursty, low-utilization workloads — the mechanics and trade-offs are covered in depth in our GPU sharing with MIG, time-slicing, and MPS piece. For autoscaling purposes, the critical fact is that neither the NVIDIA device plugin’s classic MIG/time-slicing config nor early Dynamic Resource Allocation support changes what a node group looks like to Cluster Autoscaler: CA still sees one node advertising a fixed resource quantity, and it cannot reason about “this node has three MIG slices free” versus “this node needs a different MIG profile entirely” — it can only scale the group up or down as a whole.
Karpenter’s 2026 releases added early DRA support for consumable and partitionable devices specifically to close this gap: because Karpenter evaluates instance types per pending pod rather than per fixed group, it’s structurally better positioned to eventually match a fractional-GPU request to the right physical instance and MIG profile combination. As of today that capability is still young and vendor rollout is uneven — do not assume general MIG-profile-aware bin-packing works out of the box on either autoscaler; validate against your specific device plugin version before relying on it in production.
Worked Cost Example: Mixed Training and Inference GPU Cluster
The scenario, utilization pattern, and resulting savings percentage below are an illustrative model, not a benchmark from a specific customer environment; on-demand and spot list prices are current AWS us-east-1 rates as of late August/September 2026.
Assume an ML platform running two workloads: a bursty inference service needing between one and four GPUs of g6.xlarge-class capacity (NVIDIA L4, listed around $0.805/hr on-demand) depending on traffic, and an occasional large training job needing an 8x-GPU p4d.24xlarge-class instance for a few hours a day. AWS’s June 2025 pricing update cut P4d/P4de on-demand rates by up to 33% and P5/P5en by up to 45%, and spot discounts on top of that typically run 50–70% for P4d/P5-class instances and 60–70% for G5/G6-class instances, per current market reporting.
Cluster Autoscaler approach: to guarantee inference capacity is available instantly during traffic spikes, the team keeps a g6.xlarge node group with a minimum size of 2 running around the clock, scaling to 4 under load. The training node group is kept at a minimum size of 1 so the multi-minute GPU cold-start doesn’t block the first job of the day, only scaling to 0 overnight via a scheduled action. Each group is on-demand because CA has no native interruption handling and the team doesn’t trust unattended spot fallback across a matrix of node groups they’d otherwise have to build.
Karpenter approach: a single inference NodePool spans g6.xlarge through g6.2xlarge with spot preferred and on-demand fallback, consolidating to zero nodes overnight when traffic is near zero and relying on the roughly 5–10 minute cold start only for the first request after an idle period (mitigated with a pre-baked, driver-included AMI). The training NodePool uses spot with a do-not-disrupt annotation on the training pod and a tight disruption budget, scaling to zero between runs.
| Cost driver | Cluster Autoscaler (illustrative) | Karpenter (illustrative) |
|---|---|---|
| Inference GPU hours/month | ~1,460 hrs (2 nodes × 24h × 30, on-demand floor) | ~600 hrs (spot, consolidates to 0 overnight) |
| Inference $/hr | $0.805 on-demand | ~$0.30 blended (spot ~60% off, some on-demand fallback) |
| Inference monthly cost | ~$1,175 | ~$180 |
| Training GPU hours/month | ~720 hrs (1 node kept warm 24h, on-demand) | ~90 hrs (spot, scale-to-zero between runs) |
| Training $/hr (p4d.24xlarge-class) | ~$32.77 on-demand (post-2025 cut, illustrative) | ~$13 blended spot (~60% off) |
| Training monthly cost | ~$23,600 | ~$1,170 |
| Total illustrative monthly GPU spend | ~$24,775 | ~$1,350 |
The gap here is intentionally dramatic to make the mechanism visible: it comes almost entirely from CA’s minimum-size floor keeping a p4d-class node warm 24/7 out of caution, versus Karpenter’s willingness to scale to zero and eat a bounded cold-start instead. A CA configuration tuned aggressively — minimum size 0, careful scheduled scaling, mixed-instance ASGs with manual spot fallback — closes much of this gap but requires reproducing, by hand, most of what Karpenter’s NodePool and consolidation controller do automatically. The realistic comparison for most teams isn’t “CA always costs 15x more,” it’s “CA can match Karpenter’s cost efficiency on GPU fleets, but only by taking on the operational cost of building and maintaining the flexibility Karpenter provides by default.”
Decision Matrix
| Dimension | Cluster Autoscaler | Karpenter |
|---|---|---|
| Instance-type flexibility | Fixed per node group; needs one group per type/AZ | Dynamic; one NodePool spans many types |
| Spot interruption handling | External (Node Termination Handler); retries same group | Native two-minute-notice handling; can fall back across types |
| Scale-to-zero for GPU groups | Supported but often avoided due to cold-start risk | Native via consolidation; standard pattern |
| Cold-start exposure | Lower if min-size kept warm (costs more) | Higher unless placeholder capacity used |
| Consolidation to cheaper instance | Not supported | Native, budget-gated |
| MIG/time-slicing awareness | None; sees fixed resource totals per group | Early DRA support; still maturing |
| Operational overhead | High at GPU-type scale (many groups) | Lower per NodePool, higher API/IAM surface to secure |
| Best fit | Small, stable GPU fleets with 1–2 instance types | Multi-type, bursty, or cost-sensitive GPU fleets |
Trade-offs, Gotchas, and What Goes Wrong
Karpenter’s flexibility is also its biggest operational risk: an over-broad NodePool with no do-not-disrupt guardrails can consolidate a node mid-training-epoch because the controller correctly saw it as “underutilized” without knowing a stateful job was mid-checkpoint. Teams that skip labeling long-running jobs, or that leave disruption budgets at defaults, discover this the expensive way — a multi-hour training run restarted from its last checkpoint because Karpenter decided the node was a consolidation candidate. The fix is mechanical, not exotic: tag every long-running GPU pod with do-not-disrupt, and tighten the training NodePool’s disruption budget below the platform default.
The second common failure is AMI drift silently changing driver versions. Because Karpenter can launch a wide range of instance types, an EC2NodeClass pointing at a “latest” AMI alias can pull a newer CUDA/driver combination than what your ML framework was validated against, and the failure mode is a training job that schedules fine and then crashes on a CUDA version mismatch — pin AMIs explicitly for GPU NodeClasses.
Cluster Autoscaler’s failure modes are more about capacity availability than correctness: node groups sized too conservatively simply leave pods pending, sometimes for the multi-minute GPU cold-start plus queueing time, and diagnosing “why is my GPU pod pending” usually means checking whether the group is at its max size, whether the instance type is out of capacity in that AZ, or whether taints/labels were misconfigured — none of which Karpenter’s dynamic search has to worry about, since it isn’t boxed into a single group. Both autoscalers also share a subtler gotcha: neither one understands GPU utilization the way it understands GPU allocation. A pod that requested a full GPU but is using 10% of it looks fully packed to both schedulers; solving that requires MIG, time-slicing, or a workload-level rightsizing pass, which is exactly the territory covered in our Kubernetes GPU rightsizing and cost optimization guide.
Finally, running both autoscalers on the same cluster — a common transitional state — requires strict non-overlapping node selectors or labels, or the two will fight over the same pending pods, sometimes launching duplicate capacity for a single burst of demand before either notices the other filled it.
A less obvious gotcha shows up in IAM and quota planning. Karpenter’s dynamic instance search means it can legitimately request instance types your account has never launched before, which means service quotas (vCPU limits per instance family, on-demand and spot limits tracked separately) need headroom across a family group, not just the one or two types a CA node group used historically. Teams migrating to Karpenter who don’t raise quotas proactively hit a confusing failure mode: Karpenter “wants” to launch a cheaper instance type, the launch fails on a quota limit that was never hit before because CA never tried that type, and the pod stays pending with an error that looks like a scheduling bug rather than a quota gap.
Practical Recommendations
For most teams running more than one GPU instance family, or any workload with meaningful idle time — bursty inference, scheduled training, dev/research clusters — Karpenter’s per-pod instance search and native consolidation will produce a materially lower bill with less ongoing tuning than trying to replicate that behavior across hand-built Cluster Autoscaler node groups. Teams running a single, constantly-saturated GPU shape (one instance type, always busy, never idle) will see less differential, since there’s little for consolidation or instance-type flexibility to optimize away — in that narrow case, Cluster Autoscaler’s simplicity is a legitimate reason to stay.
Either way, the guardrails matter more than the choice of autoscaler. Before switching or expanding a GPU NodePool:
- Pin GPU AMIs explicitly rather than using “latest” aliases, to avoid unplanned driver upgrades.
- Annotate every multi-hour or stateful GPU pod with
karpenter.sh/do-not-disrupt(or the CA-equivalent PodDisruptionBudget) before enabling aggressive consolidation. - Set a tighter disruption budget on training NodePools than the platform default of 10%.
- Pre-bake driver and container runtime into the AMI rather than installing at boot, regardless of autoscaler, to cut cold-start latency.
- Diversify spot exposure across at least two GPU families per workload class where the workload tolerates it.
- Validate MIG or time-slicing behavior against your specific device plugin and Kubernetes version before assuming either autoscaler understands fractional GPU capacity correctly.
- Never run Cluster Autoscaler and Karpenter against overlapping node selectors on the same cluster.
Frequently Asked Questions
Does Karpenter support GPU nodes out of the box?
Yes, but GPU support depends on your EC2NodeClass AMI including the NVIDIA driver and container runtime, and your NodePool requirements including the right instance families. Karpenter itself doesn’t install GPU drivers — the AMI or a bootstrap script does — so a misconfigured NodeClass launching a non-GPU-ready AMI is a common early setup mistake, not a Karpenter limitation.
Can Cluster Autoscaler scale multiple GPU instance types in one node group?
Only through mixed-instance ASGs with manually configured priority or weighting, and even then it’s choosing among a small, pre-declared set rather than dynamically searching all available GPU types the way Karpenter does. Most production GPU setups on Cluster Autoscaler end up with one node group per instance type instead, for predictable scheduling behavior.
How does spot interruption affect GPU training jobs differently under each autoscaler?
Karpenter reacts to the two-minute spot interruption notice directly and can replace the node with a different eligible GPU instance type if the original type is out of capacity. Cluster Autoscaler relies on an external termination handler to notice the interruption and then re-requests capacity from the same node group, which retries the same narrow instance pool that was just reclaimed.
Does Karpenter work with MIG or time-sliced GPUs?
It can coexist with both, since MIG and time-slicing are configured at the device-plugin and node level rather than the autoscaler level. Karpenter’s newer Dynamic Resource Allocation support is starting to make it fractional-GPU-aware, but that capability is still maturing in 2026 — test against your specific NVIDIA device plugin version rather than assuming full support.
Is Cluster Autoscaler being deprecated in favor of Karpenter?
No. Cluster Autoscaler remains an actively maintained, first-class option, and Kubernetes’ own documentation presents it alongside Karpenter rather than as a legacy path. Karpenter is gaining share particularly on AWS and increasingly on Azure through AKS Node Auto Provisioning, but Cluster Autoscaler is not going away, especially for teams with simple, stable node-group topologies.
What causes slow GPU node cold starts, and can changing autoscalers fix it?
Cold start on GPU nodes comes from pulling a large AMI, initializing the NVIDIA driver, and registering GPU resources with the kubelet — none of which either autoscaler controls directly. Switching autoscalers doesn’t remove that latency; pre-baking drivers into the AMI, and deciding whether to keep warm capacity (Cluster Autoscaler’s usual approach) or accept the cold start in exchange for scale-to-zero savings (Karpenter’s usual approach), is what actually changes the experience.
Further Reading
- Karpenter Node Autoscaling on Kubernetes: A Production Deep-Dive — the general-purpose mechanics of NodePools, NodeClasses, and consolidation this piece builds on.
- Kubernetes Cost Optimization and GPU Rightsizing in 2026 — how to size GPU requests correctly before autoscaling policy can help.
- Kubernetes GPU Sharing: MIG, Time-Slicing, and MPS in 2026 — the fractional-GPU mechanisms referenced above.
- Karpenter Disruption Concepts — official documentation on consolidation, drift, and disruption budgets.
- Amazon EC2 On-Demand Pricing — current GPU instance rates referenced in the worked cost example.
By Riju — about
