Pods, ReplicaSets and Deployments: ownership and rollout behavior
Explain who replaces a deleted Pod, why a Deployment creates a new ReplicaSet, and how surge, readiness and termination affect a rollout. Includes a worked three-replica example.
TL;DR: A Pod is a scheduled execution unit. A ReplicaSet maintains a desired number of matching Pods. A Deployment manages ReplicaSets to roll a Pod template from one revision to another. Container restarts, Pod replacement and Deployment rollback operate at different levels.
Ownership explains what comes back
Deleting a Pod owned by a ReplicaSet usually causes a replacement Pod to be created because the desired replica count has not changed. The replacement has a new identity and may receive a different IP address. Deleting an unmanaged Pod has no such controller guarantee.
A container can restart inside the same Pod under its restart policy while the Pod's identity remains unchanged. That distinction matters when interpreting a high restart count. The process may be repeatedly crashing within one Pod, or the workload may be repeatedly creating entirely new Pods. Those patterns suggest different causes and preserve different local evidence.
Kubernetes documents Pods as relatively ephemeral units. Build application discovery around Services and appropriate durable state, rather than hard-coding one Pod's address.
This illustrative rollout shows old and new Pods coexisting. Containers in a Pod share a network context, while volumes are shared only where configured. A Pod is therefore a meaningful placement and lifecycle boundary, rather than a synonym for one container.
What creates a Deployment revision
Changing the Deployment's Pod template triggers a rollout and a new ReplicaSet revision. Scaling the replica count alone changes capacity without creating a new Pod-template revision. A rollout history consequently represents template changes, not every event that happened to the workload.
Use the Deployment documentation to check exact update and rollback behavior for your cluster. A rollback restores an earlier Pod template. External database writes, mutable configuration sources and side effects remain separate concerns.
Work a three-replica rollout
Assume replicas: 3, maxSurge: 1 and maxUnavailable: 0. The controller can add a new replica while preserving the desired number of available replicas. Once the new Pod becomes available under the configured readiness and availability criteria, it can reduce the old ReplicaSet and repeat.
| Condition | Expected consequence | Operational decision |
|---|---|---|
| No capacity for the extra replica | New Pod may remain Pending | Provide headroom or review the update strategy |
| New Pod never becomes ready | Progress can stall while old Pods remain | Diagnose startup and dependencies before forcing replacement |
| Readiness becomes true too early | Old capacity may be removed before the new Pod serves correctly | Fix the readiness contract and verify real requests |
| Old Pod drains slowly | Terminating processes can overlap longer | Budget resources and align connection draining with grace periods |
Treat surge as a rollout constraint, not a perfect upper bound on every live process at every instant. Terminating Pods may still consume resources during their grace period. Plan for that overlap when the cluster runs close to capacity.
Readiness controls eligibility, not correctness by itself
A readiness check should establish whether the Pod can accept the kind of traffic the Service will send. A check that only verifies the process exists can pass before initialization is complete. A check that depends on every optional downstream service can remove all replicas during a shared dependency incident.
Choose the contract deliberately. For an API that can serve cached reads while an optional recommendation service is unavailable, readiness need not require that recommendation service. For a writer that cannot safely accept requests before loading required keys, readiness should remain false until those keys are usable.
Liveness answers a different question: whether restarting the container is appropriate. Restarting every replica during a downstream outage can worsen the incident. Separate these checks and validate their failure behavior under load.
Inspect the controller chain
The following commands are read-only and assume a checkout Deployment in namespace shop. Adjust the names for a lab cluster.
kubectl -n shop get deployment checkout
kubectl -n shop get replicasets -l app=checkout
kubectl -n shop get pods -l app=checkout -o wide
kubectl -n shop describe deployment checkout
kubectl -n shop get events --sort-by=.metadata.creationTimestamp
Selectors and labels must correspond to the workload you are investigating. For a specific Pod, inspect its owner references to identify the ReplicaSet, then that ReplicaSet's owner. Events can expire, so capture relevant evidence while it exists and connect it with controller and application logs.
When a replica needs a stable ordinal and storage association, examine StatefulSets. Database replication and fencing still belong to the application design.
Check the replacement model
A Pod is deleted during a deployment. Its replacement starts, but files written to the old container filesystem are gone. Has the Deployment controller failed?
No. It restored the desired execution capacity, not arbitrary container-local data. Decide whether that data is disposable, reconstructible or requires an appropriate persistent storage design. A persistent volume adds its own attachment and consistency constraints; it does not make any application automatically safe to replicate.
Practice diagnosing a Service with healthy Pods next. The ownership chain can be healthy while the request path is still broken.