WEBVTT

00:01.156 --> 00:02.201
In this video,

00:02.206 --> 00:03.690
we're going to look at

00:04.021 --> 00:05.881
CoreDNS and Kubernetes.

00:07.088 --> 00:08.676
The first question is to identify

00:08.676 --> 00:10.201
the DNS solution implemented

00:10.332 --> 00:11.204
in this cluster.

00:11.248 --> 00:17.321
Let's set an alias k=kubectl

00:18.104 --> 00:23.956
and let's do get PODs -n kube-system.

00:24.928 --> 00:26.007
We see all the PODs

00:26.041 --> 00:27.272
in the cube system namespace,

00:27.272 --> 00:28.627
and we see that

00:28.627 --> 00:30.824
we have the CoreDNS PODs.

00:31.694 --> 00:35.893
We use CoreDNS as the DNS solution.

00:37.760 --> 00:39.920
The next question is how many PODs

00:40.254 --> 00:42.261
of the DNS server are deployed?

00:44.416 --> 00:46.402
We see that there are two.

00:48.826 --> 00:50.540
That's the answer to that.

00:50.618 --> 00:51.706
There are two plots.

00:52.295 --> 00:54.169
What is the name of the service created

00:54.169 --> 00:55.716
for accessing CoreDNS?

00:56.339 --> 00:58.155
The name of the service created

00:58.155 --> 00:59.168
for accessing CoreDNS,

00:59.168 --> 01:02.307
let's do a service that as we see

01:02.307 --> 01:06.145
in the Kube system namespace,

01:07.044 --> 01:08.967
and we see that there's only one service

01:08.981 --> 01:10.087
called Kube-DNS.

01:10.126 --> 01:11.430
That's the service that's used

01:11.430 --> 01:13.461
for accessing the DNS server.

01:13.461 --> 01:15.381
That is Kube-DNS.

01:18.865 --> 01:21.282
Now, what is the IP of the CoreDNS server

01:21.282 --> 01:23.161
that should be configured on the PODs

01:23.440 --> 01:24.690
to resolve services?

01:24.926 --> 01:26.494
All the PODs should have the IP

01:26.494 --> 01:28.513
of the CoreDNS service,

01:28.819 --> 01:32.150
and that IP is 10.96.0.10.

01:32.172 --> 01:33.711
That's the IP of this service

01:34.812 --> 01:35.769
so that is just one.

01:38.792 --> 01:40.431
Now, where is the configuration file

01:40.431 --> 01:41.939
located for configuring

01:42.230 --> 01:43.677
the CoreDNS service?

01:45.369 --> 01:49.970
Let's look at the CoreDNS service.

01:50.603 --> 01:55.103
Let's do a cube system.

01:55.507 --> 01:56.841
We see that we have these two PODs.

01:56.841 --> 01:59.071
Let's take a closer look at those PODs.

01:59.677 --> 02:01.309
Do a described POD

02:02.317 --> 02:05.774
in the Kube system namespace,

02:06.615 --> 02:08.831
and we see additional information.

02:10.407 --> 02:12.608
Here is the container that runs

02:12.608 --> 02:14.235
the CoreDNS service.

02:15.403 --> 02:20.220
This is the image that runs this CoreDNS 1.7.0

02:20.967 --> 02:23.073
and these are the PODs that are exposed.

02:23.095 --> 02:24.060
Here, if you look,

02:24.106 --> 02:26.385
these are the arguments that are passed

02:26.739 --> 02:28.538
to the CoreDNS container.

02:29.704 --> 02:34.688
The config file is at /etc/coredns/Corefile.

02:35.168 --> 02:37.495
That's the etc CoreDNS Corefile.

02:37.495 --> 02:38.938
That's the configuration file.

02:41.607 --> 02:43.207
How is this Corefile passed

02:43.207 --> 02:44.557
into the CoreDNS POD?

02:44.795 --> 02:46.795
Is it pulled from Git when it starts

