‫Some of the commands you've been using, so far, have
‫a little bit of automation behind them known as
‫generators. Generators you can think of like templates.
‫They essentially create the spec, or the specification,
‫to apply to the Kubernetes cluster based
‫on your command line options.
‫You think of commands like run, and expose,
‫and create. They often will have generators behind
‫them that give the template necessary
‫with all the fields and the defaults that you're not
‫necessarily specifying at the command line.
‫Essentially, the point of these generators is to make it
‫easier for you to use one-line commands, like you've been
‫used to with Docker, and Docker Compose, and Swarm.
‫To use those one-line commands in Kubernetes while
‫leaving some of the more advanced settings up to defaults.
‫Really, Swarm does this, too.
‫Swarm has a lot of defaults when you create services and
‫stacks that are all happening in the background.
‫You just don't know it. These generators are like that.
‫Here is an example where we're creating a Deployment
‫with the create command, and we're giving it a couple of
‫options to meet the minimum requirements.
‫It will fill in the rest of the specification
‫with a generator.
‫These generators are different for each type of thing
‫you're creating. Whether it's a service, or deployment,
‫or a job, or a cron job.
‫Other stuff we'll talk about later.
‫Those generators can actually change over
‫time as each version of Kubernetes comes out.
‫They might change one or two properties of that
‫specification.
‫So, these have versions.
‫Sometimes if you've seen in documentation you might see
‫some YAML for Kubernetes, and it says something about beta.
‫That's often when a generator is first created,
‫it might have a beta version and then as it graduates
‫to a mature generator, it'll have a V1.
‫We can't really get a list of generators at the command
‫line because it spans different commands and different
‫options what generators might get used.
‫The easiest way here throughout all these different
‫commands to see what would be generated if you type
‫that command against a cluster, is to use two options.
‫The dry run, which is a really neat way to show
‫the output of what you typed, and we'll see that
‫in a second. Then the -o, which means
‫output. We're saying we want an output in YAML.
‫We're essentially saying run this command but don't
‫technically do it on the cluster.
‫Just try it out to see what would happen if I did it.
‫Then at the same time, show me the YAML output
‫of what would be generated if I finish this command.
‫You'll get nice little templates essentially.
‫You could even use that to start creating your own YAML
‫that we'll use in later lectures.
‫Finally, generators here.
‫You might also consider them opinionated defaults.
‫They really aren't opinionated.
‫They're super small.
‫They're usually 10 to 15 lines of YAML.
‫Just the bare minimum to get a thing started.
‫They do have opinions, though, which is why they're having
‫versions. You might see a beta version graduate and
‫whatnot. I do consider them opinionated
‫but they're fine, right. They're going to work for most use
‫cases when you're just trying things out for dev and test.
‫Let's go through a couple of examples to see these
‫generators at the command line.
‫The first one here is a Deployment like we've used before.
‫The create deployment.
‫You'll notice that I put the --dry-run at the end.
‫If you just do a dry run, it will only spit out
‫the type of resource it would create.
‫This is similar to the name of the resource we see when we
‫list it out with a kubectl get command.
‫If I hit the up arrow there and type -o
‫yaml on the end, it will then show me
‫the YAML output that it generated with that command.
‫We're going to go through YAML specifications
‫later. For now, you can see the major parts
‫of what was done in the background when we did that
‫create deployment command.
‫First, it shows the API version, the version
‫of this type of resource.
‫So, we're using a apps/v1 version
‫here. The kind is the deployment, and
‫that's because we're creating a Deployment.
‫If it was a Job, it was say job.
‫If it was a Service, it would say service.
‫That kind of thing. The metadata is always going to be
‫there for any resource you create.
‫It will have the timestamp, which is optional, because it
‫will generate that automatically when you really create
‫this thing. Then you're going to have labels and then a
‫name attribute here that you can specify.
‫In this case, you're seeing that it's filled a lot of this
‫in with what I gave it at command line.
‫I told it I wanted to call it test.
‫So, it's giving it a name of test.
‫It's assigning it an app since we're using a Deployment
‫here, it considers it an app, not a service or something
‫else. It'ss calling that label test.
‫These are just defaults out-of-the-box.
‫Then the spec for the Deployment
‫is replicas of one.
‫The selector we'll get into later, but that's essentially
‫how this thing determines to select the pods inside
‫this Deployment. It's basically what matches that
‫Deployment to its pods.
‫Then strategy. Which we leave blank.
‫The template here is for the ReplicaSet.
‫Then you'll see under that spec the containers that it will
‫create. So, there's a little bit of a nested layer of spec
‫thing going on here. That's due to the complexity of these
‫layers, right. We have pods, then ReplicaSets, and then
‫Deployments on top of that.
‫You can see that it's creating all that on the fly, and
‫we'll apply that to the API when we hit
‫this command.
‫Let's create a few more here. The second one is using Jobs
‫instead Deployments. It's usually designed when
‫you want to create a set of pods that will run once.
‫It tends to set them with a default to not restart.
‫In this case, we're going to use the same image, the same
‫name. We're going to dry run it with the -output
‫yaml. You'll see how much different it is.
‫In this case, since we don't have the multiple levels of
‫a Deployment with ReplicaSet nested inside it, we
‫don't need the multiple levels of spec.
‫You'll see, first off, that this one is much shorter.
‫That's largely due to the fact that with Deployments, it
‫creates a nested ReplicaSet which then creates
‫the pod. So, there's multiple levels there.
‫Where here, we really just have this batch job
‫creating pods directly for us.
‫You can see up at the top that the API version and the kind
‫have both changed.
‫The metadata is very similar, although in this case, it
‫didn't create an app label.
‫The spec is just for the Jobs
‫and then below it, the spec inside it, inside that
‫template, is the spec for
‫each container pod, right.
‫This one spec would be created for however
‫many I asked it to create.
‫We only created one by default.
‫So, it's going to have one container running Nginx with
‫the name test. You'll notice that the restart policy
‫is never. That's the change, really, with
‫most of these other ways of creating containers in
‫Kubernetes. They will automatically try to recreate, or
‫restart. With a job, or later
‫with a cron job, you'll see that the restart policy is set
‫to never. Because typically once a job finishes,
‫it's just done, and you don't want that container recreate
‫it. Lastly, let's do an expose command.
‫Even though there's a dry run here,
‫when you run expose deployment, it's going to check
‫for that deployment and realize that it doesn't exist, so
‫it can't give you the sample output because it doesn't
‫really have the valid input.
‫In this case, we technically need to create a Deployment.
‫In this one, we don't need it to be dry run and
‫output. We just want it to create it.
‫So, let's just do that.
‫Then, let's go back up to that expose command and
‫try it again. Then that dry run will
‫work this time. We'll have an API version of V1.
‫You'll notice that the Service is the kind now instead of
‫Deployment or Job.
‫Then, we've got other similar labels.
‫You'll see that the spec is all about ports and protocols
‫because that's really what a Service is.
‫It's the combination of network routes
‫and IP subnetting and TCP or UDP ports,
‫and stuff like that. Generators aren't necessarily a huge
‫deal. You don't need to memorize them or learn the
‫differences between all of them. Because as you'll find a
‫lot of them with the kubectl run command are going away,
‫as you'll find out in a minute. Then in a later lecture,
‫we'll talk more about the types of ways you create
‫containers and maybe why you won't be using a whole
‫lot of run and creates in your production workloads.
‫Remember to delete the test deployment if you created it
‫for our last command where we tested the expose.