1
1

00:00:02,470  -->  00:00:05,469
Some of the commands you've been using, so far, have
2

2

00:00:05,530  -->  00:00:08,589
a little bit of automation behind them known as
3

3

00:00:08,590  -->  00:00:11,649
generators. Generators you can think of like templates.
4

4

00:00:12,040  -->  00:00:15,609
They essentially create the spec, or the specification,
5

5

00:00:15,940  -->  00:00:19,329
to apply to the Kubernetes cluster based
6

6

00:00:19,390  -->  00:00:21,100
on your command line options.
7

7

00:00:21,310  -->  00:00:24,429
You think of commands like run, and expose,
8

8

00:00:24,670  -->  00:00:28,059
and create. They often will have generators behind
9

9

00:00:28,060  -->  00:00:29,873
them that give the template necessary
10

10

00:00:31,090  -->  00:00:33,609
with all the fields and the defaults that you're not
11

11

00:00:33,610  -->  00:00:35,320
necessarily specifying at the command line.
12

12

00:00:35,530  -->  00:00:37,570
Essentially, the point of these generators is to make it
13

13

00:00:37,630  -->  00:00:40,689
easier for you to use one-line commands, like you've been
14

14

00:00:40,690  -->  00:00:42,810
used to with Docker, and Docker Compose, and Swarm.
15

15

00:00:43,780  -->  00:00:46,230
To use those one-line commands in Kubernetes while
16

16

00:00:46,780  -->  00:00:49,390
leaving some of the more advanced settings up to defaults.
17

17

00:00:49,810  -->  00:00:51,172
Really, Swarm does this, too.
18

18

00:00:51,280  -->  00:00:53,769
Swarm has a lot of defaults when you create services and
19

19

00:00:53,770  -->  00:00:55,839
stacks that are all happening in the background.
20

20

00:00:55,840  -->  00:00:58,060
You just don't know it. These generators are like that.
21

21

00:00:58,420  -->  00:01:00,968
Here is an example where we're creating a Deployment
22

22

00:01:01,420  -->  00:01:03,699
with the create command, and we're giving it a couple of
23

23

00:01:03,700  -->  00:01:06,219
options to meet the minimum requirements.
24

24

00:01:06,610  -->  00:01:09,459
It will fill in the rest of the specification
25

25

00:01:09,790  -->  00:01:11,079
with a generator.
26

26

00:01:11,350  -->  00:01:13,947
These generators are different for each type of thing
27

27

00:01:14,170  -->  00:01:17,680
you're creating. Whether it's a service, or deployment,
28

28

00:01:17,710  -->  00:01:19,629
or a job, or a cron job.
29

29

00:01:19,660  -->  00:01:20,859
Other stuff we'll talk about later.
30

30

00:01:21,310  -->  00:01:23,319
Those generators can actually change over
31

31

00:01:24,310  -->  00:01:26,751
time as each version of Kubernetes comes out.
32

32

00:01:27,160  -->  00:01:29,709
They might change one or two properties of that
33

33

00:01:29,710  -->  00:01:30,710
specification.
34

34

00:01:30,970  -->  00:01:32,610
So, these have versions.
35

35

00:01:32,690  -->  00:01:35,109
Sometimes if you've seen in documentation you might see
36

36

00:01:35,140  -->  00:01:38,280
some YAML for Kubernetes, and it says something about beta.
37

37

00:01:38,460  -->  00:01:41,730
That's often when a generator is first created,
38

38

00:01:41,740  -->  00:01:44,337
it might have a beta version and then as it graduates
39

39

00:01:44,860  -->  00:01:47,020
to a mature generator, it'll have a V1.
40

40

00:01:47,470  -->  00:01:50,165
We can't really get a list of generators at the command
41

41

00:01:50,260  -->  00:01:52,839
line because it spans different commands and different
42

42

00:01:52,840  -->  00:01:55,210
options what generators might get used.
43

43

00:01:55,510  -->  00:01:58,029
The easiest way here throughout all these different
44

44

00:01:58,030  -->  00:02:00,529
commands to see what would be generated if you type
45

45

00:02:01,150  -->  00:02:04,390
that command against a cluster, is to use two options.
46

46

00:02:04,660  -->  00:02:07,569
The dry run, which is a really neat way to show
47

47

00:02:07,870  -->  00:02:10,222
the output of what you typed, and we'll see that
48

