Updated April 13, 2023
Introduction to Kubernetes Replication Controller
Kubernetes Replication Controller ensures that desired replicas of identical pods match the current replicas of identical pods at a given point of time which means it ensures that current status always matches desired status. Kubernetes Replication Controller guarantees that a pod or a set of identical pods never goes down. In short, we called it ‘rc’ and we use this shortcut in kubectl command as well. Kubernetes Replication Controller is almost similar to a Process Supervisor however there is one difference that is Replication Controller supervises multiple pods on multiple nodes instead of supervising a single process on a single node.
How Replication Controller works in Kubernetes?
Kubernetes Replication Controller keeps matching the desired number of pods with the current number of pods and if there are more pods running than the desired number of pods terminates the extra pods or if there are fewer pods than the desired number then it starts more pods. The pods maintained by a Replication Controller are replaced automatically if they fail, deleted, or are terminated.
For example, if we want 3 replicas of a web server then Replication Controller ensures that 3 replicas of a web server are always up and running and if any of the pod stops functioning due to any disruptive maintenance such as kernel upgrade, it automatically starts a new pod to match the desired state without any human interaction. It is recommended to use Replication Controller even if the application requires only a single pod.
Examples of Kubernetes Replication Controller
Given below are the example of Kubernetes Replication Controller:
Example #1
Replication Controller config example that runs three replicas of the nginx web server.
Code:
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-web
spec:
replicas: 5
selector:
app: nginx-web
template:
metadata:
name: nginx-web
labels:
app: nginx-web
spec:
containers:
- name: nginx-web
image: nginx
ports:
- containerPort: 80Save above code in a yaml file ‘rc_nginx.yml’ and apply this file using below command:
Code:
$kubectl apply -f rc_nginx.ymlOutput:
Explanation:
In the above example, when we applied the yaml file, one Replication Controller named “nginx-web” has been created.
Example #2
Code:
$kubectl describe replicationcontroller/nginx-webOutput:
Explanation:
In the above example, it describes all details related to the Replication Controller ‘nginx-web’. We have mentioned 5 replicas in the yaml file and we can see that the current state matches the desired state i.e. 5 replicas.
Let’s list all running pods in our cluster, in the below snapshot we can see that only 5 pods are running and the name of the pods starts with ‘nginx-web’ that is the name of the Replication Controller and then some string to differentiate the pods. If we delete the highlighted pods and again list the all running pods, it again shows 5 pods but the deleted pod is no longer available in the list. We see a new pod is just created with a new string at the end. That means when we deleted a pod that was a part of that Replication Controller, the current state goes to 4 so Replication Controller created a brand new pod.
Deletion of a Replication Controller
Given below are deletion of a replication controller:
1. We can delete a Replication Controller and all its pods by using ‘kubectl delete’.
Code:
$kubectl delete replicationcontroller/nginx-webOutput:
Explanation:
In the above example, pods are getting terminated after deleting the Replication Controller.
2. We can delete a Replication Controller but not the pods running under this controller by specifying the option ‘–cascade=false’ to the ‘kubectl delete’ command.
Code:
$kubectl delete replicationcontroller/nginx-web --cascade=falseOutput:
Explanation:
In the above snapshot, The Replication Controller has been deleted however pods are still running.
3. We can also remove a pod from a Replication Controller by changing the labels of the pod however Replication Controller will replace that pod by creating a new pod. It is mostly used to remove a pod from service for debugging, data recovery, etc.
Roles of Replication Controller
Given below are the roles of replication controller:
1. Rescheduling
A Replication Controller ensures that specified numbers of pods are running all the time whether we have to run a single pod or 100 pods in any situation, even if the node fails or pods are terminated manually or by any different control agent.
2. Scaling
We can easily the number of replicas up and down using a Replication Controller. We have to simply update the ‘replicas’ field manually or an auto-scaling control agent.
3. Rolling updates
We can also use a Replication Controller for rolling updates to service. A Replication Controller replaces pods one-by-one in rolling updates. We need to create a new Replication Controller to achieve rolling updates. We create a new Replication Controller with 1 replica and then scale it up by one and scale the old replication down by one pod. We continue this process until the old Replication Controller reaches 0 replicas. We delete the old Replication Controller once it is reached to 0 replicas.
4. Multiple release tracks
‘Canary’ is a popular test that we do in production. In this test, we just introduce a new release of the application to some of the users and we don’t completely remove the old version of application from the production.
For example, we have a service targeting all the 5 pods, now we want to introduce a new release of our application. We set up a Replication Controller with 4 replicas and with labels ‘env=prod’ and ‘track=stable’, and another Replication Controller with 1 replica with labels ‘env=prod’ and ‘track=canary’. Here the service is targeting both release track ‘stable’ and ‘canary’. We can scale the replicas of the Replication Controller as per our test result.
Responsibilities of Replication Controller
Given below are the responsibilities of replication controller:
1. The main responsibility of the Replication Controller is to ensure that the desired number of replicas matches with the current number of replicas.
2. Here, a Replication Controller only considered terminated pods that are excluded from the counts.
3. If a pod is running but not accessible then the Replication Controller is going to replace that pod as it does not perform any readiness nor liveness probes.
Conclusion
Kubernetes Replication Controller is useful if we want to continuously run a pod or multiple identical pods as only ‘Always’ restart policy is allowed in the Replication Controller. There are alternatives available for Kubernetes Replication Controller such as ‘ReplicaSet’, ‘Deployment’, ‘Bare Pods’, ‘Job’, and ‘DaemonSet’. What to choose is totally depends upon one’s requirement.
Recommended Articles
We hope that this EDUCBA information on “Kubernetes Replication Controller” was beneficial to you. You can view EDUCBA’s recommended articles for more information.
