Kubernetes Autoscaling English: VPA, HPA, KEDA, and Scaling Policy Vocabulary

Kubernetes autoscaling discussions are dense with acronyms, precise technical terms, and subtle distinctions that matter a lot in production. Whether you are presenting a capacity plan to your team, reviewing an HPA configuration in a pull request, or troubleshooting a KEDA scaler in an incident call, the English precision required is high. This post builds the vocabulary and phrases you need for those conversations.

Horizontal vs. Vertical Scaling Terms

HPA (Horizontal Pod Autoscaler) — a Kubernetes controller that automatically adjusts the number of pod replicas in a Deployment or StatefulSet based on observed metrics such as CPU utilization or custom metrics.

“Our HPA is configured to maintain 60% CPU target utilization, scaling between 3 and 50 replicas depending on traffic.”

VPA (Vertical Pod Autoscaler) — a Kubernetes controller that automatically adjusts the CPU and memory requests and limits of running pods, making each pod larger or smaller rather than adding more pods.

“We use VPA in recommendation mode for our batch jobs — it tells us what resource requests we should set, but doesn’t apply changes automatically in production.”

Scale-to-zero — the ability to reduce a workload to zero running instances when there is no traffic, eliminating idle compute costs. Not natively supported by HPA (which requires a minimum of 1), but supported by KEDA and Knative.

“With KEDA handling our event-driven consumers, we finally achieved scale-to-zero on our message processors — they only spin up when there are messages in the queue.”

Target utilization — the threshold metric value that the autoscaler tries to maintain across all pods. For CPU-based HPA, this is typically expressed as a percentage of requested CPU.

“We lowered the target utilization from 80% to 60% after the Black Friday incident — the scaler was reacting too slowly because pods were already saturated before new ones came up.”

KEDA and Advanced Autoscaling Terms

KEDA (Kubernetes Event-Driven Autoscaling) — a CNCF project that extends Kubernetes HPA to support scaling based on external event sources: queues, databases, Prometheus metrics, cron schedules, and more.

“KEDA lets us scale our worker pods based on the number of pending jobs in our RabbitMQ queue, not just CPU — it’s much more responsive to real workload.”

Scaling policy — a set of rules that govern how quickly and by how much an autoscaler can add or remove pods. Policies control the rate of scale-up and scale-down separately.

“We have an aggressive scale-up policy — up to 100% more pods per 30 seconds — but a conservative scale-down policy to avoid thrashing during traffic spikes.”

Cooldown period — a waiting period after a scaling event during which the autoscaler does not trigger another scale-down. This prevents rapid, disruptive cycling of pods.

“The default cooldown period is 5 minutes for scale-down. We extended it to 10 minutes because our traffic has a spiky pattern and we were losing pods too quickly.”

Stabilization window — a time window during which the autoscaler collects metric readings before making a scaling decision. Using the minimum (for scale-up) or maximum (for scale-down) value in that window prevents reacting to brief spikes.

“We set a 2-minute stabilization window for scale-down decisions, so a single burst of low traffic doesn’t immediately shrink our pod count.”

Metrics server — a cluster-level metrics aggregation component that collects resource usage data (CPU and memory) from kubelets and exposes it to the HPA. Required for resource-based autoscaling.

“After upgrading the cluster, the metrics server wasn’t reinstalled — HPA went into an ‘unknown’ state because it couldn’t retrieve CPU metrics.”

Custom metrics — non-default metrics (not CPU or memory) used to drive autoscaling decisions. Accessed via the custom metrics API, often backed by Prometheus Adapter or KEDA scalers.

“We wrote a custom metrics adapter that exposes our request queue depth as a Kubernetes metric, which HPA then uses as its scaling target.”

Real IT Context Phrases

These phrases appear in capacity planning documents, incident reports, and Kubernetes-related pull request reviews:

