# Single Replica Deployment

> A Deployment with 1 replica has no redundancy: any node drain, eviction or rollout takes the service down completely. ZopNight flags these as a reliability finding with no dollar figure, because the fix costs money rather than saving it, which is why it is rated medium.

Source: https://zop.dev/integrations/kubernetes/recommendations/single-replica-deployment
Updated: 2026-08-19

---

## 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

```bash
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.