WEBVTT

00:00.000 --> 00:05.213
[music]

00:05.252 --> 00:06.893
Hello and welcome to this lecture

00:06.893 --> 00:08.543
on Kubernetes controllers.

00:08.543 --> 00:10.380
My name is Mumshad Mannambeth.

00:10.380 --> 00:12.593
In this lecture, we will discuss about

00:12.593 --> 00:14.212
Kubernetes controllers.

00:14.797 --> 00:16.455
Controllers are the brain

00:16.455 --> 00:17.702
behind Kubernetes.

00:17.823 --> 00:19.983
They are the processes that monitor

00:19.983 --> 00:21.340
Kubernetes objects

00:21.434 --> 00:23.241
and respond accordingly.

00:23.740 --> 00:26.118
In this lecture, we will discuss about

00:26.118 --> 00:28.140
one controller in particular

00:28.308 --> 00:30.882
and that is the ReplicationController.

00:33.103 --> 00:36.140
What is a replica and why do we need

00:36.140 --> 00:37.806
a ReplicationController?

00:38.176 --> 00:40.284
Let's go back to our first scenario

00:40.284 --> 00:42.066
where we had a single pod

00:42.066 --> 00:43.489
running our application.

00:44.027 --> 00:45.277
What if for some reason

00:45.277 --> 00:48.046
our application crashes and the pod fails?

00:48.331 --> 00:50.104
Users will no longer be able

00:50.104 --> 00:51.911
to access our application.

00:52.400 --> 00:54.634
To prevent users from losing access

00:54.634 --> 00:55.828
to our application,

00:55.969 --> 00:57.718
we would like to have more than

00:57.718 --> 00:59.834
one instance or pod running

00:59.834 --> 01:01.097
at the same time.

01:01.321 --> 01:02.976
That way, if one fails,

01:03.051 --> 01:05.070
we still have our application running

01:05.070 --> 01:06.088
on the other one.

01:06.684 --> 01:09.004
The ReplicationController helps us

01:09.103 --> 01:12.344
run multiple instances of a single pod

01:12.344 --> 01:13.864
in the Kubernetes cluster

01:14.278 --> 01:16.753
thus providing high availability.

01:17.611 --> 01:20.074
Does that mean you can't use

01:20.074 --> 01:22.080
a ReplicationController if you plan

01:22.080 --> 01:23.613
to have a single pod?

01:24.126 --> 01:24.775
No.

01:25.084 --> 01:27.348
Even if you have a single pod,

01:27.591 --> 01:30.190
the ReplicationController can help

01:30.190 --> 01:32.082
by automatically bringing up

01:32.082 --> 01:34.386
a new pod when the existing one

01:34.386 --> 01:37.197
fails thus the ReplicationController

01:37.197 --> 01:40.038
ensures that the specified number

01:40.038 --> 01:42.388
of pods are running at all times

01:42.388 --> 01:44.860
even if it's just one or 100.

01:46.377 --> 01:47.544
Another reason we need

01:47.544 --> 01:50.022
ReplicationController is to create

01:50.022 --> 01:52.907
multiple pods to share the load across them.

01:53.307 --> 01:55.939
For example, in this simple scenario,

01:55.939 --> 01:59.235
we have a single pod serving a set of users.

01:59.633 --> 02:01.795
When the number of users increase,

02:01.795 --> 02:04.322
we deploy additional pod to balance

02:04.322 --> 02:06.386
the load across the two pods.

02:07.191 --> 02:09.329
If the demand further increase

02:09.329 --> 02:11.696
and if we were to run out of resources

02:11.696 --> 02:12.932
on the first node,

02:13.070 --> 02:15.365
we could deploy additional pods

02:15.365 --> 02:17.729
across the other nodes in the cluster.

02:18.209 --> 02:21.186
As you can see, the ReplicationController

02:21.453 --> 02:24.612
spans across multiple nodes in the cluster.

02:24.835 --> 02:26.802
It helps us balance the load

02:26.802 --> 02:29.693
across multiple pods on different nodes

02:29.693 --> 02:31.757
as well as scale our application

02:31.942 --> 02:33.776
when the demand increases.

02:35.280 --> 02:37.097
It's important to note that

02:37.197 --> 02:39.257
there are two similar terms--

02:39.528 --> 02:42.419
ReplicationController and ReplicaSet.

