A StatefulSet recovers onto new infrastructure and later only one member fails readiness with a bootstrap or identity mismatch.
A StatefulSet pod comes up and fails readiness
Storage is attached correctly, yet startup gates fail because one bootstrap artifact still assumes the previous identity layout.
Scenario
What to check first
- Identify the primary failure signal in the The Data Moved Correctly and One Bootstrap File Still Belonged to the Old Identity 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
Compare persistent bootstrap artifacts with the current ordinal and hostname assumptions before recreating the PVC.
Questions worth viewing together
Community-field Kubernetes problem inspired by StatefulSet recovery discussions where init containers still relied on an old ordinal-specific bootstrap... Stateful recovery can fail on identity artifacts even when the raw data volume is fine.
Teams often blame the storage class when the init logic is still reading an old identity marker.
Stateful bootstrap logic should be reviewed for ordinal and hostname persistence assumptions during recovery.
Similar cases seen in the field