02:46.795 --> 02:49.178
or is it configured as a ConfiMag object?

02:49.403 --> 02:50.572
Does it come built-in,

02:50.572 --> 02:53.602
or is it stored on the master node?

02:54.067 --> 02:55.277
If you look at this,

02:56.130 --> 02:57.978
the path, etc/CoreDNS,

02:58.341 --> 02:59.415
let's see if there are any mounts.

02:59.430 --> 03:00.402
There are mounts,

03:00.429 --> 03:02.283
so we have an etc/CoreDNS mount,

03:02.465 --> 03:03.823
and it says that it is coming

03:03.823 --> 03:06.945
from config volume.

03:07.367 --> 03:08.637
We can also see this

03:11.483 --> 03:14.172
if, let's say, we do a

03:16.303 --> 03:18.569
Kube-Cuddle get POD,

03:19.086 --> 03:21.316
and we look at it in the YAML format.

03:23.122 --> 03:25.638
If you look at it this way, scroll up,

03:30.400 --> 03:31.861
this is the spec section.

03:32.307 --> 03:34.099
You can ignore all of this,

03:34.339 --> 03:36.000
always look at the spec section

03:36.303 --> 03:37.740
and we have the containers.

03:37.740 --> 03:38.378
For the container,

03:38.378 --> 03:40.140
we have the arguments that we just saw,

03:40.494 --> 03:41.607
the image, and everything.

03:42.659 --> 03:44.024
If you scroll down,

03:44.213 --> 03:45.745
you'll see the volume mounts.

03:45.847 --> 03:47.282
You have volume mounts here.

03:49.437 --> 03:52.768
This etc/CoreDNS is the volume mount,

03:53.020 --> 03:55.459
and it's coming from a config volume.

03:57.265 --> 03:58.749
If you have volume mounts,

03:59.607 --> 04:00.821
then you have volumes.

04:00.889 --> 04:02.715
You scroll down and we see volumes.

04:02.715 --> 04:04.370
This is where the volumes are configured.

04:04.860 --> 04:07.025
The volume for config mount

04:07.040 --> 04:08.589
is the config volume.

04:10.310 --> 04:13.495
Here, you see you have

04:13.823 --> 04:14.775
the Corefile

04:16.046 --> 04:16.926
and CoreDNS.

04:16.926 --> 04:19.090
CoreDNS is the config volume,

04:19.110 --> 04:20.458
so ConfigMap.

04:20.460 --> 04:22.882
This is what tells us that

04:23.175 --> 04:24.906
it's loaded from a ConfigMap.

04:29.806 --> 04:30.911
The next question is,

04:30.911 --> 04:32.552
what is the name of the ConfigMap object

04:32.552 --> 04:34.007
created for the Corefile?

04:34.962 --> 04:37.049
For this volume, this ConfigMap,

04:37.073 --> 04:39.170
the name of the ConfigMap is CoreDNS.

04:40.305 --> 04:41.978
That's the name of the ConfigMap

04:45.139 --> 04:46.923
and what is the root domain,

04:46.950 --> 04:47.992
or zone configured

04:48.004 --> 04:49.524
for this Kubernetes cluster.

04:50.021 --> 04:50.826
To find that out,

04:50.826 --> 04:52.300
we have to look into that ConfigMap.

04:52.346 --> 04:53.980
Let's do that now.

04:53.980 --> 04:57.553
Let's do a get ConfigMap

04:58.560 --> 05:00.509
in the Kube system namespace.

05:02.223 --> 05:03.733
We have the CoreDNS.

05:03.767 --> 05:08.012
Let's do a describe ConfigMap

05:09.924 --> 05:12.320
in the Kube-system namespace.

05:13.629 --> 05:15.924
These are the DNS

05:16.322 --> 05:18.964
config for Kubernetes.

05:20.106 --> 05:23.386
Right here, this is the root domain.

05:23.410 --> 05:25.115
That's cluster.local.

05:28.167 --> 05:29.738
Now, we have deployed a set of PODs