02:43.012 --> 02:44.943
Both have the same purpose,

02:45.133 --> 02:46.446
but they're not the same.

02:47.147 --> 02:48.667
ReplicationController

02:48.667 --> 02:50.237
is the older technology

02:50.237 --> 02:52.902
that is being replaced by ReplicaSet.

02:53.216 --> 02:56.273
ReplicaSet is the new recommended way

02:56.273 --> 02:57.696
to set up replication.

02:58.201 --> 02:59.028
However.

02:59.081 --> 03:01.188
Whatever we discussed in the previous

03:01.188 --> 03:03.280
few slides remain applicable

03:03.280 --> 03:05.028
to both these technologies.

03:05.547 --> 03:07.070
There are minor differences

03:07.070 --> 03:08.532
in the way each works.

03:08.816 --> 03:10.477
We will look at that in a bit.

03:11.051 --> 03:14.146
As such, we will try to stick to ReplicaSets

03:14.146 --> 03:15.784
in all of our demos

03:15.784 --> 03:18.171
and implementations going forward.

03:19.219 --> 03:21.310
Let us now look at how we create

03:21.310 --> 03:22.984
a ReplicationController.

03:23.591 --> 03:25.219
As with the previous lecture,

03:25.219 --> 03:26.507
we start by creating

03:26.507 --> 03:29.280
a ReplicationController definition file.

03:29.817 --> 03:33.588
We will name it rc-definition.yml.

03:34.480 --> 03:37.128
As with any Kubernetes definition file,

03:37.128 --> 03:38.880
we have four sections--

03:39.004 --> 03:43.326
the apiVersion, kind, metadata, and spec.

03:44.126 --> 03:46.504
The apiVersion is specific

03:46.504 --> 03:47.920
to what we are creating.

03:48.151 --> 03:50.295
In this case, ReplicationController

03:50.295 --> 03:54.024
is supported in Kubernetes apiVersion v1.

03:54.634 --> 03:56.855
We will set it as v1.

03:57.536 --> 03:59.103
The kind, as we know, 

03:59.103 --> 04:01.009
is a replication controller.

04:01.851 --> 04:04.477
Under metadata, we will add a name

04:04.593 --> 04:07.740
and we will call it myapp-rc

04:07.964 --> 04:10.813
and we will also add a few labels, app,

04:10.813 --> 04:12.926
and type and assign values to them.

04:13.726 --> 04:15.657
So far, it has been very similar

04:15.657 --> 04:17.514
to how we created a pod

04:17.514 --> 04:18.833
in the previous section.

04:19.310 --> 04:21.685
The next is the most crucial part

04:21.685 --> 04:23.062
of the definition file

04:23.062 --> 04:24.893
and that is the specification 

04:25.009 --> 04:26.664
written as spec.

04:27.326 --> 04:29.682
For any Kubernetes definition file,

04:29.917 --> 04:32.780
the spec section defines what's inside

04:32.780 --> 04:34.148
the object we are creating.

04:34.615 --> 04:36.515
In this case, we know that

04:36.515 --> 04:39.026
the ReplicationController creates

04:39.026 --> 04:41.224
multiple instances of a pod.

04:41.920 --> 04:43.142
What pod?

04:43.798 --> 04:46.689
We create a template section under spec

04:46.827 --> 04:49.707
to provide a pod template to be used

04:49.707 --> 04:51.351
by the ReplicationController

04:51.492 --> 04:52.728
to create replicas.

04:53.776 --> 04:57.059
Now, how do we define the pod template?

04:57.390 --> 05:00.256
It's not that hard because we have already

05:00.256 --> 05:02.441
done that in the previous exercise.

05:03.117 --> 05:04.587
Remember, we created

05:04.587 --> 05:06.526
a pod definition file

05:06.526 --> 05:08.046
in the previous exercise.

05:08.427 --> 05:11.244
We could reuse the contents of the file

05:11.448 --> 05:13.382
to populate the template section.

05:14.333 --> 05:16.571
Move all the contents of the pod

05:16.571 --> 05:19.169
definition file into the template section

05:19.169 --> 05:20.924
of the ReplicationController,

05:21.208 --> 05:23.095
except for the first few lines

05:23.095 --> 05:25.150
which are apiVersion and kind.

05:26.027 --> 05:29.064
Remember, whatever we move must be

