k8s与dns--coredns的一些实战经验

coredns简介

安装新版本k8s，coredns已经成为默认dns了。之前是kube-dns。coredns是一个灵活，可扩展的DNS服务器，可以作为Kubernetes集群DNS。与Kubernetes一样，CoreDNS项目由CNCF主持。但是在实际使用中，需要一些注意的地方。

增加应用的反亲和性，防止coredns调度到一台主机上

coredns 所需要的资源非常小，所以很容易调度到一台主机上。coredns是一个系统组件，我们应该尽量让coredns分散部署，增强其可用性。故在deployment的yaml中增加如下设置：

      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - coredns
            topologyKey: kubernetes.io/hostname

这里利用到了k8s的一个属性反亲和性。

选择合理的coredns 伸缩

很多k8s部署，默认是部署两个coredns 实例，但是当我们集群逐步变大的时候，2个实例是不能满足需求的。因而coredns的伸缩就非常重要了。切记coredns 千万不要用hpa来弹性伸缩coredns。频繁的伸缩，会导致业务很多dns解析失败的情况。需要用cluster-proportional-autoscaler组件，我一般是选择根据node节点数来伸缩dns。具体的伸缩策略大家可以选择。

如何利用coredns 禁用ipv6的解析

如果K8S集群宿主机没有关闭IPV6内核模块的话，容器请求coredns时的默认行为是同时发起IPV4和IPV6解析。
由于我们通常只使用IPV4地址，或者是你对主机环境暂无支持ipv6，那么实际的业务场景中，AAAA解析成功返回来的IPv6地址，是会访问失败的。如下：

2019/09/06 18:12:37 [error] 37#0: *265 connect() to [2404:6800:4003:c03::5f]:443 failed (101: Network is unreachable), client: 100.125.198.131, server: , request: "POST /user/google/signin HTTP/1.1", host: "user.inner.xxx.com"
2019/09/06 18:12:37 [error] 37#0: *265 [lua] http_util.lua:49: http_get(): http request error, url = https://www.googleapis.com/oauth2/v1/userinfo?access_token=ya29.Glt7B5qqIHMVkyJNSmE32jGAo-hkEgIyK2CzMcO0ksrXcCZSMts4VcBoY-uNQmXdEhb8QJQAhVsv-5LxESalKNiD7rJrBgYJgfV-z81No9a_vwW59RgBEvYJMAAr; request headers = null ; request body = ; error = network is unreachable, client: 100.125.198.131, server: , request: "POST /user/google/signin HTTP/1.1", host: "user.inner.xxx.com"

所以此时如果我们仅仅在coredns中配置DOMAIN -> IPV4地址的解析的话，当coredns收到IPV6解析请求的时候就会因为本地找不到配置而foward到upstream DNS服务器解析，从而导致容器的DNS解析请求变慢。
coredns提供了一种plugin叫做template，经过配置后可以给所有的IPV6请求立即返回一个空结果的应答，避免请求forward到上游DNS。
而对于业务来说，ipv6解析不成功，会降级到ipv4的A解析。
template插件默认是在coredns启用的，只需要在配置文件中添加如下配置即可：

template ANY AAAA {
    rcode NXDOMAIN
}

coredns 配置stub domain和upstream nameserver

在实际场景中，我们经常会有自己的内部dns服务器，例如我们的Consul域服务器位于10.150.0.1，并且所有Consul名称都具有后缀.consul.local。要在CoreDNS中配置它，集群管理员在CoreDNS ConfigMap中创建以下配置：

consul.local:53 {
        errors
        cache 30
        forward . 10.150.0.1
    }