Last Updated : 06 Aug, 2025
With the help of the open-source container orchestration technology Kubernetes, software deployment, scalability, and management are mostly automated. Another name for Kubernetes is K8s. Google created Kubernetes, which is now overseen by the Cloud Native Computing Foundation. Even though it now works with CRI-O as well as Docker runtime, with which it was initially intended to work. Automating operational activities for container management is Kubernetes' primary goal. It has built-in capabilities for deploying apps and rolling out necessary application modifications. Businesses like Google, Spotify, and Capital One currently use it.
How a ReplicationController Works?The main purpose of the Replication Controller is to make sure that a specific number of Pod replicas are being run at a particular time. The job of the replication controller is to make sure of the availability of a Pod or a set of Pods to perform any task. It is often represented as "RC".
Working of ReplicationControllerIf there are multiple pods present at a time and are not being used then it is the Job of the ReplicationController to terminate the extra pods. If there are very few pods and there is no available pod to do the work then it is the responsibility of the Replication Controller to create more Pods. The pods which are created by the replication controller are replaced automatically if they fail, unlike the manually created pods. The job of a Replication controller is very similar to that of a Process Supervisor the only difference is that the Replication controller supervises multiple pods across various nodes whereas the Process supervisor will only check individual processes at only one node.
Running an Example ReplicationControllerBy using the following yaml file you can run the tomcat as a container in the Kubernetes cluster. Create a yaml file with the name tomcat.yaml and paste the following code in that file.
apiVersion: v1
kind: ReplicationController
metadata:
name: tomcat
spec:
replicas: 3
selector:
app: tomcat
template:
metadata:
name: tomcat
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: tomcat:latest
ports:
- containerPort: 8080
After creating yaml file know to run the yaml file by using the following command:
kubectl. apply -f tomcat.yaml
If you get the output as the following:
replicationcontroller/tomcat created
Then that your replication controller is created successfully. You can check the status of replication by using the following command.
Writing a ReplicationController Manifestkubectl describe replicationcontrollers/tomcat
RepilcationController requires the following content to write a yaml file.
Following is the sample yaml file to write the replication controller:
apiVersion: v1Kubernetes
kind: ReplicationController
metadata:
name: <replicationControllerName>
namespace: <nameSpaceName>
spec:
replicas: <noOfReplicas>
selector:
<key>: <value>
template: # POD Template
metadata:
name: <PODName>
labels:
<key>: <value>
spec:
- containers:
- name: <nameOfTheContainer>
image: <imageName>
ports:
- containerPort: <containerPort>
Labels on the ReplicationControllertemplate:
metadata:
labels:
app:<value>
The labels which are used in the replication controller are the key-value pairs that can be attached to the resources and can be reused for recognizing the resources. Labels play a major role in the replication controller where you can identify and organize the pods. By using labels you can also manage the scheduling of pods to the required nodes.
Pod SelectorA pod selector will select the pods based on their labels. Pod selector works on the key/value pair where the selectors can be used in various Kubernetes resources like
selector:
app: nginx
multiple labels can be used in pod selector you can separate them by using commas as the following.
Using ReplicationControllers with Servicesselector:
app: web app
tier: frontend
A ReplicationController is a structure that enables you to easily create multiple pods, then make sure that that number of pods always exists. If a pod does crash, the ReplicationController can be merged different services. Replication Controllers and PODS are associated with labels. Creating “RC” with a count of 1 ensures that a POD is always available.
apiVersion: v1Responsibilities of the ReplicationController
kind: ReplicationController
metadata:
name: nginx-rc
spec:
replicas: 2
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
Repilcation Controller will make sure that the desired no.of pods that are created by using Replication Controller is matching.
ReplicationController will maintain the pod lifecycle by making sure that the desired is matching with no.of pods running.
Replicaset is the next-generation of replication controller.
A Replication Controller is a structure that enables you to easily create multiple pods, then make sure that that number of pods always exists.
A Replicaset is a structure that enables you to easily create multiple pods, then make sure that that number of pods always exists.
Replication Controllers and PODS are associated with labels
ReplicaSet and PODS are associated with the selectors.
The major difference between a ReplicaSet and a Replication Controller right now is the selector support.
ReplicaSet supports the new set-based selector requirements as described in the labels user guide whereas a Replication Controller only supports equality-based selector requirements.
Kubernetes Replication Controller vs DeploymentA Replication Controller is a structure that enables you to easily create multiple pods, then make sure that that number of pods always exists. If a pod does crash, the Replication Controller replaces it.
In Kubernetes, Deployment is the recommended way to deploy Pod or RS, simply because of the advance features it comes with.
ReplicationController can't perform the rolling updates and rollouts.
Deployment can perform the rolling updates and rollouts.
The replication controller can't scale the pods so there is no command for scaling.
The command used to scale the deployment was as follows:
kubectl scale deployment [DEPLOYMENT_NAME] --replicas
[NUMBER_OF_REPLICAS]
If you want to scale the pods depending upon the incoming traffic you need to make the changes in the manifest file.
By using the commands you can scale the pods depending on the incoming traffic.
Working with ReplicationControllers Deleting a ReplicationControllerWe can delete any Replication Controller and all its pod by using the command kubectl delete. To more about Kubectl commands refer to the Kubernetes – Kubectl Commands
$ kubectl delete
The ReplicationController will become zero and will delete all the pods first before deleting the Replication Controller. There is a possibility to delete only the Replication Controller and not the pods, for this we need to specify the --cascade=orphan option with the kubectl delete command.
$ kubectl delete --cascade=orphan
This command will enable the process by scaling the Replication Controller to zero then waiting till the pods are deleted and then deleting the said replication controller. If this process stops without completion then it is restarted.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4