DNS

Architecture

MetaKube deploys two different DNS servers in each MetaKube cluster:

A highly available CoreDNS Deployment
Node-local-dns DaemonSet running on each Node

Path of a query

Each DNS query from an application in a Kubernetes Pod takes the following path:

Application queries node-local-dns locally on the node.
Cached queries for records in the cluster.local zone are resolved recursively by CoreDNS or served from a cache.
For other zones, queries are forwarded to the host's default resolver (see /etc/resolv.conf). See below.

CoreDNS

CoreDNS implements the Kubernetes DNS service.
It's deployed in the cluster through the Deployment coredns in the kube-system namespace.
The Deployment is automatically scaled horizontally based on its load.
The virtual IP of the CoreDNS Service is always the 10^th IP in the Service network (default 10.240.16.10).

For additional configuration, see extending CoreDNS configuration below.

You can find more information about the kinds of records CoreDNS serves and how you can use CoreDNS in the official Kubernetes documentation.

Node local DNS cache

A large amount of DNS queries can overload CoreDNS or lead to higher latency. That's why MetaKube Core installs a DNS cache resolver on each node.

It's deployed through the node-local-dns DaemonSet in the kube-system namespace and also runs CoreDNS, but with different configuration.
The server listens on the fixed address 169.254.20.10:53 with UDP & TCP on a dummy interface nodelocaldns.
Containers are configured by Kubelet to use the node local DNS cache by an entry in their /etc/resolve.conf file.
Queries for names in the cluster.local domain are forwarded to CoreDNS and results cached.
Queries for other names are forwarded based on the host's /etc/resolv.conf configuration, see external names.

For additional configuration, see extending CoreDNS configuration below.

External names

Queries for names not in the cluster.local domain are not answered by CoreDNS. They use the following resolvers/servers:

Local DNS resolver (systemd-resolved) listening on 127.0.0.53:53
DNS servers of the OpenStack subnet configured through DHCP

Host queries

Queries coming from the host directly (not from inside containers) don't go to CoreDNS. E.g. dig kubernetes.svc.cluster.local resolves when run in a Pod, but not on the host.

Extending the CoreDNS configuration

You can extend the configuration of both, node local DNS or CoreDNS by creating a ConfigMap coredns-extra-configs or node-local-dns-extra-configs respectively in the kube-system namespace.

It must contain a valid CoreDNS configuration file under the Corefile key. You may declare your own servers or configuration snippets.

Snippet common

The common snippet is reserved. It may be imported but must not be redeclared.

Example manifest

With the following configuration, node local DNS will forward queries for names in the example.com domain to 1.2.3.4.

apiVersion: v1
kind: ConfigMap
metadata:
  name: node-local-dns-extra-configs
  namespace: kube-system
data:
  Corefile: |
    example.com {
      import common
      forward . 1.2.3.4
    }

Note

Changes to the ConfigMaps take effect after CoreDNS reloads the config file. This should not take longer than 30s.

DNS