Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
HPA and KEDA scale workloads by changing the number of Pods; VPA recommends or adjusts the resources assigned to each Pod; Karpenter provisions and manages nodes. They work at different layers, so a common pattern is to scale a workload first and let node autoscaling add capacity when the new Pods cannot be scheduled. As demand falls, workload scaling removes Pods and node autoscaling can consolidate underused nodes.
This guide reflects Kubernetes and KEDA documentation checked on October 7, 2026. Verify feature support against the Kubernetes release and provider implementation you plan to use.
What each autoscaler changes
| Component | What it scales | Signal or input | What it does not do |
|---|---|---|---|
| HPA (Horizontal Pod Autoscaler) | A workload’s desired number of replicas | Resource metrics such as CPU or memory, or supported custom and external metrics | It does not provision nodes or right-size a Pod’s resource requests. |
| VPA (Vertical Pod Autoscaler) | Per-Pod resource sizing, or recommendations for it | Observed and historical resource use, resource availability, and events such as out-of-memory conditions | It does not increase the workload’s replica count or supply node capacity. |
| KEDA | Workload activation and scaling through Kubernetes HPA | Event-source metrics, such as pending messages in a queue | It does not provision nodes; node capacity is a separate concern. |
| Karpenter | Cluster node capacity and node lifecycle | Pending Pods, their resource requests, scheduling constraints, and configured NodePools | It does not decide how many workload replicas application demand requires. |
These roles are complementary, not four competing ways to set the same number. HPA is a Kubernetes API resource and controller. VPA is a separately installed add-on, with recommender, updater, and admission-controller components. KEDA monitors event sources and makes metrics available to Kubernetes HPA; Karpenter provisions nodes from operator-configured NodePools.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsHow workload scaling and node scaling work together
- Choose a demand signal. Use HPA when resource utilization or an available custom or external metric represents demand. Use KEDA when an event source, such as a queue, is the relevant signal.
- Let the workload scaler change the replica target. HPA or KEDA-driven scaling increases or decreases the desired number of Pods. The scheduler then tries to place the resulting Pods using their resource requests and scheduling constraints.
- Provide capacity for Pods that cannot fit. If a Pod is unschedulable because available nodes lack suitable capacity, node autoscaling can provision a node that fits it. Karpenter uses NodePool configuration to provision nodes directly from provider resources rather than relying on preconfigured node groups.
- Scale down in sequence. When demand drops, the workload scaler can remove unnecessary Pods. Node autoscaling can then consolidate nodes that are no longer needed.
That sequence is a coordination model, not a promise of a particular response time or cost outcome. Startup time, drain behavior, scheduling constraints, provider support, and the configuration of each controller affect how a cluster behaves.
#1 Best Overall
Choose HPA, KEDA, or both for workload replicas
Use HPA for resource or Kubernetes metric signals
HPA periodically adjusts a workload’s desired scale based on observed metrics. With the autoscaling/v2 API, it can use multiple metrics, including supported custom metrics. When there is more than one metric, it evaluates the recommendations and uses the largest desired replica count, subject to the configured maximum.
For CPU utilization targets, usage is calculated relative to the Pod’s CPU request. A missing or unrealistic request therefore undermines the meaning of a utilization target. Resource metrics require the metrics.k8s.io API, generally supplied by metrics-server; custom and external metrics require their corresponding metrics APIs and sources.
HPA’s behavior settings can define scaling policies, stabilization windows, and tolerance to moderate scaling behavior and reduce flapping. Configurable HPA scaling behavior has been stable since Kubernetes v1.23, according to the Kubernetes documentation reviewed on October 7, 2026.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Use KEDA when demand comes from events
KEDA is useful when a workload should respond to an event source rather than relying only on metrics from running Pods. For a queue-backed workload, for example, pending messages can activate Pods; when there is no pending work, the workload may be allowed to scale to zero. KEDA’s operator manages activation between zero and one replica, while HPA handles scaling above one.
Rank #3
Do not assume every KEDA trigger can wake a workload from zero. KEDA’s concepts documentation says CPU and memory triggers use a different metrics path: HPA reads those metrics from metrics-server, and scaling to zero is not supported for those triggers because no Pods are running to produce the metric. Check the specific trigger’s behavior and configuration before relying on zero-replica activation.
Use HPA and KEDA together only with a clear ownership model
KEDA exposes event-source metrics to HPA and manages the HPA lifecycle for its scaled workload. Decide which component and metric configuration governs each workload’s scaling rather than layering independent replica controllers without a plan. For event-driven workloads, KEDA supplies the event-based path; HPA performs the one-to-many scaling based on the metrics KEDA exposes.
Decide whether VPA belongs in the same design
VPA analyzes resource use and can produce recommendations or adjust requests and limits according to its configuration. It needs a metrics source such as metrics-server. Use it to address per-Pod sizing; it is not a replacement for HPA or KEDA when the requirement is to change replica count.
Free tools Windows power users keep installed
One-click scans. No signup required.
Requests matter beyond VPA itself. HPA’s CPU utilization is relative to CPU requests, and node autoscalers use Pod requests to assess whether a pending Pod fits and whether nodes can be consolidated. If VPA changes requests, those changes can therefore affect both workload-scaling calculations and node-capacity decisions. Treat vertical and horizontal scaling as interacting control loops, and validate their combined behavior rather than assuming they can be freely combined.
In-place Pod vertical scaling and VPA support are distinct. Kubernetes documents in-place Pod vertical scaling as stable since v1.35, but its workload-autoscaling documentation says that, as of v1.37, VPA does not support resizing Pods in-place and integration work is ongoing. Do not infer that VPA automatically uses Kubernetes’ in-place resizing capability.
A specific caution in the Kubernetes node-autoscaling documentation concerns VPA on DaemonSet Pods alongside node autoscaling: changing DaemonSet resource predictions can make node-capacity estimates unreliable. Account for this interaction when planning VPA coverage.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Understand what Karpenter contributes
Karpenter addresses node supply and lifecycle rather than workload replica count. Its NodePools describe the kinds of nodes the operator permits it to provision. The Kubernetes documentation describes Karpenter as using provider resources directly instead of depending on preconfigured node groups, and as handling broader node lifecycle tasks such as refreshing or upgrading nodes.
The Kubernetes node-autoscaling overview notes that Karpenter has fewer cloud-provider integrations than Cluster Autoscaler and names AWS and Azure as examples. That is not a complete or permanent provider-compatibility matrix: verify the current Karpenter implementation, Kubernetes release, and provider support for the cluster you intend to run.
Check these inputs before enabling autoscaling
- Resource requests: Set meaningful requests for workloads. They inform CPU utilization calculations in HPA and affect whether Pods fit on nodes and whether nodes can be consolidated.
- Metrics availability: Confirm that resource, custom, or external metrics APIs required by the selected signal are present and returning usable data.
- Scheduling constraints: Check affinity, topology, storage, and other placement requirements. A newly provisioned node still has to satisfy the Pod’s scheduling constraints.
- Scale-up and scale-down controls: Configure HPA behavior where appropriate, and account for application startup and workload draining when designing the overall response.
- Provider and release support: Confirm the intended node provider, Kubernetes release, and autoscaler versions support the features and configuration you plan to use.
- Loop interactions: Consider how VPA changes to requests affect HPA utilization and node-capacity decisions, and avoid assuming every workload is a safe candidate for every scaler.
A practical selection guide
| Requirement | Starting point | Key check |
|---|---|---|
| Change replicas based on CPU, memory, or available Kubernetes metrics | HPA | Verify the metrics API and ensure resource requests make utilization meaningful. |
| Activate a workload from queue or event demand, including from zero where supported | KEDA with its event-source trigger | Confirm the trigger supports the desired zero-replica behavior. |
| Improve per-Pod resource sizing | VPA | Decide whether it should recommend or apply changes and assess interactions with horizontal and node scaling. |
| Provide or consolidate node capacity as Pods become pending or unnecessary | Karpenter or another supported node autoscaler | Verify provider integration, NodePool configuration, requests, and scheduling constraints. |
There is no single best autoscaler across all four layers. Select a workload signal and replica controller, decide whether per-Pod sizing needs VPA, and choose a node autoscaler that supports the intended environment. The documentation reviewed does not establish a benchmark comparing these combinations for performance, cost, or response time.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
