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.
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.
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.
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-endThe 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.