Manual Scaling and HorizontalPodAutoscaler
`kubectl scale` is one command and always works. An HPA is one command and often does nothing, because it needs two things people forget: a metrics-server, and CPU requests to calculate a percentage against. Both failure modes are reproduced here, then fixed, and then a load generator drives a real scale-up from one replica to the maximum.
Application Deployment Guide 22 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 18 min
- Reviewed23 August 2026
Written against the versions above. `--cpu-percent` is deprecated and the captured output says so - the current flag is `--cpu 50%`. Note also that adding requests did not fix `<unknown>` immediately: it still read unknown 45 seconds later, because metrics-server scrapes on an interval and the Pods had just been recreated by the rollout.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster with metrics-server. Without it
kubectl topfails and an HPA can never read a value. - The session creates namespace
ckad-scale, a Deployment ofregistry.k8s.io/hpa-example, an HPA targeting 50% CPU, and a busybox Pod generating load in a loop.
-
Scaling by hand
-
An HPA with no denominator
-
Give it something to divide by
-
Put it under load
-
Taking the load away