Kubernetes HPA

HPA (Horizontal Pod Autoscaler) automatically scales the number of Pods in a workload based on observed resource usage or custom metrics.

Autoscaling helps applications handle variable load without manual intervention.

Horizontal scaling adds more Pod replicas to handle more traffic or work.

Vertical scaling changes the resource size of a Pod, such as increasing CPU or memory.

Because it scales the number of replicas horizontally.

HPA typically works with Deployments, ReplicaSets, StatefulSets, and similar scalable workloads.

A target utilization is the desired percentage of resource usage that HPA tries to maintain.

CPU utilization is the ratio of current CPU usage to the requested CPU for a Pod.

It is the CPU percentage HPA aims to achieve for the workload.

Average utilization is the average of resource usage across Pods in a scalable workload.

The minimum number of Pods allowed by the HPA.

The maximum number of Pods allowed by the HPA.

The current number of Pods in the workload.

The target number of Pods that HPA intends to scale the workload to.

The HPA controller continuously evaluates metrics and updates the replica count.

Because it continuously reconciles desired scale with observed metrics.

Scale-out means increasing Pod replicas to handle more load.

Scale-in means decreasing Pod replicas when demand drops.

It helps keep services responsive while avoiding excessive wasted capacity.

A Deployment manages a ReplicaSet and maintains a desired number of replicas.

Because a Deployment is the common workload pattern for stateless apps.

HPA updates the replica count of the target workload.

It compares observed metrics to targets and calculates the desired replica count.

Metric aggregation combines values from multiple Pods to compute a workload-level metric.

The Metrics Server collects resource metrics like CPU and memory for pods and nodes.

A custom metric is a business or application-specific metric, such as queue depth or request rate.

An external metric originates outside the cluster, such as a cloud service or queue in another system.

Because CPU-only scaling is not always enough for real workload decisions.

The target type describes what kind of metric or resource HPA uses, such as CPU utilization or a custom metric.

It is the Kubernetes object representing the HPA configuration.

It is a newer HPA API version used for richer scaling behavior and multiple metrics.

Because different services experience different traffic patterns and need different scale behavior.

HPA relies on CPU request and other metrics to estimate whether the workload is under or over capacity.

Because HPA compares current utilization to target utilization based on workload requests.

It is the amount of CPU the pod expects to use and that the scheduler reserves for it.

If the request is too low, HPA may think the pod is “overutilized” or scale unpredictably.

It can make HPA scale too conservatively or create unschedulable capacity issues.

Because HPA computes utilization based on request values and observed usage.

A scaling event is a change to the desired pod count triggered by metrics.

They directly affect cost, availability, and response time.

The average CPU used across the replicas in the workload.

Utilization is roughly current CPU / requested CPU * 100%.

It seeks to maintain the workload near the target value to balance responsiveness and cost.

The default HPA behavior is to scale based on CPU utilization when configured.

The target value is the desired metric value HPA tries to maintain.

For some metric types, HPA calculates the average across Pods or a selected set of workloads.

Behavior defines scaling policies for scaling up and down such as stabilization windows and policy rules.

It prevents rapid flapping or oscillation as metrics move.

It defines how aggressive HPA should be when scaling up.

It defines how conservative HPA should be when scaling down.

A stabilization window prevents HPA from reacting too quickly to short-term metric spikes.

It reduces churn and makes scale decisions more stable.

It chooses how HPA picks the desired replicas under multiple scaling metrics.

The minimum and maximum replicas allowed in the HPA range.

Because aggressive scaling can cause thrash or poor cost control.

It increases or decreases replicas based on actual traffic or workload.

It is a delay or stabilization period that prevents quick scale-in after a brief spike.

It is a delay or stabilization policy used to avoid too-frequent scale-out events.

Because scaling out often needs to be faster than scaling in, especially for latency-sensitive applications.

Examples include queue length, requests per second, or a business metric like active users.

A message queue depth in a cloud service or a third-party API throughput measure.

Metrics adapters provide custom and external metrics to the HPA controller.

Because HPA does not directly know every custom metric source.

Prometheus Adapter is a common adapter that exposes Prometheus metrics as custom metrics for HPA.

Because it is widely used for application-level metrics and system observability.

