作用

coreDNS的作用是在集群內(nèi)提供Service和Pod的域名解析服務(wù)敏沉。coreDNS會(huì)監(jiān)聽集群中Service和Pod的創(chuàng)建銷毀事件讯泣，當(dāng)Service或Pod被創(chuàng)建時(shí)系任，記錄對(duì)應(yīng)的解析記錄。當(dāng)其他Pod需要通過(guò)域名訪問(wèn)集群中的Service或Pod時(shí)择示，會(huì)向coreDNS服務(wù)查詢解析記錄播揪，然后訪問(wèn)解析到的IP地址。整個(gè)流程如下

image.png

K8S服務(wù)在部署好coreDNS服務(wù)后顾瞪，會(huì)對(duì)外暴露一個(gè)Service舔庶，集群內(nèi)就可以通過(guò)訪問(wèn)該Service的ClusterIP+53端口獲取域名解析服務(wù)。ClusterIP一般是固定的陈醒，在安裝kubelet時(shí)惕橙，會(huì)傳遞--cluster-dns=<cluster-ip> --cluster-domain=<default-local-domain>(默認(rèn)為cluster.local)參數(shù)給kubelet，kubelet在創(chuàng)建Pod時(shí)孵延，就會(huì)把這兩個(gè)配置寫入到Pod的/etc/resolv.conf文件中吕漂。
cat /etc/kubernetes/kubelet可以看到kubelet的配置亲配。

目前k8s支持正向查找（A記錄）尘应，端口查找（SRV記錄）惶凝，反向IP地址查找（PTR記錄）。

K8S中一般只有service和headless service后端的statefulset創(chuàng)建的Pod域名是固定的犬钢，其他Pod域名中都帶有Pod IP苍鲜，Pod重啟后IP改變域名也會(huì)改變，不推薦通過(guò)域名訪問(wèn)玷犹。

coreDNS配置說(shuō)明

Corefile配置

Corefile 是 CoreDNS 的配置文件混滔，它定義了：

• server 以什么協(xié)議監(jiān)聽在哪個(gè)端口（可以同時(shí)定義多個(gè) server 監(jiān)聽不同端口）
• server 負(fù)責(zé)哪個(gè) zone 的權(quán)威（authoritative）DNS 解析
• server 將加載哪些插件

Corefile的配置格式如下

zone:port {
 plugin1
 plugin2
}

其中zone表示監(jiān)聽的域名，可以是根域名.歹颓，頂級(jí)域名com等(一般省略前面的.)坯屿；port表示server提供服務(wù)的端口，未配置使用默認(rèn)的53端口巍扛。

server和端口是1對(duì)1的關(guān)系领跛，server和zone是1對(duì)多的關(guān)系，即一個(gè)server只監(jiān)聽一個(gè)端口撤奸，一個(gè)server可以負(fù)責(zé)多個(gè)zone的DNS解析吠昭。

正向解析

.: {
  log
  errors
}
com: {
  log
}
.:54 {
 log
}

上面的coreDNS配置表示，起兩個(gè)server胧瓜，一個(gè)監(jiān)聽53端口矢棚，提供根域和com域的解析，另一個(gè)監(jiān)聽54端口府喳，負(fù)責(zé)根域的解析蒲肋。

域名解析使用貪心算法。當(dāng)我們?cè)L問(wèn)53端口劫拢，請(qǐng)求www.baidu.com的解析時(shí)肉津，會(huì)匹配到第二個(gè)，即com域的解析舱沧。匹配成功后妹沙，開始執(zhí)行里面配置的插件，此處記錄一個(gè)log就結(jié)束了熟吏。

反向解析

