自从Kubernetes1.11之后，CoreDNS作为集群内默认的域名解析服务，你是否对它还仅仅还停留在对Kubernetes的Service解析呢？事实上光DNS在K8S内就有很多有意思的操作，今天我们不妨来看看CoreDNS的各种高阶玩法。

1. 自定义hosts解析

默认情况下，Kubernetes集群内的容器要解析外部域名时，CoreDNS会将请求转发给/etc/resolv.conf文件里指定的上游DNS服务器。这个是由这个配置决定的。

forward . /etc/resolv.conf

有的时候，我们如果需要在集群内全局劫持某个域名时，我们通常可以利用hosts插件来帮忙。
hosts插件会每隔5s将需解析的信息重新加载到coredns当中，当你有任何变化时直接更新它的配置区块即可。常见的host有两种方法配置，分别如下：

• 定义host

.:53 {
    hosts {
        1.1.1.1 test.cloudxiaobai.com
        2.2.2.2 test2.cloudxiaobai.com
        fallthrough
    }
}

• 加载hosts文件

#直接从/etc/hosts加载host信息
. {
    hosts {
        fallthrough
    }
}

#又或者,从当前目录的test.hosts文件中加载host信息

. {
    hosts test.hosts {
        fallthrough
    }
}

当被需要解析的域名不在hosts当中时，需要用fallthrough继续将请求转发给其它插件继续处理

扩展

如果我们只是想在Workloads内局部生效部分host信息时，那么可以借助于HostAliases向Pod的/etc/hosts文件内添加主机信息。我们拿deployment来举例，

apiVersion: extensions/v1beta1
kind: Deployment
spec:
  template
    spec:
      containers:
      - image: busybox:latest
        name: nginx
      hostAliases:
      - ip: 1.1.1.1
        hostnames:
        - test1.cloudxiaobai.com
      - ip: 2.2.2.2
        hostnames:
        - test1.cloudxiaobai.com
...

2. 支持SRV记录

SRV记录是域名系统中用于指定服务器提供服务的位置（如主机名和端口）数据。它在DNS记录中的是个新鲜面孔，在RFC2082中才对SRV记录进行了定义，因此有很多老旧服务器并不支持SRV记录。SRV在RFC2082定义的标准记录格式如下：

#英文
_Service._Proto.Name TTL Class SRV Priority Weight Port Target

#中文
_服务._协议.名称. TTL 类别 SRV 优先级 权重 端口 主机.

• Service ：服务的符号名称
• Proto ： 服务的传输协议，通常为TCP或UDP，Proto不区分大小写
• Name ：此RR所指的域名，在这个域名下SRV RR是唯一的
• TTL ： 标准DNS存活时间
• CLASS ： 标准DNS类别值（此值总为IN）
• Priority ： 目标主机的优先级，值越小越优先，范围0-65535
• Weight ： 相同优先度记录的相对权重，值越大越优先
• Port ： 服务所在的TCP或UDP端口
• Target : 提供服务的规范主机名，以半角句号结尾

在Kubernetes里面，CoreDNS会为有名称的端口创建SRV记录，这些端口可以是svc或headless.svc的一部分。对每个命名端口，SRV记录了一个类似下列格式的记录：

_port-name._port-protocol.my-svc.my-namespace.svc.cluster.local

在Golang中我们用net.LookupSRV来发起SRV记录查询

func (r *Resolver) LookupSRV(ctx context.Context, service, proto, name string) (cname string, addrs []*SRV, err error)

net库里对SRV结构体里定义了4个字段，分别是Target,Port，Priority,Wright。当我们使用LookupSRV发起SRV查询时，得到的返回的记录会按优先级排序，并在优先级内按权重进行随机分配。如果service和proto均为空字符串，则LookupSRV直接查找name。

拿thanos的SRV查询举个例子

1. 第一步 resolver.go中SRV查询逻辑

