Advance Concepts of K8s — Replica Set and Controllers
Now as we are familiar with creating K8s scripts using the HCL (K8s own declarative type language). Let’s try to implement some typical services which we generally require to use K8s to it’s full potential and which are required to successfully manage the application in the live production scenarios.
If you missed the previous — Basic of HCL click on link to visit.
To know the basic of Kubernetes and power of Kubernetes
We know that the actual power of Kubernetes is it’s power to manage the pods and the containers which holds the containers. The K8s derives this power from managing the labels on the Pods which we launch, and it manages all the pods using those labels only.
To achieve it’s power of Fault Tolerance which we discussed earlier, it uses some special features such as Replica Set or Replication Controller. Both the features generally provides same functionality, but have some minute difference among them. For the difference we will understand them as we will move forward and try to implement those.
These services are the one which takes our desires, store them in the configuration and actually see’s through or checks weather our desires are fulfilled at any instance or not. They are actually responsible for launching another pods of the container if one goes down.
For Ex — Suppose we defined to K8s that for this specific pod we have a desire to have 3 replicas up at any give point in time. Then the RS or RC (Replica Set or Replica Controller) will keep check weather 3 replicas are running or not, and if by any means one replica goes down it relaunches another pods having same container image as provided in the template while designing along with same labels via which it will keep them under it’s surveillance.
Moreover the load balancing is automatically manages between these multiple pods as if all pods contains a Web Site and are acting as web servers, then every time a client comes, he or she will be redirect to another pods of same container to manage the load among the pods and not to over exert any of the pod.
Let’s Implement for Replication Controllers :
We will start as usual by launching the minikube clusters on the Virtual Machine which will help us in creating a basic K8s cluster.
Now as the basics are out of the way let’s move onto implementation phase.
Here on Replication Controller, this service comes under apiVersion — 1 and it has it’s own kind which we can guess is Replication Controller itself. To implement RC successfully we have to define for labels as discussed and then these labels will be passed as selectors which will in-turn help us manage over the pod.
Here whenever a pod goes down the RC will launch another nginx container inside a new pod using the template which we defined under the spec method. The desire is described by us in terms of replicas which is 2.
As we describe for pods, we can see 2 pods with nginx image are launched automatically.
To get the RC used we can use command
kubectl get rc
kubectl get pods — show-labels (to check for labels)
As we can see our desires are stores in the RC and the labels are used by the K8s to manage over the pods and if due to any reason one of the pods gets deleted or crashes, the RC will restart to cope up with our desires and launch a new pod for us with the template which we provided before.
There is one more powerful and very useful command which is generally used in the provisioning scenarios which is to go inside the pods launched as we can do with the docker container. Kubernetes also has it’s own command which is similar to docker and can be used to go inside the pods launched.
kubectl exec -it <name> — bash
By using this command we can go inside the pods, do the required changes and can easily come out from the pod. This command has it’s own specific use cases and can play some important roles too.
Moving on to Replica Sets :
Replica Sets have basic functions a lot like Replication Controller, as they are also used to manage the duplication and task to meet the need which are mentioned in the desired by the developer.
A Replica Set is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. When a Replica Set needs to create new Pods, it uses its Pod template.
When to use Replica Sets:
A Replica Set ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages Replica Sets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.
Difference between Replica Sets and Replication Controllers
Replica sets are comparatively more useful. In recent times replication sets have replaced replication controllers. Replica sets have a few more functionalities when compared to the replication controller. The major difference comes with the usage of selectors to replicate pods. Replica Set use Set-Based selectors while replication controllers use Equity-Based selectors. Hence Replica Set is rather a newer functionality and hence it requires the newer version of API i.e apps/v1
Implementation of Replica Sets:
The Replica Sets as explained have basically same format as that of Replication Controller, but with some minute changes i.e it uses matchLabels as selectors and hence uses Set-Based selectors over labels which is rather an advanced way and can be way more powerful than using Equality Based selectors, which has several limiting factors.
By this the same image of nginx is launched in the pod but this time it uses RS to manage the pods. The desired value as mention in the image is 3 and hence as expected it will launch 3 different replicas of the image in 3 pods for us using the templates and labels which we defined. Here the port is also exposed over port 80.
We can execute the same commands over Replica Sets as well which were used for Replication Controllers.
With these we can successfully conclude the power of K8s, how it is able to manage the pods so powerfully (Requires Labels to do so) and the major services of K8s i.e. Replication Controller and Replica Sets.
Next — PVC (volume management) and Services
Previous — Basic of Cluster Orchestration
“Low-level programming is good for the programmer’s soul.”
— John Carmack
