Home Tutorials Contact About Testimonials

Search
 Us

Ads by
Introduction 
Core DNS in Kubernetes 01 JUL - 04 SEPT
Core Concepts DON'T MISS
Stop seeing
ad
this
 In this tutorial, we are going to discuss about OUT ON
Scheduling  DUBAI
Why this ad?
Core DNS in Kubernetes and how Kubernetes SUMMER
Monitoring 
implements in the cluster. SURPRISES
25TH
Application EDITION!
Lifecycle In the previous tutorial we saw how you can
Management  address a service or POD from another POD.

Cluster So in this tutorial, we will see how Kubernetes

Maintenance  makes that possible.
Security 

Kubernetes
Storage 

Networking  DISCOVER MORE

Switching and Say you were given two pods with two IP
Routing
addresses. How would you do it? Based on
DNS what we discussed in the prerequisite tutorial on
Network DNS, an easy way to get them to resolve each
Namespaces
other is to add an entry into each of their
About Docker /etc/hosts files.
Networking

Container On the first POD, I would say the second POD

Network web is at 10.244.2.5 and on the second pod I
Interface
would say the first POD test is at 10.244.1.5.
Cluster
Networking

POD
Networking

CNI in
Kubernetes But of course, when you have 1000s of PODs in
the cluster, and 100s of them being created and
Service deleted every minute. So this is not a suitable
Networking solution.
DNS in
Kubernetes Move entries into a central DNS server

Core DNS in So we move these entries into a central DNS

Kubernetes
server. We then point these PODs to the DNS
Ingress in
server by adding an entry into their
Kubernetes
/etc/resolv.conf file specifying that the
nameserver is at the IP address of the DNS
server, which happens to be 10.96.0.10 in this

case.

So every time a new POD is created, we add a

record in the DNS server for that POD. So that
other pods can access the new POD, and
configure the /etc/resolv.conf file in the POD to
the DNS server so that the pod can resolve
other PODs in the cluster.

This is kind of how Kubernetes does it. Except

that it does not create similar entries for PODs
to map pod name to its IP address as we have
seen in the previous tutorial.

It does that for services. For PODs it forms host

names by replacing dots with dashes in the IP
address of the pod.

Kubernetes implements DNS in the same way. It

deploys a DNS server within the cluster. Prior to
version v1.12 the DNS implemented by
Kubernetes was known as kube-dns.

CoreDNS

With Kubernetes version 1.12 the recommended

DNS server is CoreDNS. So how is the core
DNS setup in the cluster?

The CoreDNS server is deployed as a POD in

the kube-system namespace in the Kubernetes
cluster. Well they are deployed as two pods for
redundancy, as part of a ReplicaSet.

They are actually a replicaset within a

deployment. But it doesn’t really matter. We’ll

just see CoreDNS as a POD in this tutorial.

This POD runs the coreDNS executable, the

same executable that we ran when we deployed

CoreDNS ourselves.

CoreDNS Configuration File

CoreDNS requires a configuration file. In our

case we used a file named Corefile. So does
Kubernetes. It uses a file named Corefile
located at /etc/coredns.

$ cat /etc/coredns/Corefile
.:53 {
errors
health
kubernetes cluster.local in-addr.a
pods insecure
fallthrough in-addr.arpa ip6.ar
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
reload
}

Within this file you have a number of plugins

configured. Plugins are configured for handling

errors, reporting health, monitoring metrics,

cache etc.

The plugin that makes CoreDNS work with

Kubernetes, is the Kubernetes plugin. And this

is where the top level domain name for the

cluster is set.

In this case cluster.local. So every record in the

coredns DNS server falls under this domain.

Within the Kubernetes plugin there are multiple

options.

The PODs option you see here, is what is

responsible for creating a record for PODs in the

cluster. Remember we talked about a record
being created for each POD by converting their

IPs into a dashed format that’s disabled by

default.

But it can be enabled with this entry here. Any

record that this DNS server can’t solve, for

example say a POD tries to reach

www.google.com it is forwarded to the

nameserver specified in the coredns pods

/etc/resolv.conf file.

The /etc/resolv.conf file is set to use the

nameserver from the Kubernetes node. Also

note, that this core file is passed into the pod

has a ConfigMap object. That way if you need to

modify this configuration you can edit the

ConfigMap object.

We now have the CoreDNS POD up and

running using the appropriate Kubernetes

plugin. It watches the Kubernetes cluster for

new PODs or services, and every time a POD or

a service is created it adds a record for it in its

database.

Pods to point to the CoreDNS

Next step is for the PODs to point to the

CoreDNS server. What address do the PODs

use to reach the DNS server? When we deploy

CoreDNS solution, It also creates a service to

make it available to other components within a

cluster.

The service is named as kube-dns by default.

The IP address of this service is configured as

nameserver on the PODs.

Now you don’t have to configure this yourself.

The DNS configurations on PODs are done by

Kubernetes automatically when the PODs are

created.

Want to guess which Kubernetes component is

responsible for that? The kubelet. If you look at

the config file of the kubelet you will see the IP

of the DNS server and domain in it.

Once the pods are configured with the right

nameserver, you can now resolve other pods

and services. You can access the web-service

using just web-service, or web-service.default or

web-service.default.svc or web-

service.default.svc.cluster.local.

$ curl web-service

$ curl web-service.default

$ curl web-service.default.svc

$ curl web-service.default.svc.cluster

If you try to manually lookup the web-service

using nslookup or the host command web-

service command, it will return the fully qualified

domain name of the web-service, which

happens to be web-
service.default.svc.cluster.local.

$ host web-service
web-service.default.svc.cluster.local

But you didn’t ask for that you just set up

service. So how did it look up for the full name.

It so happens, the resolv.conf file also has a

search entry which is set to

default.svc.cluster.local as well as
svc.cluster.local and cluster.local.

$ cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local sv

This allows you to find the service using any

name. web-service or web-service.default or

web-service.default.svc.

$ host web-service
web-service.default.svc.cluster.local

$ host web-service.default
web-service.default.svc.cluster.local
 $ host web-service.default.svc
web-service.default.svc.cluster.local

$ host web-service.default.svc.cluster
web-service.default.svc.cluster.local

However, notice that it only has search entries

for service . So you won’t be able to reach a pod

the same way.

$ host 10-244-2-5
host 10-244-2-5 not found: 3(NXDOMAIN)

For example, you need to specify the full FQDN

of the pod to to reach the POD.

$ host 10-244-2-5.default.svc.cluster
web-service.default.svc.cluster.local

 Prev Next 
 Quick Links Tutorials Contact Info

Home Core Java Address: 2nd Floor,

Bachupally, Hyderabad,
About Us Kubernetes
Telangana 500090
Testimonials Docker

Privacy Policy SQL Website:

waytoeasylearn.com
Our Mission Authors PL/SQL

Suggestions Spring
Our mission is to deliver
simply easy learning with Contact Us Hibernate
clear and in depth content
on a wide range of See More…
technical stuff.

Copyright © 2021 Waytoeasylearn.     

Automated page speed optimizations for fast site performance