In this Kubernetes Tutorial we will explore ReplicaSet and compare it with ReplicationController using different scenarios and examples.
Overview on Replication Controllers
- A ReplicationController is a Kubernetes resource that ensures its pods are always kept running.
- If the pod disappears for any reason, such as in the event of a node disappearing from the cluster or because the pod was evicted from the node, the
ReplicationControllernotices the missing pod and creates a replacement pod. - The
ReplicationControllerin general, are meant to create and manage multiple copies (replicas) of a pod
- It is possible that you Node is out of resources while creating new pods with Replication controllers or replica sets, in such case it will automatically create new pods on another available cluster node
How replication controller works
A ReplicationController’s job is to make sure that an exact number of pods always matches its label selector. If it doesn’t, the ReplicationController takes the appropriate action to reconcile the actual with the desired number.
The following flow chart shows the operation of Replication Controller:
A ReplicationController has three essential parts:
- A label selector, which determines what pods are in the ReplicationController’s scope
- A replica count, which specifies the desired number of pods that should be running
- A pod template, which is used when creating new pod replicas
A ReplicationController’s replica count, the label selector, and even the pod template can all be modified at any time, but only changes to the replica count affect existing pods.
Creating a replication controller
To get the kind and apiVersion of replication controller we will check list of api-resources
[root@controller ~]# kubectl api-resources | grep -iE 'KIND|replication' NAME SHORTNAMES APIGROUP NAMESPACED KIND replicationcontrollers rc true ReplicationController
So, the kind value would be ReplicationController, now to get the apiVersion of this kind we will use kubectl explain command:
[root@controller ~]# kubectl explain ReplicationController | head -n 2 KIND: ReplicationController VERSION: v1
Now we have the kind and apiVersion value needed to create our first replication controller. Similar to pods and other Kubernetes resources, you create a ReplicationController by posting a JSON or YAML descriptor to the Kubernetes API server.
[root@controller ~]# cat replication-controller.yml
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
labels:
app: myapp
type: dev
spec:
replicas: 3
selector:
app: myapp
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: dev
spec:
containers:
- name: nginx-container
image: nginx
The highlighted section is the template to create the Pod.
When you post the file to the API server, Kubernetes creates a new Replication-Controller named myapp-rc, which makes sure three pod instances always match the label selector app=myapp. When there aren’t enough pods, new pods will be created from the provided pod template.
To create the ReplicationController, use the kubectl create command:
[root@controller ~]# kubectl create -f replication-controller.yml
replicationcontroller/myapp-rc created
Verify the operation of Replication Controller
Because no pods exist with the app=myapp label, the ReplicationController should spin up three new pods from the pod template. List the available pods in the default namespace:
[root@controller ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
init-container-example-1 1/1 Running 0 112m
myapp-rc-b2jtr 0/1 ContainerCreating 0 5s
myapp-rc-c57qm 0/1 ContainerCreating 0 5s
myapp-rc-hmj9g 0/1 ContainerCreating 0 5s
As expected, ReplicationController has started 3 pods in the default namespace, to get the status and list of available replication controllers:
[root@controller ~]# kubectl get rc NAME DESIRED CURRENT READY AGE myapp-rc 3 3 3 71s
Here 'rc' is an abbreviation for replication controller.
To make sure RC will create new pods we will delete an existing pod with label app=myapp:
[root@controller ~]# kubectl delete pod myapp-rc-c57qm
pod "myapp-rc-c57qm" deleted
As expected, the deleted pod is removed from the list of available pods and a new pod is created:
[root@controller ~]# kubectl get pods NAME READY STATUS RESTARTS AGE init-container-example-1 1/1 Running 0 113m myapp-rc-2tcgx 1/1 Running 0 15s myapp-rc-b2jtr 1/1 Running 0 52s myapp-rc-hmj9g 1/1 Running 0 52s
To check the status of the pods and the worker node where the respective pod is running you can use -o wide with kubectl get pods command:
[root@controller ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES init-container-example-1 1/1 Running 0 122m 10.36.0.2 worker-1.example.com <none> <none> myapp-rc-2tcgx 1/1 Running 0 9m58s 10.36.0.4 worker-1.example.com <none> <none> myapp-rc-b2jtr 1/1 Running 0 10m 10.36.0.3 worker-1.example.com <none> <none> myapp-rc-hmj9g 1/1 Running 0 10m 10.44.0.4 worker-2.example.com <none> <none>
You can see additional information about your ReplicationController with the kubectl describe command:
[root@controller ~]# kubectl describe rc myapp-rc
Name: myapp-rc
Namespace: default
Selector: app=myapp
Labels: app=myapp
type=dev
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=myapp
type=dev
Containers:
nginx-container:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 91s replication-controller Created pod: myapp-rc-b2jtr
Normal SuccessfulCreate 91s replication-controller Created pod: myapp-rc-c57qm
Normal SuccessfulCreate 91s replication-controller Created pod: myapp-rc-hmj9g
Normal SuccessfulCreate 54s replication-controller Created pod: myapp-rc-2tcgx
The list of events at the bottom shows the actions taken by the Replication-Controller—it has created four pods so far.
Changing the pod template
A ReplicationController’s pod template can be modified at any time. Changing the pod template will only affect the newly created pods and will have no impact on the existing pods which are in running state:
As an exercise I will update the replicas value by editing the pod template, and the change the value of replicas to 4 and save the template. This will open the ReplicationController’s YAML definition in your default text editor:
[root@controller ~]# kubectl edit rc myapp-rc
replicationcontroller/myapp-rc edited
We will now list the pods and verify the replica count, as you can see now we have 4 pods running using the myapp label:
[root@controller ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
init-container-example-1 1/1 Running 0 130m
myapp-rc-2tcgx 1/1 Running 0 17m
myapp-rc-b2jtr 1/1 Running 0 17m
myapp-rc-hmj9g 1/1 Running 0 17m
myapp-rc-ksx4f 1/1 Running 0 3m7s
You can also check the replication controller status which now shows that it allows 4 replicas:
[root@controller ~]# kubectl get rc
NAME DESIRED CURRENT READY AGE
myapp-rc 4 4 4 18m
Horizontally scaling pods
You’ve seen how ReplicationControllers make sure a specific number of pod instances is always running. Because it’s incredibly simple to change the desired number of replicas, this also means scaling pods horizontally is trivial.
Assuming you suddenly expect that load on your application is going to increase so you must deploy more pods until the load is reduced, in such case you can easily scale up the number of pods runtime.
For example here I am scaling up the number of replicas to 6:
[root@controller ~]# kubectl scale rc myapp-rc --replicas=6
replicationcontroller/myapp-rc scaled
And then verify the list of pods with myapp label, so two more pods are started:
[root@controller ~]# kubectl get pods NAME READY STATUS RESTARTS AGE init-container-example-1 1/1 Running 0 132m myapp-rc-2tcgx 1/1 Running 0 19m myapp-rc-b2jtr 1/1 Running 0 20m myapp-rc-hmj9g 1/1 Running 0 20m myapp-rc-ksx4f 1/1 Running 0 5m41s myapp-rc-pvqk2 0/1 ContainerCreating 0 3s myapp-rc-zp972 0/1 ContainerCreating 0 3s
Similarly once the load is reduced, the replicas can be scaled down as well, here I have now reduced the number of replicas to 3. All this command does is modify the spec.replicas field of the ReplicationController’s definition—like when you changed it through kubectl edit.:
[root@controller ~]# kubectl scale rc myapp-rc --replicas=3
replicationcontroller/myapp-rc scaled
And after scaling down the replicas you can see that the newly created pods are now terminating:
[root@controller ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
init-container-example-1 1/1 Running 0 134m
myapp-rc-2tcgx 1/1 Running 0 21m
myapp-rc-b2jtr 1/1 Running 0 21m
myapp-rc-hmj9g 1/1 Running 0 21m
myapp-rc-ksx4f 0/1 Terminating 0 7m13s
myapp-rc-pvqk2 0/1 Terminating 0 95s
myapp-rc-zp972 0/1 Terminating 0 95s
Deleting a ReplicationController
When you delete a ReplicationController through kubectl delete, the pods are also deleted. But because pods created by a ReplicationController aren’t an integral part of the ReplicationController, and are only managed by it, you can delete only the ReplicationController and leave the pods running.
When deleting a ReplicationController with kubectl delete, you can keep its pods running by passing the --cascade=false option to the command.
[root@controller ~]# kubectl delete rc myapp-rc --cascade=false
replicationcontroller "myapp-rc" deleted
So the pods created by this replication controller will continue to be in running state (although not managed any more):
[root@controller ~]# kubectl get pods NAME READY STATUS RESTARTS AGE init-container-example-1 1/1 Running 0 136m myapp-rc-2tcgx 1/1 Running 0 23m myapp-rc-b2jtr 1/1 Running 0 24m myapp-rc-hmj9g 1/1 Running 0 24m
Using replica sets instead of replication controller
Initially, ReplicationControllers were the only Kubernetes component for replicating pods and rescheduling them when nodes failed. Later, a similar resource called a ReplicaSet was introduced. It’s a new generation of ReplicationController and replaces it completely (ReplicationControllers will eventually be deprecated).
That being said, you should always create ReplicaSets instead of ReplicationControllers from now on. They’re almost identical, so you shouldn’t have any trouble using them instead.
Comparing a ReplicaSet to a ReplicationController
- A
ReplicaSetbehaves exactly like aReplicationController, but it has more expressive pod selectors. - Whereas a ReplicationController’s label selector only allows matching pods that include a certain label, a ReplicaSet’s selector also allows matching pods that lack a certain label or pods that include a certain label key, regardless of its value.
- Also, for example, a single ReplicationController can’t match pods with the label
env=productionand those with the labelenv=develat the same time. It can only match either pods with theenv=productionlabel or pods with theenv=devellabel. But a single ReplicaSet can match both sets of pods and treat them as a single group. - Similarly, a ReplicationController can’t match pods based merely on the presence of a label key, regardless of its value, whereas a ReplicaSet can. For example, a
ReplicaSetcan match all pods that include a label with the key env, whatever its actual value is (you can think of it asenv=*).
Example-1: Create replica set using match labels
We will create a new replica set which will now map the orphaned pods from replication controller. But before that we need to have the KIND and apiVersion value for replica set.
[root@controller ~]# kubectl api-resources | grep -iE 'KIND|replica' NAME SHORTNAMES APIGROUP NAMESPACED KIND replicationcontrollers rc true ReplicationController replicasets rs apps true ReplicaSet
Now we have the KIND value i.e. ReplicaSet, to get the apiVersion of this kind we will use kubectl explain:
[root@controller ~]# kubectl explain ReplicaSet | head -n 2 KIND: ReplicaSet VERSION: apps/v1
So the apiVersion of ReplicaSet will be apps/v1. We will use the following YAML file to create our ReplicaSet. The only difference is in the selector, instead of listing labels the pods need to have directly under the selector property, you’re specifying them under selector.matchLabels. This is the simpler (and less expressive) way of defining label selectors in a ReplicaSet.
[root@controller ~]# cat replica-set.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicaset
labels:
app: myapp
type: dev
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: dev
spec:
containers:
- name: nginx-container
image: nginx
Now we will apply this replica set to the existing pods with label app: myapp so that those orphan pods can now be managed by this replica set:
[root@controller ~]# kubectl apply -f replica-set.yml
replicaset.apps/myapp-replicaset created
Next verify the list of pods:
[root@controller ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-rc-6vjv4 1/1 Running 1 12h 10.36.0.4 worker-1.example.com <none> <none> myapp-rc-9fp5l 1/1 Running 1 12h 10.36.0.3 worker-1.example.com <none> <none> myapp-rc-cwwwh 1/1 Running 1 12h 10.44.0.4 worker-2.example.com <none> <none>
So no new pods are created, let us check the details of any of these pods:
[root@controller ~]# kubectl describe pods myapp-rc-6vjv4
Name: myapp-rc-6vjv4
Namespace: default
Priority: 0
Node: worker-1.example.com/192.168.43.49
Start Time: Mon, 30 Nov 2020 00:23:57 +0530
Labels: app=myapp
type=dev
Annotations: <none>
Status: Running
IP: 10.36.0.4
IPs:
IP: 10.36.0.4
Controlled By: ReplicaSet/myapp-replicaset
...
As you see this pod is Controlled By: ReplicaSet/myapp-replicaset. After that, you can examine the ReplicaSet with kubectl get command:
[root@controller ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp-replicaset 3 3 3 46s
To get more details on this replica set:
[root@controller ~]# kubectl describe rs myapp-replicaset
Name: myapp-replicaset
Namespace: default
Selector: app=myapp
Labels: app=myapp
type=dev
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=myapp
type=dev
Containers:
nginx-container:
Image: nginx
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
Events: <none>
Example-2: Create replica set using match expressions
The main improvements of ReplicaSets over ReplicationControllers are their more expressive label selectors. You intentionally used the simpler matchLabels selector in the first ReplicaSet example to see that ReplicaSets are no different from Replication-Controllers.
Now, we will rewrite the selector to use the more powerful matchExpressions property:
[root@controller ~]# cat replica-set.yml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicaset
labels:
app: myapp
type: dev
spec:
replicas: 3
selector:
matchExpressions:
- key: app
operator: In
values:
- myapp
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: dev
spec:
containers:
- name: nginx-container
image: nginx
Here, this selector requires the pod to contain a label with the “app” key and the label’s value must be “myapp”.
You can add additional expressions to the selector. As in the example, each expression must contain a key, an operator, and possibly (depending on the operator) a list of values. You’ll see four valid operators:
- In: Label’s value must match one of the specified values.
- NotIn: Label’s value must not match any of the specified values.
- Exists: Pod must include a label with the specified key (the value isn’t important). When using this operator, you shouldn’t specify the values field.
- DoesNotExist: Pod must not include a label with the specified key. The values property must not be specified.
If you specify multiple expressions, all those expressions must evaluate to true for the selector to match a pod. If you specify both matchLabels and matchExpressions, all the labels must match and all the expressions must evaluate to true for the pod to match the selector.
I will delete my existing replica set, (I can also update the existing one but to demonstrate this properly I will delete the existing replicaset)
[root@controller ~]# kubectl delete rs myapp-replicaset
replicaset.apps "myapp-replicaset" deleted
Now we will create replica set with new matchExpressions value:
[root@controller ~]# kubectl apply -f replica-set.yml
replicaset.apps/myapp-replicaset created
Verify the list of pods (no new pods are created by this replica set as we already had pods running with the required label):
[root@controller ~]# kubectl get pods NAME READY STATUS RESTARTS AGE myapp-rc-s4ndd 1/1 Running 0 11m myapp-rc-svqcd 1/1 Running 0 11m myapp-rc-xr4bs 1/1 Running 0 11m
To make sure the pod is managed by our replica set, we can use kubectl describe command:
[root@controller ~]# kubectl describe pods myapp-rc-s4ndd Name: myapp-rc-s4ndd Namespace: default Priority: 0 Node: worker-1.example.com/192.168.43.49 Start Time: Mon, 30 Nov 2020 14:18:24 +0530 Labels: app=myapp type=dev Annotations: <none> Status: Running IP: 10.36.0.2 IPs: IP: 10.36.0.2 Controlled By: ReplicaSet/myapp-replicaset ...
So as expected, the existing pods with label app: myapp is now mapped with our ReplicaSet.
Horizontally scaling Pod
Now similar to replication controller, we can also scale replica set pods. In this example we will scale up the number of pods to 6:
[root@controller ~]# kubectl scale rs myapp-replicaset --replicas=6
replicaset.apps/myapp-replicaset scaled
Now verify the list of pods:
[root@controller ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myapp-rc-6vjv4 1/1 Running 1 12h 10.36.0.4 worker-1.example.com <none> <none>
myapp-rc-9fp5l 1/1 Running 1 12h 10.36.0.3 worker-1.example.com <none> <none>
myapp-rc-cwwwh 1/1 Running 1 12h 10.44.0.4 worker-2.example.com <none> <none>
myapp-replicaset-8r6kx 0/1 ContainerCreating 0 6s <none> worker-2.example.com <none> <none>
myapp-replicaset-kp78z 0/1 ContainerCreating 0 6s <none> worker-1.example.com <none> <none>
myapp-replicaset-svm45 0/1 ContainerCreating 0 6s <none> worker-1.example.com <none> <none>
As you can see the new vms are now started by the new name as per our template, now we will scale down our number of pods:
[root@controller ~]# kubectl scale rs myapp-replicaset --replicas=3
replicaset.apps/myapp-replicaset scaled
So the newly created pods are now terminating:
[root@controller ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-rc-6vjv4 1/1 Running 1 12h
myapp-rc-9fp5l 1/1 Running 1 12h
myapp-rc-cwwwh 1/1 Running 1 12h
myapp-replicaset-8r6kx 0/1 Terminating 0 11m
myapp-replicaset-kp78z 0/1 Terminating 0 11m
myapp-replicaset-svm45 0/1 Terminating 0 11m
Delete replica set
This was a quick introduction to ReplicaSets as an alternative to ReplicationControllers. Remember, always use them instead of ReplicationControllers, but you may still find ReplicationControllers in other people’s deployments.
Now, delete the ReplicaSet to clean up your cluster a little. You can delete the ReplicaSet the same way you’d delete a ReplicationController:
[root@controller ~]# kubectl delete rs myapp-replicaset
replicaset.apps "myapp-replicaset" deleted
This will also delete all the pods which were part of this replica set. But you can use --cascade=false along with this command to retain all the pods part of replica set.
Conclusion
In this Kubernetes Tutorial we did a comparison between Replication Controller and Replica Set. Summary of what we learned:
- ReplicationControllers always keep the desired number of pod replicas running.
- Scaling pods horizontally is as easy as changing the desired replica count on a ReplicationController.
- Pods aren’t owned by the ReplicationControllers and can be moved between them if necessary.
- A ReplicationController creates new pods from a pod template. Changing the template has no effect on existing pods.
- ReplicationControllers should be replaced with ReplicaSets and Deployments, which provide the same functionality, but with additional powerful features.
