ReplicaSet
Does ZopNight manage 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.
Rules that fire on ReplicaSet
No active rule family targets ReplicaSet today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
kubectl get replicasets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,OWNER:.metadata.ownerReferences[0].kindReviewing 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.