‫There are two pieces of metadata in this YAML that
‫you probably have seen in the examples and
‫thought about, wondering what labels and annotations
‫are really there for.
‫You probably didn't realize their significance.
‫They're a key component of Kubernetes and
‫how things connect to each other.
‫Much more so than Swarm.
‫The first one is labels. Labels go under the metadata
‫key in the root of the file, so they're
‫optional there. You don't have to put them but they are
‫a key value, or a list of key values, underneath
‫the labels heading.
‫Those are there for multiple reasons.
‫They're not always required, but you may need them for
‫selecting the objects, grouping them
‫and even filtering them later on.
‫This can be anything that describes the
‫object or the resource.
‫It can be a key value pair that the value
‫is simply true or false.
‫The keys can be whatever you want.
‫There just can't be more than one key in each object,
‫so you can't have two keys in a row in the YAML
‫for the same object that have the key name of, let's say
‫app, right. These are used really to describe
‫the object. These resources that we're creating
‫have different properties to them.
‫Maybe it's the environment like prod, dev or test.
‫Maybe it's the location like dmz, or
‫backend or frontend. Maybe it's the app name, or
‫maybe it's the client name, if you're hosting client sites
‫or something. It could just be whatever you want and
‫there's not a whole lot of standards.
‫The Kubernetes documentation listed in the resources here
‫does give you some examples, but those are just examples.
‫There's not a whole lot of standards in the industry.
‫It's really up to your team, and your company, about how
‫you want to describe this thing.
‫We also have annotations. They're sort of a yin and yang.
‫The labels are very simple.
‫They are very limited in size and what characters you can
‫put in them. They're meant to describe the resource.
‫With annotations, this is for more complex
‫data and multi-value data, stuff like that.
‫You'll usually see annotations used when
‫you're adding custom stuff into Kubernetes that
‫can talk to Kubernetes and get data out of it.
‫The annotations are there to maybe store config data, like
‫proxies and ingress stuff can often store
‫different configurations, inside different annotations.
‫So, those are not necessarily there
‫for describing but more for configuration.
‫Let's go back to labels for a minute, because there's a lot
‫more to that that's key to understanding how all this stuff
‫works in Kubernetes.
‫The first thing is that we can do simple filters
‫by limiting to the labels from the command line.
‫We can do a get pods and just say, only show me
‫the pods with this label.
‫You can even use a comma there to add multiple labels.
‫In fact, there's a whole level of syntax
‫to this thing where you can do different types of syntaxes,
‫different or's and and's.
‫Really, it's one of those things where I don't want to
‫teach you all that because it's going to be like learning
‫Regex. It's something where you won't really learn it by
‫just trying it once.
‫It's only when you need it that you're really going to
‫understand it. The documentation from Kubernetes is really
‫great. They've got multiple links I've put in the resources
‫that will take you through the path of all the different
‫ways that you might need labels.
‫Quite frankly, you don't really need to learn that until
‫you know you need it to solve a problem.
‫You can even use it for apply commands.
‫If you had a whole bunch of stuff in one big YAML
‫file and you only wanted to apply certain parts
‫of that YAML file.
‫I don't do this a whole lot, but it is there where you
‫could limit it to say, only apply
‫the changes or information that you've put in the YAML
‫for specific labels.
‫Of course, again with this one, you can put the same
‫syntax. You can just have a single label.
‫You can put in commas, have multiple labels and values
‫there. It's up to you.
‫There's another thing that the labels do that's
‫important to how Kubernetes works.
‫It comes down to there are certain
‫resources that talk to other resources, or connect
‫to them, or are related to them.
‫However you want to say it. The good example is the
‫services need to know which pods to send their
‫traffic to. You might wonder how does it know?
‫I mean, when you type it in, if you do a kubectl service
‫Command and you're pointing it to the deployment,
‫what exactly is it using to identify that deployment?
‫Well, in the CLI, you would think that it's actually
‫pointing to the deployment object.
‫But really, the service needs to talk to the pods, not
‫the deployment itself.
‫It's using something called label selectors.
‫This is common with lots of the different resources
‫that are higher levels of abstraction of pods.
‫For them to relate to the pods, or to know which pods are
‫their's, they use label selectors. You will see that
‫in the YAML inside our repo that you've been using
‫for the last few lectures.
‫If you look in the app.yml, you'll notice that all along,
‫we've had a couple of things in there that we haven't
‫talked about. The first one is at the top part with the
‫service, we have under the spec a selector.
‫That has to be there.
‫We're telling it the key and value of a label
‫for pods that it needs to direct traffic to.
‫That's just a simple match.
‫It needs to find pods with that.
‫Then down in the deployment underneath, you'll see that our
‫spec has its own selector,
‫matchLabels, app, app-nginx.
‫What's happening there is both of those objects are
‫selecting pods based on that match.
‫That means in the template under our spec, where we're
‫templating out the pods, that needs to have
‫that label in it so that those resources
‫can find their pods.
‫The nice thing is in the later versions of Kubernetes, is
‫that at least with just a single deployment, these have
‫to be in sync. It'll actually fail to deploy if it
‫sees that the selector match labels
‫isn't matching the template metadata labels
‫because they have to in order for it to even deploy the
‫pods and be able to control them.
‫It's there to kind of prevent you from accidentally doing
‫it the wrong way. It will expect you to have those pieces
‫in there. In older versions, there used to be a way where
‫it would automatically generate them, by default, so you
‫could leave the stuff out. They've stopped doing that now,
‫and they force you to put this in there. I think that's a
‫good thing, especially how important these labels selectors
‫are. Technically, if you went back to Swarm, Swarm
‫does a little bit of this out-of-the-box where it has
‫labels that match things up from stacks to services,
‫and stacks to their volumes, and stuff like that.
‫We don't really get to control it, and we don't see it a
‫whole lot in the interface. It's kind of done in the
‫background for us in Swarm.
‫But, it's also very limiting.
‫You can't change things on the fly.
‫You can't necessarily go and customize those for really
‫unique setups.
‫Here, we could possibly have a
‫service talk to multiple deployments if we
‫wanted to change those selectors.
‫Selectors aren't just about linking resources together.
‫It's also about controlling where they go.
‫On the nodes, you can use labels and selectors
‫to control where they go.
‫You can use even further customization with things called
‫taints and toleration that are sort of the inverse
‫of that where you're telling nodes that they can't
‫do certain things so that Kubernetes knows where
‫to basically control where your pods go.
‫These things get really custom and really advanced
‫pretty quickly. Doing them all together can get
‫a little bit hairy and crazy.
‫I definitely recommend that you take it slow with them.
‫Keep it all simple out-of-the-box.
‫Avoid taints and tolerations until you really
‫need to look into those.
‫All right. Let's clean up for this whole section.
‫If you have anything running in a default namespace
‫for your cluster, if you just do a kubectl get all, and you
‫see stuff there beyond the Kubernetes API itself, then
‫go ahead and delete all those resources because we're
‫going to be moving on. We won't need those.