An operator force deletes a stuck StatefulSet pod during an incident and later the replacement remains Pending with attach-related events.
A StatefulSet pod stays Pending after force deletion because the old VolumeAttachment object outlives the node and keeps the replacement attach blocked
The dead pod is gone, yet the replacement never mounts because attachment state from the prior node still claims the volume.
Scenario
What to check first
- Identify the primary failure signal in the The Pod Disappeared but the Attachment Lock Did Not scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Inspect orphaned attachment objects and controller state before deleting PVCs or storage classes.
Questions worth viewing together
Community-field Kubernetes problem inspired by community storage incidents where stale VolumeAttachment objects blocked replacement pods. Volume lifecycle state can outlive the pod that originally held it.
Teams often blame the new node when a stale attachment object is still pinning the old state.
Force deletion is not the end of the storage story for StatefulSets.
Similar cases seen in the field