Replication Controller

Replication Controller

In this tutorial we will learn about one controller i.e., Replication Controller.

Controllers are the brain behind Kubernetes. These are the processes that monitor the Kubernetes objects and respond accordingly.

What is Replica and Why do we need Replication Controller?

Lets go back to the previous scenario, where we have a single POD running your application. Due to some reason your application crashes and POD fails. Now users will no longer able to access your application. To prevent users to loosing access to your application we would like to have more than one instance or POD running at the same time. That way if one POD fails, we still have your application running on another POD.

The Replication controller helps us run multiple instances of a single POD in the Kubernetes cluster. That’s providing high availability.

Replication Controller in Kubernetes
Load Balancing & Scaling

The another reason we need Replication Controller is to create multiple PODs to share the load across them. For example, we have single POD serving a set of users. When the number of users increase, we deploy the additional POD to balance the load across the 2 PODs.

Replication Controller in Kubernetes

If the demand further increases and if you were to run out of resources on the first node we could deploy the additional PODs across the other nodes in the cluster.

Replication Controller in Kubernetes

As you can see, the Replication Controller spans across the multiple nodes in the cluster. It helps us balance the load across multiple PODs or different nodes as well as to scale our application when demand increases.

Replication Controller vs Replica Set

These two deployments have the same purpose but they are not the same. Replication Controller is the older technology that is being replaced by Replica Set. Replica Set is the new recommended way to setup replication.

There is a minor difference between Replication Controller and Replica Set. We will discuss with example

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: font-end

spec: 
  template:
    metadata:
      name: myapp-pod
      labels: 
        app: myapp
    spec:
      containers:
        - name: nginx-container
          image: nginx
          
  replicas: 3
    

To create replication controller using following command

kubectl create -f rc-definition.yml
replicationcontroller "myapp-rc" created
kubectl get replicationcontroller 
NAME       DESIRED    CURRENT    READY    AGE
myapp-rc   3          3          3        36s


kubectl get pods
NAME                     READY    STATUS      RESTARTS   AGE
myapp-rc-41rfe           1/1     Running        0       45s
myapp-rc-4fdes           1/1     Running        0       45s
myapp-rc-lcsrx           1/1     Running        0       45s

Now we look at Replica Set

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: font-end

spec: 
  template:
    metadata:
      name: myapp-pod
      labels: 
        app: myapp
    spec:
      containers:
        - name: nginx-container
          image: nginx
      
  replicas: 3
  selector:
    matchLabels:
      type: font-end

The major difference between Replication Controller and Replica Set is Replica Set requires a selector definition. The selector section helps the Replica Set to identify what PODs fall under it.

But why could you have to specify what PODs fall under it, if you have provide the contents of the POD definition file itself in the template section. It’s because of Replica Set also manage PODs that we are not created as part of the Replica Set creation.

To create Replication Set using following command

kubectl create -f replicaset-definition.yml
replicaset "myapp-replicaset" created
kubectl get replicaset 
NAME                DESIRED    CURRENT    READY    AGE
myapp-replicaset    3          3          3        36s


kubectl get pods
NAME                        READY    STATUS      RESTARTS   AGE
myapp-replicaset-41rfe       1/1     Running        0       45s
myapp-replicaset-4fdes       1/1     Running        0       45s
myapp-replicaset-lcsrx       1/1     Running        0       45s
Labels and Selectors

For example we will create a Replication Controller or Replica Set to ensure that 3 active pods running at any time. This is the main use case of Replica Set. You can use this to monitor the existing PODs that already created. In case we are not created 3 PODs then Replica Set will create them for you.

The role of the Replica Set is to monitor the PODs and if any of them is fail then it will deploy new one. The Replica Set is in fact a process that monitors the PODs.

Then how does the Replica Set know what PODs to monitor. There could be 100’s of PODs in the cluster running different applications. This is where labeling our PODs during creation of the POD. We could now provide these labels as a filter for a ReplicaSet. Under the selector section we use the matchLabels filter and provides the same label that we used while creating the POD. This way Replica Set knows which PODs to monitor.

Note

The main difference between a Replica Set and a Replication Controller is replication controller supports equality based selectors whereas the replica set supports equality based as well as set based selectors.

Equality based Selectors

Equality based selectors allow filtering by label keys and values. Matching objects must satisfy all of the specified label constraints, though they may have additional labels as well. 

Three operators used in set based equality based selectors are = , == , !=. The first two represent equality (and are simply synonyms), while the latter represents inequality. 

For example, if we provide the following selectors

env = prod
tier != frontend

Here, we’ll select all resources with key equal to environment and value equal to production.

The latter selects all resources with key equal to tier and value distinct from front end, and all resources with no labels with the tier key.One usage scenario for equality-based label requirement is for Pods to specify node selection criteria.

Set Based Selectors

Unlike Equality based, Set-based label selectors allow filtering keys according to a set of values.

Three kinds of operators used in set-based selectors are in , notin, exists(only the key identifier).

For example, if we provide the following selectors

env in (prod, qa)
tier notin (frontend, backend)
partition

Here, in the first selector will selects all resources with key equal to environment and value equal to production or qa.

The second example selects all resources with key equal to tier and values other than front end and back end, and all resources with no labels with the tier key. The third example selects all resources including a label with key partition; no values are checked.

The set-based label selector is a general form of equality since environment=production is equivalent to environment in (production). Similarly for != and not in.

Replication Controller
Scroll to top