Replication Controller Vs Replica Set

Assume you are running an application. The application is created by running a single Pod in the Kubernetes cluster. If the application crashes then the Pod will die. If the Pod dies then the user losses access to the application. This will create a big problem among the users. Users do not use the application which fails frequently.

So we need a controller to watch the Pod status. If the Pod fails then it has to recreate another Pod. This is can be done by Replication Controller or ReplicaSets. If the Pod is re-created, then the user will not lose access to the application. And Users will be happy and stay in the application for a long-time.

In Kubernetes, Replication Controllers and ReplicaSets ensure that a specific number of identical pods are always running in your cluster. They’re like babysitters for your pods, making sure you have just the right number of them — no more, no less. But there are some differences between the two, so let’s break them down with best example! 🌟

Replication Controller 🛡️

Think of the Replication Controller as an old-school alarm clock. It does its job well: keeps an eye on your pods and makes sure the desired number is always running. If one pod crashes, it replaces it. But it has fewer features and is a bit rigid compared to modern tools.

What it Does:

• Ensures the specified number of pods (e.g., 3) are running at all times.

• If a pod dies or goes offline, it creates a new one.

• If there are extra pods, it deletes the unnecessary ones.

Limitations:

• It uses simple matching to identify pods. This can be less flexible when managing complex applications.

Command to create RC:

kubectl create rc rc-name --image=image-name --replicas=no-of-replicas

Manifest File to create Replication Controller:

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp
spec:
  replicas: 3
  template:
     metadata:
       app: swiggy
       labels: 
         app: swiggy
     spec:
         containers:
           - name: cont-1
             image: shaikmustafa/dm
             containerPort: 80

NOTE: If we create RC, RC will create Pods, Pod has containers.

Here kind: ReplicationController because it tells K8s to create RC

metadata contains the name and labels of RC

The spec section had two keys( template and replicas ).

Mention the number of replicas you need using the replicas parameter. Here I mention 3 replicas. so this will create 3 pods automatically.

Templates are used to identify the pods for re-creation, if any of the pods are deleted

• To execute a file

kubectl create -f file-name

• To get replication controllers:

kubectl create rc

• To describe RC:

kubectl describe rc rc-name

• To scale-up pods:

kubectl scale rc rc_name --replicas 5

• To scale-down pods:

kubectl scale rc rc_name --replicas 1

• To delete RC:

 kubectl delete rc rc_name

IF WE DELETE RC, PODS ARE ALSO GETS DELETED, BUT IF WE DON’T WANT TO DELETE PODS, WE WANT TO DELETE ONLY RC THEN

kubectl delete rc rc_name --cascade=orphan

Now we deleted the RC but still pods are present, if we want to assign this pods to another RC use the same selector which we used on the RC last file.

ReplicaSet 🚀

The ReplicaSet is the upgraded version of the Replication Controller. Think of it as a smartphone alarm app. It does everything the old-school alarm clock does but with added flexibility and smarter features.

What it Does:

• Ensures the desired number of pods are running, just like the Replication Controller.

• Allows more advanced pod selection using label selectors. For example, you can fine-tune which pods to include in its group.

Why It’s Better:

• Supports complex selectors, making it easier to manage multi-component apps.

• It’s the modern standard and is often paired with Deployments in Kubernetes.

Command to create RS:

kubectl create rs rs-name --image=image-name --replicas=no-of-replicas

Manifest File to create ReplicaSet:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  matchLabels:
    name: zomato
spec:
  replicas: 3
  template:
     metadata:
       app: swiggy
       labels: 
         app: swiggy
     spec:
         containers:
           - name: cont-1
             image: shaikmustafa/mygame
             containerPort: 80

• To execute a file

kubectl create -f file-name

• To get replicaset:

kubectl create rs

• To describe RS:

kubectl describe rs rs-name

• To scale-up pods:

kubectl scale rs rs_name --replicas 5

• To scale-down pods:

kubectl scale rs rs_name --replicas 1

• To delete RS:

 kubectl delete rs rs_name

IF WE DELETE RS, PODS ARE ALSO GETS DELETED, BUT IF WE DON’T WANT TO DELETE PODS, WE WANT TO DELETE ONLY RS THEN

kubectl delete rs rs_name --cascade=orphan

Now we deleted the RS but still pods are present, if we want to assign this pods to another RS use the same selector which we used on the RS last file.

Key Differences Table 📝

Conclusion:

Using the Replication concept is highly recommended. ReplicaSets is a newer technology. So use the ReplicaSets instead of Replication Controller. ReplicaSets will help us to scale the application in an easy way. And will create a new instance of a Pod if the running Pod fails. This eases our work. At any point in time, the Kubernetes cluster always had mentioned the number of running Pods. Detecting failed instances and creating a new instance for the failed instance(Pod) is a cool feature. There is no need to monitor 24/7. And we can increase and decrease the instance(Pod) based on the traffic we receive. This is why I love the Kubernetes.

If you enjoy stories that help you learn, live, and work better, consider subscribing. If this article provided you with value, please support my work — only if you can afford it. You can also connect with me on Linkedin. Thank you!