coredns

The coredns add-on provides the internal domain name resolution service for your other workloads. Do not delete or upgrade this workload; otherwise, the internal domain name resolution service will become unavailable.

Installing an Add-on

1. Log in to the CCI console. In the navigation pane, choose Add-ons > Add-on Marketplace. Then, click on the card of the add-on you want to install.
   Figure 1 coredns add-on
   

2. Select a version from the Add-on Version drop-down list, and click Submit.
   When installing coredns v2.5.9 or later, you must configure the following parameters:

   • Stub Domain: A DNS server that resolves user-defined domain names. The stub domain contains the suffix of the DNS domain name followed by one or more DNS IP addresses. For example, acme.local -- 1.2.3.4,6.7.8.9 means that DNS requests with the .acme.local suffix are forwarded to a DNS listening at 1.2.3.4,6.7.8.9.
   • Upstream DNS Server: A DNS server that resolves all domain names except intra-cluster service domain names and user-defined domain names. The value can be one or more DNS IP addresses, for example, 8.8.8.8,8.8.4.4.

   After you complete the installation, the installed add-on is available at Add-ons > Add-on Instances.

   Figure 2 coredns installed
   

Configuring Stub Domains for coredns

As a cluster administrator, you can modify the ConfigMap for the CoreDNS Corefile to change how service discovery works. You can configure stub domains for coredns using the proxy plug-in.

Assume that you are a cluster administrator and you have a Consul DNS server located at 10.150.0.1 and all Consul domain names have the suffix .consul.local. To configure this Consul DNS server in coredns, you need to write the following information in the coredns ConfigMap:

consul.local:5353 {
        errors
        cache 30
        proxy . 10.150.0.1
    }

ConfigMap after modification:

apiVersion: v1
data:
  Corefile: |-
    .:5353 {
        cache 30
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          upstream /etc/resolv.conf
          fallthrough in-addr.arpa ip6.arpa
        }
        loadbalance round_robin
        prometheus 0.0.0.0:9153
        proxy . /etc/resolv.conf
        reload
    }

    consul.local:5353 {
        errors
        cache 30
        proxy . 10.150.0.1
    }
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system

How Does Domain Name Resolution Work in Kubernetes?

DNS policies can be set on a per-pod basis. Currently, Kubernetes supports four types of DNS policies: Default, ClusterFirst, ClusterFirstWithHostNet, and None. For details, see https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/. These policies are specified in the dnsPolicy field in the pod-specific.

• Default: Pods inherit the name resolution configuration from the node that runs the pods. The custom upstream DNS server and the stub domain cannot be used together with this policy.
• ClusterFirst: Any DNS query that does not match the configured cluster domain suffix, such as www.kubernetes.io, is forwarded to the upstream name server inherited from the node. Cluster administrators may have extra stub domains and upstream DNS servers configured.
• ClusterFirstWithHostNet: For pods running with hostNetwork, set its DNS policy ClusterFirstWithHostNet.
• None: It allows a pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the dnsPolicy field in the pod-specific.

• Clusters of Kubernetes v1.10 and later support Default, ClusterFirst, ClusterFirstWithHostNet, and None. Clusters earlier than Kubernetes v1.10 support only Default, ClusterFirst, and ClusterFirstWithHostNet.
• Default is not the default DNS policy. If dnsPolicy is not explicitly specified, ClusterFirst is used.

Routing

• Without stub domain configurations: Any query that does not match the configured cluster domain suffix, such as www.kubernetes.io, is forwarded to the upstream DNS server inherited from the node.
• With stub domain configurations: If you have configured stub domains and upstream DNS servers, DNS queries are routed according to the following flow:
  1. The query is first sent to the DNS caching layer in coredns.
  2. From the caching layer, the suffix of the request is examined and then forwarded to the appropriate DNS, based on the following cases:
     • Names with the cluster suffix, for example, .cluster.local: The request is sent to coredns.
     • Names with the stub domain suffix, for example, .acme.local: The request is sent to the configured custom DNS resolver, listening for example at 1.2.3.4.
     • Names that do not match the suffix (for example, widget.com): The request is forwarded to the upstream DNS.
  Figure 3 Routing
  

Follow-Up Operations

After the add-on is installed, you can perform the following operations on the add-on.