Deployments running a single replica

This finding costs money to fix

Almost every rule in the catalogue points at something to remove. This one asks you to add a replica, which increases spend. It is here because the cheapest infrastructure is not always the right infrastructure, and a single-replica service is one node event away from an outage.

Rated medium rather than high precisely because plenty of single-replica workloads are intentional.

What takes a single replica down

A node drain. Routine: cluster upgrades, autoscaler consolidation, spot reclamation. The pod is evicted and rescheduled, and the service is unavailable until it starts elsewhere.

A rolling update. With one replica and the default strategy, the new pod may not be ready before the old one goes, depending on maxUnavailable.

Any node failure. Obvious, and the least common of the three in practice, since planned drains happen far more often than hardware dies.

Where one replica is correct

A batch worker consuming from a queue. A singleton controller or leader-elected component. A development environment nobody pages for. A workload whose state does not tolerate concurrency.

For those, this finding is noise and should be dismissed rather than actioned. That is why it does not carry a saving or a severity that demands attention.

PodDisruptionBudgets are the other half

Two replicas without a PodDisruptionBudget still permit both to be evicted simultaneously during a drain. The budget is what tells the eviction API to keep one running.

Replicas provide the capacity; the disruption budget provides the guarantee. Teams routinely add the first and skip the second, then discover during a cluster upgrade that redundancy alone did not protect them.

Deployments at one replica, cross-checked with PDBs

kubectl get deploy -A -o json | jq -r '
  .items[] | select(.spec.replicas == 1)
  | "\(.metadata.namespace)/\(.metadata.name)"'

Cross-check against kubectl get pdb -A for which of those have a disruption budget.