Introduction

In Kubernetes, you usually do not scale individual Pod objects directly. You scale the controller that owns them, such as a Deployment, StatefulSet, or ReplicaSet, and Kubernetes creates or removes Pods to match the desired replica count. Once that model is clear, the practical scaling options are manual scaling with kubectl or automatic scaling with a Horizontal Pod Autoscaler.

Scale the Workload, Not a Single Pod

Pods are meant to be replaceable. If you edit one Pod by hand, the controller will likely recreate its own desired state anyway. That is why scaling should target the workload resource.

For a Deployment:

kubectl scale deployment web-api --replicas=5

For a StatefulSet:

kubectl scale statefulset postgres-read --replicas=3

After that, Kubernetes reconciles the target replica count and manages the Pod lifecycle for you.

Manual Scaling with kubectl scale

The fastest way to change replica count is kubectl scale.

kubectl scale deployment payment-service --replicas=4
kubectl get pods -l app=payment-service

This is useful for:

• load testing
• temporary incident response
• environment bring-up
• validating readiness and startup behavior

Manual scaling is simple, but it relies on an operator noticing when traffic changes.

Declaring Replicas in YAML

You can also define the replica count in the workload manifest.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web-api
5spec:
6  replicas: 3
7  selector:
8    matchLabels:
9      app: web-api
10  template:
11    metadata:
12      labels:
13        app: web-api
14    spec:
15      containers:
16        - name: web-api
17          image: nginx:alpine
18          ports:
19            - containerPort: 80

Apply the change:

kubectl apply -f deployment.yaml

This is preferable when the desired scale should live in source control rather than in an ad hoc command history.

Automatic Scaling with HPA

If the service should scale with load, use a Horizontal Pod Autoscaler. It adjusts replicas based on metrics such as CPU or memory utilization.

kubectl autoscale deployment web-api --cpu-percent=70 --min=2 --max=10

You can inspect it with:

kubectl get hpa
kubectl describe hpa web-api

For HPA to work, the cluster typically needs a metrics provider, and the workload should have realistic resource requests configured.

Resource Requests Matter

Autoscaling on CPU or memory only works well if the Pods define resource requests. Without them, utilization signals are weak or misleading.

1resources:
2  requests:
3    cpu: "200m"
4    memory: "256Mi"
5  limits:
6    cpu: "500m"
7    memory: "512Mi"

If every Pod has different real usage but identical missing or unrealistic requests, scaling decisions become unreliable.

Watching the Rollout

After changing scale, verify that the Pods are actually becoming ready.

kubectl get deployment web-api
kubectl rollout status deployment/web-api
kubectl get pods -l app=web-api -w

Scaling from 2 to 10 replicas is not useful if half the Pods fail readiness checks or cannot be scheduled due to lack of cluster capacity.

Cluster Capacity Is a Separate Problem

Horizontal Pod scaling increases the number of Pods, but those Pods still need nodes with enough CPU and memory. If the cluster is full, new replicas stay pending.

That is where cluster autoscaling or manual node scaling comes in. Pod scaling and node scaling solve different layers of the problem.

Choosing the Right Scaling Method

Use manual scaling when:

• the demand change is temporary
• you are debugging or load testing
• the workload is predictable and low frequency

Use HPA when:

• traffic changes throughout the day
• latency depends on queue depth or CPU pressure
• you want the system to react without operator intervention

In mature systems, manual scaling often becomes the exception and HPA becomes the baseline.

Common Pitfalls

The biggest mistake is trying to scale Pods directly instead of scaling the owning Deployment or StatefulSet. Another is enabling HPA without resource requests, which leads to poor scaling signals. Teams also often increase replica count and forget that the cluster may not have enough node capacity to schedule them. Finally, scaling should always be followed by rollout and readiness checks, otherwise the new replica count is just a number in the spec rather than real serving capacity.

Summary

• Scale the workload controller, not an individual Pod.
• Use kubectl scale for quick manual changes.
• Store replicas in YAML when you want version-controlled desired state.
• Use HPA for automatic scaling based on metrics.
• Verify readiness and cluster capacity after increasing replica count.