Daniel's Tech Blog

Cloud Computing, Cloud Native & Kubernetes

Configuration options for CoreDNS in Azure Kubernetes Service

In my last blog post I have shown you the configuration of custom upstream nameservers for CoreDNS in AKS.

-> https://www.danielstechblog.io/setting-custom-upstream-nameservers-for-coredns-in-azure-kubernetes-service/

But there are more configuration options available to customize your CoreDNS experience. We will focus at some of them today.

First, let us have a look at the two options in the custom-coredns ConfigMap. We get a .override and a .server option. Where the .override option allows us to change the system configuration of CoreDNS stored in the coredns ConfigMap on AKS.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  Corefile.override: |
        forward . 8.8.8.8 8.8.4.4

The .server option let us provide specific options for domains that should not or cannot be served by the default nameservers.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  azure.server: |
    internal.cloudapp.net:53 {
        errors
        cache 30
        proxy . 168.63.129.16
    }

Looking at the official CoreDNS plugin list, you discover that there are a lot of plugins available.

-> https://coredns.io/plugins/
-> https://coredns.io/explugins/

In the default configuration on AKS CoreDNS uses the plugins errors, health, kubernetes, prometheus, proxy, cache, loop, reload, loadbalance and import.

The customization of the default system configuration of CoreDNS like changing the upstream nameservers was the topic in the blog post mentioned earlier.

-> https://www.danielstechblog.io/setting-custom-upstream-nameservers-for-coredns-in-azure-kubernetes-service/

So, we will not focus on that today. In the following example for the domain k8s.local I am using the plugins log, errors, cache and proxy.

Per default you should always use the plugins errors, cache and proxy. At least the proxy or forward plugin is required to forward requests to the specified nameserver or nameservers. The cache plugin caches requests for the specified amount of time which is specified in seconds. Ultimately the errors plugin logs errors to stdout and is useful for troubleshooting purposes.

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  k8s.local.server: |
    k8s.local:53 {
        errors
        cache 30
        log
        proxy . 172.16.0.4
    }

The log plugin logs every request to the stdout interface of the CoreDNS pods.

kl coredns-75544f5d88-57pgp
[WARNING] No files matching import glob pattern: custom/*.override
.:53
k8s.local.:53
2019-08-23T21:18:55.910Z [INFO] CoreDNS-1.3.1
2019-08-23T21:18:55.910Z [INFO] linux/amd64, go1.11.4, 6b56a9c
CoreDNS-1.3.1
linux/amd64, go1.11.4, 6b56a9c
2019-08-23T21:18:55.910Z [INFO] plugin/reload: Running configuration MD5 = 3d857228607ba1ff23e0d609eae89195
2019-08-23T21:23:37.167Z [INFO] 10.240.0.242:57045 - 4864 "A IN aks.k8s.local. udp 31 false 512" NOERROR qr,aa,rd,ra 60 0.002444787s
2019-08-23T21:23:37.167Z [INFO] 10.240.0.242:57045 - 4864 "AAAA IN aks.k8s.local. udp 31 false 512" NOERROR qr,aa,rd,ra 89 0.002917085s
2019-08-23T21:23:39.666Z [INFO] 10.240.0.242:57045 - 4864 "AAAA IN aks.k8s.local. udp 31 false 512" NOERROR qr,rd,ra 89 0.000067299s
2019-08-23T21:24:50.975Z [INFO] 10.240.0.242:58434 - 5120 "AAAA IN aks-engine.k8s.local. udp 38 false 512" NOERROR qr,aa,rd,ra 96 0.001471193s
2019-08-23T21:24:50.976Z [INFO] 10.240.0.242:58434 - 5120 "A IN aks-engine.k8s.local. udp 38 false 512" NOERROR qr,aa,rd,ra 74 0.002443388s
2019-08-23T21:24:53.476Z [INFO] 10.240.0.242:58434 - 5120 "AAAA IN aks-engine.k8s.local. udp 38 false 512" NOERROR qr,rd,ra 96 0.0001094s

For specific domains it might be useful to get the request in the CoreDNS logs but activating it in the system configuration with the .override option would cause a lot of noise in the logs.

So, if you need the logging functionality only activate it for specific domains with the .server option.

Getting the log output into Azure Monitor for containers requires additional configuration. Cause the CoreDNS pods are running in the kube-system namespace.

-> https://www.danielstechblog.io/tweaking-data-collection-for-azure-monitor-for-containers/

I hope you got an idea how to customize the CoreDNS settings on AKS covering your use cases.


Posted

in

WordPress Cookie Notice by Real Cookie Banner