StatefulSet
Does ZopNight manage StatefulSet?
StatefulSets pin 2 meters at once: pod requests reserve node capacity, and each volumeClaimTemplate provisions a per-replica disk that survives scale-down. ZopNight records podManagementPolicy, updateStrategy, serviceName, and the claim templates, marks 0 replicas stopped and ready-below-desired degraded, and applies a 15-minute settle window before calling a rollout stuck.
Rules that fire on StatefulSet
A StatefulSet runs pods with stable identities and per-pod persistent volumes. That is the shape databases, queues, and anything with local state take in Kubernetes. It holds cost on two fronts at once, and the two fronts behave differently when you scale down.
Two meters: compute now, storage forever
Pod requests reserve node capacity exactly as a Deployment’s do, but every entry in volumeClaimTemplates also provisions one PVC (and one cloud disk) per replica. Scale from 5 replicas to 0 and the compute reservation ends while all 5 disks keep billing, because StatefulSet PVCs are deliberately not deleted with their pods. Discovery captures the claim templates for precisely this reason: they are the map from a StatefulSet to the storage it will strand.
Ordered startup changes what degraded means
With the default OrderedReady pod management policy, pods start sequentially, with pod 1 waiting for pod 0 to be ready, so a StatefulSet takes genuinely longer to settle than a Deployment. The Not Fully Ready rule (RC-1715 / RC-1815 / RC-1915, high severity) accounts for that: it only fires when ready replicas trail desired after the rollout is complete per currentReplicas, and it suppresses itself for 15 minutes after any tracked start, restart, or scale transition.
What discovery keeps for stateful workloads
Beyond the shared container detail of requests, limits, images, and probes, the record includes podManagementPolicy, updateStrategy, the governing serviceName, current and updated replica counts, selector, and topology spread constraints. Status derivation matches the Deployment convention: 0 replicas is stopped, ready below desired is degraded, otherwise running.
kubectl get statefulsets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,READY:.status.readyReplicas,CURRENT:.status.currentReplicasZero replicas is not zero cost
Namespace schedules scale StatefulSets to 0 during off-hours and restore them on resume, and that is the right lever for the compute half. The storage half needs its own review: PVCs left by scaled-down or deleted StatefulSets are the classic Kubernetes orphan, and they only stop billing when someone deletes the claims and the reclaim policy lets the disks go.