05:29.064 --> 05:30.775
under the template section,

05:30.775 --> 05:33.224
meaning they should be intended to the right

05:33.459 --> 05:35.743
and have more spaces before them

05:35.966 --> 05:37.787
than the template line itself.

05:38.529 --> 05:40.093
They should be children

05:40.140 --> 05:41.820
of the template section.

05:42.805 --> 05:44.697
Looking at our file now,

05:44.846 --> 05:47.506
we now have two metadata sections.

05:47.817 --> 05:51.260
One is for the ReplicationController

05:51.260 --> 05:53.329
and another for the pod.

05:53.536 --> 05:58.107
We have two spec sections, one for each.

06:02.308 --> 06:03.296
We have nested 

06:03.296 --> 06:05.371
two definition files together--

06:05.657 --> 06:08.022
the ReplicationController being the parent,

06:08.300 --> 06:10.744
and the pod definition being the child.

06:11.793 --> 06:13.859
Now, there is something still missing.

06:14.195 --> 06:16.515
We haven't mentioned how many replicas

06:16.515 --> 06:18.866
we need in the ReplicationController.

06:19.335 --> 06:21.668
For that, add another property

06:21.668 --> 06:23.771
to the spec called replicas,

06:23.771 --> 06:25.856
and input the number of replicas

06:25.856 --> 06:26.888
you need under it.

06:27.315 --> 06:30.278
Remember that the template and replicas

06:30.278 --> 06:33.277
are direct children of spec sections.

06:33.586 --> 06:34.725
They are siblings

06:34.725 --> 06:37.241
and must be on the same vertical line,

06:37.743 --> 06:39.390
which means having equal number

06:39.390 --> 06:40.918
of spaces before them.

06:41.724 --> 06:43.257
Once the file is ready,

06:43.257 --> 06:45.657
run the kubectl create command

06:45.657 --> 06:49.299
and input the file using the -f parameter.

06:49.762 --> 06:52.082
The ReplicationController is created.

06:52.496 --> 06:54.731
When the ReplicationController is created,

06:54.948 --> 06:56.957
it first creates the pods using

06:56.957 --> 06:58.554
the pod definition template

06:58.554 --> 06:59.903
as many as required,

06:59.903 --> 07:01.735
which is three in this case.

07:02.267 --> 07:04.499
To view the list of created

07:04.499 --> 07:06.027
ReplicationControllers,

07:06.027 --> 07:08.835
run the kubectl get ReplicationController

07:08.835 --> 07:10.063
command and you will see

07:10.063 --> 07:12.016
the ReplicationController listed.

07:12.617 --> 07:14.355
We can also see the desired

07:14.355 --> 07:16.240
number of replicas or pods,

07:16.240 --> 07:17.853
the current number of replicas,

07:17.853 --> 07:18.780
and how many of them

07:18.780 --> 07:20.353
are ready in the output.

07:20.943 --> 07:22.620
If you would like to see the pods

07:22.620 --> 07:23.417
that were created 

07:23.417 --> 07:25.048
by the ReplicationController,

07:25.208 --> 07:27.922
run the kubectl get pods command

07:27.922 --> 07:29.969
and you will see three pods running.

07:30.651 --> 07:32.714
Note that all of them are starting

07:32.714 --> 07:35.108
with the name of the ReplicationController,

07:35.208 --> 07:37.646
which is myapp-rc,

07:37.884 --> 07:40.063
indicating that they're all created

07:40.063 --> 07:41.089
automatically

07:41.089 --> 07:42.833
 by the ReplicationController.

07:44.209 --> 07:45.525
What we just saw

07:45.525 --> 07:47.492
was the ReplicationController.

07:47.627 --> 07:49.798
Let us now look at ReplicaSet.

07:50.160 --> 07:52.733
Is it very similar to ReplicationController.

07:52.995 --> 07:56.477
As usual, first, we have apiVerson,

07:56.477 --> 07:58.295
kind, metadata, and spec.

07:58.353 --> 08:01.031
The apiVersion though is a bit different.

08:01.108 --> 08:04.565
It is apps/v1, which is different

08:04.565 --> 08:05.801
from what we had before

08:05.801 --> 08:07.263
for ReplicationController,

08:07.263 --> 08:09.006
which was just v1.

08:09.340 --> 08:11.619
If you get this wrong, you are likely

