‫So far, we've discussed that the YAML, there could
‫be...there's four root objects, and we've talked about
‫three of them briefly.
‫This is all about the spec.
‫The details of what you want it to do, right.
‫We first had the API, so we know what version of the API
‫we're talking to. We know what resource we want to talk to
‫and we're going to mess with.
‫Then, we know the name in the metadata.
‫We've got that. After that, the spec is
‫a whole world to explore.
‫The first command I want you to learn is simply
‫how to list all the different keys
‫that you can put for a particular resource type.
‫The first command I need you to learn the
‫kubectl explain, and then the resource type.
‫That's the kind in the YAML.
‫Then --recursive.
‫This will show you all the different keys
‫that it supports in the YAML file.
‫Just for services, you can see that it comes back with a
‫lot. It's a little bit overwhelming.
‫There's so much in there.
‫Of course, it doesn't tell us what those things do.
‫But, this is at least a quick list of all of
‫them. What this is good for for me is when I'm doing
‫my YAML building is if I can't remember exactly
‫the name of that thing, the creation timestamp.
‫Is it timestamp creation?
‫Is it plural? Is it singular?
‫You can just use this as a quick look up.
‫But, this isn't going to tell you what these things do, or
‫which ones are required or anything like that.
‫We can drill down using a slightly different command
‫and get more details.
‫Let's do the kubectl explain services
‫again, but this time, we're going to use a dot notation
‫to drill down in the YAML.
‫I'm going to say I only care about the spec.
‫I'm with you a .spec.
‫This time, I get back just the subkeys
‫of the spec and then a little description about them.
‫Then, what type of value they support, right.
‫Whether is it a Boolean? Is it a map of objects?
‫Stuff like that, right. It's just a nice little reference.
‫This is going to help you from jumping over to
‫documentation. You can avoid that a little bit by looking
‫here. This can still be a lot, especially when
‫you just want to look for one attribute.
‫You can keep drilling down that dot notation.
‫If we do spec.type, that is a particular
‫key inside of services YAML that
‫tells us the type of the load balancer.
‫If you remember this from talking about services earlier in
‫this course, this could be the cluster IP, by default.
‫If you just leave it out, it'll just do the cluster IP, or
‫a node port, or load balancer.
‫That's where you would specify that.
‫You know that it would have to go underneath spec
‫and then the key of type in your YAML file.
‫In this case, we could just start writing our YAML, right.
‫We know that the kind is going to be service.
‫The API version, it says here, is v1 for
‫this type. You could also verify that with the api-versions
‫command like we did earlier.
‫Then you can put in your value.
‫This lists the working value, so you know that
‫cluster IP is with a capital C and a capital IP,
‫stuff like that, right. Keeps you from going and
‫potentially searching all over the Internet.
‫You never know whether someone's going to be outdated or
‫correct at all.
‫This is how I like to do it.
‫Just to show how far this dot notation can go.
‫If we looked at a deployment spec, because it
‫has subspecs, which is something we hadn't
‫talked about. You can have a resource as a subobject
‫of another resource.
‫In this case, volumes, right, for storing the data.
‫We could have as many volumes as we want inside
‫a deployment, which it would then connect it to the
‫containers. Those are definitely
‫their own resource types, right, of volume.
‫In this case, we're going to see the spec twice.
‫If I were to hit enter on this command for
‫deployment.spec, one of the things in there
‫would be template.
‫Then I could just type template.
‫Then it would list all the different keys that I could put
‫in there, and one of them is spec
‫of the template.
‫Technically, we're in the spec of a spec.
‫Then underneath that spec for the template of a pod,
‫because a deployment has its own spec, and then the
‫template for the pods is underneath
‫that spec. Then it has a spec for the containers,
‫and I might have volumes in here.
‫So volumes and then nfs because that's a type
‫of volume I can use.
‫Then the server that I'm going to use inside in NFS.
‫Here we go. I could get the description and the information
‫about versions. By the way, this is another quirk with
‫Kubernetes is the documentation on the command lines is a
‫little outdated when it comes to versions which is why I
‫always use the API versions command, along with the API
‫resources. Because this is the old way
‫to do it before. They now have the new apps/v1
‫for deployments. I just happen to know that because I was
‫exploring why this was this way and it turns out that
‫they're keeping it this way in the documentation until it's
‫completely deprecated.
‫Anyway, you can see how I would eventually
‫work my way down the pipe with a dot notation.
‫I would just be deployment. Then I would look at that.
‫And then I would .spec, and so on and so forth.
‫That would be how I eventually find the right
‫keys and values to put in my YAML.
‫You can always go use other people's examples.
‫What you'll probably end up with is
‫you'll start out with some examples from either me or the
‫documentation.
‫Then you'll want to sort of see if you can
‫go from pure vanilla file using
‫my method here. Then you'll end up with your own little
‫resource, right. Your own little copy of all these resource
‫YAMLs. That your private repository
‫of knowledge. That'll be what you use in your company.
‫You might even have standards for how you create
‫deployments and standards for how you create services.
‫Maybe they'll have special labels or annotations on them,
‫which we haven't yet talked about.
‫They'll maybe have a special template features.
‫Anyway. There's lots you could do there, but most teams end
‫up with their own defaults in a repo of sorts that they
‫pull from rather than completely typing from scratch.
‫Right. We don't do that with compose and we certainly
‫aren't going to want to do that with the YAML here in
‫Kubernetes. The last little tip I'll give you here is if
‫you're more on the developer side of things, you will
‫always appreciate the API documentation,
‫which you can get all this same data from.
‫It's just not necessarily in a way that a more
‫operating-focused person would understand.
‫I come from both backgrounds, but I can definitely see how
‫the API documentation can be a little intimidating to
‫someone who's not used to reading swagger
‫and all these other types of documentation for APIs.
‫Here, I'm just going to pick, for example, on the
‫Kubernetes reference for the API under
‫115, so that's versioned.
‫I could see here, on the left, a menu of
‫all the workload API.
‫These are going to be most of the things you'll be dealing
‫with. Then there's service API.
‫These things go on top of your workloads,
‫like the services, or the ingress, endpoint, stuff like
‫that. Then you have configs and storage down here.
‫As you go, you'll actually get to more deprecated
‫or legacy API versions.
‫You could explore whether...you'll see in here like a lot
‫of these alphas and betas.
‫You can kind of figure out which ones are there.
‫If I just went up to deployment real quick
‫and came here, I could get some kubectl examples
‫of what it might look like.
‫I could also scroll down here
‫and look for the spec.
‫The spec of something is where you're going to get all that
‫detail that we were looking at earlier.
‫Underneath the spec, you'll see all these different
‫options for that particular object.
‫If I dive into the template of the deployment spec, if you
‫remember from a while ago when I was following the dot
‫notation, that'll go into the pod template.
‫Then we'll jump over here into that and you'll see
‫all these things jumping into that template, and so on and
‫so forth. It requires you to dig around a little bit to
‫figure out and find the objects and the keys that you're
‫looking for. I find that it's a little bit easier to work
‫from the command line, but the command line
‫also doesn't deal with the versions.
‫If you've got a different version of a client then your
‫server version, you'll want to definitely look at the API
‫docs because your client might be on an older
‫or newer version than what your server can support.
‫There's no real way, at the command line that I'm aware of,
‫to get the different versions of the information.
‫It's always just the version of your client.