Kubernetes Pod Replacement Lifecycle

Kubernetes Pod Replacement Lifecycle is the temporal sequence a controller follows when it detects that a Pod it owns is missing, unhealthy, or scheduled for retirement, and proceeds to create a substitute. Where Pod replacement semantics describe the identity rules governing what a replacement looks like, this lifecycle describes the procedural steps and timing, detection, decision, creation, and convergence, that a controller's reconciliation loop actually executes to carry replacement out.

Detection Through Reconciliation

Continuous Desired-State Comparison

Every controller responsible for Pod replacement, ReplicaSet, StatefulSet, DaemonSet, Job, runs a reconciliation loop that continuously compares the number and identity of Pods it currently observes against the number and identity it expects. A gap between desired and observed state is what triggers the replacement lifecycle to begin.

kubectl get replicaset web -o jsonpath='{.status.replicas}/{.spec.replicas}'

Triggering Events

Detection can be triggered by a Pod deletion, a node failure surfaced through missed kubelet heartbeats, a failed container exceeding retry limits under restartPolicy: Never, or an explicit scale-down followed by a scale-up.

Deciding Replacement Order

Delete-Then-Create Versus Create-Then-Delete

Different controllers order the two halves of replacement differently. A ReplicaSet, upon detecting a missing Pod, simply creates a new one without any coordination with a deletion, since deletion already happened. A rolling update on a Deployment, by contrast, actively sequences creation and deletion of multiple Pods according to maxSurge and maxUnavailable to control how much capacity is available at each moment.

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

With maxUnavailable: 0, the lifecycle mandates create-before-delete: a new Pod must reach Ready before its predecessor is removed.

Respecting Disruption Budgets

PodDisruptionBudget as a Brake

Voluntary replacement, triggered by rollouts, node drains, or manual scaling, is checked against any applicable PodDisruptionBudget before an old Pod is removed. If removing a Pod would violate minAvailable or maxUnavailable, the replacement lifecycle pauses that particular removal until capacity allows it, without abandoning the overall replacement goal.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Creation and Convergence

New Pod Enters Its Own Startup Lifecycle

Once the controller decides to create a replacement, that new Pod begins its own independent creation lifecycle, admission, scheduling, sandbox setup, container startup, entirely separate from whatever caused the original Pod's departure. The replacement lifecycle at the controller level is complete once the new Pod is observed and the desired-versus-actual count reconciles.

kubectl rollout status deployment/web

Retry on Failed Replacement Attempts

If a replacement Pod itself fails to schedule or start, the controller does not give up; it remains in a continuous reconciliation loop, retrying creation (subject to backoff for repeatedly failing attempts) until the desired state is achieved or an operator intervenes.

Replacement Lifecycle Diagram

This lifecycle repeats continuously for the life of the owning controller, meaning replacement is never a one-time event but an ongoing reconciliation process that reacts to any future deviation just as readily as it did to the first.