Some of the commands you've been using, so far, have 2 2
a little bit of automation behind them known as 3 3
generators. Generators you can think of like templates. 4 4
They essentially create the spec, or the specification, 5 5
to apply to the Kubernetes cluster based 6 6
on your command line options. 7 7
You think of commands like run, and expose, 8 8
and create. They often will have generators behind 9 9
them that give the template necessary 10 10
with all the fields and the defaults that you're not 11 11
necessarily specifying at the command line. 12 12
Essentially, the point of these generators is to make it 13 13
easier for you to use one-line commands, like you've been 14 14
used to with Docker, and Docker Compose, and Swarm. 15 15
To use those one-line commands in Kubernetes while 16 16
leaving some of the more advanced settings up to defaults. 17 17
Really, Swarm does this, too. 18 18
Swarm has a lot of defaults when you create services and 19 19
stacks that are all happening in the background. 20 20
You just don't know it. These generators are like that. 21 21
Here is an example where we're creating a Deployment 22 22
with the create command, and we're giving it a couple of 23 23
options to meet the minimum requirements. 24 24
It will fill in the rest of the specification 25 25
with a generator. 26 26
These generators are different for each type of thing 27 27
you're creating. Whether it's a service, or deployment, 28 28
or a job, or a cron job. 29 29
Other stuff we'll talk about later. 30 30
Those generators can actually change over 31 31
time as each version of Kubernetes comes out. 32 32
They might change one or two properties of that 33 33
specification. 34 34
So, these have versions. 35 35
Sometimes if you've seen in documentation you might see 36 36
some YAML for Kubernetes, and it says something about beta. 37 37
That's often when a generator is first created, 38 38
it might have a beta version and then as it graduates 39 39
to a mature generator, it'll have a V1. 40 40
We can't really get a list of generators at the command 41 41
line because it spans different commands and different 42 42
options what generators might get used. 43 43
The easiest way here throughout all these different 44 44
commands to see what would be generated if you type 45 45
that command against a cluster, is to use two options. 46 46
The dry run, which is a really neat way to show 47 47
the output of what you typed, and we'll see that 48 48
in a second. Then the -o, which means 49 49
output. We're saying we want an output in YAML. 50 50
We're essentially saying run this command but don't 51 51
technically do it on the cluster. 52 52
Just try it out to see what would happen if I did it. 53 53
Then at the same time, show me the YAML output 54 54
of what would be generated if I finish this command. 55 55
You'll get nice little templates essentially. 56 56
You could even use that to start creating your own YAML 57 57
that we'll use in later lectures. 58 58
Finally, generators here. 59 59
You might also consider them opinionated defaults. 60 60
They really aren't opinionated. 61 61
They're super small. 62 62
They're usually 10 to 15 lines of YAML. 63 63
Just the bare minimum to get a thing started. 64 64
They do have opinions, though, which is why they're having 65 65
versions. You might see a beta version graduate and 66 66
whatnot. I do consider them opinionated 67 67
but they're fine, right. They're going to work for most use 68 68
cases when you're just trying things out for dev and test. 69 69
Let's go through a couple of examples to see these 70 70
generators at the command line. 71 71
The first one here is a Deployment like we've used before. 72 72
The create deployment. 73 73
You'll notice that I put the --dry-run at the end. 74 74
If you just do a dry run, it will only spit out 75 75
the type of resource it would create. 76 76
This is similar to the name of the resource we see when we 77 77
list it out with a kubectl get command. 78 78
If I hit the up arrow there and type -o 79 79
yaml on the end, it will then show me 80 80
the YAML output that it generated with that command. 81 81
We're going to go through YAML specifications 82 82
later. For now, you can see the major parts 83 83
of what was done in the background when we did that 84 84
create deployment command. 85 85
First, it shows the API version, the version 86 86
of this type of resource. 87 87
So, we're using a apps/v1 version 88 88
here. The kind is the deployment, and 89 89
that's because we're creating a Deployment. 90 90
If it was a Job, it was say job. 91 91
If it was a Service, it would say service. 92 92
That kind of thing. The metadata is always going to be 93 93
there for any resource you create. 94 94
It will have the timestamp, which is optional, because it 95 95
will generate that automatically when you really create 96 96
this thing. Then you're going to have labels and then a 97 97
name attribute here that you can specify. 98 98
In this case, you're seeing that it's filled a lot of this 99 99
in with what I gave it at command line. 100 100
I told it I wanted to call it test. 101 101
So, it's giving it a name of test. 102 102
It's assigning it an app since we're using a Deployment 103 103
here, it considers it an app, not a service or something 104 104
else. It'ss calling that label test. 105 105
These are just defaults out-of-the-box. 106 106
Then the spec for the Deployment 107 107
is replicas of one. 108 108
The selector we'll get into later, but that's essentially 109 109
how this thing determines to select the pods inside 110 110
this Deployment. It's basically what matches that 111 111
Deployment to its pods. 112 112
Then strategy. Which we leave blank. 113 113
The template here is for the ReplicaSet. 114 114
Then you'll see under that spec the containers that it will 115 115
create. So, there's a little bit of a nested layer of spec 116 116
thing going on here. That's due to the complexity of these 117 117
layers, right. We have pods, then ReplicaSets, and then 118 118
Deployments on top of that. 119 119
You can see that it's creating all that on the fly, and 120 120
we'll apply that to the API when we hit 121 121
this command. 122 122
Let's create a few more here. The second one is using Jobs 123 123
instead Deployments. It's usually designed when 124 124
you want to create a set of pods that will run once. 125 125
It tends to set them with a default to not restart. 126 126
In this case, we're going to use the same image, the same 127 127
name. We're going to dry run it with the -output 128 128
yaml. You'll see how much different it is. 129 129
In this case, since we don't have the multiple levels of 130 130
a Deployment with ReplicaSet nested inside it, we 131 131
don't need the multiple levels of spec. 132 132
You'll see, first off, that this one is much shorter. 133 133
That's largely due to the fact that with Deployments, it 134 134
creates a nested ReplicaSet which then creates 135 135
the pod. So, there's multiple levels there. 136 136
Where here, we really just have this batch job 137 137
creating pods directly for us. 138 138
You can see up at the top that the API version and the kind 139 139
have both changed. 140 140
The metadata is very similar, although in this case, it 141 141
didn't create an app label. 142 142
The spec is just for the Jobs 143 143
and then below it, the spec inside it, inside that 144 144
template, is the spec for 145 145
each container pod, right. 146 146
This one spec would be created for however 147 147
many I asked it to create. 148 148
We only created one by default. 149 149
So, it's going to have one container running Nginx with 150 150
the name test. You'll notice that the restart policy 151 151
is never. That's the change, really, with 152 152
most of these other ways of creating containers in 153 153
Kubernetes. They will automatically try to recreate, or 154 154
restart. With a job, or later 155 155
with a cron job, you'll see that the restart policy is set 156 156
to never. Because typically once a job finishes, 157 157
it's just done, and you don't want that container recreate 158 158
it. Lastly, let's do an expose command. 159 159
Even though there's a dry run here, 160 160
when you run expose deployment, it's going to check 161 161
for that deployment and realize that it doesn't exist, so 162 162
it can't give you the sample output because it doesn't 163 163
really have the valid input. 164 164
In this case, we technically need to create a Deployment. 165 165
In this one, we don't need it to be dry run and 166 166
output. We just want it to create it. 167 167
So, let's just do that. 168 168
Then, let's go back up to that expose command and 169 169
try it again. Then that dry run will 170 170
work this time. We'll have an API version of V1. 171 171
You'll notice that the Service is the kind now instead of 172 172
Deployment or Job. 173 173
Then, we've got other similar labels. 174 174
You'll see that the spec is all about ports and protocols 175 175
because that's really what a Service is. 176 176
It's the combination of network routes 177 177
and IP subnetting and TCP or UDP ports, 178 178
and stuff like that. Generators aren't necessarily a huge 179 179
deal. You don't need to memorize them or learn the 180 180
differences between all of them. Because as you'll find a 181 181
lot of them with the kubectl run command are going away, 182 182
as you'll find out in a minute. Then in a later lecture, 183 183
we'll talk more about the types of ways you create 184 184
containers and maybe why you won't be using a whole 185 185
lot of run and creates in your production workloads. 186 186
Remember to delete the test deployment if you created it 187 187
for our last command where we tested the expose.