ReplicationController & ReplicaSet in Kubernetes

Kubernetes controllers are the brains behind Kubernetes. They are the processes that monitor Kubernetes’s objects and respond accordingly. One of the controllers is replicaSets

It is important to know that there are two similar terms replication controllers and replicaSets. Both have the same purpose but they are not the same replication controller is the older technology that is being replaced by replicaSets. ReplicaSets is the new recommended way to set up replication.

Why do we need ReplicationController or ReplicaSet?

To prevent users from losing access to our application.

Imagine we had a single pod running our application. What if for some reason our application crashes and the pod fails users will no longer be able to access our application. We would like to have more than one instance or pod running at the same time. That way if one failed we still have our application running on the other one. The ReplicationController or ReplicaSet helps us run multiple instances of a single pod in the Kubernetes cluster This providing high availability. So, does that mean you can not use a replication controller if you plan to have a single pod? No. Even if you have a single pod the replication controller can help by automatically bringing up a new pod when the existing one fails does the replication controller ensures that the specified number of pods are running at all times even if it is just one.

ReplicationController(ReplicaSet) for preventing users from losing access

2. To create multiple pods to share the load across them.

if the demand is increased and if we were to run out of resources on the first node we could deploy additional pods across the other nodes in the cluster. As you can see the replication controller spans across multiple nodes in the cluster. It helps us balance the load across multiple pods on different nodes as well as scale our application when the demand increases.

ReplicationController

Any Kubernetes definition files have apiVersion, kind, metadata, and spec.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-replication-controller
  labels:
    app: nginx
spec:
  replicas: 3
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx
          ports:
          - containerPort: 80
            protocol: TCP

Create ReplicationController and Pods by the ReplicationController

$ kubectl create -f nginx-replication-controller.yaml
replicationcontroller/nginx-replication-controller created
$ kubectl get pods --watch
NAME             READY   STATUS              RESTARTS   AGE
apple-rc-2wc9q   0/1     ContainerCreating   0          7s
apple-rc-bzz9v   0/1     ContainerCreating   0          7s
apple-rc-pnzjh   0/1     ContainerCreating   0          7s
apple-rc-pnzjh   1/1     Running             0          8s
apple-rc-2wc9q   1/1     Running             0          13s
apple-rc-bzz9v   1/1     Running             0          18s

Get ReplicationController information and see the pods that were created by the ReplicationController.

$ kubectl get replicationcontroller
NAME                           DESIRED   CURRENT   READY   AGE
nginx-replication-controller   3         3         3       20m
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replication-controller-547bw   1/1     Running   0          42s
nginx-replication-controller-64vjz   1/1     Running   0          42s
nginx-replication-controller-smq5x   1/1     Running   0          42s

The pod is created by replication controller.

ReplicaSet

ReplicaSet requires selector definition. The selector section helps the ReplicaSet identify what pod for under it. ReplicaSet can also manage pods that were not created as pods of the replica at creation. For example, the pods created before the creation of the ReplicaSet that match labels specified in the selector. The replica set will also take those pods into consideration when creating the replicas. The selector is one of the major differences between ReplicationController and ReplicaSet. The selector is not a required field in the case of ReplicationController but it is still available.

selector needs to matchLabels. The matchLabels matches the labels specified under it to the labels on the pods. The ReplicaSet selector also provides many other options for matching labels that were not available in a replication controller, so always to create a ReplicaSet

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx

Create ReplicaSet and Pods by ReplicaSet

$ kubectl create -f nginx-replicaset.yaml
replicaset.apps/nginx-replicaset created
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-54c7s               1/1     Running   0          12s
nginx-replicaset-99567               1/1     Running   0          12s
nginx-replicaset-x9ws9               1/1     Running   0          12s

Get ReplicaSet information and see the pods that were created by the ReplicaSet.

$ kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   3         3         3       2m4s

Labels and Selectors

Why do we label our pods and objects in kubernetes?

Imagine, we need to deploy three instances of our backend web application as three pods. We would like to create a ReplicationController or ReplicaSet to ensure that we have three active pods at any time. This is one of the use cases of ReplicaSet.

The role of the ReplicaSet is to monitor the pods and if any of them were to fail deploy new ones. The ReplicaSet is in fact a process that monitors the pods. Thus, how does the ReplicaSet know what pods to monitor? There could be hundreds of other pods in the cluster running different applications. This is where labeling our pods during creation comes in handy. This way the ReplicaSet knows which pods to monitor the same concept of labels and selectors is used in many other places throughout Kubernetes.

selector:
  matchLabels:
    app: nginx

metadata:
  name: nginx-pod
  labels:
    app: nginx

In the case, one of the pods was to fail in the future the ReplicaSet that need template section to create a new one to maintain the desired number of pods and for the ReplicaSet to create a new pod.

How do we scale up with ReplicaSet?

scale to five.

The first way is to update the number of replicas in the definition file.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx
          ports:
          - containerPort: 80
            protocol: TCP

Replace the file and execute the replace command

$ kubectl replace -f nginx-replicaset.yaml 
replicaset.apps/nginx-replicaset replaced
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-54c7s               1/1     Running   0          5m11s
nginx-replicaset-99567               1/1     Running   0          5m11s
nginx-replicaset-jwc8g               1/1     Running   0          13s
nginx-replicaset-tzx2f               1/1     Running   0          13s
nginx-replicaset-x9ws9               1/1     Running   0          5m11s

2. The second way is to run kubectl scale comman with yaml.file

Scale up to six

$ kubectl scale --replicas=6 -f nginx-replicaset.yaml
replicaset.apps/nginx-replicaset scaled
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-54c7s               1/1     Running   0          6m12s
nginx-replicaset-99567               1/1     Running   0          6m12s
nginx-replicaset-jwc8g               1/1     Running   0          74s
nginx-replicaset-tzx2f               1/1     Running   0          74s
nginx-replicaset-wwrxc               1/1     Running   0          15s
nginx-replicaset-x9ws9               1/1     Running   0          6m12s

Scale Down to two

$ kubectl scale --replicas=2 -f nginx-replicaset.yaml
replicaset.apps/nginx-replicaset scaled
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-99567               1/1     Running   0          7m25s
nginx-replicaset-x9ws9               1/1     Running   0          7m25s

3. The third way is to run kubectl scale command with type and the name of ReplicaSet

Scale up to four

$ kubectl scale --replicas=4 replicaset nginx-replicaset
replicaset.apps/nginx-replicaset scaled
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-99567               1/1     Running   0          8m47s
nginx-replicaset-bq4vz               1/1     Running   0          32s
nginx-replicaset-fvp94               1/1     Running   0          32s
nginx-replicaset-x9ws9               1/1     Running   0          8m47s

Scale Down to one

$ kubectl scale --replicas=1 replicaset nginx-replicaset
replicaset.apps/nginx-replicaset scaled
$ kubectl get pods
NAME                                 READY   STATUS    RESTARTS   AGE
nginx-replicaset-x9ws9               1/1     Running   0          9m22s

List of Commands

$ kubectl create -f nginx-replicaset.yaml
$ kubectl get replicaset
$ kubectl delete replicaset nginx-replicaset
$ kubectl replace -f nginx-replicaset.yaml
$ kubectl scale --replicas=6 -f nginx-replicaset.yaml
$ kubectl scale --replicas=4 replicaset nginx-replica