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

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

---

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

```bash
kubectl get statefulsets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas,READY:.status.readyReplicas,CURRENT:.status.currentReplicas
```

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