Queue depth is the number of pending tasks in a queue, which can indicate demand.

Because CPU may not reflect actual demand for async processing workloads.

It measures incoming requests per second and can be a strong indicator for web workloads.

Because some workloads are I/O or queue-based and CPU usage may not track demand well.

Because CPU utilization may not correlate to user-visible demand or business capacity.

A threshold is a metric value that triggers scale-out or scale-in.

HPA calculates a new desired replica count using the target metric and current metric.

Without requests, CPU utilization calculations may not make sense or can be misleading.

A cooldown is a delay period before another scaling action occurs.

It is an older HPA API version; newer clusters typically use v2 or v2beta2 depending on version.

Often 50, 60, or 70 percent is used.

Because it balances utilization and cushion but varies by workload type.

It may allow pods to saturate or become slow before scaling happens.

It may over-scale and increase costs without enough gain.

It avoids oscillation or poor cost/performance balance.

For example: scaleUp in steps, scaleDown slower than scaleUp.

Because scale-down is usually more conservative to avoid thrashing or disruption.

It chooses the maximum of multiple metric calculations when multiple metrics are used.

It chooses the minimum required replica count under multiple metrics.

Because some workloads may be limited by CPU, memory, or queue depth at different times.

It defines the target queue depth, latency, or throughput value.

A multi-metric HPA bases decisions on more than one metric.

Because real workloads may need several signals, such as CPU and queue depth.

A metric unique to the application or service, like business transactions per second.

It lets you check current HPA status and scaling decisions.

It includes current metrics, desired replicas, and the scaling event history.

It gives insight into whether autoscaling is functioning as expected.

• missing metrics-server
• no resource requests
• custom metrics not configured
• low target or wrong thresholds
• pods not ready
• workload not scalable

Because HPA depends on metrics to know current utilization.

Because HPA should only scale based on active and ready pods.

It occurs when the workload scales too slowly or not at all under demand.

It occurs when the workload scales too aggressively and increases cost without benefit.

It tends to scale later and thus may delay handling bursts.

It tends to scale earlier, leading to more replicas and higher cost.

Because autoscaling still needs a solid baseline of app sizing and resource requirements.

It is the standard metrics API for CPU and memory metrics used by HPA.

It is often deployed as `metrics-server` in the cluster.

It is an optional cluster component and must be installed.

It is an API that exposes application-specific or external metrics to the HPA.

It adapts external metrics to the Kubernetes autoscaling API.

Because some apps do not scale directly with CPU or memory.

A queue depth metric can indicate backlog or pending work to scale based on demand.

Scaling based on application transactions or requests per second.

Because it often correlates directly with user demand.

The Service load balancer receives traffic, and HPA changes pod count to absorb it.

Ingress traffic is often a strong driver for scale-out events.

KEDA (Kubernetes Event-Driven Autoscaling) is a scaler framework for event-driven workloads using custom metrics and queue-based scaling.

It helps scale workloads based on events, message queues, and external systems.

Because queue-based or event-driven workloads often do not scale well on CPU alone.

It exposes Prometheus metrics to HPA as custom metrics.

Because many clusters already gather Prometheus metrics of application performance and load.

It is usually a metric not in the cluster itself, like cloud queue length or an API usage counter.

It is the target value for average custom metrics in an HPA.

Because they reflect actual working capacity rather than generic resource percentages.

It is the current observed value of the metric used by HPA.

Because the scale decision depends on current vs target.

Desired replicas ≈ current replicas * (current metric / target metric)

Because it shows how HPA scales in proportion to observed demand.

The HPA may delay a decision until a period of stable metrics or until the same value persists.

Because if metrics fluctuate too much, HPA might quickly scale up and down.

This occurs when the stabilization window is too short or target thresholds are too aggressive.

Undersizing means too few replicas for demand. Oversizing means too many replicas for actual need.

Because HPA uses resource utilization information, which is affected by pod requests and CPU limits.

If the CPU request is too low or too high, HPA may scale wrongly.

Pods that are not ready should not count toward the metric or traffic serving.

It ensures HPA only uses eligible pods in the scale decision.

Some clusters or policies intentionally wait to avoid reacting to brief spikes.

Scale-in is often delayed to avoid churn after a brief drop in demand.

