HorizontalPodAutoscalers with maxReplicas set to 1

An autoscaler with no room to scale

The HPA API reference defines maxReplicas as the upper limit the autoscaler can scale up to, and says it cannot be less than minReplicas, which defaults to 1. Set the maximum to 1 and the range collapses to a single value. The controller still runs, still reads metrics and still reports conditions, but every calculation ends at one pod.

One common route is a template: a chart ships with maxReplicas: 1 as a safe default for dev, and the value is never overridden for production. The service then has one pod, no redundancy and no ability to absorb a spike, while dashboards and reviews see an HPA and assume the scaling question is handled.

Listing HPAs capped at one

kubectl get hpa -A -o json | jq -r '
  .items[]
  | select(.spec.maxReplicas == 1)
  | "\(.metadata.namespace)/\(.metadata.name) min=\(.spec.minReplicas // 1) target=\(.spec.scaleTargetRef.kind)/\(.spec.scaleTargetRef.name)"'

Exactly one, nothing more

ZopNight reads maxReplicas from the HPA and fires when it equals 1. There is no metric, threshold or window beyond that single value, and the finding clears when the maximum is raised. If the value was not reported, the HPA is skipped.

Cases this check leaves alone

Pinned HPAs with minimum equal to a larger maximum, such as 3 and 3, are the subject of HPA pinned, which deliberately skips the case of 1 so the two checks do not overlap. HPAs capped higher that run out of headroom appear under HPA at max capacity. The check does not look at what the HPA targets, so an HPA pointing at a Deployment that no longer exists is flagged the same way.

A reliability finding without a price

This medium-severity reliability recommendation carries no savings estimate. Raising the maximum does not cost anything until load actually calls for more pods.

Opening up the range

1. Decide the most replicas the service and its dependencies can handle at peak.
2. Raise the maximum in the chart or manifest that owns the HPA, or patch it directly: kubectl patch hpa <name> -p '{"spec":{"maxReplicas":5}}'.
3. Consider raising minReplicas to 2 for production services so a single pod failure does not take the service down.
4. Confirm the target workload has CPU or memory requests, since utilization targets are calculated against requests.
5. If a fixed single pod is really intended, delete the HPA so the manifest says what it does.