48

00:02:10,900  -->  00:02:13,930
in a second. Then the -o, which means
49

49

00:02:13,960  -->  00:02:16,590
output. We're saying we want an output in YAML.
50

50

00:02:16,970  -->  00:02:19,749
We're essentially saying run this command but don't
51

51

00:02:19,750  -->  00:02:21,580
technically do it on the cluster.
52

52

00:02:21,590  -->  00:02:24,699
Just try it out to see what would happen if I did it.
53

53

00:02:25,000  -->  00:02:28,330
Then at the same time, show me the YAML output
54

54

00:02:28,420  -->  00:02:31,240
of what would be generated if I finish this command.
55

55

00:02:31,630  -->  00:02:34,119
You'll get nice little templates essentially.
56

56

00:02:34,510  -->  00:02:37,220
You could even use that to start creating your own YAML
57

57

00:02:37,840  -->  00:02:39,279
that we'll use in later lectures.
58

58

00:02:39,880  -->  00:02:41,870
Finally, generators here.
59

59

00:02:41,890  -->  00:02:44,619
You might also consider them opinionated defaults.
60

60

00:02:44,920  -->  00:02:46,240
They really aren't opinionated.
61

61

00:02:46,270  -->  00:02:47,599
They're super small.
62

62

00:02:47,620  -->  00:02:49,680
They're usually 10 to 15 lines of YAML.
63

63

00:02:50,440  -->  00:02:52,990
Just the bare minimum to get a thing started.
64

64

00:02:53,350  -->  00:02:56,079
They do have opinions, though, which is why they're having
65

65

00:02:56,080  -->  00:02:58,269
versions. You might see a beta version graduate and
66

66

00:02:58,270  -->  00:03:01,300
whatnot. I do consider them opinionated
67

67

00:03:01,330  -->  00:03:03,669
but they're fine, right. They're going to work for most use
68

68

00:03:03,670  -->  00:03:06,069
cases when you're just trying things out for dev and test.
69

69

00:03:06,520  -->  00:03:08,709
Let's go through a couple of examples to see these
70

70

00:03:08,710  -->  00:03:10,030
generators at the command line.
71

71

00:03:10,510  -->  00:03:12,669
The first one here is a Deployment like we've used before.
72

72

00:03:12,670  -->  00:03:13,779
The create deployment.
73

73

00:03:14,130  -->  00:03:17,439
You'll notice that I put the --dry-run at the end.
74

74

00:03:17,740  -->  00:03:20,740
If you just do a dry run, it will only spit out
75

75

00:03:21,070  -->  00:03:23,590
the type of resource it would create.
76

76

00:03:23,800  -->  00:03:26,229
This is similar to the name of the resource we see when we
77

77

00:03:26,230  -->  00:03:28,449
list it out with a kubectl get command.
78

78

00:03:28,780  -->  00:03:31,770
If I hit the up arrow there and type -o
79

79

00:03:32,690  -->  00:03:34,503
yaml on the end, it will then show me
80

80

00:03:35,680  -->  00:03:38,740
the YAML output that it generated with that command.
81

81

00:03:39,400  -->  00:03:41,108
We're going to go through YAML specifications
82

82

00:03:43,000  -->  00:03:45,939
later. For now, you can see the major parts
83

83

00:03:46,030  -->  00:03:49,120
of what was done in the background when we did that
84

84

00:03:49,240  -->  00:03:50,439
create deployment command.
85

85

00:03:50,860  -->  00:03:53,919
First, it shows the API version, the version
86

86

00:03:53,980  -->  00:03:55,289
of this type of resource.
87

87

00:03:55,300  -->  00:03:58,539
So, we're using a apps/v1 version
88

88

00:03:58,540  -->  00:04:01,659
here. The kind is the deployment, and
89

89

00:04:01,750  -->  00:04:03,460
that's because we're creating a Deployment.
90

90

00:04:03,730  -->  00:04:05,409
If it was a Job, it was say job.
91

91

00:04:05,410  -->  00:04:06,999
If it was a Service, it would say service.
92

92

00:04:07,060  -->  00:04:09,729
That kind of thing. The metadata is always going to be
93

93

00:04:09,730  -->  00:04:12,039
there for any resource you create.
94

94

00:04:12,430  -->  00:04:15,223
It will have the timestamp, which is optional, because it
95

95

