Survive Pod Replacement
A Pod rollout replaces the process that holds your local cache. Decide what may disappear before you depend on a rolling update to preserve state.
| State | Recovery plan |
|---|---|
| Rebuildable cache entries | Refill from the application’s source of truth |
| Keys held by surviving subscribers | Retrieve from a surviving holder; verify that one exists |
| State uploaded to Cloud | Rehydrate from the network tier after upload acknowledgement |
| Commercial Atmos deployment | Follow its separately supplied storage and recovery guidance |
A second Pod may not hold the key you need. The operator’s health probes cannot establish that it does.
- Confirm the application handles missing keys and reconnects to its sidecar.
- For durable state, confirm it has reached the configured storage tier. A command reply alone does not prove a Cloud upload completed.
- Replace a Pod in a staging workload and verify both known keys and application behavior.
- Check cold-read latency and load on the source of truth before replacing more Pods.
Use Kubernetes operations for profile and Secret changes. Read Cloud durability semantics before a full-cluster restart.