Skip to main content

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.