In this video,
we're going to look at
CoreDNS and Kubernetes.
The first question is to identify
the DNS solution implemented
in this cluster.
Let's set an alias k=kubectl
and let's do get PODs -n kube-system.
We see all the PODs
in the cube system namespace,
and we see that
we have the CoreDNS PODs.
We use CoreDNS as the DNS solution.
The next question is how many PODs
of the DNS server are deployed?
We see that there are two.
That's the answer to that.
There are two plots.
What is the name of the service created
for accessing CoreDNS?
The name of the service created
for accessing CoreDNS,
let's do a service that as we see
in the Kube system namespace,
and we see that there's only one service
called Kube-DNS.
That's the service that's used
for accessing the DNS server.
That is Kube-DNS.
Now, what is the IP of the CoreDNS server
that should be configured on the PODs
to resolve services?
All the PODs should have the IP
of the CoreDNS service,
and that IP is 10.96.0.10.
That's the IP of this service
so that is just one.
Now, where is the configuration file
located for configuring
the CoreDNS service?
Let's look at the CoreDNS service.
Let's do a cube system.
We see that we have these two PODs.
Let's take a closer look at those PODs.
Do a described POD
in the Kube system namespace,
and we see additional information.
Here is the container that runs
the CoreDNS service.
This is the image that runs this CoreDNS 1.7.0
and these are the PODs that are exposed.
Here, if you look,
these are the arguments that are passed
to the CoreDNS container.
The config file is at /etc/coredns/Corefile.
That's the etc CoreDNS Corefile.
That's the configuration file.
How is this Corefile passed
into the CoreDNS POD?
Is it pulled from Git when it starts
or is it configured as a ConfiMag object?
Does it come built-in,
or is it stored on the master node?
If you look at this,
the path, etc/CoreDNS,
let's see if there are any mounts.
There are mounts,
so we have an etc/CoreDNS mount,
and it says that it is coming
from config volume.
We can also see this
if, let's say, we do a
Kube-Cuddle get POD,
and we look at it in the YAML format.
If you look at it this way, scroll up,
this is the spec section.
You can ignore all of this,
always look at the spec section
and we have the containers.
For the container,
we have the arguments that we just saw,
the image, and everything.
If you scroll down,
you'll see the volume mounts.
You have volume mounts here.
This etc/CoreDNS is the volume mount,
and it's coming from a config volume.
If you have volume mounts,
then you have volumes.
You scroll down and we see volumes.
This is where the volumes are configured.
The volume for config mount
is the config volume.
Here, you see you have
the Corefile
and CoreDNS.
CoreDNS is the config volume,
so ConfigMap.
This is what tells us that
it's loaded from a ConfigMap.
The next question is,
what is the name of the ConfigMap object
created for the Corefile?
For this volume, this ConfigMap,
the name of the ConfigMap is CoreDNS.
That's the name of the ConfigMap
and what is the root domain,
or zone configured
for this Kubernetes cluster.
To find that out,
we have to look into that ConfigMap.
Let's do that now.
Let's do a get ConfigMap
in the Kube system namespace.
We have the CoreDNS.
Let's do a describe ConfigMap
in the Kube-system namespace.
These are the DNS
config for Kubernetes.
Right here, this is the root domain.
That's cluster.local.
Now, we have deployed a set of PODs
and services in the default
and payroll namespaces,
inspect them and go to the next question.
Let's do that.
Let's look at get PODs.
We see that there are indeed the HR,
the simple-webapp and test.
There are four parts.
Then there's also another namespace
called payroll.
In the payroll namespace,
there is another application called web.
There are multiple applications.
That's fine.
Now, what name can be used to access
the HR web server from the Test Application?
Here we have the HR web server
and here we have the Test Application.
We want to access the HR web server
from the Test Application.
You can execute the curl command or you can--
Test Applications also have a UI.
Let's just use the UI.
I like the UI.
This is the UI of the Test Application
and we'll use this to run a connectivity test.
First, how do you access
the HR Application?
If you do an HR,
I'm assuming it's on 8080,
it's not working.
We have to find out what is the service
that's used to access this.
Let's do a curl get svc
because that's in the default namespace.
We see that there are multiple services,
here you have the test-service
and the web-service.
I'm assuming the test-service
is for the Test Application.
I'm not sure if the web-service
is for the HR Application.
Let's do a describe on the web-service.
Service is missing, svc.
We see that the selector here,
name=HR.
That indicates that the web-service
is a service for the HR application.
That's what connects them to.
It's web-service.
I'm going to use web-service.
The port, if you see is 80.
That's what I'm going to do.
I'm going to use web-service
and the port 80 and let's run the test.
It says this is the HR service.
That's good.
That confirms that, so it's web-service.
That's what is the answer to this question.
Now, which of the names CANNOT be used
to access the HR service
from the test POD?
We know that to access the HR service
from the test POD, we just use web-service.
That works.
That's web-service.default work.
It will because we are
in the default namespace.
Let's try that.
Default, that works.
Does web-service.default.svc work?
Svc,
yes, because svc stands for service
and web-service is a service
in the default namespace.
That's fine.
The next one is web-service.default.POD.
Let's try POD.
That fails.
That's not the right kind of convention.
This is the right answer to this question.
Now, which of the below name
can be used to access the payroll service
from the Test Application?
The payroll service as we know is,
it must be in the payroll namespace.
Let's explore that.
Let's do a Kube-Cuddle get POD payroll.
There's a web-service there.
Then let's do a get svc -n payroll
and we see a
web-service here.
Let's make sure that this is for that.
Let's do a k describe svc web-service
in payroll service
in the payroll namespace.
We see that the selectors name=webapp.
That's for this.
Yes, the web-service is used
for the web application
in the payroll service
in the payroll namespace.
We'll just assume that
this is the payroll service.
Which of the below name can we use
to access the payroll service
from the Test Application?
The Test Application we know
is in the default namespace.
If you do a service
from the default namespace
is going to go to the HR app.
That's not what we want.
We want to access the web service
in the payroll namespace.
The web is not the correct answer.
Web service.default.
It is going to go to the HR app,
web service.payroll
because it's in the payroll namespace.
Let's try that.
It says this is a payroll server.
It's web service.payroll.
That's the answer to this question.
Now, which of the below name
cannot be used to access the payroll service
from the Test Application?
Web service.payroll, it works.
Web service.payroll.SVC.cluster,
so payroll.SVC.cluster.
That doesn't work because it should
either be web service.payroll,
or it should be web service.payroll.SVC,
or it should be
web service.payroll.SVC.cluster.local,
because cluster.local is the route domain,
the route zone.
You should either use cluster.local
or you shouldn't use anything at all.
Cluster is something that doesn't work.
Now, we just deployed a web server
web app that accesses a database,
MySQL server.
Let's check that out, Kube-Cuddle,
get deployment,
and we see that there's a web app indeed.
Then it accesses a database at MySQL server
or the webserver is failing
to connect to the database.
We don't see a MySQL server here.
Let's do our Kube-Cuddle, get PODs
and in all namespaces
so we can see all the PODs.
We can ignore most of these.
If you look at these two,
so there are two namespaces,
and we have the web app,
the POD that runs the web app.
It says web app.
This is a web app.
This is our application.
If you look here,
we have MySQL on database here.
It is in the payroll service
payroll namespace.
Basically, this web app is trying to connect
to the MySQL POD in the payroll namespace,
but it's not able to access.
Locate the applications
and the web server interface can be seen
by clicking the tab web server
at the top of your terminal.
Here we have the web server,
so just open that.
As you can see, it is in a failed state.
If you look at the environment variables
that were passed away,
it says the DB host is MySQL
DB database, not set,
DB user route, DB password,
all of that.
It says the name does not resolve.
The issue is with the name.
If you look at this, it says MySQL.
MySQL is a name.
The web app here is trying to get
to the MySQL service here
which is in the payroll namespace.
It's not going to be able to do that.
Let's first see the service configured
for it in the payroll namespace.
We have the MySQL service.
The service is there,
but for the web app to reach the MySQL service,
it would need to say MySQL.payroll.
That's how it should be.
Let's see where that is configured.
Let's do our Kube-Cuddle,
describe the deployment web app,
and we see that
it has environment variables
configured here, so MySQL route
and the password.
Let's deploy and edit it.
Now, of course, this password here
is not a best practice.
It should be going in through a secret
or some other safer method.
We just did that here just to keep this simple.
We have the environment here,
which is MySQL,
and we're going to change that to
MySQL.payroll.
You could just say MySQL.payroll
or MySQL.payroll.SVC
or MySQL.payroll.SVC.cluster.local.
Let's save that.
Let's check the PODs.
You can see that the older one is terminating
and then the new one is already running.
Let's go back and check the status here.
We see that it's a success.
Now we have a DB host,
which is MySQL.payroll.
That's good.
Let's check the work.
That was successful.
Now the next question is,
from the HR POD, run NSlookup,
and the MySQL service
and redirect the output to a file.
From the HR POD,
so we're going to do an exec HR
and then give a command.
The command we need to run is NS lookup,
we'll do a MySQL
and it says it's not found.
We know that since the HR app
is in the default namespace,
and MySQL is in the payroll namespace
which should be pending payroll to the name.
That's got us the IP address
of the MySQL POD,
and you can also see the full name
of the MySQL service here.
Let's redirect that to this path.
Let's make sure that
it's redirected successfully
and see the output.
That's the end of this lab.
All right.
Thank you very much.