# ReplicaSet

> ReplicaSets normally sit invisible under Deployments, so ZopNight filters by owner reference and inventories only standalone ones, recording namespace, replica count, and labels. Kubernetes retains up to 10 superseded ReplicaSets per Deployment by default, all at 0 replicas; a standalone set with live replicas is usually a leftover worth migrating or retiring.

Source: https://zop.dev/integrations/kubernetes/replicaset
Updated: 2026-08-19

---

A ReplicaSet keeps a fixed number of identical pods running. In a healthy cluster you almost never touch one directly, since Deployments create and retire them as rollout machinery. That is exactly why the ones that show up on their own are interesting.

## Why most ReplicaSets never appear in the inventory

Discovery filters ReplicaSets by owner reference and keeps only the standalone ones: anything owned by a Deployment is skipped, because those are already represented by their parent and would double-count every workload. Kubernetes itself amplifies the noise this filter removes: each Deployment retains up to 10 superseded ReplicaSets by default (`revisionHistoryLimit`) as rollback points, all scaled to 0 and all irrelevant to cost.

## The standalone ReplicaSet as a smell

A ReplicaSet with no Deployment above it still reserves node capacity through its replica count and per-pod requests, but has none of the rolling-update or rollback machinery. In practice one usually means one of three things: a very old manifest written before Deployments were standard, a controller or operator that manages pods its own way, or a leftover from someone editing a Deployment's ownership out from under it. The first and third are cleanup candidates; the second is worth understanding before touching.

## What gets recorded for the ones that qualify

Standalone ReplicaSets map through the generic workload path: namespace, replica count (also stored as the unit count), labels, and creation time, with status following the shared convention, where 0 replicas is `stopped` and anything else `running`. There is no dedicated recommendation rule for the type; its value in the inventory is topological, completing the picture of what actually holds pods in a namespace.

```bash
kubectl get replicasets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,OWNER:.metadata.ownerReferences[0].kind
```

## Reviewing them takes minutes

The command above makes the audit trivial: rows whose owner column is empty are the standalone population. For each, find who deployed it and why; if the answer is nobody remembers and the replica count is above 0, it is live compute with no modern management surface. Migrate it to a Deployment or retire it.