Because cluster cost and service stability make slow scale-down more cautious.

It picks the replica count required by all relevant metrics according to the policy.

It is the calculation used to determine the desired replica count under certain metric types.

Because metrics, polls, and workloads vary over time, so HPA uses a controller loop.

It is the tuning process of setting requests and targets to align with actual workload behavior.

Because queue depth can be a better backlog indicator than CPU.

It uses requests per second or transaction rate as the scaling signal.

Because throughput is directly tied to user demand.

VPA (Vertical Pod Autoscaler) can adjust pod resource requests and limits while HPA handles replicas.

HPA changes pod count; VPA changes pod size.

They handle different dimensions of scaling: count and size.

It includes scale target, metrics, min/max replicas, and behavior.

Because they describe desired scaling behavior in YAML and are reconciled by the controller.

Because it affects cloud cost, latency, and cluster stability.

It happens when thresholds are set too low or too high and do not match workload behavior.

Check metrics-server, resource requests, target values, pod readiness, and custom metrics.

It may never scale, scale too aggressively, or scale based on the wrong metric.

Because unrealistic metrics create noisy and unstable scaling decisions.

It directly reflects user demand and can be more meaningful than CPU.

It prevents runaway cost or over-scaling under heavy load.

It keeps a baseline number of replicas available even during low traffic.

Some workloads require a minimum footprint for responsiveness or warm-up.

It occurs when metrics are stable and within the target bands.

Because some workloads are not well-suited for autoscaling or need custom metrics and tuning.

It is spare capacity beyond current load that allows good scaling behavior and latency.

New pods take time to start, so scaling may lag behind traffic.

Because HPA must account for the time to create new replicas before demand spikes too much.

A workload with sudden spikes in traffic or processing demand.

Because short-lived bursts should not immediately trigger large or oscillating scale changes.

It is visible via HPA status and the workload replica count.

Because Kubernetes core metrics do not cover application-specific business metrics.

Some serverless or event-driven systems can scale to zero when idle.

Because many workloads must remain warm or ready to respond quickly.

A cold start is the delay before a new replica becomes ready to handle traffic.

Because they affect user latency and the speed needed for HPA to react.

It occurs when traffic increases faster than pods can scale.

Because otherwise autoscaling may be too slow or too aggressive.

It is the amount of work waiting to be processed.

Because it can often predict service saturation even when CPU is not high.

SLO (Service Level Objective) is a target for acceptable application performance or reliability.

Because scaling decisions should preserve service quality, not just maximize capacity.

It reduces idle spend by scaling down during low traffic, while satisfying SLOs.

It can scale workers based on queue depth or processing backlog.

It determines when additional workers should be created.

Because web traffic, async workers, and databases behave differently.

Because CPU is a generic measure, not necessarily the real bottleneck.

To keep the workload close to the desired demand and maintain service quality while minimizing wasted capacity.

It is the periodic controller reconciliation loop that compares metrics to targets and updates replica counts.

Because it defines the cadence and responsiveness of scaling behavior.

It is a policy setting how much to increase replicas per scaling event.

It determines how many replicas to remove per scale-down event.

They prevent sudden large swings or overreactive adjustments.

It is the amount of time HPA waits before recognizing a new scaling trend.

Because metrics can fluctuate and produce noisy scale decisions.

It defines the percent change allowed per scaling event.

It depends on the custom metric target and the current metric value for the workload.

Because CPU is not always a direct signal of demand or backlog.

KEDA extends HPA by providing scaling based on external or event-driven metrics.

Because such systems often scale according to queue depth or backlog length more than CPU.

It bridges a third-party metric source to the HPA API.

Because an unstable metric source can lead to wrong or dangerous scale decisions.

It happens when the metrics adapter or backend cannot provide valid data to HPA.

Because without them, it cannot compute a correct replica count.

HPA should be tuned to keep service-level objectives within target thresholds while optimizing cost.

It is a policy or condition ensuring scaling does not exceed safe or cost-effective limits.

It ensures scaling down does not reduce capacity below acceptable service levels.

HPA is the cluster’s automatic capacity controller: it measures demand, compares it to policy and target values, and adjusts replica counts to balance performance, cost, and resilience.