Understand the difference between Deployments and ReplicaSet.

4 min readMar 8, 2023

Rolling apps to any environment such as production, UAT, and SIT have become trouble-free with the help of Kubernetes. However, to use Kubernetes more efficiently we need to know how to handle Kubernetes Pods properly. Therefore, Deployments and ReplicaSet are being used to manage Pods.

I am going to start explaining from ReplicaSet first.

ReplicaSet is a Kubernetes object that maintains the stability of Pods, it guarantees the availability of Pods depending on the replica number provided by a config file. To fulfill its purpose, it can delete or add new Pods to meet the desired number.

It acquires new Pods by matching its selector. If a pod has no OwnerReference and it matches to ReplicaSet’s selector, it will be automatically consumed by that ReplicaSet.

To create a ReplicatSet, we can write the following example. I am going to call it rs.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: backend
  labels:
    app: test-app
    tier: backend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
        - name: node-app
          image: 10.80.80.148:5000/node-app:0.0.1
          ports:
            - containerPort: 3000

I’ve created a new ReplicaSet with the number of replicas of 3 and created a selector for tier=backend .

Then, copy and apply it to our Kubernetes cluster.

kubectl apply -f rs.yml

Now, we will be seeing a new start of ReplicaSet, along with 3 pods of our node app.

Run kubectl get rs to list ReplicaSet. Please note that all Kubernetes objects that are created without specifying a namespace will be put under a default namespace.

Run kubectl get pod to list pod available.

However, I would like to produce a case where a new standalone Pod is created without OwnerReference and matched label to our existing ReplicaSet. In our case, the selector is tier=backend, so I will make a file called pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: backend
spec:
  containers:
    - name: hello1
      image: 10.80.80.148:5000/node-app:0.0.14
      ports:
        - containerPort: 3000

Then, I copy and apply it to our cluster by running a command.

kubectl apply -f pod.yml

Frankly after running a command kubectl get pod, I got the result as follows. It showed that the pod is terminating and the reason for this is that the pod was acquired by our ReplicaSet where desired replicas number is 3. At the same time, we already have 3 running backend pods, and plus the one that we created, it is going to be over a limited number of our ReplicaSet, so it will be automatically removed.

After we’ve studied about ReplicaSet, let's move on to Deployments.

Deployments are also another Kubernetes component that provides a higher-level concept of managing ReplicaSet and Pods. You can use Deployment to create ReplicaSet or replace existing Deployment with new resources. Moreover, It offers useful features for example: Rolling back an earlier version of the Deployment, cleaning up older ReplicaSets where you don't need them anymore, and so on. It has also been recommended to use Deployments over ReplicaSet.

To construct Deployment, I am going to create a new file called dp.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
  labels:
    app: test-app
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: backend
  template:
    metadata:
      labels:
        tier: backend
    spec:
      containers:
        - name: node-app
          image: 10.80.80.148:5000/node-app:0.0.14
          ports:
            - containerPort: 3000