Container Service for Kubernetes:Configure CoreDNS

In this topic, a pod that uses CoreDNS for DNS resolution is used as an example. dnsPolicy: ClusterFirst is specified in the DNS policy configuration of the pod. Example:

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: default
spec:
  containers:
  - image: alpine
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alpine
  dnsPolicy: ClusterFirst

In the kube-system namespace, you can find a CoreDNS ConfigMap. For more information about how to view a ConfigMap, see Manage ConfigMaps. CoreDNS configures and enables plug-ins that are specified in the ConfigMap. The ConfigMaps of different CoreDNS versions are slightly different. Read the CoreDNS official documentation before you modify the configurations. The following code block shows the content of the default configuration file used by CoreDNS 1.6.2:

  Corefile: |
    .:53 {
        errors
        log
        health {
           lameduck 15s
        }
        ready
        kubernetes {{.ClusterDomain}} in-addr.arpa ip6.arpa {
          pods verified
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf {
              prefer_udp
        }
        cache 30
        loop
        reload
        loadbalance
    }

You can configure extended features based on CoreDNS in the following scenarios:

• Scenario 1: Enable log collection

  To collect the log of all DNS resolution records performed by CoreDNS, you can enable the log plug-in by adding the log parameter to Corefile. Example:

    Corefile: |
      .:53 {
          errors
          log
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
                prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• Scenario 2: Customize DNS servers for specified domain names

  If domain names with a suffix of example.com need to be resolved by a user-defined DNS server (for example, DNS server 10.10.0.10), you must add a custom resolution setting for the domain names. Example:

  example.com:53 {
    errors
    cache 30
    forward . 10.10.0.10 {
    prefer_udp
    }
  }

  The following code block shows the complete Corefile configuration:

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }
      example.com:53 {
          errors
          cache 30
          forward . 10.10.0.10 {
          prefer_udp
          }
      }

• Scenario 3: Customize DNS servers for external domain names

  If the domain names that need to be resolved by user-defined DNS servers do not contain the same suffix, you can use user-defined DNS servers to perform DNS resolution for all external domain names. In this scenario, you must forward the domain names that cannot be resolved by the user-defined DNS servers to Alibaba Cloud DNS. Do not modify the /etc/resolv.conf files on Elastic Compute Service (ECS) instances of the ACK cluster. For example, if the IP addresses of the user-defined DNS servers are 10.10.0.10 and 10.10.0.20, you can modify the forward parameter. Example:

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . 10.10.0.10 10.10.0.20{
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

• Scenario 4: Customize hosts for specified domain names

  You can configure the hosts plug-in if you want to customize hosts for specified domain names, for example, you may need to point www.example.com to 127.0.0.1. Example:

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          ready
          
          hosts {
            127.0.0.1 www.example.com
            fallthrough
          }
        
          kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
          }
          prometheus :9153
          forward . /etc/resolv.conf {
            prefer_udp
          }
          cache 30
          loop
          reload
          loadbalance
      }

  Important

  You must specify fallthrough. Otherwise, domain names other than the specified one may fail to be resolved.

• Scenario 5: Enable external access to services in an ACK cluster

  If you want to enable a process on an ECS instance in an ACK cluster to access services in the cluster, you can specify the cluster IP address of kube-dns in the cluster as the value of the nameserver parameter in the /etc/resolv.conf file on the ECS instance. Do not modify other settings in the /etc/resolv.conf file.

  In an internal network, you can use an internal-facing Server Load Balancer (SLB) instance to allow internal access to services in the ACK cluster. Then, log on to the Alibaba Cloud DNS PrivateZone console and add an A record that points to the private IP address of the SLB instance.

• Scenario 6: Use a domain name to allow access to your service in an ACK cluster or enable CNAME resolution for an ACK cluster

  You can use foo.example.com to allow all access to your service in an ACK cluster from the Internet, internal networks, and inside an ACK cluster. The following section describes how to enable this feature:

  • Your service foo.default.svc.cluster.local is exposed to external access through an Internet-facing SLB instance. The domain name foo.example.com is resolved to the IP address of the Internet-facing SLB instance.

  • Your service foo.default.svc.cluster.local is exposed to internal access through an internal-facing SLB instance. Log on to the Alibaba Cloud DNS PrivateZone console to point foo.example.com to the IP address of the internal-facing SLB instance in the virtual private cloud (VPC) where the ACK cluster is deployed. For more information about the procedure, see Scenario 4: Customize hosts for specified domain names.

  • Inside the ACK cluster, you can use the rewrite plug-in to add a CNAME record to point foo.example.com to foo.default.svc.cluster.local. Example:

      Corefile: |
        .:53 {
            errors
            health {
               lameduck 15s
            }
            ready
            
            rewrite stop {
              name exact foo.example.com foo.default.svc.cluster.local
              answer name foo.default.svc.cluster.local foo.example.com 
            }
    
            kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
              ttl 30
            }
            prometheus :9153
            forward . /etc/resolv.conf {
              prefer_udp
            }
            cache 30
            loop
            reload
            loadbalance
        }

• Scenario 7: Configure CoreDNS not to return IPv6 addresses that are resolved based on AAAA records

  If your application pods do not need resolution results that are based on AAAA records, you can configure CoreDNS to intercept resolution results that are based on AAAA records and return a NODATA code. This minimizes data transfer. Example:

    Corefile: |
      .:53 {
          errors
          health {
             lameduck 15s
          }
          # Add the following line to enable the template plug-in. Do not modify other settings. 
          template IN AAAA .
      
      }

• Scenario 8: Enable the MCS feature of ACK One

  Note

  CoreDNS 1.9.3 or later supports the multi-cluster Services (MCS) feature of Distributed Cloud Container Platform for Kubernetes (ACK One). To enable this feature, make sure that you have updated CoreDNS to 1.9.3 or later. For more information, see Configure ACK to automatically update CoreDNS and Manually update CoreDNS.

  1. Run the following command to update the ConfigMap of CoreDNS:

     kubectl edit configmap/coredns -n kube-system

  2. Add a line above the line that starts with kubernetes and specify multicluster clusterset.local in the new line to enable the multicluster plug-in, which is used to enable the MCS feature of ACK One. This configuration sets the suffixes of the domain names of multi-cluster Services to clusterset.local.

     Corefile: |
         .:53 {
             # Irrelevant lines are not shown. 
             # Add the following line. 
             multicluster clusterset.local
             kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods insecure
               fallthrough in-addr.arpa ip6.arpa
               ttl 30
             }
             # Irrelevant lines are not shown. 
         }

  3. Press Esc, enter :wq!, and then press Enter to save the file and exit the edit mode.