--- title: "What StatefulSet Identity Preserves for a Stateful AI Service" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/kubernetes-statefulset-instance-identity-pvc-retention" last-updated: "2026-10-20" --- # What StatefulSet Identity Preserves for a Stateful AI Service Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. A StatefulSet preserves a stable per-instance identity and its relationship to persistent claims across Pod replacement. Under the default Retain policy, claims also remain after scale-down. These relationships help an application find its instance's storage; they do not create copies of application data or establish recovered, readable and consistently served data. Compare the identity promise, the storage lifecycle and the required application result separately. ## Start with the state the service must preserve A buyer of a stateful support service for an enterprise AI platform needs to know what remains usable when a worker is replaced or the service becomes smaller. A retrieval index is a useful example: retaining an instance's storage relationship and keeping every required index partition available answer different needs. An offer that lists three StatefulSet replicas and persistent storage leaves that distinction unresolved. The Kubernetes API describes replicas as instances of the same Pod template with distinct identities. It does not describe three copies of every application's contents. The application determines what those instances store and how their data relates. This comparison uses the official archived Kubernetes v1.34 documentation, checked October 20, 2026. It explains the identity and storage lifecycle for a buyer. The worked service is fictional, and its settled transitions are stipulated comparisons rather than an operating procedure or observed cluster result. References: [ST1](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## The instance identity crosses a Pod's lifetime A StatefulSet associates each instance with an ordinal, stable network identity and stable storage. The hostname derives from the set name and ordinal. Its governing headless Service must be provided, and storage must be supplied through a suitable provisioner or administrator-provisioned volumes. For each claim-template entry, each instance receives a PersistentVolumeClaim, or PVC. The Pod object has a shorter lifetime. Kubernetes identifies it by a UID; a replacement may reuse its name but has a different UID. An individual UID is scheduled only once, rather than moving to another node. The stable instance relationship therefore spans distinct Pod objects. Follow that relationship beyond the name. A bound claim is associated with a PersistentVolume, or PV, describing the storage resource; the backing storage holds the application's contents. Keeping the name-to-claim relationship supplies a way to identify the intended store. It does not describe the validity of those contents. Stable network identity also does not mean an immutable Pod IP or immediate discovery. The official MySQL illustration accounts for a changed Pod IP, and the StatefulSet guide describes delays from cached failed DNS lookups. Name continuity, storage access and application response remain different observations. References: [ST1](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [ST2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/), [ST3](https://v1-34.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/), [ST4](https://v1-34.docs.kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## ST-AI112: replace ordinal 1 without creating a data copy Consider original fictional service ST-AI112, a retrieval-support component named retrieval. Use the default starting ordinal of zero and one claim template. Its three instance names are retrieval-0, retrieval-1 and retrieval-2. Call their claims C0, C1 and C2; these are explanatory labels, not a claim-naming specification. Stipulate that the governing headless Service exists, compatible storage has been supplied and the initial instances can access their respective volumes. C0's backing storage contains index partition I0, C1's contains I1 and C2's contains I2. The partitions differ. No application-level copies or replication are supplied by the premise. Now stipulate a successful, settled controller replacement of ordinal 1 after a node failure, with its existing claim retained. The old Pod UID U1 is gone and the replacement has UID U1-new. Its name remains retrieval-1, its ordinal remains 1 and its claim relationship remains C1. The StatefulSet documentation explicitly distinguishes this replacement event from the scale-down and StatefulSet-deletion policies. There are still three logical instance positions and three claims in this settled comparison. U1-new replaces U1; it adds neither a fourth logical member nor another copy of I1. The unchanged relationship tells the replacement which instance's store belongs to it. It does not supply an observation that I1 is readable or that the application has recovered useful state. That last step needs evidence from the storage and application owners: access to the required contents, application recovery and consistency, and safe single ownership. A retained C1 cannot establish remote availability. If its PV is local, the related local-volume guide explains the separate node-affinity and data-access decision. References: [ST1](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [ST2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## Shrink the same service and count what remains Make a separate comparison from ST-AI112's initial three-instance state. Stipulate a settled scale-down to two instances under the default Retain claim policy. Ordinals 0 and 1 remain as the desired instance positions, and the ordinal-2 Pod is absent. C0, C1 and C2 remain. Two desired running-instance slots and three retained claims are different populations. C2 is no longer accompanied by retrieval-2. Retaining that claim does not make I2 a third serving partition, and it has not independently created a backup of I2. It preserves the claim rather than moving or copying its contents into C0 or C1. For this fictional retrieval service, suppose the buyer requires queries to cover I0, I1 and I2. The two-instance count cannot establish that requirement after shrink. The premise provides neither redistribution of I2 nor another serving copy. This supports an evidence conclusion: full coverage is unestablished. It does not supply a measured query failure or prove that the stored bytes were lost. A provider might offer an application mechanism that preserves coverage while reducing instances. Its evidence would have to show where the required partitions are served and what state the application uses. Claim retention alone leaves that explanation open. The retained C2 also supplies no observation of a later successful scale-up. References: [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## Read claim retention and volume reclaim as two policies The optional StatefulSet claim-retention policy separates whenScaled from whenDeleted. In the supported v1.34 behavior, both default to Retain. A whenScaled policy of Delete instead removes claim-template PVCs associated with excess instances after their Pods are deleted. A whenDeleted policy of Delete concerns claim-template PVCs when the StatefulSet itself is deleted. These choices can differ. For ST-AI112, choosing the supported whenScaled Delete behavior would change the lifetime of C2 after shrink. A buyer who expects that claim to remain has a materially different requirement from one whose offer includes its removal. Neither choice changes the example's missing application-copy evidence. These lifecycle policies do not turn ordinary replacement after node failure into claim deletion. The next boundary is the PV reclaim policy. It governs the volume after release from its claim. PV Retain leaves a released volume with the previous data requiring separate disposition. For plugins supporting PV Delete, reclamation removes the PV object and backing storage asset. Actual behavior therefore depends on the volume policy and supported storage implementation as well as the claim lifecycle. The repeated policy names can obscure the distinction. StatefulSet Retain concerns keeping a claim through particular controller events; PV Retain concerns the released volume. A proposal needs to identify both before describing how long the instance's state remains recoverable. References: [ST1](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [ST3](https://v1-34.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## Application replication needs its own mechanism The official v1.34 replicated-MySQL tutorial makes the separation visible. It uses stable instance identities, but separately initializes application configuration, clones existing data for a new replica and starts MySQL replication. Kubernetes labels that illustration as a nonproduction configuration. Its value here is the division of responsibilities, rather than a database configuration to adopt. ST-AI112 deliberately supplies no equivalent copying mechanism. Three instances each holding a different partition are compatible with three StatefulSet replicas. Calling those instances replicas does not transform I0, I1 and I2 into three copies of a complete index. If an offer includes replicated, recoverable application data, connect that promise to the identified partitions and required state. Evidence should explain which copies exist, which are usable for the requested task and how the application establishes a consistent result after the named event. The related recovery-objectives guide develops the separate comparison between a required return condition and an observed recovery. References: [ST4](https://v1-34.docs.kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## Choose the identity, retention and application result you need An offer that preserves retrieval-1's name and C1 relationship answers the instance-identity question. An offer that keeps C2 after shrink answers an additional storage-lifetime question. An offer that keeps the complete retrieval task usable through the named event must also answer the application-state question. Compare those deliverables against the same required partitions and event. For replacement, the useful explanation connects U1-new to ordinal 1, C1, the backing volume and the application state actually recovered. For shrink, it explains both C2's disposition and where I2 is served if complete coverage is required. Controller and claim counts supply context for those explanations; they cannot substitute for them. Ask the appointed platform and storage owners to identify the offered Kubernetes version, identity mapping, provisioning support and two storage policies. The application owner supplies the separate contents, replication and recovery evidence. Keep any demonstrated result attached to its workload and conditions. The related Pod Disruption Budget guide addresses voluntary eviction constraints. Local-volume placement, endpoint handling and application recovery also have their own decisions. A stable instance identity can be useful without settling those wider service outcomes. References: [ST1](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [ST2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/), [ST3](https://v1-34.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/), [ST5](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) ## Scope any resulting equipment installation separately If the platform choice leads to a separately selected physical equipment package, Leviathan's Rack & Stack / Colocation service can cover agreed equipment mounting, IT cabling, labels and physical installation records. Use the related service and project inquiry to discuss that package with a nonconfidential equipment list, site, approved rack and connection requirements, and receiving team. Scope and availability are confirmed for the engagement. Kubernetes administration, storage integration and application operation remain with the appointed platform, storage and software owners. References: [L1](https://www.leviathansystems.co/services/rack-and-stack) ## Primary sources - [ST1 — Kubernetes v1.34 StatefulSets: identity, stable storage and claim retention](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/controllers/statefulset/). Checked 2026-10-20. Archived controller semantics, required Service and storage support, one claim per template entry per instance, DNS discovery limits and event-specific claim retention. - [ST2 — Kubernetes v1.34 Pod Lifecycle: Pod lifetime and fault recovery](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/). Checked 2026-10-20. Distinguishes a Pod's UID and one-time scheduling from a replacement object that may reuse its name. - [ST3 — Kubernetes v1.34 Persistent Volumes: lifecycle and reclaiming](https://v1-34.docs.kubernetes.io/docs/concepts/storage/persistent-volumes/). Checked 2026-10-20. PV/PVC storage relationships and the separate effects of Retain or supported Delete reclaim behavior after claim release. - [ST4 — Kubernetes v1.34 Run a Replicated Stateful Application](https://v1-34.docs.kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/). Checked 2026-10-20. The explicitly nonproduction MySQL illustration separates stable identity from application initialization, data cloning and replication, and accounts for changed Pod IPs. - [ST5 — Kubernetes v1.34 API reference: StatefulSet, apps/v1](https://v1-34.docs.kubernetes.io/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/). Checked 2026-10-20. Defines template replicas, network-to-claim mapping, default ordinals and the separate whenScaled and whenDeleted claim-retention fields. - [L1 — Leviathan Systems: Rack & Stack / Colocation](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Agreed physical equipment mounting, IT cabling, labels and installation records for a separately scoped equipment package. ## Related Leviathan resources - [Local PV node affinity and replacement data access](/articles/kubernetes-local-pv-node-affinity-pod-replacement) - [Pod Disruption Budgets and voluntary eviction limits](/articles/gpu-kubernetes-disruption-budget-voluntary-eviction) - [Recovery objectives and observed application return](/articles/ai-workload-recovery-objectives-versus-restore-observations) - [Rack & Stack / Colocation: a separate physical installation](/services/rack-and-stack) - [Discuss a physical equipment installation package](/contact?service=rack-and-stack&from=%2Farticles%2Fkubernetes-statefulset-instance-identity-pvc-retention) ## Discuss a separately selected physical equipment package Share a nonconfidential equipment list, site and approved rack or IT connection requirements to discuss installation scope, handoff records and availability. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/kubernetes-statefulset-instance-identity-pvc-retention)