Container Compute Service:Configure unmanaged CoreDNS

Scenarios

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: alinux3
  namespace: default
spec:
  containers:
  - image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/alinux3
    command:
      - sleep
      - "10000"
    imagePullPolicy: Always
    name: alinux3
  dnsPolicy: ClusterFirst

For more information about how to configure the dnsPolicy parameter in various scenarios, see Configure DNS resolution.

Default configurations of CoreDNS

In the kube-system namespace of the ACS cluster, you can find a CoreDNS ConfigMap. CoreDNS configures and enables plug-ins that are specified in the ConfigMap. The ConfigMaps of each CoreDNS version differ slightly. Before modifying the configuration, read the CoreDNS official documentation. The default configuration file used by CoreDNS 1.6.2 is as follows:

  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
    }

Configure extended features based on CoreDNS

Configure extended features based on CoreDNS in the following scenarios:

• Scenario 1: Enable Simple Log Service

  To collect the log of all DNS resolution records performed by CoreDNS, 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, such as 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
    }
  }

  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, use user-defined DNS servers to perform DNS resolution for all external domain names.

  For example, if the IP addresses of the user-defined DNS servers are 10.10.0.10 and 10.10.0.20, 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

  Configure the hosts plug-in to specify a static IP address for specified domain names, such as pointing www.example.com to 127.0.0.1. This method has the same effect as the /etc/hosts file. 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 the fallthrough parameter in hosts. Otherwise, domain names that are not specified may fail to be resolved.

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

  To enable a process on an ECS instance in an ACK cluster to access services in the cluster, 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, use an internal-facing Classic Load Balancer (CLB) instance to allow internal access to services in the ACS 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 CLB 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

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

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

  • Your service foo.default.svc.cluster.local is exposed to internal access using an internal-facing CLB instance. Log on to the Alibaba Cloud DNS PrivateZone console to point foo.example.com to the IP address of the internal-facing CLB instance in the virtual private cloud (VPC) where the ACK cluster is deployed. See Configure unmanaged CoreDNS.

  • Use the rewrite plug-in within the ACK cluster 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 based on AAAA records, configure CoreDNS to intercept the resolution results and return a NODATA code. Doing so 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 .
      }