At this point you have probably heard of Pods, services, containers, Replica Sets, Replication Controllers but what does particular thing mean? What the order is? What the largest of these things is? And which is smallest of all of these and How are they related to each other?
By this, we should be specific and point out they are actually resources in the language of Kubernetes.
And it turns out that the smallest of all of these is actually a Pods. You might think why is it not a container? It turns out as that we know before container its inside pods and there is more than one container in a given pod.
So although you are right- containers are smaller but in pods, if you look at this you will see that in the VMware world the atomic unit of deployment is the Virtual machine(VM).
In Docker world, it is the container. Well in the Kubernetes world it is the Pod.
Because here you will notice what is a column called name with Splash dividing something on the left and something on the right.
The left is the type of resource and on the right it is actual name and so you see at the resource type and then you have the name but the container themselves are inside of that and if you continue down the line you will see a various types of resources- So we have- a Replica set and you have Pods, You have deployments and you also have Replication Controllers.
Because we know if we have a set of Pods and if we are referring to the same thing then we need to distinguish between them. So you can have a no. like 1 and then 2 and then 3 and each of these is called Replicas. So you have Replicas 1,2, and 3 here.
So how would you see that in practice? In practice, if you have a name of yum file like ReplicationController.yum, you will see the number of Replicas listed here and it is helpful to look at the “Kind” first because this tells you what the file is all about.
Notice that you have metadata and a specification. A specification now gives you the number of replicas but it also gives you what is called a “Selector”.
The interesting thing here is something called the “Template”. So when you create a Pod you can do that in a Pod that in .yum1 but in our Replication Controller.yum1 see deployment as well. That is to a pod that will become the replicas in this Yum1 file. So you are saying I have a name of nginx and that will be the name of the Pod and its will have labeled of an app of nginx and then the containers inside this pod and if you go with the flow the Docker image here is the image that you would have given if you had Docker.
Now a selector which we mentioned before the way these works is you provide one, in this case, is A name and value in your app of nginx and then anything that you define in your templates which gives your pods.
Any pods that have a label that matches a selector will become part of whatever kind you are dealing with.
So, in this case, we created a pod replica 3 i.e. we have created 3 pods with this app in nginx later would end the selector for the replication controller before any pods that have apps nginx and they get sort of attached to this replication controller.
So if we were to create this series of 3 pods it will go like this
$kubectl create -f replication.yam1.
You could watch:-
$watch-n- kubectl get all >> this meant you would see pods and they are 3 of them and then there is a postfix that you need to identify each of them.
But it turns out that this ReplicationController is being replaced by Replica Sets when they are in practice. But there is so much like a replication controller which we do like(RC).
In Fact, if you notice you will see that Replica sets are a new type, currently in Beta, that represents an improved version of Replication Controller.
Currently, the main difference consists of being able to use the new set based label selectors as we will see in the following examples:
But to use Replica sets you first create something called a deployment and a deployments means it improve on the basic mechanism of rolling update and Replication Controller.
Deployments will give you blue/green deployment sets as well as Canary deployments.
Where a blue-green is deploying all at once and the essence of canary deployment is deploying incrementally.
Off course the things if you are deploying are your sets of replicas that are your sets of pods i.e. the services are on the last component is “Services”.
Now we talked about services in previously also so the idea is that you will take something like a deployment and in the service will rap around it. So for ex:- you have a mastering 2 nodes and this first pod i.e. pod1 and other pods 2 actually worked together as the single deployment.
You can create a service that creates an IP, DNS, Port that will not change if your pods go down.
So might consider an example of a service that contains a Kind: Service, Metadata with the name and a selector and ports that provide the protocol- TCP, Port service type that people can connect to. And the target port here first two the ports on the pod some of them are the service ports those really given pod and because these pods belong to a replica set which is really doing is this – You are actually looking at load balancing that back end pod 1, back-end pod 2 from the service and that load balancing could by the way on the 2 or 3 or multiple nodes. Load balancing from this point is exactly happening here at this level- as the replica set controls both these back-end pods but its all up to the deployment that controls which set you are currently to migrate from version .1 to version .2 that the deployment part.
Remember that we have set replications that were almost the same thing as the replication controller: side by side you can see a replication controller. That was making 3 replicas is of a certain pod the pod comes as a template.
Take a look at a deployment. The deployment is created in your replica set.
So everything below this in you can see is considered to be a replica set. The set of the 3 where the pods are going to create a template follows the same structure as a replication controller.
Thus you can create one deployment1 and another deployment as 2. Why do we need deployment? But I don’t create a replica set the answer is here-
When you use deployment you don’t have to worry about managing the Replica Sets that they create deployments own and manage that replica sets. i.e. you may never need to manipulate replica set objects. Use a deployment instead and define your application in the specification section.
Visit – Hostdens
You must log in to post a comment.