00:04:15,430  -->  00:04:17,409
will generate that automatically when you really create
96

96

00:04:17,410  -->  00:04:19,989
this thing. Then you're going to have labels and then a
97

97

00:04:19,990  -->  00:04:22,299
name attribute here that you can specify.
98

98

00:04:22,330  -->  00:04:24,639
In this case, you're seeing that it's filled a lot of this
99

99

00:04:24,640  -->  00:04:26,889
in with what I gave it at command line.
100

100

00:04:26,980  -->  00:04:28,720
I told it I wanted to call it test.
101

101

00:04:29,050  -->  00:04:30,850
So, it's giving it a name of test.
102

102

00:04:31,180  -->  00:04:33,819
It's assigning it an app since we're using a Deployment
103

103

00:04:33,820  -->  00:04:36,459
here, it considers it an app, not a service or something
104

104

00:04:36,460  -->  00:04:38,439
else. It'ss calling that label test.
105

105

00:04:38,680  -->  00:04:40,504
These are just defaults out-of-the-box.
106

106

00:04:40,505  -->  00:04:43,239
Then the spec for the Deployment
107

107

00:04:43,510  -->  00:04:45,040
is replicas of one.
108

108

00:04:45,370  -->  00:04:47,800
The selector we'll get into later, but that's essentially
109

109

00:04:48,040  -->  00:04:50,539
how this thing determines to select the pods inside
110

110

00:04:51,160  -->  00:04:53,099
this Deployment. It's basically what matches that
111

111

00:04:53,100  -->  00:04:54,430
Deployment to its pods.
112

112

00:04:54,970  -->  00:04:56,889
Then strategy. Which we leave blank.
113

113

00:04:57,240  -->  00:04:59,937
The template here is for the ReplicaSet.
114

114

00:05:01,710  -->  00:05:04,769
Then you'll see under that spec the containers that it will
115

115

00:05:04,770  -->  00:05:07,419
create. So, there's a little bit of a nested layer of spec
116

116

00:05:07,530  -->  00:05:10,589
thing going on here. That's due to the complexity of these
117

117

00:05:10,590  -->  00:05:13,259
layers, right. We have pods, then ReplicaSets, and then
118

118

00:05:13,260  -->  00:05:14,369
Deployments on top of that.
119

119

00:05:14,670  -->  00:05:17,365
You can see that it's creating all that on the fly, and
120

120

00:05:17,370  -->  00:05:20,459
we'll apply that to the API when we hit
121

121

00:05:20,460  -->  00:05:21,460
this command.
122

122

00:05:21,750  -->  00:05:24,989
Let's create a few more here. The second one is using Jobs
123

123

00:05:24,990  -->  00:05:28,079
instead Deployments. It's usually designed when
124

124

00:05:28,110  -->  00:05:31,199
you want to create a set of pods that will run once.
125

125

00:05:31,410  -->  00:05:34,620
It tends to set them with a default to not restart.
126

126

00:05:35,010  -->  00:05:37,079
In this case, we're going to use the same image, the same
127

127

00:05:37,080  -->  00:05:39,110
name. We're going to dry run it with the -output
128

128

00:05:40,140  -->  00:05:43,080
yaml. You'll see how much different it is.
129

129

00:05:43,350  -->  00:05:46,094
In this case, since we don't have the multiple levels of
130

130

00:05:46,380  -->  00:05:48,781
a Deployment with ReplicaSet nested inside it, we
131

131

00:05:49,410  -->  00:05:51,329
don't need the multiple levels of spec.
132

132

00:05:51,650  -->  00:05:53,579
You'll see, first off, that this one is much shorter.
133

133

00:05:53,640  -->  00:05:56,189
That's largely due to the fact that with Deployments, it
134

134

00:05:56,190  -->  00:05:58,444
creates a nested ReplicaSet which then creates
135

135

00:05:59,160  -->  00:06:01,679
the pod. So, there's multiple levels there.
136

136

00:06:01,880  -->  00:06:05,249
Where here, we really just have this batch job
137

137

00:06:05,460  -->  00:06:06,930
creating pods directly for us.
138

138

00:06:07,135  -->  00:06:10,026
You can see up at the top that the API version and the kind
139

139

00:06:10,240  -->  00:06:11,240
have both changed.
140

140

00:06:11,580  -->  00:06:14,039
The metadata is very similar, although in this case, it
141

141

