Kubernetes: Understanding Resources via YAML, Deployments, Replica Sets, and Pods

at this point you've probably heard of pods services containers replication controllers and replica sets but it may not be particularly clear what the order is what is the largest of these things what's the smallest and how are they related to each other and by things we should be specific and point out that they're actually resources in the language of kubernetes and it turns out that the smallest of all of these is actually a pod now you might think well why is it not a container well it turns out that as we know from before containers sit inside of pods and you can have more than one container in a given pod so although you're right containers are smaller than pods if you look at this book you'll see that in the VM world the atomic unit is a virtual machine and in docker it's a container but in kubernetes it's a pod so how would you know that probably the best clue is to run a cube CTL get all all namespaces out wide which we've talked about before because here you'll notice a column called name with a slash dividing something on the left and something on the right the left is the type of resource and on the right is its actual name and so you see that a deploy is the resource type and then you have the name but the containers themselves are inside of that and if you continue down the line you'll see various types of resources so you have a replica set and you have pods and you have deployments and you also have replication controllers and it turns out that replication controllers are next and they are abbreviated as or C so first of all why replication controllers well we know that if you have a series of pods and they're all doing roughly the same thing then we need to distinguish between them so you can have a number like a 1 and then a 2 and then a 3 and each of these are called replicas so you have replicas 1 2 & 3 here so how would you see that in practice well if you had a yamo file like replication dot yamo you would see the number of replicas listed here and to give you an idea how this file works I think it's helpful to look at the kind first because this tells you what this file is all about notice that you have metadata and a specification the specification obviously is key the number of Records but it's also giving you what's called a selector we'll talk about that later but the interesting thing here is something called a template so when you create a pod you can do that in a pod that Yamma but in a replication controller and we'll see in deployments as well you'll have something called a template and the template refers to the pods that will become the replicas in this yamo file so you are saying I have a name of Engine X and that will be the name of the pod and it will have a label of an app with engine X and then you have the containers inside this pod and if you're familiar with the docker world here is the image that you would have given if you had docker now a selector we've mentioned before the way this works is you provide one in this case it's 8 name and a value pair app and engine X and then anything that you define in your template so here's your pods any pauses that have a label that matches the selector will become part of whatever kind you're dealing with so in this case we created a pod we'll create actually three pods with this app engine X label and the selector for the replication controller is looking for any pods that have App Engine X and they get sort of attached to this replication controller so if I were to create this series of three pods it would look like this you could watch it with this command you would see pods and there are three of them and then here is a postfix to uniquely identify each of them but it turns out that replication controllers are being replaced by replication sets in daily practice but there's so much like a replication controller will just do this and in fact if you look at this book you'll see that replica sets are a new type no longer in beta that represent an improved version of replication controllers and the main difference is that they can use the new set based and I mean replica set based label selectors but to use a replica set you first create something called a deployment and deployments improve on the base mechanisms of rolling update and replication controllers and deployments will give you blue green deployments as well as canary deployments where a blue green is essentially deploying all at once and a canary deployment is essentially deploying incrementally and of course the things that you are deploying are your sets of replicas that is your sets of pods and that means that services is our last component up here now we've talked about services in a previous video but the idea is that you would take something like a deployment and in the service would wrap around it so for example if you have a master in two nodes and this pod and this pod actually work together as a single deployment you can create a service definition that creates an IP a DNS and a port that will not change if your pods go down so you might for example have a service that looks like this the kind is service metadata with a name and then you have your specification where you again have your selector and ports that provide this sort of abstract service type that people can connect to and a target port here refers to the ports on the pod so in other words that service port is really connecting to cue proxy on whichever node in that given pod and because these pods belong to a replica said what you're really doing is this you're actually load-balancing that back-end pod 1 and back in pod 2 from the service and that load balancing could by the way be on node 2 or 3 or multiple nodes and just a drive home at this point that load balancing is actually happening here at this level as the replicas set controls these back-end pods but it's the deployment that controls which set your currently and so if your once it migrated from version one to version two that's what the deployment will help you do and remember that we said at replication set was almost the same thing as a replication controller here they are side by side and you can see replication controller remember that it was making three replicas of a certain pod the pod comes from a template here's the template take a look at the deployment the deployment is creating your replicas set so everything below this you can consider to be the replica set the set of three where the pods it's going to create essentially fallout the same structure as a replication controller does so in other words this could be one deployment this might for example be dot one and then you create another deployment and that could be two now in case you're wondering why is it that I create a deployment kind but I don't create a replica set kind the answer is here when you use deployments you don't have to worry about managing the replica sets that they create the deployments own and manage their own replica sets so what that actually means is you may never need to manipulate a replica set object use the deployment instead and define your application in the spec section in other words if you actually created a replica set it would look something like this but you don't have to because when you create a deployment kind this replica set is actually located under spec so don't let that confuse you it's essentially created by providing a spec section

Channel: Sean Wingert

Views: 70,658

Rating: 4.9323382 out of 5

Keywords:

Id: ohSUtEfDefc

Length: 7min 49sec (469 seconds)

Published: Mon Oct 02 2017