Track Kubernetes Pod identity separately from container restarts

A familiar Pod name does not prove that the original Pod or its local state survived.

Source facts

Kubernetes assigns each Pod a UID. A container can restart within that Pod, but a Pod is not moved to another node. Replacement creates a different Pod with a different UID, even when its name matches the old one. Kubernetes does not guarantee replacement on the original node. Resources tied to a particular Pod lifetime are recreated with its replacement.

Source: Kubernetes documentation — Pod Lifecycle.

Applicability

Review Pod identity, node assignment and Pod-lifetime resources when investigating replacement.

DSE recommendation

DSE recommends recording the Pod UID, node, owning controller, and container restart count when investigating an interruption. Decide whether the recovery procedure expects an in-place process restart or complete workload replacement. Keep indispensable state outside resources whose lifetime is tied to one Pod. Give the incident record a timeline that distinguishes container failures from deletion and recreation; otherwise a stable display name can hide the important transition. Assign the application owner responsibility for defining which state can be regenerated.

Verification

In a disposable workload, compare identity and restart count after a container failure and after Pod replacement. Check the relevant storage independently, then confirm that monitoring identifies the two events differently. These are proposed checks, not a report of a production test. Retain both old and new UIDs in the exercise record, and ask the incident reviewer to reconstruct the sequence without relying on a Pod name alone.

Official reference

Kubernetes documentation — Pod Lifecycle. Reviewed October 20, 2026.