Hedronite · Cert Lesson · Cert-Prep / CNCF · Wed 2026-09-30

CKA HorizontalPodAutoscaler — CPU target and scale-down stabilization

HPA points at a Deployment. Stabilization lives under behavior.scaleDown.

Lesson Class: Cert-Prep (CKA · Workloads / Autoscaling)
Cert Target: CKA (CNCF)
Paired Ops: EKS Fargate profiles
Paired Dev: Async kube-rs LabelSelector census
Grounding: CKA Q5 Questions+SolutionNotes · HPA walkthrough
Q5
apache-server · 50% CPU · min 1 · max 4 · scaleDown 30s
API
autoscaling/v2 for metrics + behavior
Trap
v1 has no behavior field
Write the window under scaleDown. Check CPU requests on the target.

<!-- hal:authoritative:yaml -->

On the exam, HPA points at a Deployment, names a CPU utilization target, and bounds the replica range. Stabilization lives under behavior.scaleDown.

§I - Frame

k8s_day_counter 22 is even, so CKA-emphasis. Recent Cert days spent CKS upgrade/drain (09-27), CKA StorageClass (09-24), CKS ServiceAccount hardening (09-21), and CKA Gateway (09-18). Tonight is Bootcamp Q5: create HorizontalPodAutoscaler apache-server in namespace autoscale, targeting Deployment apache-deployment, 50% CPU, min 1, max 4, scale-down stabilization 30 seconds.

Ops today colors scale-out with EKS Fargate profiles: every new pod HPA creates must still match a profile selector to land on Fargate. The exam stem does not mention Fargate. Memorize the HPA object.

§II - Objective map

NeedMechanism
Point at a workloadspec.scaleTargetRef (apps/v1, Deployment, name)
CPU targetmetrics[].type: Resource with resource.name: cpu and averageUtilization
Replica floor/ceilingminReplicas, maxReplicas
Slow the downscalebehavior.scaleDown.stabilizationWindowSeconds
API versionPrefer autoscaling/v2 (metrics array + behavior)

Metrics-server (or an equivalent metrics API) must be present for Resource metrics. On the exam cluster it usually is. Without it the HPA stays unable to compute replicas.

§III - Q5 drill pattern (exam core)

  1. Confirm the Deployment exists: kubectl get deploy -n autoscale apache-deployment
  2. Apply the HPA (SolutionNotes shape):
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: apache-server
  namespace: autoscale
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: apache-deployment
  minReplicas: 1
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 30
  1. Check: kubectl get hpa -n autoscale apache-server shows TARGETS and REPLICAS once metrics arrive.
  2. Optional shorthand (may omit behavior): kubectl autoscale deploy apache-deployment -n autoscale --cpu-percent=50 --min=1 --max=4 --name=apache-server then patch behavior if the stem requires the 30s window.

Q5 wants the stabilization window. If you use kubectl autoscale, verify the window is present afterward.

§IV - Discriminators

Utilization vs averageValue. averageUtilization: 50 means 50% of each pod's requested CPU. The Deployment must set CPU requests or utilization math is meaningless.

minReplicas default. If you omit minReplicas, the API defaults to 1. Still write it when the stem names it.

behavior is v2. autoscaling/v1 has no behavior field. Use v2 when the stem mentions stabilization, scale-up policies, or select policies.

Scale-down stabilization. During the window, HPA remembers recent desired replica recommendations and picks the highest, which delays flapping down. Thirty seconds is short; production often uses longer. Write what the stem says.

§V - Exam traps

  1. Writing a v1 HPA and wondering where behavior went. Use autoscaling/v2.
  2. Putting stabilization under scaleUp. Q5 asks scaleDown.
  3. Targeting a Pod or ReplicaSet instead of the Deployment. scaleTargetRef must match the stem's kind and name.
  4. Setting averageUtilization without CPU requests on the pod template. HPA may sit unknown or mis-scale.
  5. Answering with Gateway, StorageClass, or NetworkPolicy YAML. Wrong domain for Q5.

§VI - Study drill

  1. Run Bootcamp Q5 LabSetUp if present; apply SolutionNotes cold.
  2. Run validate.bash; fix until name, namespace, target, CPU 50, min 1, max 4, and stabilization 30 all pass.
  3. Flash three lines: scaleTargetRef / Resource CPU utilization / behavior.scaleDown window.
  4. Optional Ops adjacency: say whether a new replica in batch with label app=etl would match today's Fargate profile selectors (not on the exam).

Success: Q5 validate exit 0; you can write v2 metrics and behavior without looking up field paths more than once.

§VII - Close instruction

File Q5 as muscle memory. Pair: Ops EKS Fargate coverage census; Dev async kube-rs LabelSelector census. Maghrib owns quiz.html later.

Related