in-addr.arpa （反向域名解析距糖，從IP地址到域名的映射)
　in-addr是inverse address, arpa 的標(biāo)準(zhǔn)名稱對(duì)應(yīng)為Address and Routing Parameter Area, 即“地址路由參數(shù)域”。
由于在域名系統(tǒng)中牵寺，一個(gè)IP地址可以對(duì)應(yīng)多個(gè)域名悍引，因此從IP出發(fā)去找域名，理論上應(yīng)該遍歷整個(gè)域名樹帽氓，但這在 Internet上是不現(xiàn)實(shí)的趣斤。為了完成逆向域名解析，系統(tǒng)提供一個(gè)特別域黎休，該特別域稱為逆向解析域in-addr.arpa浓领。這樣欲解析的IP地址就會(huì)被表達(dá)成一種像域名一樣的可顯示串形式玉凯，后綴以逆向解析域域名“in-addr.arpa”結(jié)尾。例如一個(gè)IP地址：218.30.103.170联贩，其逆向域名表達(dá)方式為：170.103.30.218.in-addr.arpa漫仆。兩種表達(dá)方式中IP地址部分順序恰好相反，因?yàn)橛蛎Y(jié)構(gòu)是自底向上(從子域到域)泪幌，而IP地址結(jié)構(gòu)是自頂向下(從網(wǎng)絡(luò)到主機(jī))的盲厌。實(shí)質(zhì)上逆向域名解析是將IP地址表達(dá)成一個(gè)域名，以地址做為索引的域名空間祸泪，這樣逆向解析的很大部分可以納入正向解析中吗浩。

coreDNS在K8S中的配置

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        log
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        hosts {
            10.20.31.104 www.google.com
            fallthrough
        }
        prometheus :9153
        forward . /etc/resolv.conf {
            prefer_udp
        }
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
......　

插件調(diào)用說(shuō)明

匹配域名后，會(huì)按照域內(nèi)的插件順序没隘，依次調(diào)用插件拓萌。插件處理邏輯有以下四種：

• 插件處理完成后，直接返回結(jié)果升略。如kubernetes微王，hosts，如果沒有加fallthrough品嚣，則調(diào)用結(jié)束本插件后炕倘，就返回了。
• 不被該插件處理翰撑，流轉(zhuǎn)到下一個(gè)插件罩旋，如果所有插件不處理，則返回錯(cuò)誤眶诈。
• 插件內(nèi)有fallthrough關(guān)鍵字涨醋，fallthrough到下一個(gè)插件。fallthrough關(guān)鍵字的含義是逝撬，繼續(xù)調(diào)用下一個(gè)插件處理浴骂。
• 插件處理后，打上hint宪潮，流轉(zhuǎn)到下一個(gè)插件溯警。

其他典型場(chǎng)景

• 特定域名使用自定義DNS服務(wù)器

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

• 外部域名完全使用自建DNS服務(wù)器

  Corefile: |
    .:53 {
...
        forward . 10.10.0.10 10.10.0.20{
          prefer_udp
        }
...
    }

• 禁止CoreDNS對(duì)IPv6類型的AAAA記錄查詢返回

  Corefile: |
    .:53 {
        errors
        health {
           lameduck 15s
        }
        #新增以下一行Template插件偏陪，其它數(shù)據(jù)請(qǐng)保持不變抢呆。
        template IN AAAA .
    
    }

• 統(tǒng)一域名訪問(wèn)服務(wù)或是在集群內(nèi)對(duì)域名的做CNAME解析

Corefile: |
    .:53 {
        errors
        health {
           lameduck 15s
        }
        ready
        
        rewrite stop {
          name regex 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
    }

此處的含義是請(qǐng)求域名符合正則表達(dá)式foo.example.com時(shí)，重定向到foo.default.svc.cluster.local處理笛谦；處理完返回時(shí)抱虐，把response的foo.default.svc.cluster.local改寫為foo.example.com，否則client端可能會(huì)認(rèn)為返回結(jié)果無(wú)效饥脑，因?yàn)閏lient請(qǐng)求的地址和接收到的answer的地址不是同一個(gè)恳邀，會(huì)認(rèn)為存在中間人攻擊。
rewrite的好處是灶轰，在公網(wǎng)（默認(rèn)使用域名foo.example.com）谣沸、內(nèi)網(wǎng)（默認(rèn)使用域名foo.example.com）、集群內(nèi)部（默認(rèn)使用域名foo.default.svc.cluster.local）笋颤，都可以使用同一個(gè)域名foo.example.com訪問(wèn)服務(wù)乳附。（前提：該服務(wù)在公網(wǎng)和內(nèi)網(wǎng)都通過(guò)LB暴露并綁定了域名。）
rewrite用法參考。

參考

https://www.cnblogs.com/zhangmingcheng/p/15680815.html
https://help.aliyun.com/document_detail/380963.html