一、CoreDNS简介：
从Kubernetes 1.11版本开始，Kubernetes集群的DNS服务由CoreDNS提供。CoreDNS是CNCF基金会的一个项目，是用Go语言实现的高性能、插件式、易扩展的DNS服务端。CoreDNS解决了KubeDNS的一些问题，例如dnsmasq的安全漏洞、externalName不能使用stubDomains设置，等等。
CoreDNS支持自定义DNS记录及配置upstream DNS Server，可以统一管理Kubernetes基于服务的内部DNS和数据中心的物理DNS。
CoreDNS没有使用多个容器的架构，只用一个容器便实现了KubeDNS内3个容器的全部功能。
二、Corefile介绍
从kubernetes官方提供的coredns.yml文件中，不难看出coredns服务配置至少需要一个ConfigMap、一个Deployment和一个Service共3个资源对象。ConfigMapcoredns主要配置文件Corefile的内容：
---
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
labels:
addonmanager.kubernetes.io/mode: EnsureExists
data:
Corefile: |
.:53 {
errors #错误信息标准输出
health { #在CoreDNS的http://localhost:8080/health端口提供CoreDNS服务的健康报告
lameduck 5s
}
ready #监听8181端口，当CoreDNS的插件都已就绪时，访问该接口会返回200OK
#CoreDNS将基于kubernetes.service.name进行DNS查询并返回查询记录给客户端
kubernetes cluster.local in-addr.arpa ip6.arpa { #修改成当时部署k8s时host文件里面CLUSTER_DNS_DOMAIN对应的值，我这里是cluster.local
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153 #度量指标数据以Prometheus的key-value的格式在http://localhost:9153/metrics URI 上提供
forward . /etc/resolv.conf { #不是kubernetes集群内的其他任务域名查询都将转发到预定义的目的server
max_concurrent 1000
}
cache 30 #启用servic解析缓存，单位为秒
loop #检测域名解析是否有死循环，如coredens转发给内网DNS服务器，而内网DNS服务器又转发给CoreDNS,如果发现死循环，则强制中止CoreDNS进程，kubernetes重建
reload #检测corefile是否更改，再重新编辑configmap配置后，默认2分钟后会优雅的自动加载
loadbalance #轮训DNS域名解析，如果一个域名存在多个记录则轮训解析
}
其中主要有二个地方来解析配置
1、这段配置的意思是cluster.local后缀的域名都是kubernetes内部域名，coredns会监控service的变化来修改域名的记录
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
2、如果coredns没有找到dns记录，则去找/etc/resolv.conf中的nameserver解析
forward . /etc/resolv.conf { #不是kubernetes集群内的其他任务域名查询都将转发到预定义的目的server
max_concurrent 1000
}
三、DNS解析举例
接下来使用一个带有nslookup工具的Pod来验证DNS服务能否正常工作：
3.1、查看集群是所有服务的信息
root@k8s-master1:~# kubectl get svc -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.100.0.1 443/TCP 18d
default ng-deploy-80 NodePort 10.100.245.174 81:30019/TCP 14d
kube-system kube-dns ClusterIP 10.100.0.2 53/UDP,53/TCP,9153/TCP 18d
kubernetes-dashboard dashboard-metrics-scraper ClusterIP 10.100.37.45 8000/TCP 18d
kubernetes-dashboard kubernetes-dashboard NodePort 10.100.227.64 443:30004/TCP 18d
myserver myserver-myapp-service-name NodePort 10.100.98.248 80:30080/TCP 79m
3.2、查找同命名空间的服务
通过nslookup进行测试。
查找defaul命名空间存在的ng-deploy-80服务
root@k8s-master1:~# kubectl exec -it -n default net-test1 bash
[root@net-test1 /]# nslookup ng-deploy-80
Server: 10.100.0.2
Address: 10.100.0.2#53
Name: ng-deploy-80.default.svc.cluster.local
Address: 10.100.245.174
#可以看到，通过DNS服务器10.100.0.2成功找到了ng-deploy-80服务的IP地址10.100.245.174
3.3、查找不同命名空间的服务
如果某个Service属于不同的命名空间，那么在进行Service查找时，需要补充Namespace的名称，组合成完整的域名。下面以查找kubernetes-dashboard服务为例，
#将其所在的Namespace“kube-system”补充在服务名之后，用“.”连接为“kubernetes-dashboard.kubernetes-dashboard”，即可查询成功：
[root@net-test1 /]# nslookup kubernetes-dashboard.kubernetes-dashboard
Server: 10.100.0.2
Address: 10.100.0.2#53
Name: kubernetes-dashboard.kubernetes-dashboard.svc.cluster.local
Address: 10.100.227.64
#完整的域名查找（结果同上）
[root@net-test1 /]# nslookup kubernetes-dashboard.kubernetes-dashboard.svc.cluster.local
Server: 10.100.0.2
Address: 10.100.0.2#53
Name: kubernetes-dashboard.kubernetes-dashboard.svc.cluster.local
Address: 10.100.227.64
3.4、查询公网域名
[root@net-test1 /]# nslookup www.baidu.com
Server: 10.100.0.2
Address: 10.100.0.2#53
Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 163.177.151.110
Name: www.a.shifen.com
Address: 163.177.151.109
四、DNS 策略及域名解析过程分析
4.1 DNS 策略
众所周知, DNS 服务器用于将域名转换为 IP (具体为啥要转换建议复习下 7 层网络模型). Linux 服务器中 DNS 解析配置位于/etc/resolv.conf, 在 Pod 中也不例外,
DNS 策略可以逐个 Pod 来设定。当前kubernetes支持这4中DNS 策略
- "
Default": Pod 从运行所在的节点继承名称解析配置。 - "
ClusterFirst": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "[www.kubernetes.io"）都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 - "
ClusterFirstWithHostNet"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 "ClusterFirstWithHostNet"。 - "
None": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其dnsConfig字段 所提供的 DNS 设置。
如果我们不填dnsPolicy, 默认策略就是ClusterFirst。
kubelet 在起 pause 容器的时候，会将其 DNS 解析配置初始化成集群内的配置。配置: 它的nameserver就是指向coredns的
[root@net-test1 /]# cat /etc/resolv.conf
nameserver 10.100.0.2
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
k8s里面有4种DNS策略， 而coredns使用的DNS策略就是Default， 这个策略的意思就是继承宿主机上的/etc/resolve.conf, 所以coredns Pod 里面的/etc/resolve.conf 的内容就是宿主机上的内容。
4.2 域名解析过程分析
在集群中 pod 之间互相用 svc name 访问的时候，会根据 resolv.conf 文件的 DNS 配置来解析域名，下面来分析具体的过程。
pod 的 resolv.conf 文件主要有三个部分，分别为 nameserver、search 和 option。而这三个部分可以由 K8s 指定，也可以通过 pod.spec.dnsConfig 字段自定义。
nameserver
resolv.conf 文件的第一行 nameserver 指定的是 DNS 服务的 IP，这里就是 coreDNS 的
clusterIP：
root@k8s-master1:~# kubectl get svc -n kube-system -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP 10.100.0.2 53/UDP,53/TCP,9153/TCP 18d k8s-app=kube-dns
也就是说所有域名的解析，都要经过coreDNS的虚拟IP 10.100.0.2进行解析， 不论是内部域还是外部域名。
search 域
resolv.conf 文件的第二行指定的是 DNS search 域。解析域名的时候，将要访问的域名依次带入 search 域，进行 DNS 查询。
比如我要在刚才那个 pod 中访问一个域名为 ng-deploy-80的服务，其进行的 DNS 域名查询的顺序是：
ng-deploy-80.default.svc.cluster.local -> ng-deploy-80.svc.cluster.local -> ng-deploy-80.cluster.local
options
resolv.conf 文件的第三行指定的是其他项，最常见的是 dnots。dnots 指的是如果查询的域名包含的点 “.” 小于 5，则先走 search 域，再用绝对域名；如果查询的域名包含点数大于或等于 5，则先用绝对域名，再走 search 域。K8s 中默认的配置是 5。
也就是说，如果我访问的是 a.b.c.e.f.g ，那么域名查找的顺序如下：
a.b.c.e.f.g. -> a.b.c.e.f.g.default.svc.cluster.local -> a.b.c.e.f.g.svc.cluster.local -> a.b.c.e.f.g.cluster.local
a.b.c.e.default.svc.cluster.local -> a.b.c.e.svc.cluster.local -> a.b.c.e.cluster.local -> a.b.c.e
五、pod 之间的通信
通过 svc 访问
在 K8s 中，Pod 之间通过 svc 访问的时候，会经过 DNS 域名解析，再拿到 ip 通信。而 K8s 的域名全称为 "
#查看svc
root@k8s-master1:~# kubectl get svc -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default kubernetes ClusterIP 10.100.0.1 443/TCP 18d
default ng-deploy-80 NodePort 10.100.245.174 81:30019/TCP 14d
kube-system kube-dns ClusterIP 10.100.0.2 53/UDP,53/TCP,9153/TCP 18d
kubernetes-dashboard dashboard-metrics-scraper ClusterIP 10.100.37.45 8000/TCP 18d
kubernetes-dashboard kubernetes-dashboard NodePort 10.100.227.64 443:30004/TCP 18d
myserver myserver-myapp-service-name NodePort 10.100.98.248 80:30080/TCP 130m
#进入pod
root@k8s-master1:~# kubectl exec -it -n default net-test1 bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
#同名称空间测试
[root@net-test1 /]# wget kubernetes
--2022-05-14 13:42:44-- http://kubernetes/
Resolving kubernetes (kubernetes)... 10.100.0.1
Connecting to kubernetes (kubernetes)|10.100.0.1|:80... failed: Connection refused.
[root@net-test1 /]# wget ng-deploy-80
--2022-05-14 13:43:30-- http://ng-deploy-80/
Resolving ng-deploy-80 (ng-deploy-80)... 10.100.245.174
Connecting to ng-deploy-80 (ng-deploy-80)|10.100.245.174|:80... failed: Connection refused.
#不同名称空间测试
[root@net-test1 /]# wget kubernetes
--2022-05-14 13:43:38-- http://kubernetes/
Resolving kubernetes (kubernetes)... 10.100.0.1
Connecting to kubernetes (kubernetes)|10.100.0.1|:80... failed: Connection refused.
[root@net-test1 /]# wget kube-dns
--2022-05-14 13:44:01-- http://kube-dns/
Resolving kube-dns (kube-dns)... failed: Name or service not known.
wget: unable to resolve host address 'kube-dns'
#要加上名称空间才行
[root@net-test1 /]# wget kube-dns.kube-system
--2022-05-14 13:44:09-- http://kube-dns.kube-system/
Resolving kube-dns.kube-system (kube-dns.kube-system)... 10.100.0.2
Connecting to kube-dns.kube-system (kube-dns.kube-system)|10.100.0.2|:80... failed: Connection refused.
参考
（1）K8S落地实践 之 服务发现（CoreDNS）
https://blog.51cto.com/u_12965094/2641238
（2）自定义 DNS 服务
https://kubernetes.io/zh/docs/tasks/administer-cluster/dns-custom-nameservers/
（3）Kubernetes 服务发现之 coreDNS
https://juejin.cn/post/6844903965520297991
（4）Kubernetes 集群 DNS 服务发现原理
https://developer.aliyun.com/article/779121
（5）Kubernetes之服务发现和域名解析过程分析
https://www.jianshu.com/p/80ad7ff37744