• “The HPA is flapping — it scaled up and down four times in 20 minutes.” — incident observation, refers to unstable scaling behavior
• “We need to tune the stabilization window to prevent this kind of thrashing.” — recommended fix during a postmortem
• “Let’s set a scale-to-zero floor only for the non-critical workers, not the API pods.” — capacity planning decision in a design review
• “The scaler isn’t reacting because the metrics server hasn’t collected enough samples yet.” — troubleshooting explanation during an incident call
• “Our VPA recommendations show the memory limit is 4x higher than actual usage — we’re over-provisioning significantly.” — cost optimization finding in a quarterly review

Key Collocations

Collocation	Example
trigger autoscaling	”High queue depth triggers autoscaling on the consumer deployment.”
tune the HPA	”Let’s tune the HPA stabilization window before the next load test.”
provision pods	”KEDA provisions pods proactively before the morning traffic peak.”
scale down aggressively	”Scaling down too aggressively causes connection-reset errors for in-flight requests.”
set resource requests	”VPA recommendations help us set resource requests more accurately.”
hit the replica limit	”We hit the replica limit at 50 pods — we need to raise the max or optimize the service.”
drain a node	”Before scaling down the node pool, the cluster drains each node to reschedule pods gracefully.”

Practice

Find your team’s most frequently scaled Kubernetes workload. Write a short capacity planning note in English (one paragraph, 6–8 sentences) that covers: what metric drives scaling, what the current HPA or KEDA configuration targets, what the observed failure mode is during traffic spikes, and what one configuration change you would propose. Use at least five terms from this post. This directly mirrors the format of a capacity planning section in a quarterly infrastructure review document.

Navigating the Nuances: A Practical Perspective on Scaling Policies

Let’s be honest – “scaling policy” sounds incredibly dry. It isn’t. It describes a complex conversation about resource needs, performance targets, and potential bottlenecks within your application. Often, it’s not just about blindly increasing CPU or memory; it’s about understanding why the scaling is happening and ensuring that the underlying system can actually handle the increased load. This is where precise English becomes crucial – avoiding ambiguity and communicating effectively with developers, operations teams, and stakeholders. A common phrase you’ll hear is “achieving optimal resource utilization,” which isn’t just a technical term but reflects a broader business goal: minimizing costs while maintaining performance. Furthermore, the discussion frequently shifts between theoretical capacity planning and the actual observed behavior of your application – leading to debates about whether a scaling policy is truly effective or simply reacting to spikes that could have been prevented with better design. The key is to move beyond simply stating “increase CPU” and towards articulating how much, why, and under what conditions. For example, instead of saying “scale up,” a more informative statement would be: “Increase the HPA target for pod ‘my-app’ by 20% during peak hours (defined as 9 AM – 12 PM) to accommodate anticipated traffic increases based on recent monitoring data.” This level of detail is essential for ensuring that scaling decisions are aligned with business needs and technical constraints. Finally, remember that effective communication doesn’t just rely on the right words; it relies on active listening and a shared understanding of the problem being solved.

Let’s look at an example using Kubernetes Horizontal Pod Autoscaler (HPA) configuration. A code review comment might read: “This HPA adjustment seems overly aggressive. Can you provide more granular metrics to justify increasing the pod count by 50%? Are we tracking queue length, request latency, or something else?” This highlights a critical point – the basis for scaling decisions matters enormously. Without understanding what’s driving the load, scaling becomes a reactive measure rather than a proactive one. The comment isn’t criticizing; it’s prompting a deeper investigation and clarifying the rationale behind the change. Consider this command to set an HPA target:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70 #This is the key - setting a target for CPU utilization

The averageUtilization parameter, in this case targeting 70%, demonstrates how you’re not simply reacting to requests but establishing a baseline expectation. A more sophisticated approach might combine resource metrics with custom metrics exposing application-specific load patterns. Ultimately, mastering the vocabulary around scaling policies is about shifting from describing what to doing – increasing pods – to explaining why and ensuring that those actions are aligned with measurable outcomes.