thanos中的resolver.go里面包含了处理SRV查询的逻辑，如下：

    case SRV, SRVNoA:
        _, recs, err := s.resolver.LookupSRV(ctx, "", "", host)
        if err != nil {
            return nil, errors.Wrapf(err, "lookup SRV records %q", host)
        }

        for _, rec := range recs {
            resPort := port
            if resPort == "" {
            //获取SRV返回的端口
                resPort = strconv.Itoa(int(rec.Port))
            }

            if qtype == SRVNoA {
            //如果不需要使用A或者AAAA记录查询时，则组合主机名:端口
                res = append(res, appendScheme(scheme, net.JoinHostPort(rec.Target, resPort)))
                continue
            }
            // Do A lookup for the domain in SRV answer.
            resIPs, err := s.resolver.LookupIPAddr(ctx, rec.Target)
            if err != nil {
                return nil, errors.Wrapf(err, "look IP addresses %q", rec.Target)
            }
            //根据主机名遍历出所有的ip地址，并组合成ip:port的方式
            for _, resIP := range resIPs {
                res = append(res, appendScheme(scheme, net.JoinHostPort(resIP.String(), resPort)))
            }

第二步 创建Kubernetes Service

CoreDNS中对于有名称的port，会为其创建一条对应的SRV记录。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: thanos-receiver
  name: thanos-receiver
  namespace: monitor
spec:
  ClusterIP: None
  ports:
  - name: grpc
    port: 10901
    protocol: TCP
    targetPort: 10901

如上结构的Service我们就可以使用如下方式查询域名:

_grpc._tcp.thanos-receiver.monitor.svc.cluster.local

我们用dig命令做一次SRV记录查询就可以得到响应，可以看到下列的ANSWER SECTION中得到了net库里面定义的SRV结构体的数据了，并且CoreDNS返回了三条记录：

# dig srv _grpc._tcp.thanos-receiver.monitor.svc.cluster.local

...
;; ANSWER SECTION:
_grpc._tcp.thanos-receiver.monitor.svc.cluster.local. 6 IN SRV 0 33 10901 10-59-155-238.thanos-receiver.monitor.svc.cluster.local.
_grpc._tcp.thanos-receiver.monitor.svc.cluster.local. 6 IN SRV 0 33 10901 10-59-42-68.thanos-receiver.monitor.svc.cluster.local.
_grpc._tcp.thanos-receiver.monitor.svc.cluster.local. 6 IN SRV 0 33 10901 10-59-48-162.thanos-receiver.monitor.svc.cluster.local.

;; ADDITIONAL SECTION:
10-59-48-162.thanos-receiver.monitor.svc.cluster.local. 6 IN A 10.59.48.162
10-59-42-68.thanos-receiver.monitor.svc.cluster.local. 6 IN A 10.59.42.68
10-59-155-238.thanos-receiver.monitor.svc.cluster.local. 6 IN A 10.59.155.238
...

可以看到这条SRV记录里面，分别返回了三个服务的IP地址、端口、以及服务的优先级和权重

第三步 使用SRV记录做服务发现

对于代码中启用了SRV记录的业务，只需要在业务配置里面加上需要访问的SRV地址即可，例如thanos-query需要调thanos-receiver的grpc端口做监控数据查询，如果我们集群内有多个receiver服务的话，我们就像如下配置，即可做到DNS的服务发现：

...
    spec:
      containers:
      - args:
        - query
        # 定义thanos-receiver服务SRV记录
        - --store=dnssrv+_grpc._tcp.thanos-receiver.monitor.svc.cluster.local
...

当服务正常运行后我们就可以查到receiver服务以及注册到query里面了

?

3. NodeLocal DNSCache

有很多同学经常会抱怨，在Kubernetes中有时候会遇到DNS解析间歇性5s超时的问题。其实这个问题社区很早意识到DNS的经过Iptables到Conntrack遇到竞争的问题，并给出来利用Daemonset在集群的每个Node上运行一个精简版的CoreDNS并监听一个虚拟ip地址来绕过Conntrack，同时还能充当缓存环境CoreDNS压力。此举能大幅降低DNS查询timeout的频次，提升服务稳定性。

?

关于部署

node-local-dns通过添加iptables规则能够接收节点上所有发往169.254.20.10的dns查询请求，把针对集群内部域名查询请求路由到coredns。把集群外部域名请求直接通过host网络发往本地/etc/resolv.conf记录的外部DNS服务器中。

# 下载部署脚本
$ curl https://node-local-dns.oss-cn-hangzhou.aliyuncs.com/install-nodelocaldns.sh

# 部署,确保kubectl能够连接集群
$ bash install-nodelocaldns.sh

如何使用

NodeLocal DNSCache的部署并不会直接产生效果,通常我们有两种方式可以让集群的pod使用上本机DNS缓存。

1. 定制业务容器dnsConfig

Kubernetes的workload中允许我们自定义dns相关的配置，其中我们需要注意以下几点：

• dnsPolicy: None，不使用ClusterDNS。
• 配置searches，保证集群内部域名能够被正常解析。
• 适当降低ndots值，当前ACK集群ndots值默认为5,降低ndots值有利于加速集群外部域名访问。
• 适当调整options参数，避免并发请求single-request和分开A和AAAA请求采用的源端口single-request-reopen

可以参考如下

dnsPolicy: None
dnsConfig:
    nameservers: ["169.254.20.10"]
    searches:
    - default.svc.cluster.local
    - svc.cluster.local
    - cluster.local
    options:
    - name: ndots
      value: "2"
    - name: single-request-reopen
      value: ""
    - name: timeout
      value: "1"

2. 修改Kubelet配置

kubelet启动参数中可以通过参数--cluster-dns来指定容器的nameserver，我们只需将它修改成169.254.20.10重启即可。不过容器要真正将NodeLocal DNSCache用起来话，还得将Pod重启才会生效。

4. 禁用IPv6域名解析

有时候我们Kubernetes集群内没有启用IPv6的话，可以在CoreDNS内禁止IPv6的域名解析，这个时候我们可以用Template这个插件来解决：

.:53 {
    template ANY AAAA {
        rcode NXDOMAIN
    }
...

}

这条记录会将所有的AAAA查询直接返回NXDOMAIN,并且不会被转发给其它插件处理

--- 未完待续 ---