‫Hopefully this YAML stuff is starting to make a little bit
‫of sense, and this is where we learn how
‫to create essentially this YAML from scratch.
‫When I started learning the Kubernetes
‫YAML format, I first started off just using
‫documentation examples, right, from their docs on the
‫kubernetes.io site, or maybe from other places.
‫The thing about other places is, just like Docker, is those
‫blogs and other stuff, they all get outdated.
‫The thing about Kubernetes is some of these things have
‫changed over time, especially when it comes to things like
‫deployments, and pods and other core
‫stuff. They've tweaked their formats.
‫The versions in the API have changed.
‫We want to stay on the current
‫stuff, which means you need to know how to start from
‫scratch. How do you know when your files need to change
‫rather than just going and rereading the documentation
‫randomly to see if anything's changed, right.
‫This part is, I think, a skill that it took me a
‫while to figure this stuff out, and how to
‫build a file without using some sort of pre-existing
‫template. We talked about the four types in the last
‫lecture, and that root key of kind,
‫which is the resource type, is what I want to focus on
‫first. Because you can get a list of those in a cluster.
‫In our setup test clusters, most of these will be
‫the same between all of us.
‫As you get into production and you start adding third-party
‫stuff to your cluster, this list will get longer
‫depending on what you're using because third
‫party tools can add new resource objects
‫to the API.
‫Let's do a kubectl api-resources.
‫You'll get back at least dozens
‫of different objects that we could scroll through and talk
‫about for hours.
‫We're not going to do that.
‫We've already talked about a few of them like Deployments,
‫and Pods, and ReplicaSets and Services.
‫Those are the standard out-of-the-box things.
‫A lot of the rest of this you may never touch.
‫That's the thing about Kubernetes is there's just so much
‫to it that you may never actually need all
‫the power from it. It's not that important that you go
‫through and memorize all of these.
‫You'll notice this kind column over on the right.
‫That's what goes in our YAML file.
‫If we want to create a pod, you can see that there's a kind
‫pod here. If we want to create a deployment, there
‫is a kind called deployment.
‫You'll also see the API group.
‫That API group is related to the API
‫version. You'll see that in a second.
‫This doesn't exactly give us a prescriptive manual
‫necessarily. But, if I was sitting here and I said, I need
‫to create a pod, I would look through this list for pods
‫in the type of resources.
‫I would see the kind that it is.
‫That's what I know I need to put in my YAML.
‫I would see if there's any API group because that's going
‫to tell me where to find the versions
‫that I can use, because you probably have seen different
‫documentation for let's say a deployment.
‫Because deployments had multiple versions over time.
‫There was a v1beta1, a v1beta2.
‫It's actually even moved around in the API because there's
‫old stuff and new stuff, so it can be a little confusing.
‫If you look at this list, you'll actually find that there
‫are deployments up here,
‫and there are deployments down here.
‫The only difference between the two is this middle
‫row, the API group.
‫That API group is where in the API
‫this type of resource can be accessed, created,
‫deleted, etc.
‫This gets a little bit into the weeds, but once
‫you start working with this stuff, you're going to have to
‫spend a little bit of time when you see cases like
‫seeing two types of deployments here.
‫Which one do I use?
‫Well, you start to go and do research and you'll find,
‫either in the documentation, or in the API
‫guide itself, which we'll look at in a little bit.
‫You'll see that stuff where it'll tell you one's
‫deprecated, and one is moving to another one and in
‫this case with deployments, the new version of it, in the
‫latest version, is the app's API.
‫The next command that goes along with that, to help
‫us get a better picture of kind, plus
‫API version, is the kubectl API
‫versions command.
‫That gives us a shorter list which is just
‫the different versions of APIs that we need to
‫worry about. In the case of deployments,
‫you'll see on here that there's something familiar.
‫Remember, we saw that there was an apps one, and there was
‫an extensions one for deployments.
‫We'll see those show up here.
‫Technically, there's the extensions of v1beta1
‫API. There is the apps API
‫of which you can see three different versions there.
‫You probably would want to use the V1 apps,
‫not the older betas.
‫But, you can see where the API is sort of holding
‫on to deprecated versions of this API
‫as it rolls out new ones.
‫That way, basically, your old YAML isn't broke until
‫many versions go by and they pull stuff out of the API
‫once it's no longer needed.
‫What typically happens over the lifetime of your YAML, if
‫you were on the early days of Kubernetes, is you might have
‫been using a YAML file that said
‫extensions/v1beta1
‫for the API version, and the kind
‫was deployments.
‫But, as that API has changed, and they're now
‫calling it the apps API, and
‫the version is different, you would still have kind
‫of deployment, but you would change that API version
‫to be apps/v1 now.
‫The way I know that is because I had to do searching
‫and you'd look at the documentation.
‫You see in the examples that, oh hey.
‫It says apps now. It doesn't say extensions anymore.
‫That's weird. Let me go look it up. Then you find some
‫Kubernetes issues in GitHub that talk about it.
‫It's a little messy. There's not always a clear
‫deprecation list of everything that's changing all the
‫time, so it can be something that is a problem.
‫The way that you'll know that this doesn't work is when you
‫take an old YAML and you apply it to a new cluster, and
‫it will tell you, I don't support this API
‫version anymore. Or, I don't know what this kind is.
‫So, it'll give you a nice errors that lets you know that,
‫hey that's the problem. Then, you can probably do some
‫quick searching and find out what's outdated.
‫The point I'm making is that the kind, plus
‫the API version, are used together to
‫decide which resource you're going to get and which API
‫version you're going to be able to use for that resource.
‫Those are the first two things you need to figure out
‫before you even create a YAML.
‫Once you have that, then you're going to create the
‫metadata part. The only thing you have to have there is the
‫name of the resource you're going to create.
‫Just give it a nice name.
‫Then, you're going to go to the spec. That's where all of
‫the action is at because the spec is going to be completely
‫different based on the resource you're creating.
‫If you're creating storage versus a deployment,
‫you can imagine how the YAML would be quite different,
‫right.
‫In the next lecture, we're going to go through some kubectl
‫commands to help you explore the API
‫for all the different spec stuff that you can put
‫into your YAML for different resources.