ReplicaSets act as wrappers around Pods that lets you manage the number of Pods you want to run at a point in time. K8s claims high availability and fault tolerance, and having multiple pods running helps to achieve this. The responsibility of the ReplicaSet is to ensure Kubernetes is running the configured number of Pods.

Even though ReplicaSets are important but you will seldom need to create or manage them directly. Deployments will manage ReplicaSets for you. You would only need to deal with them when you are troubleshooting unexpected problems. Let’s dive deeper to know what exactly are ReplicaSets and the way they work.

What Are ReplicaSets?

A ReplicaSet can be explained as one of the Kubernetes controllers that ensures that we have a specified number of pod replicas running. A controller in Kubernetes is responsible to take care of tasks to ensure the desired state of the cluster matches the observed state.

Without RS, we will have to create multiple manifests for the number of pods we need which is too much work to deploy replicas of a single application. In the earlier versions of Kubernetes, the ReplicaSet was known as Replication Controller. The major difference between the two is that ReplicaSets allow us to use something called Label Selector.

Labels are defined as the key-value pair which are used to specify attributes of objects that are meaningful and useful to users, therefore it does not change the way the core system works. Label Selectors are helpful in identifying a set of objects in Kubernetes.

Kinds Of Operators To Use With ReplicaSets

Three kinds of operators that we can use with ReplicaSets:
a) In
b) Notin
c) Exists

ReplicaSets manages all the pods with labels that match the selector. When pods are created, it does not differentiate between all pods so if you create another ReplicaSets with the same label selector, the former ReplicaSets will think it created those pods, hence causing issues.

Hence, it is important to ensure that label selectors do not match from one ReplicaSets to another.

How Does The ReplicaSet Manifest Look?

APIVersion, kind, and Metadata look like any other object in Kubernetes but the Spec section appear somewhat different from other objects. If you look at the above example there are two Spec’s in the manifest above. The first Spec lets you declare what the ReplicaSet should appear like and the second spec is for containers. “.spec.template” is the only essential field of the first spec section. If you do not specify replicas, it will deploy just one pod. Here, take notice that the “.spec.template.metadata.labels” must resemble exactly what you have in the “.spec.selector” or K8s will not permit it to be created.

apiVersion: apps/v1 # our API version
kind: ReplicaSet   # The kind we are creating
Metadata: # Specify all Metadata like name, labels
  name: some-name
  labels:
    app: some-App
    tier: some-Tier
Spec: 
  replicas: 3 # Here is where we tell k8s how many replicas we want
  Selector: # This is our label selector field. 
    matchLabels:
      tier: some-Tier
    matchExpressions:
      - {key: tier, operator: In, values: [some-Tier]} # we are using the set-based operators
  template:
    metadata:
      labels:
        app: some-App
        tier: someTier
    Spec: # This spec section should look like spec in a pod definition
      Containers:

An Example Of ReplicaSet

Now that you have understood what a ReplicaSet is, it is time you create one for yourself. In this case, we will deploy our replica.yaml file which will create a basic frontend nginx app with 3 replicas.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicas
  labels:
    app: myapp
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: myapp
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Firstly, to apply our manifest we will run kubectl create command.

$ kubectl create -f replica.yaml
replicaset.apps "myapp-replicas" created

Next, you have to ensure it is created.

$ kubectl get replicaset
NAME                            DESIRED   CURRENT   READY     AGE
myapp-replicas                  3         3         3         15s

We observe that 3 are deployed and 3 are ready. We can also mark a check on the pods as well.

$ kubectl get pod
NAME                            READY     STATUS    RESTARTS   AGE
myapp-replicas-67rkp            1/1       Running   0          33s
myapp-replicas-6kfd8            1/1       Running   0          33s
myapp-replicas-s96sg            1/1       Running   0          33s

Here, we see that all 3 are running with 0 restarts which implies that our application is not crashing. We can also describe the object which will provide us more details about our replicas.

$ kubectl describe replicaset myapp-replicas
Name:         myapp-replicas
Namespace:    default
Selector:     tier=frontend,tier in (frontend)
Labels:       app=myapp
              tier=frontend
Annotations:  
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=myapp
           tier=frontend
  Containers:
   nginx:
    Image:        nginx
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  
    Mounts:       
  Volumes:        
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: myapp-replicas-6kfd8
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: myapp-replicas-67rkp
  Normal  SuccessfulCreate  12m   replicaset-controller  Created pod: myapp-replicas-s96sg

What If We Need One Replica Instead Of Three?

In such a scenario all we have to do is change the replica field to the value we wish and k8s will scale it to that number. For example, “replicas: 1”. If we make the desired change and re-apply, we will only have one replica running.

Can The Pod Be Removed From A ReplicaSets?

Yes, the pod can be removed from a replicaSets. It is simple like removing the label from the pod and it will automatically be removed from the Set.

How Can You Clean Up RS?

To remove ReplicaSet, you need to run “kubectl delete ReplicaSet myapp-Replicas”. This command will clean up RS and the pods.

Final Words

Generally, Kubernetes recommend that we use deployment(a higher-level concept that manages ReplicaSets and provides declarative updates to pods along with a lot of other useful features) controller instead of ReplicaSets.

Team IdeaClan

Team IdeaClan

A martech company with 10+ years in the market that is engaging technology and media buying skills to transform the face of digital marketing

Leave a Reply