08:11.619 --> 08:13.644
to get an error that looks like this.

08:14.074 --> 08:17.131
It would say, "No match for Kind=ReplicaSet,"

08:17.266 --> 08:18.449
because the specified

08:18.449 --> 08:20.085
Kubernetes apiVersion

08:20.270 --> 08:22.284
has no support for ReplicaSet.

08:23.735 --> 08:25.704
The kind would be ReplicaSet.

08:26.110 --> 08:29.793
We add name and labels in the metadata.

08:33.034 --> 08:34.579
The specification section

08:34.579 --> 08:35.630
 looks very similar

08:35.630 --> 08:37.211
to ReplicationController.

08:37.340 --> 08:39.837
It has a template section where we provide

08:39.914 --> 08:41.953
pod definition as before.

08:42.402 --> 08:43.972
I'm going to copy contents

08:43.972 --> 08:45.812
over from pod definition file.

08:45.812 --> 08:47.445
We have number of replicas

08:47.445 --> 08:48.753
which is set to three.

08:49.310 --> 08:51.762
However, there is one major difference

08:51.762 --> 08:53.475
between ReplicationController

08:53.475 --> 08:54.551
and ReplicaSet.

08:54.885 --> 08:58.350
ReplicaSet requires a selector definition.

08:58.915 --> 09:01.848
The selector section helps the ReplicaSet

09:01.848 --> 09:05.125
identify what pods fall under it.

09:06.336 --> 09:08.364
Why would you have to specify

09:08.364 --> 09:11.136
what pods fall under it if you have

09:11.136 --> 09:12.275
provided the contents

09:12.275 --> 09:13.845
of the pod definition file 

09:13.845 --> 09:15.572
itself in the template?

09:16.551 --> 09:20.157
It's because ReplicaSet can also manage

09:20.157 --> 09:22.071
pods that were not created

09:22.071 --> 09:24.416
as part of the ReplicaSet creation.

09:24.855 --> 09:26.113
Say, for example,

09:26.245 --> 09:28.016
there were pods created

09:28.016 --> 09:30.066
before the creation of the ReplicaSet

09:30.118 --> 09:31.702
that matched labels

09:31.702 --> 09:33.268
specified in the selector,

09:33.572 --> 09:36.320
the ReplicaSet will also take those pods

09:36.320 --> 09:38.171
into consideration when creating

09:38.171 --> 09:39.059
the replicas.

09:39.776 --> 09:42.270
I will elaborate this in the next slide.

09:42.769 --> 09:44.228
Before we get into that,

09:44.402 --> 09:46.833
I would like to mention that the selector

09:46.833 --> 09:48.289
is one of the major differences

09:48.289 --> 09:50.068
between ReplicationController 

09:50.068 --> 09:51.227
and ReplicaSet.

09:51.817 --> 09:54.593
The selector is not a required field

09:54.593 --> 09:56.571
in case of a ReplicationController.

09:56.811 --> 09:58.342
It is still available.

09:58.471 --> 09:59.393
When you skip it,

09:59.586 --> 10:01.412
as we did in the previous slide,

10:01.553 --> 10:04.223
it assumes it to be the same as the labels

10:04.223 --> 10:06.739
provided in the pod definition file.

10:07.335 --> 10:08.995
In case of ReplicaSet,

10:09.042 --> 10:12.485
a user input is required for this property,

10:12.612 --> 10:14.510
and it has to be written in the form

10:14.510 --> 10:17.332
of matchLabels as shown here.

10:17.892 --> 10:20.700
The matchLabels selectors simply matches

10:20.700 --> 10:22.918
the labels specified under it

10:22.951 --> 10:24.460
to the labels on the pod.

10:24.863 --> 10:27.674
The ReplicaSet selector also provides

10:27.944 --> 10:30.513
many other options for matching labels

10:30.800 --> 10:32.113
that were not available

10:32.113 --> 10:33.732
in a ReplicationController.

10:35.506 --> 10:37.878
As always, to create a ReplicaSet,

10:37.878 --> 10:40.060
run the kubectl create command

10:40.060 --> 10:42.422
providing the definition file as input.

10:42.957 --> 10:45.051
To see the created replicas,

10:45.051 --> 10:48.424
run the kubectl get ReplicaSet command.

10:48.960 --> 10:50.579
To get list of pods,

