Maintains a stable set of replica Pods running at any given time. Uses label selectors to identify which Pods to manage. Created and owned by Deployment.
Level 3: Pods (Managed by ReplicaSet)
P
nginx-...-7ci7o
Pod
Status: Running IP: 10.244.1.5 Node: worker-1
app: nginx
pod-template-hash: 75675f5897
Pod 1
Running nginx container. If this Pod is deleted, the ReplicaSet immediately creates a replacement to maintain desired count.
P
nginx-...-a1b2c
Pod
Status: Running IP: 10.244.2.8 Node: worker-2
app: nginx
pod-template-hash: 75675f5897
Pod 2
Running nginx container. Managed by ReplicaSet, which ensures this Pod is healthy and running.
P
nginx-...-d3e4f
Pod
Status: Running IP: 10.244.1.9 Node: worker-1
app: nginx
pod-template-hash: 75675f5897
Pod 3
Running nginx container. Part of the replica set maintaining 3 desired replicas.
Key Concept: The Deployment owns the ReplicaSet, and the ReplicaSet owns the Pods. This ownership is tracked via metadata.ownerReferences field, enabling cascading deletion and proper lifecycle management.
Creation Flow: From kubectl to Running Pods
1
User Creates Deployment
kubectl apply -f deployment.yaml
You define the desired state: 3 nginx Pods with specific container image and configuration.
2
API Server Validates and Stores
The API Server validates the Deployment spec, authenticates the request, and stores the desired state in etcd. The Deployment object now exists in the cluster.
3
Deployment Controller Creates ReplicaSet
The Deployment Controller watches for new Deployment objects. It creates a ReplicaSet with name format: [deployment-name]-[hash]. The hash is derived from the Pod template to enable version tracking.
4
ReplicaSet Controller Creates Pods
The ReplicaSet Controller sees the new ReplicaSet and creates 3 Pod objects (matching the replicas: 3 spec). Each Pod gets a unique name with the ReplicaSet prefix plus a random suffix.
5
Scheduler Assigns Pods to Nodes
The Scheduler watches for unscheduled Pods and assigns each to an optimal worker node based on resource availability, affinity rules, taints, and tolerations.
6
Kubelet Starts Containers
The Kubelet on each node sees Pods assigned to it, pulls the nginx container image, and instructs the container runtime (containerd/CRI-O) to start the containers.
7
Continuous Reconciliation
All controllers continuously watch the cluster state. If a Pod dies, the ReplicaSet Controller creates a new one. If you update the Deployment, it creates a new ReplicaSet and gradually transitions Pods.
Important: This entire process is declarative. You declare what you want (3 nginx Pods), and Kubernetes controllers work continuously to make it happen and keep it that way.
How Label Selectors Connect the Hierarchy
Deployment Selector
spec.selector.matchLabels:
app: nginx
Deployment uses this to find its ReplicaSets and Pods
# Deployment specifies what labels to matchspec:selector:matchLabels:app:nginx# Must match Pod template labelstemplate:metadata:labels:app:nginx# These labels are applied to Pods
The pod-template-hash Label
Kubernetes automatically adds a pod-template-hash label to distinguish Pods from different versions during rolling updates.
Old ReplicaSet (v1)
app: nginx
pod-template-hash: 75675f5897
vs
New ReplicaSet (v2)
app: nginx
pod-template-hash: 8f9d6c4b21
Why This Matters: The pod-template-hash ensures that Pods from different ReplicaSets don't conflict during rolling updates. Each ReplicaSet manages only its own version of Pods.
Ownership References
Besides labels, Kubernetes uses ownerReferences to track the ownership chain:
Pod's ownerReferences Field
metadata:ownerReferences:
- apiVersion:apps/v1kind:ReplicaSetname:nginx-deployment-75675f5897uid:e129deca-f864-481b-bb16-b27abfd92292controller:true# This ReplicaSet is the controllerblockOwnerDeletion:true# Prevents deleting owner if dependents exist
Complete YAML Examples
1. Deployment YAML
apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:3# Desired number of Podsselector:matchLabels:app:nginx# Must match template.metadata.labelstemplate:# Pod template - used by ReplicaSet to create Podsmetadata:labels:app:nginx# Labels applied to each Podspec:containers:
- name:nginximage:nginx:1.14.2ports:
- containerPort:80
Notice: Only the Deployment YAML is created by users. The ReplicaSet and Pod YAMLs are automatically generated by Kubernetes controllers, with ownership references and template hashes added automatically.
Best Practice: Always manage your application through the Deployment. Don't manually edit ReplicaSets or delete individual Pods (except for troubleshooting). The Deployment controller ensures proper rolling updates and rollback capabilities.
Rolling Update Behavior
When you update the Deployment (e.g., change container image), a controlled rollout occurs:
Rolling Update Process
# Update the container image
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
# What happens behind the scenes:# 1. New ReplicaSet created: nginx-deployment-8f9d6c4b21# 2. Old ReplicaSet scaled down gradually: 3 → 2 → 1 → 0# 3. New ReplicaSet scaled up gradually: 0 → 1 → 2 → 3# 4. Old ReplicaSet kept (scaled to 0) for rollback capability# During the update:
kubectl get replicasets
# NAME DESIRED CURRENT READY# nginx-deployment-75675f5897 1 1 1 # Old# nginx-deployment-8f9d6c4b21 2 2 2 # New