A Kubernetes deployment's replica count oscillates all day — up 20, down 8, up 15. Which HorizontalPodAutoscaler settings control that, and how do the scaleUp and scaleDown stabilization windows actually work?

## Why autoscalers oscillate An HPA is a proportional controller with a delay. Load rises, replicas are added, load per pod falls, replicas are removed, load per pod rises again — a classic feedback loop. It gets worse when the metric is noisy, when the workload has a slow start (new pods burn CPU warming caches or JIT-compiling, which *raises* the average and triggers more scale-up), or when the signal lags the action. ## The behavior block `spec.behavior` (autoscaling/v2) has two independent sub-objects, `scaleUp` and `scaleDown`, each with a stabilization window and a list of policies. ```yaml behavior: scaleUp: stabilizationWindowSeconds: 0 policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 selectPolicy: Max scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` That is the **default** behavior, worth memorizing because most questions are really "what changes if I leave it out". ## How the stabilization window works — precisely The controller records its raw recommendation every sync. When deciding a new replica count it does **not** use the latest recommendation directly: - **Scaling down**: it takes the **maximum** recommendation observed over the past `scaleDown.stabilizationWindowSeconds`. A single low reading cannot shrink the fleet; every reading in the window must be low before the maximum itself drops. - **Scaling up**: it takes the **minimum** recommendation over `scaleUp.stabilizationWindowSeconds`. With the default of 0 the window is empty and the current recommendation applies immediately. So the window is not a cooldown timer and not an average — it is a directional envelope. Understanding "max for down, min for up" is the crisp answer interviewers listen for. ## How policies work Each policy caps *change per period*: - `type: Pods, value: 4, periodSeconds: 60` — at most 4 pods added (or removed) in any 60-second window. - `type: Percent, value: 10, periodSeconds: 60` — at most 10% of the current replica count per 60 seconds. `selectPolicy` decides how multiple policies combine: `Max` (default) takes the most permissive, `Min` the most restrictive, and `selectPolicy: Disabled` on a direction **forbids scaling that way entirely** — the standard way to build a scale-up-only autoscaler where a human handles shrinking. Note that percent policies interact badly with tiny fleets: 10% of 3 replicas rounds to a change of 1 at best, so combine a percent policy with a pods policy for predictable behavior at both ends of the range. ## Recipes **Damp a flapping web service:** keep scale-up aggressive, widen scale-down. ```yaml behavior: scaleDown: stabilizationWindowSeconds: 900 policies: - type: Pods value: 1 periodSeconds: 120 selectPolicy: Min ``` This shrinks by one pod every two minutes and only after 15 minutes of consistently low demand — expensive in idle capacity, cheap in incidents. **Absorb a known traffic spike:** raise `scaleUp` percent to 200–300% per 15s and raise `minReplicas` ahead of the event, because proportional math from a low base is slow: from 2 replicas even a 100% policy needs several syncs to reach 30. **Freeze scale-down during business hours:** `scaleDown.selectPolicy: Disabled`, flipped by a scheduled process, is more predictable than a very long window. ## What behavior cannot fix Tuning windows treats the symptom. Also check: - **Slow-starting pods.** If a new replica spends 90 seconds at 100% CPU warming up, it inflates the average and drives further scale-up. Fix with readiness probes that gate traffic until warm, `ContainerResource` metrics scoped to the app container, and a startup-aware request size. - **Noisy or high-resolution metrics.** Autoscaling on a raw 15-second gauge invites oscillation; smooth it in the adapter query instead. - **Tolerance too tight** for the fleet size. At 2–3 replicas each step is a huge relative capacity change; a higher `minReplicas` makes the control loop better behaved. - **Disruption cost.** Rapid scale-down repeatedly terminates pods; combine with a PodDisruptionBudget and proper `terminationGracePeriodSeconds` so shrinking never drops in-flight work. ## Observing it `kubectl describe hpa` events log each change with the reason. If replica counts move but events are sparse, something other than the HPA is writing `spec.replicas`.