10:50.764 --> 10:54.024
simply run the kubectl get pods command.

10:56.066 --> 10:59.153
What is the deal with labels and selectors?

10:59.393 --> 11:01.188
Why do we label our pods

11:01.188 --> 11:02.744
and objects in Kubernetes?

11:03.070 --> 11:04.979
Let us look at a simple scenario.

11:05.743 --> 11:08.008
Savy deployed three instances

11:08.008 --> 11:10.347
of our front-end web application

11:10.347 --> 11:11.809
as three pods.

11:12.598 --> 11:13.729
We would like to create

11:13.729 --> 11:16.317
a ReplicationController or ReplicaSet

11:16.377 --> 11:19.097
to ensure that we have three active pods

11:19.097 --> 11:20.063
at any time.

11:20.664 --> 11:24.063
Yes, that is one of the use case of ReplicaSets.

11:24.286 --> 11:27.406
You can use it to monitor existing pods

11:27.406 --> 11:29.351
if you have them already created,

11:29.492 --> 11:31.453
as it is in this example.

11:32.223 --> 11:33.953
In case they were not created,

11:34.013 --> 11:36.433
the ReplicaSet will create them for you.

11:37.128 --> 11:38.769
The role of the ReplicaSet

11:38.769 --> 11:40.193
is to monitor the pods

11:40.193 --> 11:42.228
and if any of them were to fail,

11:42.228 --> 11:43.371
deploy new ones.

11:43.875 --> 11:45.751
The ReplicaSet is in fact,

11:45.864 --> 11:48.780
a process that monitors the pods.

11:49.553 --> 11:51.048
Now, how does the ReplicaSet

11:51.142 --> 11:53.475
know what pods to monitor?

11:53.856 --> 11:55.972
There could be hundreds of other pods

11:55.972 --> 11:57.131
in the cluster running

11:57.131 --> 11:58.529
different applications.

11:59.313 --> 12:01.837
This is where labeling our pods

12:02.074 --> 12:04.182
during creation comes in handy.

12:05.790 --> 12:07.942
We could now provide these labels

12:07.942 --> 12:10.474
as a filter for ReplicaSet.

12:11.120 --> 12:12.645
Under the selector section,

12:12.645 --> 12:14.642
we use the matchLabels filter

12:14.642 --> 12:16.273
and provide the same label

12:16.273 --> 12:18.331
that we used while creating the pods.

12:18.962 --> 12:21.348
This way the ReplicaSet knows

12:21.547 --> 12:23.304
which pods to monitor.

12:24.099 --> 12:27.031
The same concept of labels and selectors

12:27.031 --> 12:29.511
is used in many other places

12:29.928 --> 12:31.373
throughout Kubernetes.

12:33.222 --> 12:34.907
Now, let me ask you a question

12:34.907 --> 12:36.198
along the same lines.

12:36.642 --> 12:39.205
In the ReplicaSet specification section,

12:39.205 --> 12:41.900
we learned that there are three sections--

12:42.027 --> 12:44.576
template, replicas, and the selector.

12:45.106 --> 12:46.626
We need three replicas

12:46.626 --> 12:48.689
and we have updated our selector

12:48.689 --> 12:49.873
based on our discussion

12:49.873 --> 12:51.078
in the previous slide.

12:51.900 --> 12:52.998
Say, for instance,

12:52.998 --> 12:54.742
we have the same scenario

12:54.742 --> 12:56.739
as in the previous slide where we have

12:56.739 --> 12:58.226
three existing pods

12:58.275 --> 12:59.942
that were created already,

13:00.240 --> 13:02.331
and we need to create a ReplicaSet

13:02.438 --> 13:04.446
to monitor the pods to ensure

13:04.601 --> 13:06.228
there are a minimum of three

13:06.228 --> 13:07.635
running at all times.

13:08.220 --> 13:10.780
When the ReplicationController is created,

13:10.849 --> 13:13.500
it is not going to deploy a new instance

13:13.500 --> 13:15.440
of pod as three of them

13:15.440 --> 13:18.325
with matching labels are already created.

13:19.335 --> 13:21.613
In that case, do we really need

13:21.613 --> 13:23.495
to provide a template section

13:23.495 --> 13:25.837
in the ReplicaSet specification

13:26.176 --> 13:28.645
since we are not expecting the ReplicaSet

