kubectl autoscale & HPA: A Production Maturity Guide for 2025

Static replica counts are a gamble you can’t win. You either overprovision and burn cash on oversized pods, or you underprovision and risk cascading failures during traffic spikes. For any production system running on Kubernetes, dynamic autoscaling is a key discipline for achieving both reliability and cost efficiency.

Mastering Kubernetes autoscaling is a journey of increasing maturity, one that often starts with a single, powerful command: kubectl autoscale. It’s the fastest and most direct way to add elasticity to a deployment, delivering an immediate win. But while this command is the front door to a more intelligent system, production-grade automation requires moving beyond that first step toward a more declarative and robust strategy.

This guide walks you through that entire maturity journey, from your first CLI command to a fully autonomous scaling strategy, equipping you with the tools to build a truly resilient and cost-efficient platform.

The First Step: Quick Wins with kubectl autoscale

The fastest way to enable autoscaling and see immediate results is with the kubectl autoscale command. Without writing a single line of YAML, you can give a deployment the elasticity it needs to handle variable load.

Here is the command:

kubectl autoscale deployment my-webapp --min=2 --max=10 --cpu-percent=75

This single line instructs Kubernetes to create a Horizontal Pod Autoscaler (HPA) resource. The HPA controller will monitor the my-webapp deployment and automatically adjust its replica count to keep the average CPU utilization across all its pods at around 75%.

The command is governed by three critical flags:

In seconds, you’ve moved from a static, fragile configuration to a dynamic, resilient one. This is the first and most impactful step on the path to production-ready autoscaling.

The Production Baseline: Declarative HPAs in GitOps

The kubectl autoscale command is spot-on for discovery and testing, but it’s an imperative command. A one-time instruction that tells the cluster to do something. Production systems, however, require a declarative approach. Your infrastructure’s desired state, including its scaling policies, must be defined as code and stored in a version control system like Git. This is the core principle of GitOps.

Instead of running a command, you define an HPA resource in a YAML file. This manifest is the source of truth for your scaling policy.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-webapp-hpa
spec:
  # Point HPA at the deployment it needs to scale
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-webapp
  # Define the scaling boundaries
  minReplicas: 2
  maxReplicas: 10
  # Define the metric to scale on
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 75

It is then applied to your cluster as part of your standard deployment process. This declarative, GitOps-friendly approach is the non-negotiable baseline for production for several key reasons:

The Operator’s Toolkit: Debugging and Verification

You can only trust automation that you can verify. When HPA doesn’t behave as you expect by scaling too slowly, too quickly, or not at all, knowing how to diagnose the issue is a critical operator skill. Kubernetes provides two essential commands for peeling back the layers and understanding HPA’s decision-making process.

The Quick Look: kubectl get hpa

Your first stop is a high-level status check. This command gives you a concise, one-line view of the current state: the target metric, the current value, and the number of replicas.

kubectl get hpa my-webapp-hpa

You’ll see output like this, which is perfect for a quick confirmation that HPA is active and receiving metric data.

NAME           REFERENCE	        TARGETS	 MINPODS  MAXPODS  REPLICAS  AGE
my-webapp-hpa  Deployment/my-webapp	30%/75%	 2	      10	   2	     5m

The Deep Dive: kubectl describe hpa

For a detailed diagnosis, kubectl describe hpa is your best friend. It provides a rich, multi-section output that reveals HPA’s entire thought process. Pay special attention to the Events section at the very bottom; it’s a chronological log of HPA’s observations and actions.

kubectl describe hpa my-webapp-hpa

Most common problems can be diagnosed by reading these events. Here’s how to translate HPA’s messages into common “gotchas” and their fixes:

The Tipping Point: From Manual Tuning to Autonomous Optimization

We have now reached the peak of what can be reasonably managed by hand. You understand the limits of the HPA’s reactive nature, you’ve seen how KEDA can help, and you’re aware of the VPA/HPA conflict. This new level of sophistication, however, introduces a new challenge: continuous, manual tuning.

At scale, this becomes an unsustainable operational burden for even the most skilled platform team. How do you make the HPA proactive? How do you solve the pod sizing dilemma without the risks of the standard VPA? The tipping point is when the time your team spends tuning the automation outweighs the benefits of the automation itself. This is the final step in the maturity journey: moving from human-managed automation to a truly autonomous system.

Introducing ScaleOps: Your Autonomous Scaling Engine

This is where an intelligent control plane becomes essential. Instead of replacing your existing tools, ScaleOps acts as an autonomous layer that directly solves the gaps in the native Kubernetes landscape.

Take the Next Step

Moving from manual tuning to an autonomous platform is the final step in the autoscaling maturity journey. When you’re ready to see how an intelligent control plane can transform your operations, here’s how to get started.