Kubernetes Pod Replacement Semantics

Kubernetes Pod Replacement Semantics describe the rules governing how a Pod, once terminated or deleted, is or is not substituted with a new Pod object, and what identity relationship the replacement carries to the one it succeeds. Because Pods are immutable and non-restartable at the object level, replacement is never an in-place resurrection; it is always the creation of a brand-new Pod object with a new UID, and the specific semantics differ sharply depending on which controller owns the Pod.

Pods Are Never Truly Restarted

Container Restarts Versus Pod Replacement

It is a common misconception that a "restarted Pod" is the same object coming back to life. In reality, restartPolicy (Always, OnFailure, Never) governs container-level restarts performed by the kubelet within the same Pod object, incrementing restartCount. Pod replacement is a distinct, higher-level event: the entire Pod object is deleted and a new one, with a new name and UID, is created by a controller.

kubectl get pod web-7d4b9c8f6d-x2z9k -o jsonpath='{.metadata.uid}'

Replacement Under a ReplicaSet

Stateless, Interchangeable Identity

A ReplicaSet enforces a desired replica count without regard to which specific Pod fulfills it. When a Pod owned by a ReplicaSet is deleted, evicted, or its node fails, the ReplicaSet controller observes the discrepancy between desired and actual replica counts and creates a new Pod with a freshly generated name suffix, no persistent volume binding by default, and no memory of the previous Pod's identity.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: app
          image: registry.example.com/web:3.0.0

Replacement Under a StatefulSet

Preserved Ordinal Identity

A StatefulSet replaces Pods with strict identity preservation. When web-0 is deleted, the replacement Pod is also named web-0, receives the same PersistentVolumeClaim (if volumeClaimTemplates is used), and retains the same DNS entry under the headless Service, even though it is a distinct object with a new UID.

Ordered, Sequential Replacement

Unlike a ReplicaSet, which may create replacement Pods in parallel, a StatefulSet with the default OrderedReady pod management policy replaces Pods one at a time and waits for each replacement to become ready before proceeding to the next ordinal.

Replacement Under a DaemonSet

One-to-One With Nodes

A DaemonSet ties Pod identity to node identity rather than to an ordinal or replica slot. If a DaemonSet Pod is deleted, the controller creates exactly one replacement Pod scheduled to the same node, since the DaemonSet's invariant is "one Pod per matching node," not a numeric replica count.

Replacement Under a Job

Completion-Bounded Replacement

A Job replaces failed Pods up to a bound defined by backoffLimit, attempting the work again until either the required number of successful completions is reached or the failure limit is exceeded, at which point the Job itself is marked Failed and stops creating replacements.

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-task
spec:
  backoffLimit: 4
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: worker
          image: registry.example.com/worker:1.0.0

Standalone Pods Have No Replacement

A Pod created directly, without an owning controller, is never replaced. If it is deleted or its node fails, no new Pod is created to take its place, since there is no controller reconciling a desired state against it.

Replacement Semantics Comparison

Across every controller type, one invariant holds: the replacement is always a new API object with a new UID, and only the surrounding metadata (name, node placement, volume binding) is preserved or regenerated according to that controller's specific replacement policy.