13:28.645 --> 13:30.971
to create a new pod on deployment?

13:31.828 --> 13:32.891
Yes, we do.

13:32.995 --> 13:35.075
Because in case one of the pods

13:35.075 --> 13:36.943
were to fail in the future,

13:37.235 --> 13:39.696
the ReplicaSet needs to create

13:39.696 --> 13:41.335
a new one to maintain

13:41.335 --> 13:43.277
the desired number of pods.

13:43.740 --> 13:46.413
For the ReplicaSet, to create a new pod,

13:46.576 --> 13:49.942
the template definition section is required.

13:52.035 --> 13:54.728
Let's now look at  how we scale the ReplicaSet. 

13:55.277 --> 13:57.291
Say, we started with three replicas,

13:57.437 --> 14:00.055
and in the future, we decided to scale to six.

14:00.540 --> 14:02.576
How do we update our ReplicaSet

14:02.576 --> 14:04.526
to scale to six replicas?

14:05.205 --> 14:07.089
There are multiple ways to do it.

14:07.282 --> 14:09.354
The first is to update the number

14:09.354 --> 14:12.700
of replicas in the definition file to six.

14:15.222 --> 14:18.855
Then run the kubectl replace command

14:18.855 --> 14:20.526
to specify the same file 

14:20.526 --> 14:22.430
using the -f parameter.

14:22.430 --> 14:24.375
That will update the ReplicaSet

14:24.375 --> 14:26.132
to have six replicas.

14:27.040 --> 14:29.230
The second way to do it is to run

14:29.230 --> 14:31.500
the kubectl scale command,

14:31.823 --> 14:34.143
use the replicas parameter to provide

14:34.143 --> 14:35.655
the new number of replicas,

14:35.655 --> 14:38.331
and specify the same file as input.

14:39.415 --> 14:41.771
You may either input the definition file

14:41.771 --> 14:44.024
or provide the ReplicaSet name

14:44.024 --> 14:46.044
in the type name format.

14:47.133 --> 14:50.532
However, remember that using the file name

14:50.532 --> 14:52.926
as input will not result in the number

14:52.926 --> 14:54.708
of replicas being updated

14:54.708 --> 14:56.248
automatically in the file.

14:56.824 --> 14:59.299
In other words, the number of replicas

14:59.299 --> 15:01.445
in the Replica Sets definition file

15:01.445 --> 15:03.586
will still be three even though

15:03.586 --> 15:05.547
you scaled your ReplicaSet to have

15:05.594 --> 15:07.026
six replicas using 

15:07.026 --> 15:08.940
the kubectl scale command

15:08.987 --> 15:10.648
and the file as input.

15:11.428 --> 15:13.575
There are also options available

15:13.575 --> 15:15.142
for automatically scaling

15:15.142 --> 15:17.211
the ReplicaSet based on load.

15:17.853 --> 15:19.288
That is an advanced topic.

15:19.428 --> 15:21.840
We will discuss it at a later time.

15:23.092 --> 15:25.398
Let us now review the commands real quick.

15:26.245 --> 15:28.124
The kubectl create command,

15:28.124 --> 15:29.437
as we know, is used to create

15:29.437 --> 15:32.548
a ReplicaSet or basically any object

15:32.548 --> 15:34.543
in Kubernetes depending on the file

15:34.543 --> 15:36.074
we are providing as input.

15:36.797 --> 15:38.502
You must provide the input file

15:38.502 --> 15:40.336
using the -f parameter.

15:41.511 --> 15:43.696
Use the kubectl get command to see

15:43.696 --> 15:45.657
the list of ReplicaSets created.

15:45.721 --> 15:47.577
Use the kubectl delete

15:47.737 --> 15:49.406
ReplicaSet command followed by

15:49.406 --> 15:50.852
the name of the ReplicaSet

15:50.929 --> 15:52.430
to delete the ReplicaSet.

15:52.937 --> 15:55.194
Then we have the kubectl replace

15:55.194 --> 15:57.009
command to replace or update

15:57.009 --> 16:00.424
the ReplicaSet and also the kubectl scale

16:00.424 --> 16:02.499
command to scale ReplicaSet

16:02.706 --> 16:04.201
simply from the command line

16:04.201 --> 16:06.110
without having to modify the file. 

16:07.622 --> 16:09.155
That's it for this lecture.