05:29.738 --> 05:30.904
and services in the default

05:30.904 --> 05:32.227
and payroll namespaces,

05:32.332 --> 05:34.535
inspect them and go to the next question.

05:34.729 --> 05:36.249
Let's do that.

05:36.783 --> 05:38.993
Let's look at get PODs.

05:39.013 --> 05:41.842
We see that there are indeed the HR,

05:41.869 --> 05:44.511
the simple-webapp and test.

05:44.511 --> 05:47.221
There are four parts.

05:47.248 --> 05:51.020
Then there's also another namespace

05:52.133 --> 05:53.803
called payroll.

05:55.117 --> 05:56.109
In the payroll namespace,

05:56.138 --> 05:57.929
there is another application called web.

05:58.324 --> 05:59.844
There are multiple applications.

05:59.859 --> 06:00.843
That's fine.

06:01.255 --> 06:03.609
Now, what name can be used to access

06:03.963 --> 06:06.584
the HR web server from the Test Application?

06:07.049 --> 06:08.681
Here we have the HR web server

06:09.350 --> 06:11.575
and here we have the Test Application.

06:11.856 --> 06:14.819
We want to access the HR web server

06:14.819 --> 06:16.029
from the Test Application.

06:16.596 --> 06:19.541
You can execute the curl command or you can--

06:19.549 --> 06:21.699
Test Applications also have a UI.

06:22.855 --> 06:24.237
Let's just use the UI.

06:24.450 --> 06:25.478
I like the UI.

06:26.002 --> 06:27.738
This is the UI of the Test Application

06:28.169 --> 06:30.836
and we'll use this to run a connectivity test.

06:32.729 --> 06:34.833
First, how do you access

06:35.141 --> 06:36.208
the HR Application?

06:39.873 --> 06:41.132
If you do an HR,

06:41.263 --> 06:42.947
I'm assuming it's on 8080,

06:44.652 --> 06:45.626
it's not working.

06:45.641 --> 06:47.781
We have to find out what is the service

06:47.842 --> 06:48.858
that's used to access this.

06:48.867 --> 06:52.196
Let's do a curl get svc

06:53.158 --> 06:55.059
because that's in the default namespace.

06:55.200 --> 06:56.666
We see that there are multiple services,

06:56.666 --> 06:58.193
here you have the test-service

06:58.193 --> 06:59.204
and the web-service.

06:59.430 --> 07:00.494
I'm assuming the test-service

07:00.494 --> 07:02.072
is for the Test Application.

07:02.533 --> 07:03.997
I'm not sure if the web-service

07:03.997 --> 07:05.369
is for the HR Application.

07:05.369 --> 07:10.792
Let's do a describe on the web-service.

07:14.940 --> 07:18.775
Service is missing, svc.

07:19.541 --> 07:22.303
We see that the selector here,

07:23.287 --> 07:24.574
name=HR.

07:24.763 --> 07:28.494
That indicates that the web-service

07:28.960 --> 07:31.391
is a service for the HR application.

07:32.232 --> 07:34.089
That's what connects them to.

07:34.429 --> 07:35.270
It's web-service.

07:35.270 --> 07:36.358
I'm going to use web-service.

07:36.358 --> 07:38.186
The port, if you see is 80.

07:38.463 --> 07:39.503
That's what I'm going to do.

07:39.503 --> 07:41.456
I'm going to use web-service

07:41.486 --> 07:44.400
and the port 80 and let's run the test.

07:44.448 --> 07:46.162
It says this is the HR service.

07:46.681 --> 07:47.333
That's good.

07:47.730 --> 07:50.067
That confirms that, so it's web-service.

07:50.084 --> 07:54.460
That's what is the answer to this question.

07:58.463 --> 08:00.574
Now, which of the names CANNOT be used

08:00.586 --> 08:01.830
to access the HR service

08:01.842 --> 08:02.991
from the test POD?

08:03.204 --> 08:05.660
We know that to access the HR service