00:06:14,040  -->  00:06:16,139
didn't create an app label.
142

142

00:06:16,560  -->  00:06:19,619
The spec is just for the Jobs
143

143

00:06:19,710  -->  00:06:21,540
and then below it, the spec inside it, inside that
144

144

00:06:21,541  -->  00:06:22,766
template, is the spec for
145

145

00:06:24,540  -->  00:06:25,801
each container pod, right.
146

146

00:06:25,802  -->  00:06:29,009
This one spec would be created for however
147

147

00:06:29,040  -->  00:06:30,441
many I asked it to create.
148

148

00:06:30,570  -->  00:06:31,980
We only created one by default.
149

149

00:06:32,190  -->  00:06:35,142
So, it's going to have one container running Nginx with
150

150

00:06:35,250  -->  00:06:38,519
the name test. You'll notice that the restart policy
151

151

00:06:38,520  -->  00:06:41,519
is never. That's the change, really, with
152

152

00:06:41,820  -->  00:06:44,420
most of these other ways of creating containers in
153

153

00:06:44,640  -->  00:06:47,335
Kubernetes. They will automatically try to recreate, or
154

154

00:06:47,610  -->  00:06:49,031
restart. With a job, or later
155

155

00:06:50,760  -->  00:06:53,602
with a cron job, you'll see that the restart policy is set
156

156

00:06:53,820  -->  00:06:56,759
to never. Because typically once a job finishes,
157

157

00:06:56,790  -->  00:06:59,249
it's just done, and you don't want that container recreate
158

158

00:06:59,250  -->  00:07:02,250
it. Lastly, let's do an expose command.
159

159

00:07:02,310  -->  00:07:05,339
Even though there's a dry run here,
160

160

00:07:05,580  -->  00:07:08,079
when you run expose deployment, it's going to check
161

161

00:07:08,970  -->  00:07:11,489
for that deployment and realize that it doesn't exist, so
162

162

00:07:11,490  -->  00:07:14,136
it can't give you the sample output because it doesn't
163

163

00:07:14,610  -->  00:07:15,779
really have the valid input.
164

164

00:07:16,080  -->  00:07:18,600
In this case, we technically need to create a Deployment.
165

165

00:07:21,560  -->  00:07:24,670
In this one, we don't need it to be dry run and
166

166

00:07:24,710  -->  00:07:26,689
output. We just want it to create it.
167

167

00:07:26,750  -->  00:07:27,769
So, let's just do that.
168

168

00:07:28,070  -->  00:07:30,471
Then, let's go back up to that expose command and
169

169

00:07:31,100  -->  00:07:32,864
try it again. Then that dry run will
170

170

00:07:34,220  -->  00:07:36,860
work this time. We'll have an API version of V1.
171

171

00:07:37,490  -->  00:07:40,099
You'll notice that the Service is the kind now instead of
172

172

00:07:40,100  -->  00:07:41,359
Deployment or Job.
173

173

00:07:41,930  -->  00:07:44,239
Then, we've got other similar labels.
174

174

00:07:44,720  -->  00:07:47,689
You'll see that the spec is all about ports and protocols
175

175

00:07:47,720  -->  00:07:49,699
because that's really what a Service is.
176

176

00:07:50,080  -->  00:07:53,329
It's the combination of network routes
177

177

00:07:53,360  -->  00:07:56,629
and IP subnetting and TCP or UDP ports,
178

178

00:07:56,660  -->  00:07:59,453
and stuff like that. Generators aren't necessarily a huge
179

179

00:07:59,930  -->  00:08:02,359
deal. You don't need to memorize them or learn the
180

180

00:08:02,360  -->  00:08:04,729
differences between all of them. Because as you'll find a
181

181

00:08:04,730  -->  00:08:07,760
lot of them with the kubectl run command are going away,
182

182

00:08:07,790  -->  00:08:10,159
as you'll find out in a minute. Then in a later lecture,
183

183

00:08:10,160  -->  00:08:12,610
we'll talk more about the types of ways you create
184

184

00:08:12,920  -->  00:08:16,009
containers and maybe why you won't be using a whole
185

185

00:08:16,010  -->  00:08:18,499
lot of run and creates in your production workloads.
186

186

00:08:18,800  -->  00:08:21,439
Remember to delete the test deployment if you created it
187

187

00:08:21,440  -->  00:08:24,170
for our last command where we tested the expose.