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.
CoreDNS resolves cached queries for records in the cluster.local zone, or serves them from cache.
For other zones, the resolver sends queries 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 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 DNS cache resolver on each node prevents query volume from overloading CoreDNS or increasing latency. MetaKube Core installs the resolver as a DaemonSet.

The node-local-dns DaemonSet in the kube-system namespace runs CoreDNS with different configuration.
The server listens on the fixed address 169.254.20.10:53 with UDP & TCP on a dummy interface nodelocaldns.
Kubelet configures containers to use the node local DNS cache through an entry in their /etc/resolve.conf file.
For names in the cluster.local domain, the resolver forwards queries to CoreDNS and caches the results.
For other names, the resolver follows the host's /etc/resolv.conf configuration, see external names.

For 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