08:05.672 --> 08:08.145
from the test POD, we just use web-service.

08:08.489 --> 08:09.141
That works.

08:09.573 --> 08:11.280
That's web-service.default work.

08:11.825 --> 08:13.376
It will because we are

08:13.376 --> 08:14.736
in the default namespace.

08:15.476 --> 08:16.307
Let's try that.

08:17.403 --> 08:20.899
Default, that works.

08:21.704 --> 08:24.152
Does web-service.default.svc work?

08:25.127 --> 08:26.460
Svc,

08:27.352 --> 08:29.294
yes, because svc stands for service

08:29.294 --> 08:30.785
and web-service is a service

08:30.870 --> 08:32.305
in the default namespace.

08:32.305 --> 08:33.512
That's fine.

08:33.852 --> 08:36.703
The next one is web-service.default.POD.

08:36.986 --> 08:38.305
Let's try POD.

08:40.169 --> 08:41.134
That fails.

08:41.246 --> 08:43.699
That's not the right kind of convention.

08:43.704 --> 08:46.038
This is the right answer to this question.

08:46.739 --> 08:48.147
Now, which of the below name

08:48.162 --> 08:51.107
can be used to access the payroll service

08:51.430 --> 08:52.618
from the Test Application?

08:53.454 --> 08:56.162
The payroll service as we know is,

08:57.694 --> 09:00.084
it must be in the payroll namespace.

09:01.185 --> 09:02.147
Let's explore that.

09:02.167 --> 09:06.024
Let's do a Kube-Cuddle get POD payroll.

09:07.330 --> 09:09.212
There's a web-service there.

09:09.236 --> 09:12.712
Then let's do a get svc -n payroll

09:13.694 --> 09:14.739
and we see a

09:15.728 --> 09:17.151
web-service here.

09:17.536 --> 09:19.827
Let's make sure that this is for that.

09:19.827 --> 09:24.635
Let's do a k describe svc web-service

09:24.659 --> 09:26.463
in payroll service

09:28.339 --> 09:29.847
in the payroll namespace.

09:36.409 --> 09:38.790
We see that the selectors name=webapp.

09:39.049 --> 09:40.387
That's for this.

09:41.013 --> 09:42.867
Yes, the web-service is used

09:42.867 --> 09:44.884
for the web application

09:44.892 --> 09:46.004
in the payroll service

09:46.111 --> 09:47.073
in the payroll namespace.

09:47.073 --> 09:48.346
We'll just assume that

09:48.346 --> 09:50.317
this is the payroll service.

09:50.700 --> 09:52.416
Which of the below name can we use

09:52.416 --> 09:53.493
to access the payroll service

09:53.493 --> 09:54.683
from the Test Application?

09:54.683 --> 09:56.012
The Test Application we know

09:56.012 --> 09:57.595
is in the default namespace.

09:58.172 --> 09:59.452
If you do a service

09:59.452 --> 10:00.465
from the default namespace

10:00.465 --> 10:02.596
is going to go to the HR app.

10:02.749 --> 10:03.801
That's not what we want.

10:03.927 --> 10:05.820
We want to access the web service

10:05.837 --> 10:07.190
in the payroll namespace.

10:08.715 --> 10:10.475
The web is not the correct answer.

10:10.496 --> 10:11.643
Web service.default.

10:11.643 --> 10:13.158
It is going to go to the HR app,

10:13.396 --> 10:14.649
web service.payroll

10:14.649 --> 10:18.167
because it's in the payroll namespace.

10:18.181 --> 10:19.083
Let's try that.

10:21.158 --> 10:22.933
It says this is a payroll server.

10:22.933 --> 10:24.724
It's web service.payroll.

10:25.010 --> 10:27.023
That's the answer to this question.

10:28.829 --> 10:30.334
Now, which of the below name

10:30.458 --> 10:32.400
cannot be used to access the payroll service

10:32.400 --> 10:33.718
from the Test Application?

10:33.953 --> 10:36.036
Web service.payroll, it works.

