How the Kubernetes ReplicationController works

A ReplicationController is responsible for managing the pod lifecycle and ensuring that the specified number of pods required are running at any given time.

Have you ever wondered what is responsible for supervising and managing just the exact number of pods running inside the Kubernetes cluster? Kubernetes can do this in multiple ways, but one common approach is using ReplicationController (rc). A ReplicationController is responsible for managing the pod lifecycle and ensuring that the specified number of pods required are running at any given time. On the other hand, it is not responsible for the advanced cluster capabilities like performing auto-scaling, readiness and liveliness probes, and other advanced replication capabilities. Other components within the Kubernetes cluster better perform those capabilities.

In short, the ReplicationController has limited responsibility and gets typically used for specific implementations that do not require complex logic to attain certain requirements (for example, ensuring that the desired number of pods always matches the specified number). If there are more than the desired number, the ReplicationController removes the excess ones and ensures the same number of pods exist even in the event of node failure or pod termination

Simple things do not require complex solutions, and this is, for me, a perfect metaphor of how a ReplicationController gets used.

How to Create a ReplicationController

Like most Kubernetes resources, you can create a ReplicationController using YAML or JSON format then post it to the Kubernetes API endpoint.

$ kubectl create -f rcexample.yaml
  replicationcontroller/rcexample created

Now, I'll dig a bit deeper into what rcexample.yaml looks like.

apiVersion: v1
kind: ReplicationController   → rc descriptor    
metadata:
 name: rcexample            → Name of the replication controller               
spec:
 replicas: 3                 → Desired number of pods       
 selector:                   → The pod selector for this rc        
   app: nginx                        
 template:                   → The template for creating a new pod        
   metadata:                         
     labels:                         
       app: nginx                    
   spec:                             
     containers:                     
     - name: nginx                   
       image: nginx

To explain further, this file, when executed to create a ReplicationController called rcexample ensures that three instances of pods called nginx are running all the time. If one or all the pods app=nginx are not running, new pods are created based on the defined pod template.

A ReplicationController has three parts:

Replica: 3
Pod Template: app=nginx
Pod Selector: app=nginx

Notice that Pod Template matches with Pod Selector to prevent the ReplicationController from indefinitely creating pods. If you create a ReplicationController with a pod selector not matching the template, the Kubernetes API server gives you an error.

To verify that the ReplicationController rcexample got created:

$ kubectl get po
NAME          READY     STATUS              RESTARTS   AGE
rcexample-53thy   0/1   Running  		0          10s
rcexample-k0xz6   0/1   Running  		0          10s
rcexample-q3vkg   0/1   Running  		0          10s

To delete the ReplicationController:

$ kubectl delete rc rcexample
  replicationcontroller "rcexample" deleted

Note that you can use a rolling update strategy to the service in the ReplicationController by replacing pods one by one.

Other methods to replicate containers

In a Kubernetes deployment, there are multiple ways you that can attain replication of containers. One of the main reasons Kubernetes is the main choice for container platforms is the native ability to replicate containers to attain reliability, load balancing, and scaling.

I have shown above how you can easily create a ReplicationController to make sure that a certain number of pods is available at any given time. You can manually scale pods by updating the number of replicas.

The other possible approach to attain replication is by using ReplicaSet.

(kind: ReplicaSet)

ReplicaSet (rs) functions are almost identical to ReplicationController. The main difference is that a ReplicaSet does not allow a rolling-update strategy.

Another approach to attain replication is by using Deployments.

(kind: Deployment)

Deployments is a more advanced container replication approach. Functionality-wise, Deployments provide the same functionality but can roll out and roll back changes if needed. This functionality is possible because Deployments has StrategyType specification to replace old pods with new ones. There are two types of deployment strategies that you can define—Recreate and RollingUpdate. You specify the deployment strategy as shown below:

StrategyType: RollingUpdate

Conclusion

Replication of containers is one of the main reasons why Kubernetes gets considered for most enterprise container adoption. Replication allows you to attain the reliability and scalability that most critical applications need as minimum requirements for production.

Understanding which methods to use to attain replication in a Kubernetes cluster is important to decide which one is the best for you to incorporate in your application architecture consideration.