ReplicaSet
A ReplicaSet's purpose is to maintain a definite number of replica Pods running at any given time.
Usually, we define a Deployment and let that Deployment manages the ReplicaSet.
It is recommended to use Deployment instead unless your requirement is otherwise.
However, we will just briefly learn about the ReplicaSet. Below is an example ReplicaSet manifest.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend-rs
labels:
app: employee-handbook
tier: frontend
spec:
replicas: 2
selector:
matchLabels:
tier: frontend-pod
template:
metadata:
labels:
tier: frontend-pod
spec:
containers:
- name: php-redis
image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5
A typical ReplicaSet manifest's spec contains below important fields:
replicas: Number of desired Pods.selector: A label that specifies how to identify Pods it needs to manage. If empty, it defaults to the labels present on the Pod template. In this example, both the RelicaSet selector and the Pod's label match, i.e.frontend-pod
Save this manifest as frontend-rs.yaml and create or apply it.
kubectl apply -f frontend-rs.yaml
Check the deployed ReplicaSets.
kubectl get rs
vagrant@vagrant:~$ kubectl get rs NAME DESIRED CURRENT READY AGE frontend-rs 2 2 2 7m59s
Check the Pods in the ReplicaSet:
kubectl get pods
vagrant@vagrant:~$ kubectl get pods NAME READY STATUS RESTARTS AGE frontend-rs-jw7qf 1/1 Running 0 11m frontend-rs-s7g6g 1/1 Running 0 11m
How does a ReplicaSet manages its Pods
A ReplicaSet is linked to its Pods via the Pods' metadata.ownerReferences field,
which specifies what resource the current object is owned by.
We can get all the fields of an object using the -o yaml option.
For one of our ReplicaSet Pods, we can check the owner by using the below command.
kubectl get pod frontend-rs-jw7qf -o yaml
vagrant@vagrant:~$ kubectl get pod frontend-rs-jw7qf -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2026-07-10T04:05:59Z"
generateName: frontend-rs-
generation: 1
labels:
tier: frontend-pod
name: frontend-rs-jw7qf
namespace: default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: frontend-rs
uid: 245bb73e-18a3-4059-afa8-8d919936c27d
resourceVersion: "7291"
uid: 114c8b68-5718-492f-afac-108d40ec1679
...
If we observe the Pod object, we have metadata.ownerReferences which is pointing to the frontend-rs ReplicaSet,
uid: 245bb73e-18a3-4059-afa8-8d919936c27d.
Let's check the unique ID of the ReplicaSet.
kubectl get rs frontend-rs -o yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration:
...
creationTimestamp: "2026-07-10T04:05:59Z"
generation: 1
labels:
app: employee-handbook
tier: frontend
name: frontend-rs
namespace: default
resourceVersion: "7292"
uid: 245bb73e-18a3-4059-afa8-8d919936c27d
...
ReplicaSet with other Pods
We learnt that a ReplicaSet identifies the Pods it needs to manage using its selector.
What if an outside Pod has a label that matches a ReplicaSet selector?
It will be acquired by the matching ReplicaSet.
Let's create a separate Pod with the label frontend-pod which
matches the ReplicaSet's selector.
apiVersion: v1
kind: Pod
metadata:
name: example-pod
labels:
tier: frontend-pod
spec:
containers:
- name: hello-container
image: gcr.io/google-samples/hello-app:2.0
kubectl apply -f pod.yaml
Immediately or parallelly after creating the Pod, watch the status of the Pods:
kubectl get pods -w
- -w: Watch the output of a kubectl command
vagrant@vagrant:~$ kubectl get pods -w NAME READY STATUS RESTARTS AGE frontend-rs-cw8p2 1/1 Running 0 9m52s frontend-rs-svzcm 1/1 Running 0 9m52s example-pod 0/1 Pending 0 0s example-pod 0/1 Pending 0 0s example-pod 0/1 Pending 0 0s example-pod 0/1 Terminating 0 0s example-pod 0/1 Terminating 0 1s example-pod 0/1 Terminating 0 2s example-pod 0/1 ContainerStatusUnknown 0 3s example-pod 0/1 ContainerStatusUnknown 0 3s example-pod 0/1 ContainerStatusUnknown 0 3s
Kubernetes tried to create the Pod which was terminated immediately. Because, in the backend the ReplicaSet identified that this Pod has the matching label and acquired it. And since the ReplicaSet already has 2 Pods running as per the desired state, it terminated the newly created example-pod.