10:36.067 --> 10:40.077
Web service.payroll.SVC.cluster,

10:40.560 --> 10:44.033
so payroll.SVC.cluster.

10:46.632 --> 10:49.459
That doesn't work because it should

10:49.459 --> 10:51.054
either be web service.payroll,

10:51.127 --> 10:53.726
or it should be web service.payroll.SVC,

10:53.907 --> 10:54.744
or it should be

10:54.744 --> 10:58.991
web service.payroll.SVC.cluster.local,

10:58.991 --> 11:02.237
because cluster.local is the route domain,

11:03.195 --> 11:04.002
the route zone.

11:04.363 --> 11:07.049
You should either use cluster.local

11:07.163 --> 11:09.253
or you shouldn't use anything at all.

11:09.706 --> 11:12.351
Cluster is something that doesn't work.

11:13.716 --> 11:15.556
Now, we just deployed a web server

11:15.570 --> 11:18.438
web app that accesses a database,

11:18.438 --> 11:19.701
MySQL server.

11:21.318 --> 11:23.871
Let's check that out, Kube-Cuddle,

11:24.181 --> 11:26.087
get deployment,

11:27.112 --> 11:30.303
and we see that there's a web app indeed.

11:30.618 --> 11:33.852
Then it accesses a database at MySQL server

11:33.898 --> 11:35.207
or the webserver is failing

11:35.207 --> 11:36.375
to connect to the database.

11:36.567 --> 11:38.443
We don't see a MySQL server here.

11:38.443 --> 11:44.598
Let's do our Kube-Cuddle, get PODs

11:45.410 --> 11:47.626
and in all namespaces

11:47.648 --> 11:48.892
so we can see all the PODs.

11:49.233 --> 11:51.488
We can ignore most of these.

11:52.681 --> 11:53.840
If you look at these two,

11:53.840 --> 11:55.185
so there are two namespaces,

11:55.187 --> 11:56.850
and we have the web app,

11:56.887 --> 11:58.419
the POD that runs the web app.

11:58.831 --> 11:59.638
It says web app.

11:59.641 --> 12:00.690
This is a web app.

12:01.010 --> 12:03.212
This is our application.

12:03.568 --> 12:05.001
If you look here,

12:05.025 --> 12:06.969
we have MySQL on database here.

12:06.969 --> 12:08.247
It is in the payroll service

12:08.273 --> 12:09.498
payroll namespace.

12:09.815 --> 12:12.080
Basically, this web app is trying to connect

12:12.094 --> 12:15.755
to the MySQL POD in the payroll namespace,

12:16.041 --> 12:18.494
but it's not able to access.

12:19.820 --> 12:20.955
Locate the applications

12:20.989 --> 12:22.446
and the web server interface can be seen

12:22.446 --> 12:23.716
by clicking the tab web server

12:23.716 --> 12:24.698
at the top of your terminal.

12:24.698 --> 12:26.000
Here we have the web server,

12:26.172 --> 12:27.323
so just open that.

12:27.718 --> 12:33.888
As you can see, it is in a failed state.

12:34.060 --> 12:35.473
If you look at the environment variables

12:35.473 --> 12:36.223
that were passed away,

12:36.227 --> 12:37.940
it says the DB host is MySQL

12:37.992 --> 12:39.449
DB database, not set,

12:39.711 --> 12:41.924
DB user route, DB password,

12:42.176 --> 12:42.824
all of that.

12:43.093 --> 12:45.202
It says the name does not resolve.

12:45.469 --> 12:46.753
The issue is with the name.

12:46.877 --> 12:49.292
If you look at this, it says MySQL.

12:49.292 --> 12:50.361
MySQL is a name.

12:50.560 --> 12:53.343
The web app here is trying to get

12:53.364 --> 12:56.533
to the MySQL service here

12:56.552 --> 12:58.863
which is in the payroll namespace.

12:59.129 --> 13:01.100
It's not going to be able to do that.

13:01.151 --> 13:03.883
Let's first see the service configured

13:03.883 --> 13:08.201
for it in the payroll namespace.

13:09.064 --> 13:11.854
We have the MySQL service.

13:12.744 --> 13:13.893
The service is there,

13:14.130 --> 13:16.341
but for the web app to reach the MySQL service,

13:16.341 --> 13:20.351
it would need to say MySQL.payroll.

13:20.547 --> 13:22.276
That's how it should be.

13:24.802 --> 13:26.397
Let's see where that is configured.

13:26.463 --> 13:27.992
Let's do our Kube-Cuddle,

13:28.356 --> 13:30.753
describe the deployment web app,

13:36.029 --> 13:39.207
and we see that

13:39.299 --> 13:40.392
it has environment variables

13:40.392 --> 13:41.910
configured here, so MySQL route

13:41.924 --> 13:43.040
and the password.

13:43.410 --> 13:48.967
Let's deploy and edit it.

13:50.993 --> 13:52.407
Now, of course, this password here

13:52.407 --> 13:53.881
is not a best practice.

13:54.123 --> 13:57.936
It should be going in through a secret

13:58.581 --> 14:02.281
or some other safer method.

14:02.361 --> 14:06.586
We just did that here just to keep this simple.

14:07.120 --> 14:08.666
We have the environment here,

14:10.392 --> 14:11.755
which is MySQL,

14:12.138 --> 14:13.633
and we're going to change that to

14:14.225 --> 14:17.078
MySQL.payroll.

14:18.247 --> 14:20.632
You could just say MySQL.payroll

14:20.644 --> 14:22.654
or MySQL.payroll.SVC

14:22.853 --> 14:25.837
or MySQL.payroll.SVC.cluster.local.

14:26.339 --> 14:27.975
Let's save that.

14:29.214 --> 14:30.964
Let's check the PODs.

14:32.070 --> 14:33.692
You can see that the older one is terminating

14:33.692 --> 14:36.036
and then the new one is already running.

14:36.261 --> 14:38.145
Let's go back and check the status here.

14:38.816 --> 14:39.956
We see that it's a success.

14:39.956 --> 14:41.103
Now we have a DB host,

14:41.103 --> 14:42.526
which is MySQL.payroll.

14:42.967 --> 14:45.743
That's good.

14:45.849 --> 14:46.962
Let's check the work.

14:48.031 --> 14:49.738
That was successful.

14:50.341 --> 14:51.398
Now the next question is,

14:51.435 --> 14:55.224
from the HR POD, run NSlookup,

14:55.583 --> 14:57.869
and the MySQL service

14:58.160 --> 14:59.563
and redirect the output to a file.

15:00.640 --> 15:01.861
From the HR POD,

15:01.951 --> 15:05.187
so we're going to do an exec HR

15:05.709 --> 15:07.081
and then give a command.

15:09.532 --> 15:12.184
The command we need to run is NS lookup,

15:12.821 --> 15:14.055
we'll do a MySQL

15:15.636 --> 15:17.192
and it says it's not found.

15:17.192 --> 15:20.375
We know that since the HR app

15:20.395 --> 15:21.733
is in the default namespace,

15:21.733 --> 15:25.498
and MySQL is in the payroll namespace

15:25.498 --> 15:29.093
which should be pending payroll to the name.

15:29.912 --> 15:33.430
That's got us the IP address

15:33.440 --> 15:35.037
of the MySQL POD,

15:35.037 --> 15:38.109
and you can also see the full name

15:38.109 --> 15:39.706
of the MySQL service here.

15:40.676 --> 15:44.581
Let's redirect that to this path.

15:45.854 --> 15:46.853
Let's make sure that

15:46.853 --> 15:49.008
it's redirected successfully

15:49.255 --> 15:50.848
and see the output.

15:51.890 --> 15:54.179
That's the end of this lab.

15:54.271 --> 15:54.734
All right.

15:54.751 --> 15:55.682
Thank you very much.